none
Inconsistency between signed driver status in Device Manager RRS feed

  • Question

  • Hi,

    We have developed a driver for Windows 7 and have signed it using an SPC provided by GlobalSign. Signing using SignTool produced no errors and verification was also OK.

    However, when installing the driver, although no errors are produced and the device is functioning properly in the Device Manager, an error message appears in setupapi.dev.log:

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

    This already appeared to be strange to me since verifying the exact same file using SignTool (using the /kp switch) gives an OK. Is there a different verification mechanism between the two?

    Anyway, when looking at the properties of the device in the Device Manager, in the Driver tab, everything seems ok: Digital Signer mentions the name of our company and all other info is present. Then, when I click Driver Details, the dialog that is opened says Digital Signer: Not digitally signed. How come in one dialog, Windows verifies the signature correctly and in another similar dialog, suddenly it doesn't anymore?

    When running sigverif, the driver is also marked as unsigned. When checking the log, I notice that the Version info is wrong (where it should state the supported OS versions e.g. 2:6.0, it states the version number of the driver e.g. 8.11.0) and the catalog file is N/A.

    So I've got some tools/processes in Windows saying that everything is OK while others say it's not which makes it a bit difficult to get to the bottom of this... Has anyone encountered similar problems before and found a way to solve this?

    Thanks.

    Thursday, June 27, 2013 3:07 PM

Answers

  • Are you using the GlobalSign cross certificate?  When you do "signtool /kp /v", the Cross Certificate Chain must end with "Microsoft Code Verification Root".  If it does not, then you didn't get the right cross certificate.

    Note that the non-crossed signature is considered "digitally signed", but it is not enough to satisfy KMCS.  Also note that, in some cases where the system checks a signature, it only considers a WHQL certificate to be "digitally signed".


    Tim Roberts, VC++ MVP Providenza & Boekelheide, Inc.

    Thursday, June 27, 2013 5:40 PM

All replies

  • Are you using the GlobalSign cross certificate?  When you do "signtool /kp /v", the Cross Certificate Chain must end with "Microsoft Code Verification Root".  If it does not, then you didn't get the right cross certificate.

    Note that the non-crossed signature is considered "digitally signed", but it is not enough to satisfy KMCS.  Also note that, in some cases where the system checks a signature, it only considers a WHQL certificate to be "digitally signed".


    Tim Roberts, VC++ MVP Providenza & Boekelheide, Inc.

    Thursday, June 27, 2013 5:40 PM
  • I haven't checked my setupapi.dev.log but I see the same thing E Hall reports when checking our digitally signed driver with Device Manager.  I understand that WHQL may be a requirement in some cases, but I can find nothing that indicate that Device Manager would require it (and the extensive MS documentation I've read would seem to imply otherwise). In any case one would think Device Manager would not report the digital signature status differently on different dialog pages. Here's the output from SignTool on the driver .sys file. Any help appreciated.

    The following certificate was selected:
        Issued to: Engineering Design Team
        Issued by: VeriSign Class 3 Code Signing 2009-2 CA
        Expires:   Wed Sep 25 16:59:59 2013
        SHA1 hash: 6F26FBE1A2C15DCCB46F04549B3FEB6C8AEC49A2

    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: Class 3 Public Primary Certification Authority
            Issued by: Microsoft Code Verification Root
            Expires:   Mon May 23 10:11:29 2016
            SHA1 hash: 58455389CF1D0CD6A08E3CE216F65ADFF7A86408

                Issued to: VeriSign Class 3 Code Signing 2009-2 CA
                Issued by: Class 3 Public Primary Certification Authority
                Expires:   Mon May 20 16:59:59 2019
                SHA1 hash: 12D4872BC3EF019E7E0B6F132480AE29DB5B1CA3

                    Issued to: Engineering Design Team
                    Issued by: VeriSign Class 3 Code Signing 2009-2 CA
                    Expires:   Wed Sep 25 16:59:59 2013
                    SHA1 hash: 6F26FBE1A2C15DCCB46F04549B3FEB6C8AEC49A2

    Wednesday, July 3, 2013 10:42 PM