Signed INF driver works on the computer where it was signed, not others

21
votes

My company purchased a Driver Signing Certificate from Go Daddy. I used it to sign a simple INF file that is a driver for some of our USB devices that use Microsoft's usbser.sys. Everything seems to work on the Windows 7 64-bit computer where I signed it: if I right-click on the INF file and select "Install" then the second warning I see is this good warning that shows the correct Publisher name:

Publisher is correct

However, if I go to a different computer (Windows Vista 64-bit), right click on the INF file, and select "Install", then I get this error message instead:

Cannot verify publisher

This makes me think that my drivers are not properly signed, and the only reason it looks good on my computer is because of some root/intermediate/cross certificate I installed during Go Daddy's installation process. I definitely want my users to be able to see that we are the verified publisher without having to manually install a certificate on their computer.

The INF file and the .cat file in the same directory.

Does anyone know why this is happening and how I can fix it?

I suspect the main problem is that I get this error when I run signtool verify /v pololu.cat (more details below), and I haven't figured out why:

SignTool Error: A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider.

Details of my procedure

The Driver Signing Certificate is a new product from Go Daddy that they launched a few weeks ago. I am not totally sure how it is different from the Code Signing Certificate, but it is the same price. I followed the instructions on Go Daddy's website to download and install the certificate, though the instructions do not match reality perfectly. After I installed the Microsoft Cross Certificate in step 1, I saw a red warning message that said:

Before you can install your certificate, you must use Windows Update to update your root certificates or manually download and install the root certificate from our repository.

I'm not sure what to do about that. I did install some GoDaddy root certificates from their repository but it made no noticeable difference.

I installed the latest version (8.0) of the Windows Driver Kit (WDK) and then installed the latest version (8.0) of the Windows Software Development Kit (SDK) for Windows 8. This gives me access to the inf2cat and signtool utilities. Both of the kits were released within the last month, so it's possible there could be some new bugs that we are treading on.

In a new directory, I put three files:

  1. pololu_usb_to_serial.inf, the INF file I want to sign. It is long but simple; you can read it here. This INF file is a standalone driver; no other files are needed in our driver package. This file is basically the same as the version that our company has successfully distributed (unsigned) for years, but I had to make a few changes for Inf2Cat to accept it.
  2. mscvr-cross-gdroot-g2.crt, which I downloaded from the Go Daddy certificate repository. I believe this is the Cross Certificate that proves that the "Go Daddy Root Certificate Authority - G2" is trusted by Microsoft, but I am not totally sure if this is the right certificate to use.
  3. sign_it.bat, the batch file I run to do the signing.

The batch file just contains:

"C:\Program Files (x86)\Windows Kits\8.0\bin\x86\inf2cat" /v /driver:%~dp0 /os:XP_X86,Vista_X86,Vista_X64,7_X86,7_X64,8_X86,8_X64

"C:\Program Files (x86)\Windows Kits\8.0\bin\x86\signtool" sign /v /ac "mscvr-cross-gdroot-g2.crt" /n "Pololu Corporation" /t http://tsa.starfieldtech.com pololu.cat

The first command invokes inf2cat from the Windows Driver Kit. The /v option makes it verbose. The /driver:%~dp0 option points it to the directory that contains the batch file; a . does not work for some reason and this is nicer than having to hard code the full path. The /os option specifies all the operating systems I would like to support with this driver package. This command creates pololu.cat.

