> What I previously read was dual signing a driver with the command below would make it
compatible with Windows Vista to Windows 10 (included).
signtool.exe sign /t http://timestamp.digicert.com /sha1 XXXSHA1THUMBPRINT driver.sys
signtool.exe sign /tr http://timestamp.digicert.com /td sha256 /fd sha256 /as /sha1 XXXSHA256THUMBPRINT driver.sys
The primary thing missing from these command lines is the kernel-mode
signing cross-certificate parameters.
That’s the “Downloading the Code Signing Cross-Certificate” and
/AC-involved command lines shown in “Using Your Standard Kernel-Mode
Code Signing Certificate” sections in DigiCert’s walk through:
https://www.digicert.com/code-signing/driver-signing-in-windows-using-signtool.htm#download_cross_certificate
The command lines you’ve posted here are correct, but are appropriate
for code signing a .DLL or .EXE file and not a kernel-mode driver.
Note you can and probably should continue to use the /SHA1 THUMBPRINT
certificate selection instead of the /A auto-selection shown in the
DigiCert example.
You will need to continue providing an SHA1 code signing certificate
(in addition to your SHA256 certificate) so long as you continue to
target the pre-Windows 7 SP1 platforms. Or alternatively, you would
need to do the appropriate WLK testing (not HCK or HLK) and submission
to have Microsoft sign them using Microsoft’s SHA1 certificate to
satisfy those platforms.
As a side note, Microsoft Driver Signing Policy states that SHA2 signature
is only required on Windows 10, version 1607+ with Secure Boot on and SHA1
is required all previous versions.
That table seems to be describing “supported” rather than “required”,
else “SHA1 or SHA2” in the 1607+ Secure Boot column doesn’t make a lot
of sense. Seems like all columns should say “SHA1 or SHA2” at this
point. Using an SHA1 certificate is certainly not recommended or a
best practice any more.
(Note if you have an SHA1 certificate issues prior to July 2015,
Windows 10 is intentionally grandfathering those signatures. I’m not
aware of what Windows 10 would do with an SHA1-only signed driver
using a certificate issued more recently. But its being worded as
though they may become unrecognized in the future, if not already.
https://docs.microsoft.com/en-us/windows-hardware/drivers/dashboard/get-a-code-signing-certificate)
That document is also unclear in asserting “Starting with Windows 10,
version 1607, Windows will not load any new kernel mode drivers which
are not signed by the Dev Portal.” That statement means “when Secure
Boot is enabled.” So as a driver publisher, “to not ignore any
segment of Windows 10 customers” you need to have a Microsoft-signed
driver for Windows 10 1607 and later. But that’s still different than
saying “a non-Microsoft signed driver won’t run on Windows 10 1607 and
later”, which isn’t true.
The document’s statement of “Windows Server does not load attestation
signed drivers” is also not true. (Yet.) Current shipping Windows
Server 2016 versions continue to load attested signed drivers.
Alan Adams
Client for Open Enterprise Server
Micro Focus
xxxxx@microfocus.com