Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Before Posting... Please check out the Community Guidelines in the
Announcements and Administration Category, below.

Problem with legacy x64 driver signing

Hi all,

I'm maintaining a driver package which contains both an x86 and an amd64 kernel driver. An earlier version of the package has been signed with SHA1 before 2016-01-01, and it still works even on x64 Windows.

Now I'm trying to rebuild the package and sign it with a new SHA256 cert, but when I try to install it e.g. on Win7 x64 using the "devcon" utility the driver fails to load with an error saying the signature can't be verified.

In %windir%\inf\setupapi.dev.log I get this error:

Device has problem: 0x34: CM_PROB_UNSIGNED_DRIVER.

This happens even though "signtool /kp" says that the signature of the driver binaries as well as the signature of the .cat file is OK for this purpose, the .sys file is copied correctly, and if I use explorer to check the propertiess of the installed sys file it says, "Digital signature is valid". Only if I enable the TESTSIGNING boot configuration option the driver is loaded and works correctly.

BTW, this is *not* yet for Windows 10 desktop with EV cert, just for legacy Windows x64.

The driver package is available here:
https://www.meinberg.de/download/temp/burnicki/driver.zip

Some associated debug information:
https://www.meinberg.de/download/temp/burnicki/driver-log.txt

Anybody who has an idea what may be wrong? The certificates, even though "signtool /kp" says that everything's fine?

Thanks,

Martin

