none
Driver Signing with Verisign, can't get rid of warning RRS feed

  • Question

  • Hi there,

    We have a few drivers we've been signing with a Verisign cert. They install and run everywhere, including Win7 x64, no problem. Except we can't get them to install without the red "Windows can't verify the publisher..." dialog. This is a hassle.

    I spent a /lot/ of time tracking information down on this problem. I've downloaded what was supposed to be an updated cross-cert from here: http://msdn.microsoft.com/en-ca/library/windows/hardware/gg487315.aspx

    I've downloaded and installed updated intermediate certs from Verisign here:https://knowledge.verisign.com/support/code-signing-support/index?page=content&id=AR1739

    Neither of these steps helped. The drivers load and run, but we still get the warning on install.

    During build, I get this output from "signtool verify /v /kp":

    -----
    Signing Certificate Chain:
        Issued to: VeriSign Class 3 Public Primary Certification Authority - G5
        Issued by: VeriSign Class 3 Public Primary Certification Authority - G5
        Expires:   Wed Jul 16 19:59:59 2036
        SHA1 hash: 4EB6D578499B1CCF5F581EAD56BE3D9B6744A5E5

            Issued to: VeriSign Class 3 Code Signing 2010 CA
            Issued by: VeriSign Class 3 Public Primary Certification Authority - G5
            Expires:   Fri Feb 07 19:59:59 2020
            SHA1 hash: 495847A93187CFB8C71F840CB7B41497AD95C64F

                Issued to: Opteon Corporation
                Issued by: VeriSign Class 3 Code Signing 2010 CA
                Expires:   Fri Jul 26 19:59:59 2013
                SHA1 hash: 6381A430F7B1C14FCDCA0D0999DB12B2950EF299

    The signature is timestamped: Fri Apr 05 14:42:03 2013
    Timestamp Verified by:
        Issued to: Thawte Timestamping CA
        Issued by: Thawte Timestamping CA
        Expires:   Thu Dec 31 19:59:59 2020
        SHA1 hash: BE36A4562FB2EE05DBB3D32323ADF445084ED656

            Issued to: Symantec Time Stamping Services CA - G2
            Issued by: Thawte Timestamping CA
            Expires:   Wed Dec 30 19:59:59 2020
            SHA1 hash: 6C07453FFDDA08B83707C09B82FB3D15F35336B1

                Issued to: Symantec Time Stamping Services Signer - G4
                Issued by: Symantec Time Stamping Services CA - G2
                Expires:   Tue Dec 29 19:59:59 2020
                SHA1 hash: 65439929B67973EB192D6FF243E6767ADF0834E4

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

            Issued to: Class 3 Public Primary Certification Authority
            Issued by: Microsoft Code Verification Root
            Expires:   Mon May 23 13:11:29 2016
            SHA1 hash: 58455389CF1D0CD6A08E3CE216F65ADFF7A86408

                Issued to: VeriSign Class 3 Public Primary Certification Authority - G5
                Issued by: Class 3 Public Primary Certification Authority
                Expires:   Sun Nov 07 19:59:59 2021
                SHA1 hash: 32F30882622B87CF8856C63DB873DF0853B4DD27

                    Issued to: VeriSign Class 3 Code Signing 2010 CA
                    Issued by: VeriSign Class 3 Public Primary Certification Authority - G5
                    Expires:   Fri Feb 07 19:59:59 2020
                    SHA1 hash: 495847A93187CFB8C71F840CB7B41497AD95C64F

                        Issued to: Opteon Corporation
                        Issued by: VeriSign Class 3 Code Signing 2010 CA
                        Expires:   Fri Jul 26 19:59:59 2013
                        SHA1 hash: 6381A430F7B1C14FCDCA0D0999DB12B2950EF299

    Successfully verified: i386\OptEnNxN.sys

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

    -----

    The Cross Certificate Chain above is what I think my Signing Certificate Chain should look like, but I can't get that to happen no matter what I do. 

    If I instead do "signtool verify /v" (no /kp), I get this:

    -----

    Signing Certificate Chain:
        Issued to: VeriSign Class 3 Public Primary Certification Authority - G5
        Issued by: VeriSign Class 3 Public Primary Certification Authority - G5
        Expires:   Wed Jul 16 19:59:59 2036
        SHA1 hash: 4EB6D578499B1CCF5F581EAD56BE3D9B6744A5E5

            Issued to: VeriSign Class 3 Code Signing 2010 CA
            Issued by: VeriSign Class 3 Public Primary Certification Authority - G5
            Expires:   Fri Feb 07 19:59:59 2020
            SHA1 hash: 495847A93187CFB8C71F840CB7B41497AD95C64F

                Issued to: Opteon Corporation
                Issued by: VeriSign Class 3 Code Signing 2010 CA
                Expires:   Fri Jul 26 19:59:59 2013
                SHA1 hash: 6381A430F7B1C14FCDCA0D0999DB12B2950EF299

    The signature is timestamped: Fri Apr 05 14:42:03 2013
    Timestamp Verified by:
        Issued to: Thawte Timestamping CA
        Issued by: Thawte Timestamping CA
        Expires:   Thu Dec 31 19:59:59 2020
        SHA1 hash: BE36A4562FB2EE05DBB3D32323ADF445084ED656

            Issued to: Symantec Time Stamping Services CA - G2
            Issued by: Thawte Timestamping CA
            Expires:   Wed Dec 30 19:59:59 2020
            SHA1 hash: 6C07453FFDDA08B83707C09B82FB3D15F35336B1

                Issued to: Symantec Time Stamping Services Signer - G4
                Issued by: Symantec Time Stamping Services CA - G2
                Expires:   Tue Dec 29 19:59:59 2020
                SHA1 hash: 65439929B67973EB192D6FF243E6767ADF0834E4

    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

    -----

    Here there is no Cross Certificate Chain reported that points back to the ms root cert.

    During signing, I get the following:

    signtool sign /v /n "Opteon" /ac MSVC-VSClass3.cer /t http://timestamp.verisign.com/scripts/timestamp.dll optennxn.sys

    The following certificate was selected:
        Issued to: Opteon Corporation
        Issued by: VeriSign Class 3 Code Signing 2010 CA
        Expires:   Fri Jul 26 19:59:59 2013
        SHA1 hash: 6381A430F7B1C14FCDCA0D0999DB12B2950EF299

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

            Issued to: VeriSign Class 3 Public Primary Certification Authority - G5
            Issued by: Microsoft Code Verification Root
            Expires:   Mon Feb 22 15:35:17 2021
            SHA1 hash: 57534CCC33914C41F70E2CBB2103A1DB18817D8B

                Issued to: VeriSign Class 3 Code Signing 2010 CA
                Issued by: VeriSign Class 3 Public Primary Certification Authority - G5
                Expires:   Fri Feb 07 19:59:59 2020
                SHA1 hash: 495847A93187CFB8C71F840CB7B41497AD95C64F

                    Issued to: Opteon Corporation
                    Issued by: VeriSign Class 3 Code Signing 2010 CA
                    Expires:   Fri Jul 26 19:59:59 2013
                    SHA1 hash: 6381A430F7B1C14FCDCA0D0999DB12B2950EF299

    Done Adding Additional Store
    Successfully signed and timestamped: i386\OptEnNxN.sys

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

    -----

    I'm worried about the "using machine store" part above. I specify a cross-cert in the command line. Why does it need the machine store?

    Any help would be very greatly appreciated!

    Thanks

    Rob McCready

    Friday, April 5, 2013 6:52 PM

