If you are developing drivers for 64bit Vista or 2008, not only do you have to sign your driver with your company’s code signing certificate (sometimes referred to as a Software Publishing Certificate or SPC), you may also need to cross-sign your drivers so Windows does not complain and consequently reject loading your driver.  

What is cross-signing (aka qualified subordination) exactly ? PGP users do it all the time when they sign another person’s PGP key, attesting to the fact that the key indeed belongs to the person (whose email address, photograph etc are on the key chain). Cross-signing is the exact same attestation in X.509 world except it is between Certification Authorities (CAs). A cross-signed driver establishes chain of trust to Microsoft’s CA whereas without cross-signing, the chain of trust is established with the CA that issued your company’s code signing certificate (Verisign, Thawte etc).

Depending on who your CA is, you can download the corresponding Microsoft cross-signing cert from here. Cross-signing is achieved by specifying signtool /ac (Additional Certificate) option on the command line along with the SPC certificate store and other parameters. This /ac option is supported only in signtool packaged with Vista WDK onwards.

The cross-signed driver signature does not look any different from non cross-signed driver in Windows Explorer (File->Properties->Digital Signatures tab). So it is kind of tricky to know whether cross signing worked fine or not. You can check whether a driver is a cross-signed driver by using signtool. If you have a driver with the signature embedded in it and signed by an SPC issued by Verisign you may see something like the following –

a cross signed driver

The second cert from top is the cross certificate that links the chain of trust to Microsoft Code Verification Root certificate. Note also that we do not see the Verisign root certificate in this chain. That chain still exists even though we do not see it here. The bottom line is as long as the top certificate shows up as Microsoft Code Verification Root,  your driver has been successfully cross-signed. 

If you are on a machine where signtool is not installed (for example a customer’s machine), a quick and dirty way to check for cross-signing is to look for a certain string in the driver like below

findstr /m “MicrosoftCodeVerifRoot” <yourdriver.sys>

This will not output anything if the driver is not cross-signed. If it is, findstr will echo back your driver name in output.

Happy signing !

Tagged with →  
Share →

9 Responses to Cross signing kernel mode drivers

  1. tobi delbruck says:

    Thanks for this helpful post.

  2. Jason McClinsey says:

    This is the best article that I have found on cross-signing. Thank you so much for posting this! Where is the donate button?

  3. Satya Das says:

    Thanks for dropping by. I am glad you found it useful.

  4. Brian Moody says:

    When I run findstr /m “MicrosoftCodeVerifRoot” , my driver name is outputted. So I’m still confused on why I get a warning about an unverified publisher when I install the driver. I’ve cross signed it using a Verisign certificate.

  5. Satya Das says:

    Try to see what you get with signtool /verify output (like above) says on the build machine. If everything looks fine, check if you have an updated set of root certificates installed on the installation machine.

  6. Brian Moody says:

    When I run signtool verify with the /kp option, Microsoft Code Verification Root shows up as the first one in the chain under the “Cross Certificate Chain” section. It does not show up at all under the “Signing Certificate Chain” section (as your output shows).

    I’ve read elsewhere about updating the root certificates – how is this done? I don’t find real clear info anywhere on this.

  7. Satya Das says:

    You can use certmgr for that. If you look into the last document linked in my post, you will see all the details in the walkthrough. Kernel mode signing is complex and perhaps you need to sign your cat file in addition to signing your driver. Make sure you understand what is required for your type of driver.

  8. Brian Moody says:

    It appears I’ve solved the problem. Well there were 2 issues. First, I discovered that a cat file is required for Plug and Play driver installtion. This tool much researching to find out! Secondly, there was apparently a slight mistake in the SourceDiskNames portion of my inf file. The problem was never an issue for the normal operation and running of the driver. But when it came time to sign it, I believe the inf2cat got confused by this mistake and created a bad hash in the cat file.

    Appreciate your time and info in this article.

  9. Satya Das says:

    Excellent. Thanks for posting what you found.

Leave a Reply

Your email address will not be published. Required fields are marked *


Looking for something?

Use the form below to search the site:

Still not finding what you're looking for? Drop us a note so we can take care of it!

Visit our friends!

A few highly recommended friends...

Set your Twitter account name in your settings to use the TwitterBar Section.