Comments

  • Mark_RoddyMark_Roddy Posts: 4,265
    You have to have the sha256 kb applied. See
    https://technet.microsoft.com/en-us/library/security/2949927.aspx


    Mark Roddy

    On Wed, Oct 11, 2017 at 1:24 PM, xxxxx@meinberg.de <
    xxxxx@lists.osr.com> wrote:

    > Hi all,
    >
    > I'm maintaining a driver package which contains both an x86 and an amd64
    > kernel driver. An earlier version of the package has been signed with SHA1
    > before 2016-01-01, and it still works even on x64 Windows.
    >
    > Now I'm trying to rebuild the package and sign it with a new SHA256 cert,
    > but when I try to install it e.g. on Win7 x64 using the "devcon" utility
    > the driver fails to load with an error saying the signature can't be
    > verified.
    >
    > In %windir%\inf\setupapi.dev.log I get this error:
    >
    > Device has problem: 0x34: CM_PROB_UNSIGNED_DRIVER.
    >
    > This happens even though "signtool /kp" says that the signature of the
    > driver binaries as well as the signature of the .cat file is OK for this
    > purpose, the .sys file is copied correctly, and if I use explorer to check
    > the propertiess of the installed sys file it says, "Digital signature is
    > valid". Only if I enable the TESTSIGNING boot configuration option the
    > driver is loaded and works correctly.
    >
    > BTW, this is *not* yet for Windows 10 desktop with EV cert, just for
    > legacy Windows x64.
    >
    > The driver package is available here:
    > https://www.meinberg.de/download/temp/burnicki/driver.zip
    >
    > Some associated debug information:
    > https://www.meinberg.de/download/temp/burnicki/driver-log.txt
    >
    > Anybody who has an idea what may be wrong? The certificates, even though
    > "signtool /kp" says that everything's fine?
    >
    > Thanks,
    >
    > Martin
    >
    >
    > ---
    > NTDEV is sponsored by OSR
    >
    > Visit the list online at: showlists.cfm?list=ntdev>
    >
    > MONTHLY seminars on crash dump analysis, WDF, Windows internals and
    > software drivers!
    > Details at
    >
    > To unsubscribe, visit the List Server section of OSR Online at <
    > http://www.osronline.com/page.cfm?name=ListServer>;
    >
  • SHA2 certificates/signatures will only work on Windows 7 with the SHA2
    security patch applied.

    https://technet.microsoft.com/en-us/library/security/3033929.aspx

    Might this be the issue?

    FYI,
    Dave
  • Mark, Dave,

    thanks for your reply.

    I haven't been aware that Win7 needs a specific patch to be able to use SHA2 signatures.

    However, I don't think this is the reason of the problem. I mentioned Win7 x64 as an example only. The same problem exists on a Win 8.1 x64 box, and a Win 10 x64 box that has been upgraded from Win 7.

    I'm afraid the certificates are not the correct ones, even though signtool says they are. Unfortunately I don't know how to find out by looking at the certs if they are appropriate, or not.

    Any further ideas, anybody?

    Thanks,
    Martin
  • You don't have the Microsoft cross-signature.

    "signtool verify /kp amd64\mbgclock.sys" shows the error:

    SignTool Error: Signing Cert does not chain to a Microsoft Root Cert.



    -------- Original Message --------
    Subject: Re: [ntdev] Problem with legacy x64 driver signing
    From: xxxxx@meinberg.de <xxxxx@lists.osr.com>
    To: Windows System Software Devs Interest List <xxxxx@lists.osr.com>
    Date: 10/12/2017 10:06 AM

    > Mark, Dave,
    >
    > thanks for your reply.
    >
    > I haven't been aware that Win7 needs a specific patch to be able to use SHA2 signatures.
    >
    > However, I don't think this is the reason of the problem. I mentioned Win7 x64 as an example only. The same problem exists on a Win 8.1 x64 box, and a Win 10 x64 box that has been upgraded from Win 7.
    >
    > I'm afraid the certificates are not the correct ones, even though signtool says they are. Unfortunately I don't know how to find out by looking at the certs if they are appropriate, or not.
    >
    > Any further ideas, anybody?
    >
    > Thanks,
    > Martin
  • >You don't have the Microsoft cross-signature.

    Microsoft only signs the CAT file (attestation) I think, the binary is not touched, is that correct ?

    Was the user asked to trust the editor ?

    If the user trusts the editor and also check the "Always trust software from The Editor" button then the certificate is added to the machine's certificate store for approved editors.

    Read this:

    https://docs.microsoft.com/en-us/windows-hardware/drivers/install/troubleshooting-driver-signing-installation
  • "%%merge inmail_.HdrFromSpc_%%" <xxxxx@lists.osr.com> wrote:

    > Microsoft only signs the CAT file (attestation) I think, the binary is not touched, is that correct ?

    With attested signing, the binary files receive a Microsoft signature
    too, in addition to the .CAT that is created and given a Microsoft
    signature, and is attributed to only be a valid .CAT for the Windows
    10 platform(s) that were selected.

    The fact that the binary files receive a Microsoft signature too is
    why the attested signing process can work even for products which do
    NOT use an .INF to install their driver(s). You have to use a "dummy"
    .INF file to make it through the attested signing process, but then
    you take just the binary files and use whatever MSI-based or direct
    CreateService-type installation you've always been doing. Windows
    agrees to load the driver because of the embedded Microsoft signature
    in the binary file itself.

    > If the user trusts the editor and also check the "Always trust software from The Editor"
    > button then the certificate is added to the machine's certificate store for approved editors.

    That does also bring to mind one additional issue for the Windows 7
    platform, besides the need for the SHA256 KB 3033929 update.

    The "Always trust" checkbox does not actually work, if the certificate
    that would be added to the Trusted Publishers is an SHA256
    certificate. Meaning the checkbox is offered, and the user can
    successfully select it, but it doesn't have any future effect. Upon
    encountering "The Editor" software again in the future, the user would
    again be prompted.

    This is resolved by applying the separate Windows 7 KB 2921916.

    Alan Adams
    Client for Open Enterprise Server
    Micro Focus
    xxxxx@microfocus.com
  • Mark_RoddyMark_Roddy Posts: 4,265
    OK so you should have mentioned that it wasn't working *anywhere*.
    Obviously you have not signed it correctly. However, win7 also has to have
    the sha2 kbs installed or it still won't work on that platform. 8.1 and 10
    come with sha2 support.

    Mark Roddy

    On Thu, Oct 12, 2017 at 11:06 AM, xxxxx@meinberg.de <
    xxxxx@lists.osr.com> wrote:

    > Mark, Dave,
    >
    > thanks for your reply.
    >
    > I haven't been aware that Win7 needs a specific patch to be able to use
    > SHA2 signatures.
    >
    > However, I don't think this is the reason of the problem. I mentioned Win7
    > x64 as an example only. The same problem exists on a Win 8.1 x64 box, and a
    > Win 10 x64 box that has been upgraded from Win 7.
    >
    > I'm afraid the certificates are not the correct ones, even though signtool
    > says they are. Unfortunately I don't know how to find out by looking at the
    > certs if they are appropriate, or not.
    >
    > Any further ideas, anybody?
    >
    > Thanks,
    > Martin
    >
    >
    > ---
    > NTDEV is sponsored by OSR
    >
    > Visit the list online at: showlists.cfm?list=ntdev>
    >
    > MONTHLY seminars on crash dump analysis, WDF, Windows internals and
    > software drivers!
    > Details at
    >
    > To unsubscribe, visit the List Server section of OSR Online at <
    > http://www.osronline.com/page.cfm?name=ListServer>;
    >
  • Tim_RobertsTim_Roberts Posts: 12,568
    xxxxx@gmail.com wrote:
    >> You don't have the Microsoft cross-signature.
    > Microsoft only signs the CAT file (attestation) I think, the binary is not touched, is that correct ?

    No.  In attestation, Microsoft adds a signature to every binary in the
    package.  They then create a brand-new CAT file, and sign that.

    However, that has nothing to do with cross-signing.

    --
    Tim Roberts, xxxxx@probo.com
    Providenza & Boekelheide, Inc.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • Tim_RobertsTim_Roberts Posts: 12,568
    xxxxx@microwiz.com wrote:
    >
    > You don't have the Microsoft cross-signature.
    >
    > "signtool verify /kp amd64\mbgclock.sys" shows the error:
    >
    > SignTool Error: Signing Cert does not chain to a Microsoft Root Cert.

    To stop this thread from going any further awry, THIS is definitively
    the correct diagnosis of the problem, and kudos to the original poster
    for letting us examine his actual driver package.

    To the OP, you signed your package with a GlobalSign certificate. 
    Windows doesn't know from GlobalSign.  In order for Windows to accept
    your signature, you have to sign it with a "cross-certificate", which
    essentially is a Microsoft-issued certificate that says "we trust
    GlobalSign".  Windows only looks for the "Microsoft Code Verification
    Root" certificate.

    If you were building this with a newer WDK, the tools can choose the
    correct cross-certificate for you.  If you are signing using your own
    tools, you will have to go to this page to fetch the proper certificate:
        http://www.microsoft.com/whdc/winlogo/drvsign/crosscert.mspx

    You then use the /ac parameter to "signtool sign" to point to the cross
    certificate.  Once you have done that, if you do "signtool verify /v
    /kp", you should see the "Microsoft Code Vertification Root" in your
    certificate chain.  That's what allows it to work.

    --
    Tim Roberts, xxxxx@probo.com
    Providenza & Boekelheide, Inc.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • xxxxx@microwiz.com wrote:
    > You don't have the Microsoft cross-signature.
    >
    > "signtool verify /kp amd64\mbgclock.sys" shows the error:
    >
    > SignTool Error: Signing Cert does not chain to a Microsoft Root Cert.

    Wow. From which package is the signtool version you are running?

    When I started investigating I found that I'd have to use signtool from
    Windows SDK for Windows 8.1. I've also installed the SDK for Windows 10,
    but that one doesn't include signtool.

    If I run signtool from SDK 8.1 against the driver binary I've uploaded,
    I get this:

    "signtool verify /v /kp amd64\mbgclock.sys"

    Verifying: amd64\mbgclock.sys

    Signature Index: 0 (Primary Signature)
    Hash of file (sha256):
    058125091A16A597BD117AF8ED459852BE4509CCD05DE5A1416F4A17E0FBD9B3

    Signing Certificate Chain:
    Issued to: GlobalSign Root CA
    Issued by: GlobalSign Root CA
    Expires: Fri Jan 28 14:00:00 2028
    SHA1 hash: B1BC968BD4F49D622AA89A81F2150152A41D829C

    Issued to: GlobalSign
    Issued by: GlobalSign Root CA
    Expires: Mon Mar 18 12:00:00 2019
    SHA1 hash: 4765557AF418C68A641199146A7E556AA8242996

    Issued to: GlobalSign CodeSigning CA - SHA256 - G3
    Issued by: GlobalSign
    Expires: Sat Jun 15 02:00:00 2024
    SHA1 hash: 090D03435EB2A8364F79B78CB173D35E8EB63558

    Issued to: Meinberg Funkuhren GmbH & Co. KG
    Issued by: GlobalSign CodeSigning CA - SHA256 - G3
    Expires: Sun Sep 15 11:20:14 2019
    SHA1 hash: FDB08D99B61F95D7881B8CDA5EB6638F7F410CF6

    The signature is timestamped: Wed Oct 11 18:30:48 2017
    Timestamp Verified by:
    Issued to: GlobalSign Root CA
    Issued by: GlobalSign Root CA
    Expires: Fri Jan 28 14:00:00 2028
    SHA1 hash: B1BC968BD4F49D622AA89A81F2150152A41D829C

    Issued to: GlobalSign Timestamping CA - G2
    Issued by: GlobalSign Root CA
    Expires: Fri Jan 28 14:00:00 2028
    SHA1 hash: C0E49D2D7D90A5CD427F02D9125694D5D6EC5B71

    Issued to: GlobalSign TSA for Standard - G2
    Issued by: GlobalSign Timestamping CA - G2
    Expires: Thu Jun 24 02:00:00 2027
    SHA1 hash: 83FDE1BA76FEF55291B50D6861906DAA45B58CB5

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

    Issued to: GlobalSign Root CA
    Issued by: Microsoft Code Verification Root
    Expires: Thu Apr 15 22:05:08 2021
    SHA1 hash: CC1DEEBF6D55C2C9061BA16F10A0BFA6979A4A32

    Issued to: GlobalSign
    Issued by: GlobalSign Root CA
    Expires: Mon Mar 18 12:00:00 2019
    SHA1 hash: 4765557AF418C68A641199146A7E556AA8242996

    Issued to: GlobalSign CodeSigning CA - SHA256 - G3
    Issued by: GlobalSign
    Expires: Sat Jun 15 02:00:00 2024
    SHA1 hash: 090D03435EB2A8364F79B78CB173D35E8EB63558

    Issued to: Meinberg Funkuhren GmbH & Co. KG
    Issued by: GlobalSign CodeSigning CA - SHA256 - G3
    Expires: Sun Sep 15 11:20:14 2019
    SHA1 hash: FDB08D99B61F95D7881B8CDA5EB6638F7F410CF6

    Successfully verified: uploaded\amd64\mbgclock.sys

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


    So why is my signtool saying that everything's OK but your signtool says
    that it's not?
  • xxxxx@gmail.com wrote:
    >> You don't have the Microsoft cross-signature.
    >
    > Microsoft only signs the CAT file (attestation) I think, the binary is not touched, is that correct ?
    >
    > Was the user asked to trust the editor ?
    >
    > If the user trusts the editor and also check the "Always trust software from The Editor" button then the certificate is added to the machine's certificate store for approved editors.
    >
    > Read this:
    >
    > https://docs.microsoft.com/en-us/windows-hardware/drivers/install/troubleshooting-driver-signing-installation

    Thanks. I'm going to have a look at this. However, if I understand this
    correctly, this only determines whether the question will be asked next
    time again, or not.

    Martin
  • xxxxx@gmail.com wrote:
    > OK so you should have mentioned that it wasn't working *anywhere*.
    > Obviously you have not signed it correctly. However, win7 also has to
    > have the sha2 kbs installed or it still won't work on that platform. 8.1
    > and 10 come with sha2 support.

    I said "e.g. on Win7 x64" since I hadn't been aware that it makes a
    difference, compared to Win 8.1, etc. I just learned this from earlier
    replies here. Sorry for the confusion.

    Martin
  • Tim,

    see also my earlier reply regarding signtool.

    xxxxx@probo.com wrote:
    > xxxxx@microwiz.com wrote:
    >>
    >> You don't have the Microsoft cross-signature.
    >>
    >> "signtool verify /kp amd64\mbgclock.sys" shows the error:
    >>
    >> SignTool Error: Signing Cert does not chain to a Microsoft Root Cert.
    >
    > To stop this thread from going any further awry, THIS is definitively
    > the correct diagnosis of the problem, and kudos to the original poster
    > for letting us examine his actual driver package.

    I've been assuming that it's a certificate problem.

    > To the OP, you signed your package with a GlobalSign certificate. 
    > Windows doesn't know from GlobalSign.  In order for Windows to accept
    > your signature, you have to sign it with a "cross-certificate", which
    > essentially is a Microsoft-issued certificate that says "we trust
    > GlobalSign".  Windows only looks for the "Microsoft Code Verification
    > Root" certificate.

    Indeed, when I first tried the SHA-256 certificate, my signtool version
    also said that the cross certificate was missing. I then contacted
    GlobalSign support who pointed me to a link to another cert which should
    be the missing cross cert. They also said I had to import the cert into
    the Windows cert store on my development machine, and after I had done
    that, my signtool was happy with the newly signed binaries.

    > If you were building this with a newer WDK, the tools can choose the
    > correct cross-certificate for you.  If you are signing using your own
    > tools, you will have to go to this page to fetch the proper certificate:
    >     http://www.microsoft.com/whdc/winlogo/drvsign/crosscert.mspx

    The layout of that page is pretty confusing, IMO. Anyway, I'm sure I
    have also downloaded and imported the Globalsign cert from that page,
    but I'm going to double-check this.

    > You then use the /ac parameter to "signtool sign" to point to the cross
    > certificate.  Once you have done that, if you do "signtool verify /v
    > /kp", you should see the "Microsoft Code Vertification Root" in your
    > certificate chain.  That's what allows it to work.

    Hm, it looks like "Microsoft Code Vertification Root" is listed in the
    output. See my previous email.

    Very strange, or I'm some kind of blind to see the reason of the problem.

    Thanks,

    Martin
  • Tim_RobertsTim_Roberts Posts: 12,568
    xxxxx@meinberg.de wrote:
    > xxxxx@microwiz.com wrote:
    >> You don't have the Microsoft cross-signature.
    >>
    >> "signtool verify /kp amd64\mbgclock.sys" shows the error:
    >>
    >> SignTool Error: Signing Cert does not chain to a Microsoft Root Cert.
    > Wow. From which package is the signtool version you are running?

    I tried the Windows 10 WDK, the 8.1 WDK, the 8.0 WDK, and even the
    Windows 7 SDK.  All give the same result, and I confirmed it with a hex
    editor.

     
    > When I started investigating I found that I'd have to use signtool from
    > Windows SDK for Windows 8.1. I've also installed the SDK for Windows 10,
    > but that one doesn't include signtool.

    Signtool should be part of the WDK.

     
    > If I run signtool from SDK 8.1 against the driver binary I've uploaded,
    > I get this:

    This cannot be the driver package you uploaded.  I am looking at the
    both the .CAT file and the .SYS file from that package in a hex editor. 
    There are more than 5,200 bytes of certificates in these files, but
    nowhere does the string "Code Verification Root" appear.   The odd thing
    is that the signed timestamps in our two listings are identical (modulo
    the timezone difference).  What are your file lengths?

     Directory of C:\tmp\x
    10/11/2017  06:30 PM            12,487 meinberg.cat
    10/11/2017  10:12 AM            11,367 meinberg.inf
     Directory of C:\tmp\x\amd64
    10/11/2017  06:30 PM            70,480 mbgclock.sys
     Directory of C:\tmp\x\i386
    10/11/2017  06:30 PM            47,824 mbgclock.sys


    > So why is my signtool saying that everything's OK but your signtool says
    > that it's not?

    Well, it's more than signtool.  Thanks to the hex editor, I can assert
    with confidence that the file I'm looking at is not the same file as the
    one whose output you showed us.  The cross certificate is simply not
    there.  Is it possible you ran signtool again with the /ac after you
    made the zip?

    And have you tried installing that exact package?  Because that should
    work just fine.

    C:\tmp\x>"\Program Files (x86)\Windows Kits\8.1\bin\x86\signtool.exe"
    verify  /v /kp amd64\mbgclock.sys    
                                                                                                               

    Verifying:
    amd64\mbgclock.sys                                                                              

    Signature Index: 0 (Primary
    Signature)                                                                     

    Hash of file (sha256):
    058125091A16A597BD117AF8ED459852BE4509CCD05DE5A1416F4A17E0FBD9B3                    

                                                                                                               

    Signing Certificate
    Chain:                                                                                 

        Issued to: GlobalSign Root
    CA                                                                          

        Issued by: GlobalSign Root
    CA                                                                          

        Expires:   Fri Jan 28 05:00:00
    2028                                                                    
        SHA1 hash:
    B1BC968BD4F49D622AA89A81F2150152A41D829C                                                    

                                                                                                               

            Issued to:
    GlobalSign                                                                              

            Issued by: GlobalSign Root
    CA                                                                      
            Expires:   Mon Mar 18 03:00:00
    2019                                                                
            SHA1 hash:
    4765557AF418C68A641199146A7E556AA8242996                                                

                                                                                                               

                Issued to: GlobalSign CodeSigning CA - SHA256 -
    G3                                             
                Issued by:
    GlobalSign                                                                          

                Expires:   Fri Jun 14 17:00:00
    2024                                                            
                SHA1 hash:
    090D03435EB2A8364F79B78CB173D35E8EB63558                                            

                                                                                                               

                    Issued to: Meinberg Funkuhren GmbH & Co.
    KG                                                
                    Issued by: GlobalSign CodeSigning CA - SHA256 -
    G3                                         
                    Expires:   Sun Sep 15 02:20:14
    2019                                                        
                    SHA1 hash:
    FDB08D99B61F95D7881B8CDA5EB6638F7F410CF6                                        

                                                                                                               

    The signature is timestamped: Wed Oct 11 09:30:48
    2017                                                     
    Timestamp Verified
    by:                                                                                     

        Issued to: GlobalSign Root
    CA                                                                          

        Issued by: GlobalSign Root
    CA                                                                          

        Expires:   Fri Jan 28 05:00:00
    2028                                                                    
        SHA1 hash:
    B1BC968BD4F49D622AA89A81F2150152A41D829C                                                    

                                                                                                               

            Issued to: GlobalSign Timestamping CA -
    G2                                                         
            Issued by: GlobalSign Root
    CA                                                                      
            Expires:   Fri Jan 28 05:00:00
    2028                                                                
            SHA1 hash:
    C0E49D2D7D90A5CD427F02D9125694D5D6EC5B71                                                

                                                                                                               

                Issued to: GlobalSign TSA for Standard -
    G2                                                    
                Issued by: GlobalSign Timestamping CA -
    G2                                                     
                Expires:   Wed Jun 23 17:00:00
    2027                                                            
                SHA1 hash:
    83FDE1BA76FEF55291B50D6861906DAA45B58CB5                                            

                                                                                                               

    SignTool Error: Signing Cert does not chain to a Microsoft Root
    Cert.                                      
                                                                                                               

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

    Number of errors:
    1                                                                                        

                                                                                                               

    C:\tmp\x>


    --
    Tim Roberts, xxxxx@probo.com
    Providenza & Boekelheide, Inc.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • Tim_RobertsTim_Roberts Posts: 12,568
    I see my signtool output got screwed up in the cut-and-paste. Trying again.

    xxxxx@meinberg.de wrote:
    > xxxxx@microwiz.com wrote:
    >> You don't have the Microsoft cross-signature.
    >>
    >> "signtool verify /kp amd64\mbgclock.sys" shows the error:
    >>
    >> SignTool Error: Signing Cert does not chain to a Microsoft Root Cert.
    > Wow. From which package is the signtool version you are running?

    I tried the Windows 10 WDK, the 8.1 WDK, the 8.0 WDK, and even the
    Windows 7 SDK.  All give the same result, and I confirmed it with a hex
    editor.

     
    > When I started investigating I found that I'd have to use signtool from
    > Windows SDK for Windows 8.1. I've also installed the SDK for Windows 10,
    > but that one doesn't include signtool.

    Signtool should be part of the WDK.

     
    > If I run signtool from SDK 8.1 against the driver binary I've uploaded,
    > I get this:

    This cannot be the driver package you uploaded.  I am looking at the
    both the .CAT file and the .SYS file from that package in a hex editor.
    There are more than 5,200 bytes of certificates in these files, but
    nowhere does the string "Code Verification Root" appear.   The odd thing
    is that the signed timestamps in our two listings are identical (modulo
    the timezone difference).  What are your file lengths?

     Directory of C:\tmp\x
    10/11/2017  06:30 PM            12,487 meinberg.cat
    10/11/2017  10:12 AM            11,367 meinberg.inf
     Directory of C:\tmp\x\amd64
    10/11/2017  06:30 PM            70,480 mbgclock.sys
     Directory of C:\tmp\x\i386
    10/11/2017  06:30 PM            47,824 mbgclock.sys


    > So why is my signtool saying that everything's OK but your signtool says
    > that it's not?

    Well, it's more than signtool.  Thanks to the hex editor, I can assert
    with confidence that the file I'm looking at is not the same file as the
    one whose output you showed us.  The cross certificate is simply not
    there.  Is it possible you ran signtool again with the /ac after you
    made the zip?

    And have you tried installing that exact package?  Because that should
    work just fine.

    Verifying: amd64\mbgclock.sys
    Hash of file (sha256):
    058125091A16A597BD117AF8ED459852BE4509CCD05DE5A1416F4A17E0FBD9B3

    Signing Certificate Chain:
    Issued to: GlobalSign Root CA
    Issued by: GlobalSign Root CA
    Expires: Fri Jan 28 05:00:00 2028
    SHA1 hash: B1BC968BD4F49D622AA89A81F2150152A41D829C

    Issued to: GlobalSign
    Issued by: GlobalSign Root CA
    Expires: Mon Mar 18 03:00:00 2019
    SHA1 hash: 4765557AF418C68A641199146A7E556AA8242996

    Issued to: GlobalSign CodeSigning CA - SHA256 - G3
    Issued by: GlobalSign
    Expires: Fri Jun 14 17:00:00 2024
    SHA1 hash: 090D03435EB2A8364F79B78CB173D35E8EB63558

    Issued to: Meinberg Funkuhren GmbH & Co. KG
    Issued by: GlobalSign CodeSigning CA - SHA256 - G3
    Expires: Sun Sep 15 02:20:14 2019
    SHA1 hash: FDB08D99B61F95D7881B8CDA5EB6638F7F410CF6

    The signature is timestamped: Wed Oct 11 09:30:48 2017
    Timestamp Verified by:
    Issued to: GlobalSign Root CA
    Issued by: GlobalSign Root CA
    Expires: Fri Jan 28 05:00:00 2028
    SHA1 hash: B1BC968BD4F49D622AA89A81F2150152A41D829C

    Issued to: GlobalSign Timestamping CA - G2
    Issued by: GlobalSign Root CA
    Expires: Fri Jan 28 05:00:00 2028
    SHA1 hash: C0E49D2D7D90A5CD427F02D9125694D5D6EC5B71

    Issued to: GlobalSign TSA for Standard - G2
    Issued by: GlobalSign Timestamping CA - G2
    Expires: Wed Jun 23 17:00:00 2027
    SHA1 hash: 83FDE1BA76FEF55291B50D6861906DAA45B58CB5

    SignTool Error: Signing Cert does not chain to a Microsoft Root Cert.

    Number of files successfully Verified: 0
    Number of warnings: 0
    Number of errors: 1
    C:\tmp\x>


    --
    Tim Roberts, xxxxx@probo.com
    Providenza & Boekelheide, Inc.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • Hi Tim,

    sorry for the late reply. I've been out of the office over the weekend,
    including Monday. ;-)

    xxxxx@probo.com wrote:
    > I see my signtool output got screwed up in the cut-and-paste. Trying again.
    >
    > xxxxx@meinberg.de wrote:
    >> xxxxx@microwiz.com wrote:
    >>> You don't have the Microsoft cross-signature.
    >>>
    >>> "signtool verify /kp amd64\mbgclock.sys" shows the error:
    >>>
    >>> SignTool Error: Signing Cert does not chain to a Microsoft Root Cert.
    >> Wow. From which package is the signtool version you are running?
    >
    > I tried the Windows 10 WDK, the 8.1 WDK, the 8.0 WDK, and even the
    > Windows 7 SDK.  All give the same result, and I confirmed it with a hex
    > editor.
    >
    >  
    >> When I started investigating I found that I'd have to use signtool from
    >> Windows SDK for Windows 8.1. I've also installed the SDK for Windows 10,
    >> but that one doesn't include signtool.
    >
    > Signtool should be part of the WDK.

    Yes, of course.

    Thanks to your help I've found the reason for the error.

    Before I posted to this list I've been playing around a lot with
    different certs, also from GlobalSign.

    One of their hints was to import the certs into my PC's cert store, and
    *don't* use signtool's /ac option to specify the cross cert, since
    signtool would figure out the certs to be added automatically.

    I did this on my development machine, and "signtool /kp" was happy with
    the signed driver files I had uploaded, even though the cross cert had
    indeed not been added to the file.

    However, "signtool /kp" obviously dosn't look only at the certs in the
    driver files, so it found the missing cross cert in my PC's cert store
    and everything was fine.

    I then installed WDK 8.1 on a different machine and when I ran "signtool
    /kp" there against the files I had uploaded I got the same error as you
    got, since the GlobalSign cross cert was not installed on that PC.

    So finally I used the /ac option to explicitly specify the cross cert
    when signing, and now "signtool /kp" is happy also on the new machine.

    So the different output from signtool that you posted led me on the
    right track to find the reason of this problem.

    Personally, I find it a little bit confusing that "signtool /kp" also
    uses the certs from the cert store when it should try to verify the
    signature appended to the driver file, but of course there may be
    specific reasons for this.

    In the mean time I found out that "import the cert and *don't* use /ac"
    is probably the appropriate way to prepare a driver cab file with an EV
    cert, to get it signed by Microsoft. This will be the next step to do
    for me.

    Looks like GlobalSign have modified the relevant support web pages in
    the mean time. The information there is now much clearer then it was
    when I started working on this.

    I've also re-enabled dual signing of the driver with SHA1 and SHA256,
    and this seems to be working, too. I'll have to do some more testing,
    though.

    For anyone who's interested, the newly signed files are here:
    https://www.meinberg.de/download/temp/burnicki/driver-fixed.zip

    Thanks to everybody who contributed!


    Martin
    --
    Martin Burnicki

    Senior Software Engineer

    MEINBERG Funkuhren GmbH & Co. KG
    Email: xxxxx@meinberg.de
    Phone: +49 (0)5281 9309-14
    Linkedin: https://www.linkedin.com/in/martinburnicki/

    Lange Wand 9, 31812 Bad Pyrmont, Germany
    Amtsgericht Hannover 17HRA 100322
    Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg,
    Andre Hartmann, Heiko Gerstung
    Websites: https://www.meinberg.de https://www.meinbergglobal.com
    Training: https://www.meinberg.academy
  • Tim_RobertsTim_Roberts Posts: 12,568
    xxxxx@meinberg.de wrote:
    >
    > Thanks to your help I've found the reason for the error.
    >
    > Before I posted to this list I've been playing around a lot with
    > different certs, also from GlobalSign.
    >
    > One of their hints was to import the certs into my PC's cert store, and
    > *don't* use signtool's /ac option to specify the cross cert, since
    > signtool would figure out the certs to be added automatically.

    I'm pretty sure that's not true.  The WDK extensions to Visual Studio
    certainly do have the magic ability to look up the correct
    cross-certificate, and it will provide the correct /ac parameter, but as
    far as I know "signtool sign" has never had this ability.


    > In the mean time I found out that "import the cert and *don't* use /ac"
    > is probably the appropriate way to prepare a driver cab file with an EV
    > cert, to get it signed by Microsoft. This will be the next step to do
    > for me.

    Right.  Cross-signing is only an issue for KMCS.  The
    sysdev/WHQL/dashboard process does not care about cross-signing at all. 
    In fact, you don't have to sign your driver files in a submission; all
    you have to sign is the cabinet.

    --
    Tim Roberts, xxxxx@probo.com
    Providenza & Boekelheide, Inc.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • xxxxx@probo.com wrote:
    > xxxxx@meinberg.de wrote:
    >>
    >> Thanks to your help I've found the reason for the error.
    >>
    >> Before I posted to this list I've been playing around a lot with
    >> different certs, also from GlobalSign.
    >>
    >> One of their hints was to import the certs into my PC's cert store, and
    >> *don't* use signtool's /ac option to specify the cross cert, since
    >> signtool would figure out the certs to be added automatically.
    >
    > I'm pretty sure that's not true.

    Now I know this, too. ;-)

    > The WDK extensions to Visual Studio
    > certainly do have the magic ability to look up the correct
    > cross-certificate, and it will provide the correct /ac parameter, but as
    > far as I know "signtool sign" has never had this ability.

    I'm not using a current version of VS for driver development. I just run
    signtool as specified in my on nmake makefile. This used to work for
    many years now for the older SHA1 signatures.

    >> In the mean time I found out that "import the cert and *don't* use /ac"
    >> is probably the appropriate way to prepare a driver cab file with an EV
    >> cert, to get it signed by Microsoft. This will be the next step to do
    >> for me.
    >
    > Right.  Cross-signing is only an issue for KMCS.  The
    > sysdev/WHQL/dashboard process does not care about cross-signing at all. 
    > In fact, you don't have to sign your driver files in a submission; all
    > you have to sign is the cabinet.

    Yes. That will be the next step I have to do.


    Thanks again,

    Martin
    --
    Martin Burnicki

    Senior Software Engineer

    MEINBERG Funkuhren GmbH & Co. KG
    Email: xxxxx@meinberg.de
    Phone: +49 (0)5281 9309-14
    Linkedin: https://www.linkedin.com/in/martinburnicki/

    Lange Wand 9, 31812 Bad Pyrmont, Germany
    Amtsgericht Hannover 17HRA 100322
    Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg,
    Andre Hartmann, Heiko Gerstung
    Websites: https://www.meinberg.de https://www.meinbergglobal.com
    Training: https://www.meinberg.academy
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!