Windows Server 2016 /2019 ---Windows 10 Kernel Driver Signing

We are having issues with a hardware "composite bus" driver. The driver needed for Windows Server 2016 and Windows Server 2019 does not exist in the out of the box install in either OS. However the Windows Server 2012 R2 included the required driver package in the OS install. The driver in question was exported from the Server 2012 R2 install and currently requires a Version Update --number change --and new CA and Digital Signature to be created. We signed digitally the driver with "authenticode", which works for a Windows 2012 install but does not pass Server 2016 or Server 2019 requirements of needing a "MICROSOFT SIGNED" DRIVER. So, an original MS Driver needs to have a CA and Digital Signature created --FOR LOCAL USE /TESTING "Let’s take a step back and look at the requirements of the different versions of Windows. Microsoft’s Driver Signing Policy stipulates that, for Windows 7 64-bit, Windows 8 and Windows 10 up to version 1511, a driver must be signed with SHA1 and the certificate used must come from a CA that is on Microsoft’s Cross-Certificate List. For Windows 10 versions 1607 to 1709, SHA1 or SHA2 is allowed as the signature algorithm, while only SHA2 is allowed from Windows 10 version 1803 and higher. The signature must come from a Microsoft root authority too. In other words, a new installation of Windows 10 version 1607 will no longer load new kernel drivers that have not been signed by the Hardware Dev Center. These changes were described in detail in the blog article entitled Driver Signing changes in Windows 10, version 1607. In the interests of backward compatibility, Microsoft defined exceptions so that not all drivers have to be re-signed: Computers deployed before Windows 10 version 1607 and updated since then still allow the installation of cross-signed drivers Computers without secure boot still allow the installation of cross-signed drivers Drivers with the signature of a certificate issued before 7/29/2015 that contains a supported cross-signed CA in the certificate chain are still allowed This means that all new drivers for current Windows 10 versions must therefore be signed with an EV CS certificate, then validated by the Windows Hardware Developer Center, then signed by Microsoft." "Signing a driver Microsoft offers a comprehensive Windows Driver Signing Tutorial, which includes instructions for implementing a test signature. However, you will need to boot the operating system in a special mode to deactivate the driver signature enforcement option for the session. You can then create your own certificate and use it to sign and load drivers. These steps can be useful for initial attempts and tests. However, self-signed drivers cannot be used on external machines with current Windows versions. "You will need the Windows Driver Kit (WDK) to sign drivers. The most important tool in the WDK is the SignTool. It is used for signing and potentially verifying drivers. Microsoft advises against using a certificate file (PFX) for signature purposes; instead, it recommends importing the certificate into the operating system’s certificate store and then performing the signature process. Additionally, an EV CS certificate is delivered on a USB token or smartcard rather than a PFX file." "Kernel-Mode Code Signing Requirements during Development and Test 64-bit versions of Windows starting with Windows Vista The kernel-mode code signing policy requires that a kernel-mode driver be test-signed and that test-signing is enabled. A test signature can be a WHQL test signature or generated in-house by a test certificate. Drivers must be test-signed as follows: A kernel-mode boot-start driver must have an embedded test signature. This applies to any type of PnP or non-PnP kernel-mode driver. A kernel-mode driver that is not a boot-start driver must have either a test-signed catalog file or the driver file must include an embedded test signature. This applies to any type of PnP or non-PnP kernel-mode driver.