Part 3 of our driver signing guide deviates slightly from the self-signed certificate approach. My current client uses Active Directory Certificate Services (ADCS) to create and issue certificates. I won’t discuss ADCS in any detail because I’m not a security expert. However, there’s a useful guide here that will assist you in creating a code signing certificate for use with all your unsigned device drivers.
I exported our code signing certificate from ADCS as a pfx file, which importantly, forms part of a certificate chain with the root certificate (our code signing certificate is signed by the root certificate). The root certificate for the organisation is already in the Trusted Root store (for the computer….not the user) on all machines. If this root certificate didn’t exist, our new crtificate chain will not validate and hence our ‘signed’ driver would not appear as being signed when we install it.
The exported code signing certificate uses SHA-256 encryption. Exporting certificates as SHA-256 is currently a security best practise. As a result of this, when we’re signing a driver’s .cat file the syntax is slightly different (ensure you download the latest version of signtool.exe before running this command line):
signtool.exe sign /fd SHA256 /f C:\driver\AlkaneCert.pfx /p PASSWORD /tr http://sha256timestamp.ws.symantec.com/sha256/timestamp C:\driver\Alkane.cat
Now all you need to do is ensure that your code signing certificate is imported into the Trusted Publisher store (for the computer….not the user) on every machine in your organisation. But wait….
Even though we did this, when we installed the driver it appeared signed (yay) but we received a message saying the publisher wasn’t trusted (boo)! After much debugging, it turned out that this patch (KB2921916) released from Microsoft was required on all machines and fixed the issue!
Before I wrap up, I should also mention a very nice article I found here explaining the driver signing process in more detail.