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

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: http:> showlists.cfm?list=ntdev>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
></http:></http:>

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
To: Windows System Software Devs Interest List
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_%%” 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

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: http:> showlists.cfm?list=ntdev>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
></http:></http:>

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.

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.

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

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.

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.

Hi Tim,

sorry for the late reply. I’ve been out of the office over the weekend,
including Monday. :wink:

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

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.

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. :wink:

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