Driver Problems? Questions? Issues?
Put OSR's experience to work for you! Contact us for assistance with:
  • Creating the right design for your requirements
  • Reviewing your existing driver code
  • Analyzing driver reliability/performance issues
  • Custom training mixed with consulting and focused directly on your specific areas of interest/concern.
Check us out. OSR, the Windows driver experts.

Monthly Seminars at OSR Headquarters

East Coast USA
Windows Internals and SW Drivers, Dulles (Sterling) VA, 13 November 2017

Kernel Debugging & Crash Analysis for Windows, Nashua (Amherst) NH, 4 December 2017

Writing WDF Drivers I: Core Concepts, Nashua (Amherst) NH, 8 January 2018

WDF Drivers II: Advanced Implementation Techniques, Nashua (Amherst) NH, 15 January 2018


Go Back   OSR Online Lists > ntdev
Welcome, Guest
You must login to post to this list
  Message 1 of 19  
11 Oct 17 13:25
Martin Burnicki
xxxxxx@meinberg.de
Join Date: 11 Oct 2017
Posts To This List: 8
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
  Message 2 of 19  
11 Oct 17 13:32
Mark Roddy
xxxxxx@gmail.com
Join Date: 25 Feb 2000
Posts To This List: 4012
Problem with legacy x64 driver signing

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. <...excess quoted lines suppressed...> --
  Message 3 of 19  
11 Oct 17 13:34
David Mary
xxxxxx@digitalguardian.com
Join Date: 05 Jan 2017
Posts To This List: 3
Problem with legacy x64 driver signing

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
  Message 4 of 19  
12 Oct 17 11:07
Martin Burnicki
xxxxxx@meinberg.de
Join Date: 11 Oct 2017
Posts To This List: 8
Problem with legacy x64 driver signing

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
  Message 5 of 19  
12 Oct 17 11:52
John McNamee
xxxxxx@microwiz.com
Join Date: 02 Apr 2009
Posts To This List: 37
Problem with legacy x64 driver signing

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. > <...excess quoted lines suppressed...>
  Message 6 of 19  
12 Oct 17 12:29
W. D.
xxxxxx@gmail.com
Join Date: 12 Oct 2017
Posts To This List: 40
Problem with legacy x64 driver signing

>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
  Message 7 of 19  
12 Oct 17 12:52
Alan Adams
xxxxxx@novell.com
Join Date: 20 Dec 2010
Posts To This List: 22
Problem with legacy x64 driver signing

"%%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
  Message 8 of 19  
12 Oct 17 12:56
Mark Roddy
xxxxxx@gmail.com
Join Date: 25 Feb 2000
Posts To This List: 4012
Problem with legacy x64 driver signing

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. <...excess quoted lines suppressed...> --
  Message 9 of 19  
12 Oct 17 14:18
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 11622
Problem with legacy x64 driver signing

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.
  Message 10 of 19  
12 Oct 17 14:24
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 11622
Problem with legacy x64 driver signing

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.
  Message 11 of 19  
13 Oct 17 09:35
Martin Burnicki
xxxxxx@meinberg.de
Join Date: 11 Oct 2017
Posts To This List: 8
Problem with legacy x64 driver signing

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?
  Message 12 of 19  
13 Oct 17 10:12
Martin Burnicki
xxxxxx@meinberg.de
Join Date: 11 Oct 2017
Posts To This List: 8
Problem with legacy x64 driver signing

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: > <...excess quoted lines suppressed...> 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
  Message 13 of 19  
13 Oct 17 10:15
Martin Burnicki
xxxxxx@meinberg.de
Join Date: 11 Oct 2017
Posts To This List: 8
Problem with legacy x64 driver signing

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
  Message 14 of 19  
13 Oct 17 10:39
Martin Burnicki
xxxxxx@meinberg.de
Join Date: 11 Oct 2017
Posts To This List: 8
Problem with legacy x64 driver signing

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 <...excess quoted lines suppressed...> 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
  Message 15 of 19  
13 Oct 17 13:10
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 11622
Problem with legacy x64 driver signing

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.
  Message 16 of 19  
13 Oct 17 13:14
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 11622
Problem with legacy x64 driver signing

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.
  Message 17 of 19  
17 Oct 17 12:38
Martin Burnicki
xxxxxx@meinberg.de
Join Date: 11 Oct 2017
Posts To This List: 8
Problem with legacy x64 driver signing

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? <...excess quoted lines suppressed...> 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
  Message 18 of 19  
17 Oct 17 13:01
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 11622
Problem with legacy x64 driver signing

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.
  Message 19 of 19  
17 Oct 17 13:36
Martin Burnicki
xxxxxx@meinberg.de
Join Date: 11 Oct 2017
Posts To This List: 8
Problem with legacy x64 driver signing

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. <...excess quoted lines suppressed...> 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
Posting Rules  
You may not post new threads
You may not post replies
You may not post attachments
You must login to OSR Online AND be a member of the ntdev list to be able to post.

All times are GMT -5. The time now is 02:21.


Copyright ©2015, OSR Open Systems Resources, Inc.
Based on vBulletin Copyright ©2000 - 2005, Jelsoft Enterprises Ltd.
Modified under license