Code Signed Driver on Windows 7 Fails with 0xC0000428

[Sarah M Weinberger]

My signed driver yields a Windows (Windows 7 with the SHA256 hot fix) that fails to start and yields error code 0xC0000428 (Windows cannot verify the digital signature for this file).



I took over a driver project, created using Visual Studio 2010, and my first task was to update the expired code signing certificate. Originally the digital certificate was with Global Sign and now using Digi Cert. The original programmer stated on an email to me that he has trouble with this topic every year.

I examined the working but expired `icsflt.sys` driver file and see that it is SHA256 with the thumbprint being SHA1. Everything else works. I tried many different variations (dual signed certificate, SHA1, and SHA2). My last attempt, straight from Digi Cert technical support uses the following command line.

C:\ICS\IM6000\Certificate>"C:\Program Files (x86)\Windows Kits\8.1\bin\x64\signtool.exe" sign /tr http://timestamp.digicert.com /td sha256 /fd sha256 /a "C:\ICS\IM6000\filter\objfre_win7_AMD64\amd64\icsflt.sys"
Done Adding Additional Store
Successfully signed: C:\ICS\IM6000\filter\objfre_win7_AMD64\amd64\icsflt.sys

Here is the certificate, which looks similar to the original one.



Here is the base certificate clearly showing SHA256 for the digest algorithm. The certificates are from the build machine. The first screenshot of the "Windows Boot Manager" is from the test machine.



Here are some of the links that I used from Digi Certs website.

1. Dual Signing SHA256 and SHA1
2. Sign Code SignTool.exe Command Line
3. Installing Code Signing Certificate
   

Here is the working expired certificate view.



Here is the driver properties Digital Signature for the good/working driver.




You can tell them apart, as I renamed the good/working one `icflt-good.sys`. Aside from the company name, dates, and Certificate Authority (CA) the two look identical, yet Windows 7 barks on the new one from Digi Cert.

Here is the code to the previous `signtool.exe` command lines, which I commented out.

@echo on

@REM see "How to Release-Sign a Driver Package" and "Release-Signing a Driver through an Embedded Signature in Windows DDK"
@REM despite the store's name seems to be Personal we should use MY when using Signtool. Otherwise the certificate is not found.
@REM when Personal store is created with makecert, another Personal is created. Weird.
@REM Signtool sign /v /ac MSCV-GlobalSign.cer /s MY /sha1 5250f1a5ddd11e3e4e924757e6da1c43dd3487c0 /t RFC 3161 Compliance %mydriverpath%
@REM Signtool sign /v /ac MSCV-GlobalSign.cer /s MY /sha1 5D743B02DCDE74B16D133BDFEB2E1C5F6F44E966 /t RFC 3161 Compliance %mydriverpath%

@REM check $\IM6000\Certificate\current for the exact file names and password
@REM Signtool sign /v /ac %PROJECT_DIR%\..\Certificate\current\MSCV-GlobalSign.cer /f %PROJECT_DIR%\..\Certificate\current\OS201602156091.pfx /p 1C73295775925A7EE1C6D35ADF9DF611A55A60B8 /t RFC 3161 Compliance %mydriverpath%
@REM Signtool sign /v /ac %PROJECT_DIR%\..\Certificate\current\GlobalSignRootCA.crt /f %PROJECT_DIR%\..\Certificate\current\OS201701106786.pfx /p ICScertificate2017 /t RFC 3161 Compliance %mydriverpath%
@REM Signtool sign /v /fd sha256 /ac %PROJECT_DIR%\..\Certificate\current\GlobalSignRootCA.crt /f %PROJECT_DIR%\..\Certificate\current\OS201701106786.pfx /p ICScertificate2017 /tr RFC 3161 Compliance /td sha256 %mydriverpath%

Continue reading...