I am trying to code sign a driver in Windows (drivers for a video capture card). I have the inf, cat, sys files for this driver. I have followed various Windows articles and so far am able to:
1) Download a "DER" file from GoDaddy and then create a "mycompanyinc.cer"
2) Use signtool to sign the .cat, .sys drivers
3) verified the .cat, .sys driver files are updated with digital certifiates.They correctly stated that its issued to "my company" and issued by "go daddy CA". I exported the above certificate to a ".cer" and put on a different computer
I used MMC to make sure it shows up in the Trusted Root Certificate Authorities on the system where I need to install the drivers. While there driver file shows correctly the information "issued by" ,"issued to" etc. Windows is still complaining during drivers install that the digital signature can't be verified.
Any help, direction in this matter will be greatly appreciated.
thanks!
Since 2016 Microsoft require a longer process along with an EV Code Signing Certificate for signing drivers.
They explain it in this article.
Related
I am reading Microsoft documentation on how to sign a driver for windows 10 X64 and I am getting different information from the Microsoft website.
This document explains how to sign a driver by the developer without the need to send it to Microsoft.
This document explains how to submit the driver to Microsoft for signing.
and on other sites, the information is very different.
I need to sign my driver which I will send alongside my hardware to the user (so no need to be part of the windows update).
How can I sign it? which procedures should I follow and which certificate should I buy?
Microsoft deprecated cross-signing certificates, however, it's not clear from the docs what's the new procedure.
From the docs above MS is the sole provider but their support claims you can still get one from other vendors (e.g. Digicert, Globalsign, etc...)
Does anybody know what's the process for signing production kernel drivers for Windows 11 & 10?
Any help would be appreciated,
Thanks!
I haven't done it myself, but if you want to make a kernel module for Windows 10 or 11 I think you're supposed to use "attestation signing". The page you linked to has a link named "attestation signing" that goes here:
https://learn.microsoft.com/en-us/windows-hardware/drivers/dashboard/attestation-signing-a-kernel-driver-for-public-release
Basically you make a driver, sign it with an EV certificate from a certificate authority, and then you submit to be checked and signed by Microsoft using a website called the "Hardware Developer Center Dashboard portal". I have also seen Microsoft use some other names for the website: "Hardware Dev Center Dashboard" and "Partner Center".
You don't need to use the portal if you are making a simple INF-only driver, or you are using a kernal module that is part of Windows, or you are using a kernel module that was already signed properly by another party.
Here is the original announcement from 2015 introducing the portal:
https://techcommunity.microsoft.com/t5/windows-hardware-certification/driver-signing-changes-in-windows-10/ba-p/364859
There's more info in this long article I wrote: https://www.davidegrayson.com/signing/
I'm trying to load a kernel driver that's been signed with a certificate generated by MakeCert.exe.
I followed the instructions given in the Windows Driver Kit documentation:
Sign the driver with MakeCert.exe
Verify the signature with SignTool verify /v /pa DriverFileName.sys.
Installing the cert into the test computer's Trusted Root Certification Authorities store and Trusted Publishers store, using CertMgr.exe
When I verify the signature with SignTool verify /v /pa DriverFileName.sys as described in WDK Microsoft Docs, SignTool reports that the signature is ok. I've done this on both the development computer and the test machine that is supposed to load the driver.
However, the driver doesn't actually load. The Windows CodeIntegrity log says 3004: Windows is unable to verify the image integrity of the file \Device\HarddiskVolume3\path\DriverFileName.sys because file hash could not be found on the system. 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 looked at this similar question. I get the same results as in that question, when I run SignTool verify /v /kp DriverFileName.sys. It says: SignTool Error: Signing Cert does not chain to a Microsoft Root Cert.
The linked question's resolution involved using a real, non-test certificate, and changing the signing setup so that it correctly chained to the Microsoft Root Certificate. I'm not yet at that stage; I just want to get my test infrastructure working "properly".
I'm interested in having the kernel load my driver, and verify the signature using the certificates that I've manually installed on the test machine. I know I can use bcdedit -set testsigning yes to disable signature validation entirely, but that seems like overkill - it will allow any signed driver to run, even if it wasn't signed with the test certificate I've installed on the machines. Is it possible to leave "testsigning" mode turned off (so the driver signature is still actually validated against an installed cert), but still use my internal self-generated MakeCert.exe test certificate?
It looks the answer is no, it's not possible.
Can I install self-signed drivers on 64-bit Windows without test mode if the self-signed CA root certificate is imported to the machine store?
The WDK documentation seems quite misleading. Installing the certificate generated by MakeCert.exe on x64 test machines seems to be entirely pointless, since the kernel never pays any attention to it.
If TESTSIGNING mode is on, the signature isn't validated, so the cert doesn't need to be installed.
If TESTSIGNING mode is off, the self-signed certificate isn't cross-signed by anything the kernel trusts, so it's not considered valid, so installing the cert doesn't help.
I'm happy to accept corrections.
For some years we used a Comodo SHA-1 code signing certificate to sign the .cat file of our Windows printer driver. The built signed driver installed fine on XP up to Windows 10. On systems that have never seen the driver before we get the expected warning dialog asking if the user trusts us, the author of the driver.
So everything's been fine up til now.
Unfortunately, that certificate just expired, and since SHA-1 certificates are deprecated, the supplied replacement certificate is SHA-2.
The only thing that has changed in our build is the certificate. The build still produces a signed driver, and that driver behaves the same as before, i.e. absolutely fine, on Windows 8 and up. But on Windows 7, even after installing the Windows patch to make it understand SHA-2, at driver-install time we now get the scary red warning dialog saying the driver is unsigned.
My question is - is there anything I can do get the driver to install without the scary warning on Windows 7 with the Windows SHA-2 patch installed?
Once I'd added the comodo-supplied cross certificate to the Intermediate Certification Authorities store on the build machine I was able to rebuild the driver so that it installed on Win7x64 without any scary red warnings.
We have been using an Authenticode code signing certificate from Globalsign for years to sign our Windows 7 drivers. Since now there is a move towards new "SHA-256" code signing certificates, we got such a new certificate which works fine under Windows 8.1 or 10, but not under Windows 7.
When I install the driver, Windows ask me if I trust the publisher and offers the checkbox "always trust this publisher", i.e., it offers to save this selection for future installations. However, under Windows 7 this no longer works, i.e., I get asked every time I install the driver.
I guess this is a bug in Windows 7. Has anyone else experienced this? Is there any solution?
Yes, I've experienced exactly the same issue, which is not very convenient when you're trying to install a driver package automatically from the command-line, for instance...
And yes, there is a solution which fixed this for me, you can find a hot-fix on the Microsoft support website here.
It is not directly available, but you just have to enter your e-mail address in the form and Microsoft will send it to you.