My Windows application includes a service that loads a rather simple driver. This driver contains embedded SHA1 as well as SHA256 signatures and includes a cross-signing certificate chain for both of them, as per the KMCS requirements described in the MS Kernel Signing doc for signing a driver without a CAT file.
The driver loads perfectly fine on most Windows installations but fails to load in some rare cases, mostly on Windows 7 x64 and Windows 10 x64. The error is 0x241 (577): 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 damaged, or that might be malicious software from an unknown source.
I've been trying to figure out what might be the cause of this problem for the better part of two weeks. As you'd expect, this error only comes up on the user's machines. I have installed 4 VMs with Windows 7 x64 and another 4 VMs with Windows 10 x64 in various configurations and with various levels of updates. I went as far as completely reproducing a user's setup in one of the Windows 10 VMs - I spent a whole day installing the exact Windows edition with the right language and with all the software they had down to the precise version in an attempt to reproduce the problem. No such luck, though: when installing my application, the driver loaded perfectly fine.
In the hope that someone might have an idea of what might be going on or could at least point me in the right direction, I decided to ask here: what could possibly be causing a driver that is apparently correctly signed to fail validation on some Windows installations?
I am using a StartCom Class 3 Code Signing certificate. I downloaded the cross-signing StartCom certificate from the Microsoft Cross-Certificates for Kernel Mode Code Signing page.
My certificate is in a pfx file and I am signing the driver as follows:
signtool.exe sign /v /ac "MS_xs_st.crt" /d "Driver description" /du "https://webpage/" /f my_certificate.pfx /t http://timestamp.verisign.com/scripts/timstamp.dll /p %1 driver.sys
signtool.exe sign /v /ac "MS_xs_st.crt" /d "Driver description" /du "https://webpage/" /f my_certificate.pfx /fd sha256 /tr http://timestamp.comodoca.com/?td=sha256 /td sha256 /as /p %1 driver.sys
Since this is not a hardware driver that would need to be installed, it does not include a .CAT file or .INF file. It's simply a driver that gets loaded when the service starts and unloaded when the service stops.
As it can be noticed, the SHA256 signature is added after the SHA1 signature (with /as) and it also uses an SHA256 timestamping server. It is dual signed for compatibility with older operating systems, although I must say it fails to load in Vista x64, presumably because my certificate is using SHA256 as the signature algorithm. It's worth noting that the driver loads fine on Windows XP x64. It's also worth mentioning that all users for whom it failed to load report that both signatures are validated fine when inspecting the Digital Signature tab of the file properties. I can live without Vista x64 compatibility, but the Windows 7 and Windows 10 problems are very worrying and force me to keep the application in beta testing.
Out of some 150+ installs across various Windows versions, I've had:
Every time the driver fails to load, an Audit Failure event is generated in the Security event category with the text: *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.
File Name: \Device\HarddiskVolumeX\Program Files (x86)\path\to\driver.sys*
I get exactly the same error in Vista x64 and enabling the Code Integrity verbose log results in a lot of messages about loading all the .CAT files and nothing else of interest. Naturally, in Vista x64 the Code Integrity operational log includes an Error about the file not getting validated, rather similar to the Audit Error above.
Running
signtool.exe verify /v /kp driver.sys
Results in:
Verifying: driver.sys
Signature Index: 0 (Primary Signature)
Hash of file (sha1): EE2FE2A16395DC66ACCB5264742987D99ECF5A66
Signing Certificate Chain:
Issued to: StartCom Certification Authority
Issued by: StartCom Certification Authority
Expires: Wed Sep 17 22:46:36 2036
SHA1 hash: 3E2BF7F2031B96F38CE6C4D8A85D3E2D58476A0F
Issued to: StartCom Class 3 Object CA
Issued by: StartCom Certification Authority
Expires: Mon Dec 16 04:00:05 2030
SHA1 hash: E181101EE744817E49B6F97466E14DFA0809BD46
Issued to: My company
Issued by: StartCom Class 3 Object CA
Expires: Sun Aug 04 16:18:18 2019
SHA1 hash: 62...E9
The signature is timestamped: Sun Sep 25 12:49:52 2016
Timestamp Verified by:
Issued to: Thawte Timestamping CA
Issued by: Thawte Timestamping CA
Expires: Fri Jan 01 02:59:59 2021
SHA1 hash: BE36A4562FB2EE05DBB3D32323ADF445084ED656
Issued to: Symantec Time Stamping Services CA - G2
Issued by: Thawte Timestamping CA
Expires: Thu Dec 31 02:59:59 2020
SHA1 hash: 6C07453FFDDA08B83707C09B82FB3D15F35336B1
Issued to: Symantec Time Stamping Services Signer - G4
Issued by: Symantec Time Stamping Services CA - G2
Expires: Wed Dec 30 02:59:59 2020
SHA1 hash: 65439929B67973EB192D6FF243E6767ADF0834E4
Cross Certificate Chain:
Issued to: Microsoft Code Verification Root
Issued by: Microsoft Code Verification Root
Expires: Sat Nov 01 16:54:03 2025
SHA1 hash: 8FBE4D070EF8AB1BCCAF2A9D5CCAE7282A2C66B3
Issued to: StartCom Certification Authority
Issued by: Microsoft Code Verification Root
Expires: Thu Apr 15 23:23:19 2021
SHA1 hash: E6069E048DEA8D817AFC4188B1BEF1D888D0AF17
Issued to: StartCom Class 3 Object CA
Issued by: StartCom Certification Authority
Expires: Mon Dec 16 04:00:05 2030
SHA1 hash: E181101EE744817E49B6F97466E14DFA0809BD46
Issued to: My company
Issued by: StartCom Class 3 Object CA
Expires: Sun Aug 04 16:18:18 2019
SHA1 hash: 62...E9
Successfully verified: driver.sys
Number of files successfully Verified: 1
Number of warnings: 0
Number of errors: 0
Running
signtool.exe verify /v /pa /all driver.sys
Results in:
Verifying: driver.sys
Signature Index: 0 (Primary Signature)
Hash of file (sha1): EE2FE2A16395DC66ACCB5264742987D99ECF5A66
Signing Certificate Chain:
Issued to: StartCom Certification Authority
Issued by: StartCom Certification Authority
Expires: Wed Sep 17 22:46:36 2036
SHA1 hash: 3E2BF7F2031B96F38CE6C4D8A85D3E2D58476A0F
Issued to: StartCom Class 3 Object CA
Issued by: StartCom Certification Authority
Expires: Mon Dec 16 04:00:05 2030
SHA1 hash: E181101EE744817E49B6F97466E14DFA0809BD46
Issued to: My company
Issued by: StartCom Class 3 Object CA
Expires: Sun Aug 04 16:18:18 2019
SHA1 hash: 62...E9
The signature is timestamped: Sun Sep 25 12:49:52 2016
Timestamp Verified by:
Issued to: Thawte Timestamping CA
Issued by: Thawte Timestamping CA
Expires: Fri Jan 01 02:59:59 2021
SHA1 hash: BE36A4562FB2EE05DBB3D32323ADF445084ED656
Issued to: Symantec Time Stamping Services CA - G2
Issued by: Thawte Timestamping CA
Expires: Thu Dec 31 02:59:59 2020
SHA1 hash: 6C07453FFDDA08B83707C09B82FB3D15F35336B1
Issued to: Symantec Time Stamping Services Signer - G4
Issued by: Symantec Time Stamping Services CA - G2
Expires: Wed Dec 30 02:59:59 2020
SHA1 hash: 65439929B67973EB192D6FF243E6767ADF0834E4
Signature Index: 1
Hash of file (sha256): 79E9A2EF552906EA10F56FF7B2F95A1999B52902BCD9B78DD076157B563E900B
Signing Certificate Chain:
Issued to: StartCom Certification Authority
Issued by: StartCom Certification Authority
Expires: Wed Sep 17 22:46:36 2036
SHA1 hash: 3E2BF7F2031B96F38CE6C4D8A85D3E2D58476A0F
Issued to: StartCom Class 3 Object CA
Issued by: StartCom Certification Authority
Expires: Mon Dec 16 04:00:05 2030
SHA1 hash: E181101EE744817E49B6F97466E14DFA0809BD46
Issued to: My company
Issued by: StartCom Class 3 Object CA
Expires: Sun Aug 04 16:18:18 2019
SHA1 hash: 62...E9
The signature is timestamped: Sun Sep 25 12:49:53 2016
Timestamp Verified by:
Issued to: UTN-USERFirst-Object
Issued by: UTN-USERFirst-Object
Expires: Tue Jul 09 21:40:36 2019
SHA1 hash: E12DFB4B41D7D9C32B30514BAC1D81D8385E2D46
Issued to: COMODO SHA-256 Time Stamping Signer
Issued by: UTN-USERFirst-Object
Expires: Tue Jul 09 21:40:36 2019
SHA1 hash: 36527D4FA26A68F9EB4596F1D99ABB2C0EA76DFA
Successfully verified: driver.sys
Number of signatures successfully Verified: 2
Number of warnings: 0
Number of errors: 0
What is a bit strange is that verifying with no special switches results in certificate chain errors. Then again, I get the same error when checking a VMWare driver so I guess it's not something to worry about. In any case, running:
signtool.exe verify /v /all driver.sys
Results in:
Verifying: driver.sys
Signature Index: 0 (Primary Signature)
Hash of file (sha1): EE2FE2A16395DC66ACCB5264742987D99ECF5A66
Signing Certificate Chain:
Issued to: StartCom Certification Authority
Issued by: StartCom Certification Authority
Expires: Wed Sep 17 22:46:36 2036
SHA1 hash: 3E2BF7F2031B96F38CE6C4D8A85D3E2D58476A0F
Issued to: StartCom Class 3 Object CA
Issued by: StartCom Certification Authority
Expires: Mon Dec 16 04:00:05 2030
SHA1 hash: E181101EE744817E49B6F97466E14DFA0809BD46
Issued to: My company
Issued by: StartCom Class 3 Object CA
Expires: Sun Aug 04 16:18:18 2019
SHA1 hash: 62...E9
The signature is timestamped: Sun Sep 25 12:49:52 2016
Timestamp Verified by:
Issued to: Thawte Timestamping CA
Issued by: Thawte Timestamping CA
Expires: Fri Jan 01 02:59:59 2021
SHA1 hash: BE36A4562FB2EE05DBB3D32323ADF445084ED656
Issued to: Symantec Time Stamping Services CA - G2
Issued by: Thawte Timestamping CA
Expires: Thu Dec 31 02:59:59 2020
SHA1 hash: 6C07453FFDDA08B83707C09B82FB3D15F35336B1
Issued to: Symantec Time Stamping Services Signer - G4
Issued by: Symantec Time Stamping Services CA - G2
Expires: Wed Dec 30 02:59:59 2020
SHA1 hash: 65439929B67973EB192D6FF243E6767ADF0834E4
SignTool Error: A certificate chain processed, but terminated in a root
certificate which is not trusted by the trust provider.
Signature Index: 1
Hash of file (sha256): 79E9A2EF552906EA10F56FF7B2F95A1999B52902BCD9B78DD076157B563E900B
Signing Certificate Chain:
Issued to: StartCom Certification Authority
Issued by: StartCom Certification Authority
Expires: Wed Sep 17 22:46:36 2036
SHA1 hash: 3E2BF7F2031B96F38CE6C4D8A85D3E2D58476A0F
Issued to: StartCom Class 3 Object CA
Issued by: StartCom Certification Authority
Expires: Mon Dec 16 04:00:05 2030
SHA1 hash: E181101EE744817E49B6F97466E14DFA0809BD46
Issued to: My company
Issued by: StartCom Class 3 Object CA
Expires: Sun Aug 04 16:18:18 2019
SHA1 hash: 62...E9
The signature is timestamped: Sun Sep 25 12:49:53 2016
Timestamp Verified by:
Issued to: UTN-USERFirst-Object
Issued by: UTN-USERFirst-Object
Expires: Tue Jul 09 21:40:36 2019
SHA1 hash: E12DFB4B41D7D9C32B30514BAC1D81D8385E2D46
Issued to: COMODO SHA-256 Time Stamping Signer
Issued by: UTN-USERFirst-Object
Expires: Tue Jul 09 21:40:36 2019
SHA1 hash: 36527D4FA26A68F9EB4596F1D99ABB2C0EA76DFA
SignTool Error: A certificate chain processed, but terminated in a root
certificate which is not trusted by the trust provider.
Number of signatures successfully Verified: 0
Number of warnings: 0
Number of errors: 2
I am using signtool.exe from the 8.1 Windows kit that ships with VS 2015, its version is 6.3.9600.17298. For what it's worth, the driver is compiled with WDK 7.1.0 (7600.13685.1).
As Martin Drab posted above, the problem is twofold. By the way, thanks Martin, your comment helped me sort it out, I was able to reproduce the Windows 10 problem by setting up a VM with Secure Boot enabled.
For operating systems older than Windows 10, the problem seems to be fixed by installing all the latest updates. If the PC wasn't updated since before 01.11.2015 (when the new Microsoft Code Verification Root certificate was issued), it won't be able to validate because the kernel doesn't recognize the root certificate.
For Windows 10 there is a new Kernel Mode Code Signining Policy that specifies that all fresh installations of Windows 10 Anniversary Edition will not validate any kernel code that is not signed by the Microsoft Dev Portal (which requires an EV certificate) unless it was signed with a cross-signing certificate issued prior to July 29th 2015 or Secure Boot is disabled.
The reason the problem was only occurring rarely is that most people don't have Windows 7 machines that haven't been updated in ages and most of those that have Windows 10 at the time of this writing aren't using fresh installs of the Anniversary Edition.
The only real solution for Windows 10 is to get an EV certificate.