I had to make a minor update to a driver that works from Vista or later - hasn’t been an update for a couple years. My normal process is to submit the Win10+ driver to MS for signing and using the crossed-signed-certificate for the older Windows OS versions. However, today I tried the process with my new EV certificate received July 2022 (prior one expired) and the cross-signing no longer would work.
I went to look for an updated cross-signing certificate but found they stopped issuing one. Ugh, so now the question is, how do I sign for the older OSes ? Right now I only care about Win7, my other drivers that work from NT4 onward were already running in to nobody issuing SHA1 certificates for those OSes that required signing but didn’t support SHA256 (I could create a self-signed one and provide root certificate but didn’t help for drivers which needed to be cross-signed). When I use MS system for signing, there is no Win7 option, it’s all Win10+ from what I recall (unless I don’t understand what all the weird versions list there are?).
The bottom line question is, how do I sign drivers for Win7?
Well Win7 UI sees it as signed and valid so maybe it will just work? But then, why do we have to tick all those boxes when signing? - I think I know, the CAT file … so why can’t they offer a Win7 / Vista option which may support SHA-2?
Signature Index: 0 (Primary Signature)
Hash of file (sha256): 2148A71E5EF84643B11A1A528E421B3860D2D07831FB7BCECA9D0E5DE7B4AC43
Signing Certificate Chain:
Issued to: Microsoft Root Certificate Authority 2010
Issued by: Microsoft Root Certificate Authority 2010
Expires: Sun Jun 24 06:04:01 2035
SHA1 hash: 3B1EFD3A66EA28B16697394703A72CA340A05BD5
Issued to: Microsoft Windows Third Party Component CA 2014
Issued by: Microsoft Root Certificate Authority 2010
Expires: Tue Oct 16 04:41:27 2029
SHA1 hash: 1906DCF62629B563252C826FDD874EFCEB6856C6
Issued to: Microsoft Windows Hardware Compatibility Publisher
Issued by: Microsoft Windows Third Party Component CA 2014
Expires: Fri Dec 03 06:25:28 2021
SHA1 hash: 984E03B613E8C2AE9C692F0DB2C031BF3EE3A0FA
The signature is timestamped: Sat Nov 13 19:54:14 2021
Timestamp Verified by:
Issued to: Microsoft Root Certificate Authority 2010
Issued by: Microsoft Root Certificate Authority 2010
Expires: Sun Jun 24 06:04:01 2035
SHA1 hash: 3B1EFD3A66EA28B16697394703A72CA340A05BD5
Issued to: Microsoft Time-Stamp PCA 2010
Issued by: Microsoft Root Certificate Authority 2010
Expires: Wed Jul 02 05:46:55 2025
SHA1 hash: 2AA752FE64C49ABE82913C463529CF10FF2F04EE
Issued to: Microsoft Time-Stamp Service
Issued by: Microsoft Time-Stamp PCA 2010
Expires: Thu Jan 13 01:28:25 2022
SHA1 hash: A04C15E8F4C630938C2935B1375329AF93CC90D4
Cross Certificate Chain:
Issued to: Microsoft Root Certificate Authority 2010
Issued by: Microsoft Root Certificate Authority 2010
Expires: Sun Jun 24 06:04:01 2035
SHA1 hash: 3B1EFD3A66EA28B16697394703A72CA340A05BD5
Issued to: Microsoft Windows Third Party Component CA 2014
Issued by: Microsoft Root Certificate Authority 2010
Expires: Tue Oct 16 04:41:27 2029
SHA1 hash: 1906DCF62629B563252C826FDD874EFCEB6856C6
Issued to: Microsoft Windows Hardware Compatibility Publisher
Issued by: Microsoft Windows Third Party Component CA 2014
Expires: Fri Dec 03 06:25:28 2021
SHA1 hash: 984E03B613E8C2AE9C692F0DB2C031BF3EE3A0FA
Looks like this would work for all the older OSes:
“Drivers can still be signed with a 3rd party issued code signing certificate. However, the certificate that signed the driver must be imported into the Local Computer Trusted Publishers certificate store on the target computer. See Trusted Publishers Certificate Store for more information.”
The catch22 is, had I written a utility to do that and signed it in the past with both certificates (SHA1/SHA2) it would work, but a new utility couldn’t be signed with something the an old OS supports.
“Drivers can still be signed with a 3rd party issued code signing certificate. However, the certificate that signed the driver must be imported into the Local Computer Trusted Publishers certificate store on the target computer. See Trusted Publishers Certificate Store for more information.”
Unfortunately it’s not working on my test of a Win7 x64 (6.1 build 7601: SP 1) - ensured it was in localmachine store, even put the “DigiCert Trusted Root G4” (which is top of my EV certificate) in the Trusted Root Certification Authority store, no change.
net start drivername
“Windows cannot verify the digital signature for this file. A recent hardware or
software change might have installed a file that is signed incorrectly or damage
d, or that might be malicious software from an unknown source.”
Turns out you have to enable testing mode in Win7 to use driver that is not crossed signed. So scratch that. What about the VHLK, can that be used to create whatever is needed to get Win7/Vista driver signed? I read somewhere that the HCK/HLK method would end Jan 2023, so I don’t want to waste my time with all the complicated stuff when all I want to do is sign something. Would me setting up another system with the date set way back to sign things without a timestamp work or is a signed timestamp needed? Or better, can someone convince MS to add the tick boxes for the catalog to support vista/win7 (and server equivalents) - It’s the same driver that works in Win10. Also be nice to allow SHA1 for older OS (signed MS SHA1) - since all the new Windows versions ignore SHA1 anyway, generating one for old OS that needs them isn’t a security issue. That would solve everything!
The timestamp is needed or says expired. Win7 is still widely used. I forgot about Win8.x but signing would cover those as well. Between Win 8/7 it is 15 to 20% of the install base.
Have you solved this puzzle?
I’m in a similar situation now - need to update our old WFP callout driver. And we still have a pretty large customer base who use pre-8.1 systems.
Using DefaultInstall INF installation, not P&P, no hardware device.
Ensured that our Win7/8 test systems have SHA-2 updates installed, nonetheless EV-attestation signed drivers can’t load - same “net start” error as above. Also there’s a record in the Windows Security log, generated by System process: “Code integrity determined that the image hash of a file is not valid. The file could be corrupt due to unauthorized modification or the invalid hash could indicate a potential disk device error.” As if the kernel does not see sha256 hashes.