Answers

  • You mention trying to update the device using device manager. Can you check your %WINDIR%\INF\setupapi.dev.log and see the information logged about your driver package for these attempts?Does it have any information about the signer, the catalog file or the signature? It may have some clues as to why the signature in your cat file appears invalid.

    Faisal.


    This posting is provided "AS IS" with no warranties, and confers no rights.

    Tuesday, April 9, 2013 11:50 PM

All replies

  • Certs need to be installed in the machine cert store when used to validate driver packages. Are you getting can't verify publisher or do you want to trust this publisher?

    d -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Sunday, April 7, 2013 12:13 AM
  • Hi Doron,

    We're getting both, but it is the "can't verify publisher" that we can't get rid of. We expect the "do you want to trust" if this is the first install from us. That dialog shows up properly with our name, and if the user selects to trust us every time, it never shows up again. Even after that, however, we continue to get the "can't verify publisher" message.

    Thanks,

    Rob

    Monday, April 8, 2013 5:16 PM
  • Hi Rob,

    This usually means that either the catalog file is not present, or it is not consistent with the driver package content. How are you installing the driver? Check your %WINDIR%\INF\setupapi.dev.log file, is there any information there about the catalog file or the signer?

    I notice you do have information about embed signing the driver, it seems that from the information that you need an updated catalog file for the INF. See http://msdn.microsoft.com/en-us/library/windows/hardware/gg487328.aspx for how to create a catalog file for release signing.

    Faisal. 


    This posting is provided "AS IS" with no warranties, and confers no rights.

    Tuesday, April 9, 2013 3:47 AM
  • Hi Faisal,

    I perform exactly the same signing on the .cat file. I sign the .sys file first, generate the .cat file with inf2cat, and then sign the .cat using the same cert and cross-cert I use to sign the driver. I call "signtool verify" on the .cat just as I do with the driver, and the verify succeeds as long as I specify /kp. Just as with the .sys file, if I do not specify /kp I get an error.

    Thanks,

    Rob

    Tuesday, April 9, 2013 3:24 PM
  • Hi Rob,

    The error you see when not using /kp would be expected because the cross-cert is not trusted for driver policy. What do you see if you run /pa for Authenticode Policy?

    Faisal.


    This posting is provided "AS IS" with no warranties, and confers no rights.

    Tuesday, April 9, 2013 9:04 PM
  • Hi Faisal,

    Thanks for helping out! Here is what I get with /pa on the .cat:

    signtool verify /v /pa i386\optennxn.cat
    
    Verifying: i386\optennxn.cat
    Hash of file (sha1): 7DE2D162CD1F450E5E2D0D5FA9B564D9C5218989
    
    Signing Certificate Chain:
        Issued to: VeriSign Class 3 Public Primary Certification Authority - G5
        Issued by: VeriSign Class 3 Public Primary Certification Authority - G5
        Expires:   Wed Jul 16 19:59:59 2036
        SHA1 hash: 4EB6D578499B1CCF5F581EAD56BE3D9B6744A5E5
    
            Issued to: VeriSign Class 3 Code Signing 2010 CA
            Issued by: VeriSign Class 3 Public Primary Certification Authority - G5
            Expires:   Fri Feb 07 19:59:59 2020
            SHA1 hash: 495847A93187CFB8C71F840CB7B41497AD95C64F
    
                Issued to: Opteon Corporation
                Issued by: VeriSign Class 3 Code Signing 2010 CA
                Expires:   Fri Jul 26 19:59:59 2013
                SHA1 hash: 6381A430F7B1C14FCDCA0D0999DB12B2950EF299
    
    The signature is timestamped: Fri Apr 05 14:42:03 2013
    Timestamp Verified by:
        Issued to: Thawte Timestamping CA
        Issued by: Thawte Timestamping CA
        Expires:   Thu Dec 31 19:59:59 2020
        SHA1 hash: BE36A4562FB2EE05DBB3D32323ADF445084ED656
    
            Issued to: Symantec Time Stamping Services CA - G2
            Issued by: Thawte Timestamping CA
            Expires:   Wed Dec 30 19:59:59 2020
            SHA1 hash: 6C07453FFDDA08B83707C09B82FB3D15F35336B1
    
                Issued to: Symantec Time Stamping Services Signer - G4
                Issued by: Symantec Time Stamping Services CA - G2
                Expires:   Tue Dec 29 19:59:59 2020
                SHA1 hash: 65439929B67973EB192D6FF243E6767ADF0834E4
    
    Successfully verified: i386\optennxn.cat
    
    Number of files successfully Verified: 1
    Number of warnings: 0
    Number of errors: 0

    So, I guess that looks good? If I take the exact .inf, .sys, and .cat files that I run the "verify" on, copy them to another machine, and use them to update the driver from Device Manager, I get the "cannot verify publisher" message. Any other ideas?

    Thanks again,

    Rob

    Tuesday, April 9, 2013 9:23 PM
  • Hi Pavel,

    I just fired up a fresh virtual PC running Win7 with absolutely nothing on it. Dropped signtool on with the drivers. Exactly the same results as on the build machine.

    Thanks,

    Rob

    Tuesday, April 9, 2013 9:49 PM
  • You mention trying to update the device using device manager. Can you check your %WINDIR%\INF\setupapi.dev.log and see the information logged about your driver package for these attempts?Does it have any information about the signer, the catalog file or the signature? It may have some clues as to why the signature in your cat file appears invalid.

    Faisal.


    This posting is provided "AS IS" with no warranties, and confers no rights.

    Tuesday, April 9, 2013 11:50 PM
  • Hi Faisal,

    Thanks for the help, particularly suggesting I look in setupapi.dev.log. I'd forgotten about that. When I looked there, I could see that the OS was complaining that the .inf file hash didn't match what was in the .cat file. I looked at the build scripts and noticed some eol changes buried in a post-signing .bat file. After fixing that, it all works.

    So I guess "signtool verify" doesn't check that kind of thing, but instead just looks at the certs on the .cat file alone. That's why the verify succeeded but we still got that warning on install. Good to know!

    Thanks, too, to Pavel and Doron for working through the other possibilities so we could exclude them and get to the real problem!

    Best,

    Rob

    Thursday, April 11, 2013 4:48 PM