The second command invokes signtool from the Windows Software Development Kit to sign the catalog file. The /v option makes it verbose. The /ac option specifies which cross certificate use (see #2 above). The /n option specifies the name of the certificate to use (that certificate is installed on my computer according to certmgr.msc). The /t option specifies the URL of Go Daddy's timestamping server.

Here is the output in the Command Prompt when I run the batch file:

C:\Users\david.POLOLU\Desktop\sign_it>"C:\Program Files (x86)\Windows Kits\8.0\b
in\x86\inf2cat" /v /driver:C:\Users\david.POLOLU\Desktop\sign_it\ /os:XP_X86,Vis
ta_X86,Vista_X64,7_X86,7_X64,8_X86,8_X64
Processing directory (C:\Users\david.POLOLU\Desktop\sign_it\) file (mscvr-cross-
gdroot-g2.crt)
Processing directory (C:\Users\david.POLOLU\Desktop\sign_it\) file (pololu_usb_t
o_serial.inf)
Processing directory (C:\Users\david.POLOLU\Desktop\sign_it\) file (sign_it.bat)

Parsing INF: C:\Users\david.POLOLU\Desktop\sign_it\pololu_usb_to_serial.inf
Finished parsing INFs
Processing INF: C:\Users\david.POLOLU\Desktop\sign_it\pololu_usb_to_serial.inf
Finished processing INFs
Testing driver package...
Testing driver package...
Testing driver package...
Testing driver package...
Testing driver package...
Testing driver package...
Testing driver package...
Testing driver package...
Testing driver package...
Testing driver package...
Testing driver package...
Testing driver package...
Testing driver package...
Testing driver package...
Testing driver package...

Signability test complete.

Errors:
None

Warnings:
None

Catalog generation complete.
C:\Users\david.POLOLU\Desktop\sign_it\pololu.cat

C:\Users\david.POLOLU\Desktop\sign_it>"C:\Program Files (x86)\Windows Kits\8.0\b
in\x86\signtool" sign /v /ac "mscvr-cross-gdroot-g2.crt" /n "Pololu Corporation"
 /t http://tsa.starfieldtech.com pololu.cat
The following certificate was selected:
    Issued to: Pololu Corporation
    Issued by: Go Daddy Secure Certificate Authority - G2
    Expires:   Sat Aug 31 11:35:25 2013
    SHA1 hash: E2FE1275AD8DA85DEABA67ADE26BE42E0834B4C0

Cross certificate chain (using machine store):
    Issued to: Microsoft Code Verification Root
    Issued by: Microsoft Code Verification Root
    Expires:   Sat Nov 01 06:54:03 2025
    SHA1 hash: 8FBE4D070EF8AB1BCCAF2A9D5CCAE7282A2C66B3

        Issued to: Go Daddy Root Certificate Authority - G2
        Issued by: Microsoft Code Verification Root
        Expires:   Thu Apr 15 13:07:40 2021
        SHA1 hash: 842C5CB34B73BBC5ED8564BDEDA786967D7B42EF

            Issued to: Go Daddy Secure Certificate Authority - G2
            Issued by: Go Daddy Root Certificate Authority - G2
            Expires:   Sat May 03 00:00:00 2031
            SHA1 hash: 27AC9369FAF25207BB2627CEFACCBE4EF9C319B8

                Issued to: Pololu Corporation
                Issued by: Go Daddy Secure Certificate Authority - G2
                Expires:   Sat Aug 31 11:35:25 2013
                SHA1 hash: E2FE1275AD8DA85DEABA67ADE26BE42E0834B4C0

Done Adding Additional Store
Successfully signed: pololu.cat

Number of files successfully Signed: 1
Number of warnings: 0
Number of errors: 0

As I said, I am keeping the .cat and .inf file together in the same directory, but they only work properly on the computer were I signed them.

Verification with Signtool

The signtool utility from Microsoft also has a "verify" feature that lets you verify if your signature is correct. There are three different policies you can use when verifying and they each give different results:

  • The Windows Driver Verification Policy says my signature chain does not trace back to Microsoft, and prints an error message about how my root is not trusted. That seems like a problem to me.
  • The Default Authenticode Verification Policy (/pa) also says my signature chain does not trace back to Microsoft, but it doesn't give an error.
  • The kernel-mode driver signing policy (/kp, which is probably not applicable because I am not signing kernel-mode drivers) says my signature chain does trace back to Microsoft, and gives no error.

Does anyone know which policy is used by Windows for INF files? That would at least help me narrow down the problem.

Here is the full, verbose output from signtool verify:

C:\Users\david.POLOLU\Desktop\sign_it>"C:\Program Files (x86)\Windows Kits\8.0\b
in\x86\signtool" verify /v pololu.cat

Verifying: pololu.cat
Signature Index: 0 (Primary Signature)
Hash of file (sha1): 09A611ECC83E61646DB967D4C23EED725B903C1B

Signing Certificate Chain:
    Issued to: Go Daddy Root Certificate Authority - G2
    Issued by: Go Daddy Root Certificate Authority - G2
    Expires:   Thu Dec 31 16:59:59 2037
    SHA1 hash: 47BEABC922EAE80E78783462A79F45C254FDE68B

        Issued to: Go Daddy Secure Certificate Authority - G2
        Issued by: Go Daddy Root Certificate Authority - G2
        Expires:   Sat May 03 00:00:00 2031
        SHA1 hash: 27AC9369FAF25207BB2627CEFACCBE4EF9C319B8

            Issued to: Pololu Corporation
            Issued by: Go Daddy Secure Certificate Authority - G2
            Expires:   Sat Aug 31 11:35:25 2013
            SHA1 hash: E2FE1275AD8DA85DEABA67ADE26BE42E0834B4C0

The signature is timestamped: Wed Sep 05 16:22:34 2012
Timestamp Verified by:
    Issued to: Starfield Services Root Certificate Authority
    Issued by: Starfield Services Root Certificate Authority
    Expires:   Mon Dec 31 16:59:59 2029
    SHA1 hash: 5D003860F002ED829DEAA41868F788186D62127F

        Issued to: Starfield Services Timestamp Authority
        Issued by: Starfield Services Root Certificate Authority
        Expires:   Wed Apr 26 00:00:00 2017
        SHA1 hash: AEAC793CDD107ACFB314A2FE384A8F16840B7C26

SignTool Error: A certificate chain processed, but terminated in a root
        certificate which is not trusted by the trust provider.

Number of files successfully Verified: 0
Number of warnings: 0
Number of errors: 1

C:\Users\david.POLOLU\Desktop\sign_it>"C:\Program Files (x86)\Windows Kits\8.0\b
in\x86\signtool" verify /v /pa pololu.cat

Verifying: pololu.cat
Signature Index: 0 (Primary Signature)
Hash of file (sha1): 09A611ECC83E61646DB967D4C23EED725B903C1B

Signing Certificate Chain:
    Issued to: Go Daddy Root Certificate Authority - G2
    Issued by: Go Daddy Root Certificate Authority - G2
    Expires:   Thu Dec 31 16:59:59 2037
    SHA1 hash: 47BEABC922EAE80E78783462A79F45C254FDE68B

        Issued to: Go Daddy Secure Certificate Authority - G2
        Issued by: Go Daddy Root Certificate Authority - G2
        Expires:   Sat May 03 00:00:00 2031
        SHA1 hash: 27AC9369FAF25207BB2627CEFACCBE4EF9C319B8

            Issued to: Pololu Corporation
            Issued by: Go Daddy Secure Certificate Authority - G2
            Expires:   Sat Aug 31 11:35:25 2013
            SHA1 hash: E2FE1275AD8DA85DEABA67ADE26BE42E0834B4C0

The signature is timestamped: Wed Sep 05 16:22:34 2012
Timestamp Verified by:
    Issued to: Starfield Services Root Certificate Authority
    Issued by: Starfield Services Root Certificate Authority
    Expires:   Mon Dec 31 16:59:59 2029
    SHA1 hash: 5D003860F002ED829DEAA41868F788186D62127F

        Issued to: Starfield Services Timestamp Authority
        Issued by: Starfield Services Root Certificate Authority
        Expires:   Wed Apr 26 00:00:00 2017
        SHA1 hash: AEAC793CDD107ACFB314A2FE384A8F16840B7C26


Successfully verified: pololu.cat

Number of files successfully Verified: 1
Number of warnings: 0
Number of errors: 0

C:\Users\david.POLOLU\Desktop\sign_it>"C:\Program Files (x86)\Windows Kits\8.0\b
in\x86\signtool" verify /v /kp pololu.cat

Verifying: pololu.cat
Signature Index: 0 (Primary Signature)
Hash of file (sha1): 09A611ECC83E61646DB967D4C23EED725B903C1B

Signing Certificate Chain:
    Issued to: Go Daddy Root Certificate Authority - G2
    Issued by: Go Daddy Root Certificate Authority - G2
    Expires:   Thu Dec 31 16:59:59 2037
    SHA1 hash: 47BEABC922EAE80E78783462A79F45C254FDE68B

        Issued to: Go Daddy Secure Certificate Authority - G2
        Issued by: Go Daddy Root Certificate Authority - G2
        Expires:   Sat May 03 00:00:00 2031
        SHA1 hash: 27AC9369FAF25207BB2627CEFACCBE4EF9C319B8

            Issued to: Pololu Corporation
            Issued by: Go Daddy Secure Certificate Authority - G2
            Expires:   Sat Aug 31 11:35:25 2013
            SHA1 hash: E2FE1275AD8DA85DEABA67ADE26BE42E0834B4C0

The signature is timestamped: Wed Sep 05 16:22:34 2012
Timestamp Verified by:
    Issued to: Starfield Services Root Certificate Authority
    Issued by: Starfield Services Root Certificate Authority
    Expires:   Mon Dec 31 16:59:59 2029
    SHA1 hash: 5D003860F002ED829DEAA41868F788186D62127F

        Issued to: Starfield Services Timestamp Authority
        Issued by: Starfield Services Root Certificate Authority
        Expires:   Wed Apr 26 00:00:00 2017
        SHA1 hash: AEAC793CDD107ACFB314A2FE384A8F16840B7C26

Cross Certificate Chain:
    Issued to: Microsoft Code Verification Root
    Issued by: Microsoft Code Verification Root
    Expires:   Sat Nov 01 06:54:03 2025
    SHA1 hash: 8FBE4D070EF8AB1BCCAF2A9D5CCAE7282A2C66B3

        Issued to: Go Daddy Root Certificate Authority - G2
        Issued by: Microsoft Code Verification Root
        Expires:   Thu Apr 15 13:07:40 2021
        SHA1 hash: 842C5CB34B73BBC5ED8564BDEDA786967D7B42EF

            Issued to: Go Daddy Secure Certificate Authority - G2
            Issued by: Go Daddy Root Certificate Authority - G2
            Expires:   Sat May 03 00:00:00 2031
            SHA1 hash: 27AC9369FAF25207BB2627CEFACCBE4EF9C319B8

                Issued to: Pololu Corporation
                Issued by: Go Daddy Secure Certificate Authority - G2
                Expires:   Sat Aug 31 11:35:25 2013
                SHA1 hash: E2FE1275AD8DA85DEABA67ADE26BE42E0834B4C0


Successfully verified: pololu.cat

Number of files successfully Verified: 1
Number of warnings: 0
Number of errors: 0

The output looked the same when run on the computer where I signed the driver (where it is working) and on the other computer (where it is not working).

Similar Questions on StackOverflow

Thawte driver signing for 64-bit Windows - The solution to this guy's problem was to add a CatalogFile directive to the INF file, but I already have that. (CatalogFile=pololu.cat).

Edit #1: Signing executables works

I used signtool with those same options to sign an executable file (NSIS installer), and it worked correctly on the first try, on both computers. So I think there is something different about the signing policy for INF driver files and that is what is screwing me up.

Edit #2: Warning on GoDaddy's certificate

If I double click on mscvr-cross-gdroot-g2.crt, in the General tab it says "Windows does not have enough information to verify this certificate." In the Certification Path tab, under "Certificate status:", it says "The issuer of this certificate could not be found.". I also see those same warnings if I double click on gd_ms_drv_sign_bundle.p7b (a certificate bundle from GoDaddy) and open up the first certificate.

The issuer of both of those certificates is supposed to be the Microsoft Code Verification Root. Should I worry about that warning message?

Edit #3: Deleting GoDaddy's certificates

Lindsay from GoDaddy's advanced support team got back to me. She linked to this page from globalsign which explains how you have to uninstall the root and intermediate certificates from your CA on the computer where you sign the drivers. Lindsay says that if you don't do this step, the signing tools will assume that those certificates are present on other computers and hence not include them in the signature.

Does anyone know how to check what certificates are "imported" into a signature? What tools can I use to see if Lindsay and GlobalSign are right?

By the way, we have Windows XP computers around but Microsoft will stop supporting that OS soon. Despite what GlobalSign says, there has got to be a way to make this work on Windows 7.

Based on Lindsay's advice, I followed instructions from Microsoft to Turn off Automatic Root Certificates Update, and then I used the UI of certmgr.msc to delete all GoDaddy certificates from "Trusted Root Certification Authorities" and "Intermediate Certification Authorities". Then I re-signed my inf file.

Unfortunately, that did not work! After signing, I double checked that all the GoDaddy certificates are still deleted.

I have received no feedback from GoDaddy on the output of signtool verify, or any input on which driver signing policy I should check when doing the verification. I was hoping that they could just look at the verification output and tell me what I was doing wrong, or tell me what correct output would look like.

For completeness, here are the three outputs from signtool verify after I deleted those certificates and re-signed the drivers:

C:\Users\david.POLOLU\Desktop\sign_inf>"C:\Program Files (x86)\Windows Kits\8.0\
bin\x86\signtool.exe" verify /v pololu.cat

Verifying: pololu.cat
Signature Index: 0 (Primary Signature)
Hash of file (sha1): 5AE4F370471009C8B0ED936C9AE19ED14ABD67D7

Signing Certificate Chain:
    Issued to: Go Daddy Root Certificate Authority - G2
    Issued by: Microsoft Code Verification Root
    Expires:   Thu Apr 15 13:07:40 2021
    SHA1 hash: 842C5CB34B73BBC5ED8564BDEDA786967D7B42EF

        Issued to: Go Daddy Secure Certificate Authority - G2
        Issued by: Go Daddy Root Certificate Authority - G2
        Expires:   Sat May 03 00:00:00 2031
        SHA1 hash: 27AC9369FAF25207BB2627CEFACCBE4EF9C319B8

            Issued to: Pololu Corporation
            Issued by: Go Daddy Secure Certificate Authority - G2
            Expires:   Sat Aug 31 11:35:25 2013
            SHA1 hash: E2FE1275AD8DA85DEABA67ADE26BE42E0834B4C0

The signature is timestamped: Wed Sep 12 14:52:19 2012
Timestamp Verified by:
    Issued to: Starfield Services Root Certificate Authority
    Issued by: Starfield Services Root Certificate Authority
    Expires:   Mon Dec 31 16:59:59 2029
    SHA1 hash: 5D003860F002ED829DEAA41868F788186D62127F

        Issued to: Starfield Services Timestamp Authority
        Issued by: Starfield Services Root Certificate Authority
        Expires:   Wed Apr 26 00:00:00 2017
        SHA1 hash: AEAC793CDD107ACFB314A2FE384A8F16840B7C26

SignTool Error: A certificate chain processed, but terminated in a root
        certificate which is not trusted by the trust provider.

Number of files successfully Verified: 0
Number of warnings: 0
Number of errors: 1

C:\Users\david.POLOLU\Desktop\sign_inf>"C:\Program Files (x86)\Windows Kits\8.0\
bin\x86\signtool.exe" verify /v /pa pololu.cat

Verifying: pololu.cat
Signature Index: 0 (Primary Signature)
Hash of file (sha1): 5AE4F370471009C8B0ED936C9AE19ED14ABD67D7

Signing Certificate Chain:
    Issued to: Go Daddy Root Certificate Authority - G2
    Issued by: Microsoft Code Verification Root
    Expires:   Thu Apr 15 13:07:40 2021
    SHA1 hash: 842C5CB34B73BBC5ED8564BDEDA786967D7B42EF

        Issued to: Go Daddy Secure Certificate Authority - G2
        Issued by: Go Daddy Root Certificate Authority - G2
        Expires:   Sat May 03 00:00:00 2031
        SHA1 hash: 27AC9369FAF25207BB2627CEFACCBE4EF9C319B8

            Issued to: Pololu Corporation
            Issued by: Go Daddy Secure Certificate Authority - G2
            Expires:   Sat Aug 31 11:35:25 2013
            SHA1 hash: E2FE1275AD8DA85DEABA67ADE26BE42E0834B4C0

The signature is timestamped: Wed Sep 12 14:52:19 2012
Timestamp Verified by:
    Issued to: Starfield Services Root Certificate Authority
    Issued by: Starfield Services Root Certificate Authority
    Expires:   Mon Dec 31 16:59:59 2029
    SHA1 hash: 5D003860F002ED829DEAA41868F788186D62127F

        Issued to: Starfield Services Timestamp Authority
        Issued by: Starfield Services Root Certificate Authority
        Expires:   Wed Apr 26 00:00:00 2017
        SHA1 hash: AEAC793CDD107ACFB314A2FE384A8F16840B7C26

SignTool Error: WinVerifyTrust returned error: 0x800B010A
        A certificate chain could not be built to a trusted root authority.

Number of files successfully Verified: 0
Number of warnings: 0
Number of errors: 1

C:\Users\david.POLOLU\Desktop\sign_inf>"C:\Program Files (x86)\Windows Kits\8.0\
bin\x86\signtool.exe" verify /v /kp pololu.cat

Verifying: pololu.cat
Signature Index: 0 (Primary Signature)
Hash of file (sha1): 5AE4F370471009C8B0ED936C9AE19ED14ABD67D7

Signing Certificate Chain:
    Issued to: Go Daddy Root Certificate Authority - G2
    Issued by: Microsoft Code Verification Root
    Expires:   Thu Apr 15 13:07:40 2021
    SHA1 hash: 842C5CB34B73BBC5ED8564BDEDA786967D7B42EF

        Issued to: Go Daddy Secure Certificate Authority - G2
        Issued by: Go Daddy Root Certificate Authority - G2
        Expires:   Sat May 03 00:00:00 2031
        SHA1 hash: 27AC9369FAF25207BB2627CEFACCBE4EF9C319B8

            Issued to: Pololu Corporation
            Issued by: Go Daddy Secure Certificate Authority - G2
            Expires:   Sat Aug 31 11:35:25 2013
            SHA1 hash: E2FE1275AD8DA85DEABA67ADE26BE42E0834B4C0

The signature is timestamped: Wed Sep 12 14:52:19 2012
Timestamp Verified by:
    Issued to: Starfield Services Root Certificate Authority
    Issued by: Starfield Services Root Certificate Authority
    Expires:   Mon Dec 31 16:59:59 2029
    SHA1 hash: 5D003860F002ED829DEAA41868F788186D62127F

        Issued to: Starfield Services Timestamp Authority
        Issued by: Starfield Services Root Certificate Authority
        Expires:   Wed Apr 26 00:00:00 2017
        SHA1 hash: AEAC793CDD107ACFB314A2FE384A8F16840B7C26

SignTool Error: WinVerifyTrust returned error: 0x800B010A
        A certificate chain could not be built to a trusted root authority.

Number of files successfully Verified: 0
Number of warnings: 0
Number of errors: 1

Edit #4: DefaultInstall section is a no-no

In the documentation of the DefaultInstall section from Microsoft, I discovered this:

Note The INF file of a driver package must not contain an INF DefaultInstall section if the driver package is to be digitally signed.

Does anyone know why that is true? I couldn't find an explanation.

Anyway, I took out the DefaultInstall section of my INF file, so from now on I have to test it by running a little DLL I wrote, that calls SetupCopyOemInf.

Still no luck; I keep on getting the unverified publisher warning on the Windows Vista computer.

Edit #5: JLink driver is signed correctly

I was poking around in C:\Windows\System32\DriverStore\FileRepository to try to find some properly signed driver packages. The first interesting one I found is JLinkCDC.cat/JLinkCDC.inf. The version of the Inf file is DriverVer=01/25/2012,6.0.2600.4. On the Windows Vista machine, if I call SetupCopyOemInf on the inf file (using my DLL) then I get a proper message telling me who the publisher is (Segger GMBH or something like that). Therefore, it is possible to sign driver packages like mine properly, but somehow GoDaddy or I am doing something wrong.

The JLinkCDC.inf driver is very similar to my driver because it is just one file and uses usbser.sys. The trust chain of their signature goes back to VeriSign Class 3 Public Primary Certificate Authority - G5.

Basically, this JLinkCDC driver is similar to mine and it works, so I plan on looking carefully at it to see what the differences are.

The output of signtool verify for JLinkCDC.cat looks very similar to mine except it traces back to Verisign instead of GoDaddy.

Edit #6: Minor changes

To make my driver more like JLinkCDC.inf, I added DriverPackageType=PlugAndPlay to the INF file and I shortened the file names: the files are now called polser.cat and polser.inf. Still no luck!

Edit #7: Some success!

I think the following things are true; please correct me if I am wrong:

  • For a driver package (.cat file), the correct option for signtool verify is /pa. I infer this from KMCS_Walkthrough.doc.
  • For a driver package, Windows only considers the publisher to be verified if the chain of trust goes back to a certificate in the "Trusted Root Certification Authorities" folder in certmgr.msc.
  • For a driver package, you can sign it with a cross certificate (extending the chain of trust from gdroot-g2.crt to the Microsoft Code Verification Root), but Windows seems to ignore that. This is because the Microsoft Code Verification Root is not a "Trusted Root Certification Authority".
  • There are certificate stores for the current user and certificates for the local machine. Both of them matter, so you should use the MMC Certificates Snap-In to view both. Certmgr.msc only shows the ones for the current user.
  • Windows should seamlessly add the "Go Daddy Root Certificate Authority - G2" (gdroot-g2.crt) to the "Trusted Root Certification Authorities" folder when needed, downloading it from Windows Update, but it doesn't. More info here.

I used the Windows Event Viewer on the test machine to see what was up. It looks like Windows WILL fetch "Go Daddy Root Certificate Authority - G2" automatically, but only after it displays the undesirable unverified publisher warning dialog. As soon as the user closes that dialog, the certificate is fetched from Windows Update, so the next attempt at installation should be successful. Interestingly, it does automatically download the a Starfield certificate (which is the root at the chain of trust for my timestamp) in a timely manner.

I have gotten my signature to work on Windows 7 and Windows Vista computers by double-clicking on gdroot-g2.crt and importing it before I attempt to install the drivers. I will see if this process can be automated and added to an installer.

I found a driver package from another company (JLinkCDC.cat) that was signed with a VeriSign certificate, rooted in "VeriSign Class 3 Public Primary Certification Authority - G5". That certificate is on all the computers I have looked at, so if you go with VeriSign instead of Go Daddy I think you can avoid this problem with Windows Update.

I did notice that the VeriSign certificates use SHA1 while my Go Daddy certificates use SHA256 for the signature algorithm and signature hash algorithm. Not sure if that matters.

Edit #8: Asked Microsoft for help

See the discussion and my conclusion on the MSDN forums: http://social.msdn.microsoft.com/Forums/en-US/wdk/thread/1fede768-7925-4f30-8eef-ce5bd08b0b60

4
windowsdriverauthenticodeinfdriver-signing
Looking in certmgr.msc I do not see "Microsoft Code Verification Root" as a trusted certificate on any of my Windows machines. I think such a signature verification cannot pass because of that. – glagolig
Thank you for the information, @glagolig. So did GoDaddy create their certificate incorrectly? Is there something I can do to work around that? – David Grayson
It turned out my assumption was wrong. The article sourceforge.net/apps/mediawiki/libwdi/… indirectly states that "Microsoft Code Verification Root" does not show up in trusted certificate list but it is still recognized by the operating system. – glagolig
Thanks for the link to libwdi! I learned a lot from reading the Signed Driver Walkthrough found from github.com/pbatard/libwdi/wiki/_pages ; this is the first resource I found that starts to explain the difference between signing a driver package (which is what I am starting to do) and signing driver binaries. – David Grayson
Let's say that the booby girls at GoDaddy don't give the user much confidence in the a certificate issued by them, promising that the driver always works. Drivers for the 64-bit version of Windows have to be qualified by Microsoft, not them girls. Google "whql labs certifications". – Hans Passant

4 Answers

9
votes

As of 9/27/2012, GoDaddy Driver Signing Certificate will not work with Windows Vista or Windows 7. It will only work with Windows 8. The GoDaddy certificate is only available with SHA256.

We ended up getting one from GlobalSign (MS Authenticode).

From http://msdn.microsoft.com/en-us/library/windows/hardware/hh967734%28v=vs.85%29.aspx :

Signing a driver package with two signatures

In some cases, you might want to sign a driver package with two different signatures. For example, suppose you want your driver to run on Windows 7 and Windows 8. Windows 8 supports signatures created with the SHA256 hashing algorithm, but Windows 7 does not. For Windows 7, you need a signature created with the SHA1 hashing algorithm.

2012-09-28 Update: The GlobalSign worked. I let Firefox 15 download the GlobalSign provided link (protected by a Pickup Password). Ended up with Firefox holding the signed certificate, and downloading 3 other GlobalSign certs. The signed certificate was exported from Firefox into a .p12 file. All four files were then double clicked to import them into the MS Certificate Store using automatic defaults. Driver and package were signed and tested in a Windows 7 Ultimate x64 without any driver signing errors. The driver BSoD'd but that's a different issue. ;)

GoDaddy will only give you website credit minus $15 and only if you revoke within 30 days of purchase.

2016-01-13 Update: https://technet.microsoft.com/en-us/library/security/3033929 Microsoft Security Advisory 3033929 Availability of SHA-2 Code Signing Support for Windows 7 and Windows Server 2008 R2 Published: March 10, 2015 ... Basically, you need to install the security update in the links provided by Microsoft which is usually done automatically by Windows Update.

We are now using EV Code Signing Certificates from GlobalSign. Warning: SafeSign does not work with Windows services (e.g., buildbot slave).

4
votes

Due to lack of reputation I cannot up-vote rcpao's answer, but I wanted to post in agreement. I recently went thru a similar process attempting to sign a Windows 7 driver package with a driver signing certificate from GoDaddy. In short, Win7 x64 would not take the drivers--most certainly due to the SHA-2 hashing used in the GoDaddy certificate.

While there are articles stating that Windows 7 is compatible with SHA-2 signing I don't think that applies to driver signatures. Definitely there are some ambiguous texts available that makes the issue less clear.

My company ended up purchasing a DigiCert code signing certificate that includes kernel-mode signing for drivers. It worked as expected, and the cost was comparable to GoDaddy.

1
votes

Answering my own question:

I ended up getting a Code Signing Certificate from Go Daddy and keying it to be SHA-2 (the other option is SHA-1), because I wanted the possibility of some day signing driver packages that contain .sys files and GoDaddy's SHA-2 option lets you do that. Now I sign our .cat files using that certificate along with the Go Daddy G1 to G2 Cross Certificate (gdroot-g2_cross.crt), so the chain of trust looks like:

  1. Go Daddy Class 2 Certification Authority ( 27 96 ba e6 3f 18 01 e2 77 26 1b a0 d7 77 70 02 8f 20 ee e4 ) (will be a trusted root CA on your user's computer)
  2. Go Daddy Root Certificate Authority - G2 ( 84 1d 4a 9f c9 d3 b2 f0 ca 5f ab 95 52 5a b2 06 6a cf 83 22 ) (supposed to be a trusted root CA, but it depends on Windows Update working reliably)
  3. Go Daddy Secure Certificate Authority - G2 ( 27 ac 93 69 fa f2 52 07 bb 26 27 ce fa cc be 4e f9 c3 19 b8 )
  4. Our company

This has been working great for our needs, but unfortunately, that plan does not allow us to sign driver packages that contain Kernel-Mode .sys files, because the chain of trust is not rooted in the Microsoft Code Verification Root. Based on my reading of kmsigning.doc, the correct way to sign your .cat file if you have kernel-mode driver files is to use the Microsoft to Go Daddy G2 Cross Certificate (mscvr-cross-gdroot-g2.crt). I haven't actually gotten that to work yet, but that will be another discussion.

SHA 2

I have to respectfully disagree with rcpao and kris. As far as I can tell, there is problem with SHA256 on Windows Vista or Windows 7, at least for the purpose of driver package installation. For loading a .sys file into the kernel, there might be a different story, and especially because I'm having trouble with .sys signing now I will have to look into that.

DefaultInstall

The MSDN documentation of the INF DefaultInstall Section is just wrong. There seems to be no incompatibility between DefaultInstall and driver signing and I see now reason why there should be.

1
votes

Sounds like you need to get your driver certified and signed by Microsoft, which can be achieved by using the Hardware Certification Kit (HCK). But for Windows 10 and up they are using Hardware Lab Kit (HLK). This is how I've signed kernel-mode drivers, which is done after passing the testing and having Microsoft certify and sign the .sys files and .cat files.