I’ve read lots of posts both here and at the MSDN support forums, but nothing that addresses my problem. Any thought would be welcome.
I am working on a tool that includes a filter driver in the storage stack. Since it will need to work on Vista 64, the driver needs to be signed, and I am at wits’ end trying to get the signing to work.
The msi installer package is built as a VS 2005 project. There is no .cat file or .inf file, just the .sys file. The first time the user opens the app that needs the driver, they are informed that they need to install it, which they can do from a menu. The installation consists of copying the driver file to windows\system32\drivers, and setting the registry to load the driver as an upper filter. (I inherited the project; I don’t know why it was done that way, but it works fine on 32-bit systems and on Vista 64 with test signing enabled.)
I got a certificate from our corporate site. Its certification path is:
GeoTrust (Equifax under the hood)
Intel External Basic Policy CA
Intel External Basic Issuing CA 3A
Intel Code Signing External Cert for IPEAK External Cert
I downloaded the cross cert for Equifax from MS, and signed the driver thus:
C:\WinDDK\6001.18001>signtool sign /v /ac EquifaxSecureCertAuth.cer /s My /n “I
PEAK External Cert” c:\Data\IPEAK_Storage_Toolkit\SPT\bin\amd64\mydriver.sys
The following certificate was selected:
Issued to: IPEAK External Cert
Issued by: Intel External Basic Issuing CA 3A
Expires: 3/22/2012 3:32:42 PM
SHA1 hash:
Done Adding Additional Store
Attempting to sign: c:\Data\IPEAK_Storage_Toolkit\SPT\bin\amd64\mydriver.sys Successfully signed: c:\Data\IPEAK_Storage_Toolkit\SPT\bin\amd64\mydriver.sys
Number of files successfully Signed: 1 Number of warnings: 0 Number of errors: 0 ==========
Then I rebuild the installer, bundling the driver into the msi. I also export my cert to a pfx file, and add it to the store on my text box. I install the tool on the Vista 64 test box, and install the driver using the method shown above.
When I reboot the Vista 64 test box, it always fails with the message : File: \Windows\System32\Drivers\mydriver.sys Status: 0xc0000428 Info: Windows cannot verify the digital signature for this file.
At that point I have to reboot to the last known good configuration, after which I can run certmgr.msc and look at the different certs. Everything looks exactly the same as it did on the signing box. If I right-click on the driver file in Explorer and view properties, it also says the signature is ok.
At this point I don’t know what else to try, since everything looks like it should work.
I’ve read lots of posts both here and at the MSDN support forums, but nothing that addresses my problem. Any thought would be welcome.
I am working on a tool that includes a filter driver in the storage stack. Since it will need to work on Vista 64, the driver needs to be signed, and I am at wits’ end trying to get the signing to work.
The msi installer package is built as a VS 2005 project. There is no .cat file or .inf file, just the .sys file. The first time the user opens the app that needs the driver, they are informed that they need to install it, which they can do from a menu. The installation consists of copying the driver file to windows\system32\drivers, and setting the registry to load the driver as an upper filter. (I inherited the project; I don’t know why it was done that way, but it works fine on 32-bit systems and on Vista 64 with test signing enabled.)
I got a certificate from our corporate site. Its certification path is:
GeoTrust (Equifax under the hood)
Intel External Basic Policy CA
Intel External Basic Issuing CA 3A
Intel Code Signing External Cert for IPEAK External Cert
I downloaded the cross cert for Equifax from MS, and signed the driver thus:
Did you verify the signing chain after you signed it? Try this:
signtool verify /kp /v mydriver.sys
You must see an entire chain starting from “Microsoft Code Verification
Root”, going all the way through GeoTrust and ending at your IPEAK cert.
I’m not convinced that “Equifax under the hood” is the same as Equifax.
Certificates have to match exactly. There is a GeoTrust cross
certificate; did you try that?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
How do you copy the driver files? In particular, is the file copied by a
32-bit or by a 64-bit application?
On Vista Microsoft does some “virtualization” of system-related paths. A
32-bit application attempting to deal with the path “\Windows\System32” ( a
folder for 64-bit binaries on a 64-bit system) actually accesses
“\Windows\SysWow64” (a folder for 32-bit binaries on a 64-bit system).
If the VS2005 MSI does the copy, then there is a Special Folder for 64-bit
components.
Perhaps it can’t verify the SYS because it isn’t in the right folder.
In addition, copying files to the System32 folder and tinkering with
registry entries that load drivers both require elevated privileges.
Good luck,
Thomas
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-360122- xxxxx@lists.osr.com] On Behalf Of xxxxx@intel.com
Sent: Wednesday, April 01, 2009 2:33 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] More driver signing woes
Hi,
I’ve read lots of posts both here and at the MSDN support forums, but
nothing that addresses my problem. Any thought would be welcome.
I am working on a tool that includes a filter driver in the storage
stack. Since it will need to work on Vista 64, the driver needs to be
signed, and I am at wits’ end trying to get the signing to work.
The msi installer package is built as a VS 2005 project. There is no
.cat file or .inf file, just the .sys file. The first time the user
opens the app that needs the driver, they are informed that they need
to install it, which they can do from a menu. The installation consists
of copying the driver file to windows\system32\drivers, and setting the
registry to load the driver as an upper filter. (I inherited the
project; I don’t know why it was done that way, but it works fine on
32-bit systems and on Vista 64 with test signing enabled.)
I got a certificate from our corporate site. Its certification path is:
GeoTrust (Equifax under the hood)
Intel External Basic Policy CA
Intel External Basic Issuing CA 3A
Intel Code Signing External Cert for IPEAK External Cert
I downloaded the cross cert for Equifax from MS, and signed the driver
thus:
C:\WinDDK\6001.18001>signtool sign /v /ac EquifaxSecureCertAuth.cer /s
My /n “I
PEAK External Cert”
c:\Data\IPEAK_Storage_Toolkit\SPT\bin\amd64\mydriver.sys
The following certificate was selected:
Issued to: IPEAK External Cert
Issued by: Intel External Basic Issuing CA 3A
Expires: 3/22/2012 3:32:42 PM
SHA1 hash: > > Done Adding Additional Store > > Attempting to sign: > c:\Data\IPEAK_Storage_Toolkit\SPT\bin\amd64\mydriver.sys > Successfully signed: > c:\Data\IPEAK_Storage_Toolkit\SPT\bin\amd64\mydriver.sys > > Number of files successfully Signed: 1 > Number of warnings: 0 > Number of errors: 0 > ========== > > Then I rebuild the installer, bundling the driver into the msi. > I also export my cert to a pfx file, and add it to the store on my text > box. > I install the tool on the Vista 64 test box, and install the driver > using the method shown above. > > When I reboot the Vista 64 test box, it always fails with the message : > File: \Windows\System32\Drivers\mydriver.sys > Status: 0xc0000428 > Info: Windows cannot verify the digital signature for this file. > > At that point I have to reboot to the last known good configuration, > after which I can run certmgr.msc and look at the different certs. > Everything looks exactly the same as it did on the signing box. If I > right-click on the driver file in Explorer and view properties, it also > says the signature is ok. > > At this point I don’t know what else to try, since everything looks > like it should work. > > Thanks, > Dennis > > > — > NTDEV is sponsored by OSR > > For our schedule of WDF, WDM, debugging and other seminars visit: > http://www.osr.com/seminars > > To unsubscribe, visit the List Server section of OSR Online at > http://www.osronline.com/page.cfm?name=ListServer
“Equifax under the hood” was just my comment that it was really an Equifax cert and that GeoTrust was just the friendly name.
I downloaded the GeoTrust cross-cert, but it fails the same way. However, when I run the signtool verify command, the Equifax cert is at the top of the list, not “Microsoft Code Verification Root.” I suspect that may be my problem, but I have no idea how to add that to the signtool sign command. The command doesn’t accept more than one “/ac” option. I have a feeling that I’m missing some small step, but the light hasn’t come on yet.
Thomas,
I checked via Explorer, and my driver is in system32, not sysWOW64. Also, regedit shows the entries in the correct places. The app that does the copy and the registry entries is a 64-bit app, and the driver is also 64-bit.
Thank you both for the replies. I think I’m getting closer.
Dennis
“Equifax under the hood” was just my comment that it was really an Equifax cert and that GeoTrust was just the friendly name.
I downloaded the GeoTrust cross-cert, but it fails the same way. However, when I run the signtool verify command, the Equifax cert is at the top of the list, not “Microsoft Code Verification Root.” I suspect that may be my problem, but I have no idea how to add that to the signtool sign command. The command doesn’t accept more than one “/ac” option. I have a feeling that I’m missing some small step, but the light hasn’t come on yet.
You should only need one cross-certificate, but it absolutely must be
the CORRECT cross-certificate. The cross-certificate does more than say
“certificates from GeoTrust are OK”. It links from one specific
certificate provider instance to the Microsoft root. If your corporate
certificate was not issued by the normal Equifax or GeoTrust
code-signing certificate authority, then you can’t use it for KMCS.
The top of the trust chain must be the “Microsoft Code Verification
Root”. That is the only way to satisfy KMCS.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Try the corss cert of GeoTrust Global CA, probably it can work.
Btw, if you just want to run it for test, you don’t need to sign it. Just
choose disable Digital Signing after press F8 in Windows boot menu.
wrote in message news:xxxxx@ntdev… > Hi, > > I’ve read lots of posts both here and at the MSDN support forums, but > nothing that addresses my problem. Any thought would be welcome. > > I am working on a tool that includes a filter driver in the storage stack. > Since it will need to work on Vista 64, the driver needs to be signed, and > I am at wits’ end trying to get the signing to work. > > The msi installer package is built as a VS 2005 project. There is no .cat > file or .inf file, just the .sys file. The first time the user opens the > app that needs the driver, they are informed that they need to install it, > which they can do from a menu. The installation consists of copying the > driver file to windows\system32\drivers, and setting the registry to load > the driver as an upper filter. (I inherited the project; I don’t know why > it was done that way, but it works fine on 32-bit systems and on Vista 64 > with test signing enabled.) > > I got a certificate from our corporate site. Its certification path is: > GeoTrust (Equifax under the hood) > Intel External Basic Policy CA > Intel External Basic Issuing CA 3A > Intel Code Signing External Cert for IPEAK External Cert > > I downloaded the cross cert for Equifax from MS, and signed the driver > thus: > ========== > C:\WinDDK\6001.18001>signtool sign /v /ac EquifaxSecureCertAuth.cer /s My > /n “I > PEAK External Cert” > c:\Data\IPEAK_Storage_Toolkit\SPT\bin\amd64\mydriver.sys > The following certificate was selected: > Issued to: IPEAK External Cert > Issued by: Intel External Basic Issuing CA 3A > Expires: 3/22/2012 3:32:42 PM > SHA1 hash: > > Done Adding Additional Store > > Attempting to sign: > c:\Data\IPEAK_Storage_Toolkit\SPT\bin\amd64\mydriver.sys > Successfully signed: > c:\Data\IPEAK_Storage_Toolkit\SPT\bin\amd64\mydriver.sys > > Number of files successfully Signed: 1 > Number of warnings: 0 > Number of errors: 0 > ========== > > Then I rebuild the installer, bundling the driver into the msi. > I also export my cert to a pfx file, and add it to the store on my text > box. > I install the tool on the Vista 64 test box, and install the driver using > the method shown above. > > When I reboot the Vista 64 test box, it always fails with the message : > File: \Windows\System32\Drivers\mydriver.sys > Status: 0xc0000428 > Info: Windows cannot verify the digital signature for this file. > > At that point I have to reboot to the last known good configuration, after > which I can run certmgr.msc and look at the different certs. Everything > looks exactly the same as it did on the signing box. If I right-click on > the driver file in Explorer and view properties, it also says the > signature is ok. > > At this point I don’t know what else to try, since everything looks like > it should work. > > Thanks, > Dennis > >
I’m not sure if all the op wants to do is test, but if that will fill the bill, then test signing
will also work and the op won’t have to do the ‘F8’ at every boot.
If that works for the op’s needs, then this document describes the process, which despite the
appearance that it’s 50 or so pages presents, it’s quite straight forward and takes about ten
minutes, start to finish, including scanning the document.
Good luck,
mm
R. Yang wrote:
Try the corss cert of GeoTrust Global CA, probably it can work.
Btw, if you just want to run it for test, you don’t need to sign it.
Just choose disable Digital Signing after press F8 in Windows boot menu.
wrote in message news:xxxxx@ntdev… >> Hi, >> >> I’ve read lots of posts both here and at the MSDN support forums, but >> nothing that addresses my problem. Any thought would be welcome. >> >> I am working on a tool that includes a filter driver in the storage >> stack. Since it will need to work on Vista 64, the driver needs to be >> signed, and I am at wits’ end trying to get the signing to work. >> >> The msi installer package is built as a VS 2005 project. There is no >> .cat file or .inf file, just the .sys file. The first time the user >> opens the app that needs the driver, they are informed that they need >> to install it, which they can do from a menu. The installation >> consists of copying the driver file to windows\system32\drivers, and >> setting the registry to load the driver as an upper filter. (I >> inherited the project; I don’t know why it was done that way, but it >> works fine on 32-bit systems and on Vista 64 with test signing enabled.) >> >> I got a certificate from our corporate site. Its certification path is: >> GeoTrust (Equifax under the hood) >> Intel External Basic Policy CA >> Intel External Basic Issuing CA 3A >> Intel Code Signing External Cert for IPEAK External Cert >> >> I downloaded the cross cert for Equifax from MS, and signed the driver >> thus: >> ========== >> C:\WinDDK\6001.18001>signtool sign /v /ac EquifaxSecureCertAuth.cer >> /s My /n “I >> PEAK External Cert” >> c:\Data\IPEAK_Storage_Toolkit\SPT\bin\amd64\mydriver.sys >> The following certificate was selected: >> Issued to: IPEAK External Cert >> Issued by: Intel External Basic Issuing CA 3A >> Expires: 3/22/2012 3:32:42 PM >> SHA1 hash: >> >> Done Adding Additional Store >> >> Attempting to sign: >> c:\Data\IPEAK_Storage_Toolkit\SPT\bin\amd64\mydriver.sys >> Successfully signed: >> c:\Data\IPEAK_Storage_Toolkit\SPT\bin\amd64\mydriver.sys >> >> Number of files successfully Signed: 1 >> Number of warnings: 0 >> Number of errors: 0 >> ========== >> >> Then I rebuild the installer, bundling the driver into the msi. >> I also export my cert to a pfx file, and add it to the store on my >> text box. >> I install the tool on the Vista 64 test box, and install the driver >> using the method shown above. >> >> When I reboot the Vista 64 test box, it always fails with the message : >> File: \Windows\System32\Drivers\mydriver.sys >> Status: 0xc0000428 >> Info: Windows cannot verify the digital signature for this file. >> >> At that point I have to reboot to the last known good configuration, >> after which I can run certmgr.msc and look at the different certs. >> Everything looks exactly the same as it did on the signing box. If I >> right-click on the driver file in Explorer and view properties, it >> also says the signature is ok. >> >> At this point I don’t know what else to try, since everything looks >> like it should work. >> >> Thanks, >> Dennis >> >> > >
I think test signing doesn’t work for boot driver - Sometime ago I tried
this with my boot load driver and it failed.
“Martin O’Brien” wrote in message news:xxxxx@ntdev… > I’m not sure if all the op wants to do is test, but if that will fill the > bill, then test signing will also work and the op won’t have to do the > ‘F8’ at every boot. > > http://download.microsoft.com/download/9/c/5/9c5b2167-8017-4bae-9fde-d599bac8184a/KMCS_Walkthrough.doc > > If that works for the op’s needs, then this document describes the > process, which despite the appearance that it’s 50 or so pages presents, > it’s quite straight forward and takes about ten minutes, start to finish, > including scanning the document. > > Good luck, > > mm > > R. Yang wrote: >> Try the corss cert of GeoTrust Global CA, probably it can work. >> >> Btw, if you just want to run it for test, you don’t need to sign it. Just >> choose disable Digital Signing after press F8 in Windows boot menu. >> >> wrote in message news:xxxxx@ntdev… >>> Hi, >>> >>> I’ve read lots of posts both here and at the MSDN support forums, but >>> nothing that addresses my problem. Any thought would be welcome. >>> >>> I am working on a tool that includes a filter driver in the storage >>> stack. Since it will need to work on Vista 64, the driver needs to be >>> signed, and I am at wits’ end trying to get the signing to work. >>> >>> The msi installer package is built as a VS 2005 project. There is no >>> .cat file or .inf file, just the .sys file. The first time the user >>> opens the app that needs the driver, they are informed that they need to >>> install it, which they can do from a menu. The installation consists of >>> copying the driver file to windows\system32\drivers, and setting the >>> registry to load the driver as an upper filter. (I inherited the >>> project; I don’t know why it was done that way, but it works fine on >>> 32-bit systems and on Vista 64 with test signing enabled.) >>> >>> I got a certificate from our corporate site. Its certification path is: >>> GeoTrust (Equifax under the hood) >>> Intel External Basic Policy CA >>> Intel External Basic Issuing CA 3A >>> Intel Code Signing External Cert for IPEAK External Cert >>> >>> I downloaded the cross cert for Equifax from MS, and signed the driver >>> thus: >>> ========== >>> C:\WinDDK\6001.18001>signtool sign /v /ac EquifaxSecureCertAuth.cer /s >>> My /n “I >>> PEAK External Cert” >>> c:\Data\IPEAK_Storage_Toolkit\SPT\bin\amd64\mydriver.sys >>> The following certificate was selected: >>> Issued to: IPEAK External Cert >>> Issued by: Intel External Basic Issuing CA 3A >>> Expires: 3/22/2012 3:32:42 PM >>> SHA1 hash: >>> >>> Done Adding Additional Store >>> >>> Attempting to sign: >>> c:\Data\IPEAK_Storage_Toolkit\SPT\bin\amd64\mydriver.sys >>> Successfully signed: >>> c:\Data\IPEAK_Storage_Toolkit\SPT\bin\amd64\mydriver.sys >>> >>> Number of files successfully Signed: 1 >>> Number of warnings: 0 >>> Number of errors: 0 >>> ========== >>> >>> Then I rebuild the installer, bundling the driver into the msi. >>> I also export my cert to a pfx file, and add it to the store on my text >>> box. >>> I install the tool on the Vista 64 test box, and install the driver >>> using the method shown above. >>> >>> When I reboot the Vista 64 test box, it always fails with the message : >>> File: \Windows\System32\Drivers\mydriver.sys >>> Status: 0xc0000428 >>> Info: Windows cannot verify the digital signature for this file. >>> >>> At that point I have to reboot to the last known good configuration, >>> after which I can run certmgr.msc and look at the different certs. >>> Everything looks exactly the same as it did on the signing box. If I >>> right-click on the driver file in Explorer and view properties, it also >>> says the signature is ok. >>> >>> At this point I don’t know what else to try, since everything looks like >>> it should work. >>> >>> Thanks, >>> Dennis >>> >>> >> >> >
I got test signing to work fine, but I can’t use that for releasing the tool. It also works if I do the F8 boot and disable signing verification, but of course you have to do that every boot. But at least it tells me that my code isn’t totally broken.
I discovered that the chain of Authority Key Identifiers to Subject Key Identifiers from one cert to the next is broken at the MS Root cert. That is, each cert from my lowest one up to the Equifax cross cert point to the next one, just like a linked list. But the Equifax cross cert, and also the GeoTrust cross cert, do not point to the MS Root cert that I have on the build machine. I’m investigating what the heck is going on with that. I’ll report back on what I find. At least I have someplace to look now. Thanks for all the help and suggestions.
> On Vista Microsoft does some “virtualization” of system-related paths. A
32-bit application attempting to deal with the path “\Windows\System32” ( a
folder for 64-bit binaries on a 64-bit system) actually accesses
“\Windows\SysWow64” (a folder for 32-bit binaries on a 64-bit system).
Intel is running it’s own internal Certificate Authority. The root
certificate you got from GeoTrust may not be the same root referenced by
Microsoft’s cross-certificate. Public CA’s like GeoTrust often have
multiple roots, used for different purposes. Run certmgr and look at
the Trusted Root CA store. GeoTrust has five certs listed. The one
they use to issue software publishing certificates may be different than
the one they used to issue the cert for Intel’s internal CA. This works
for SSL because the various certs are included in the Trusted Root CA
store, and all are treated equally. It doesn’t work for kernel-mode
code signing because Microsoft has issued a very limited set of cross
certificates.
–John
P.S. In addition to the technical issues, Intel’s contract with
GeoTrust may limit what you can do. Specifically, certificates issued
by your internal CA may be limited to internal use, and should not be
used to sign code released to the public. You should check with the
team that runs your CA and/or your legal department.
I got a certificate from our corporate site. Its certification path is:
GeoTrust (Equifax under the hood)
Intel External Basic Policy CA
Intel External Basic Issuing CA 3A
Intel Code Signing External Cert for IPEAK External Cert
I have more info. It looks like my problem is cross-certification. I downloaded the Equifax Secure Certificate Authority cross-cert and signed my driver with it. When I use signtool to verify the signature, the chain stops at Equifax, i.e. it does not have the Microsoft Root Certificate Authority at the top of the list.
On the MS Cross-cert site, it shows the Equifax thumbprint as
35 0d 68 90 31 00 98 3f 80 4d b2 65 f9 a5 e2 45 d9 c5 92 28, which is what my cert shows. It shows the Root certificate thumbprint as:
d2 32 09 ad 23 d3 14 23 21 74 e4 0d 7f 9d 62 13 97 86 63 3a, which is definitely not what I have on my system or any other system I’ve checked, either XP or Vista.
If I double-click the cross-cert in Explorer, I get the message that “Windows does not have enough information to verify this certificate” which makes sense knowing that the numbers don’t match. But I have no how to fix that. Any ideas are welcome.
I figured this one out, so I thought I should report what I did. It turned out that I had more than one cert named “Equivax Secure Certificate Authority” in my Trusted Root Certification Authority store on the signing machine. I deleted them all and started fresh, and everything worked just the way it should. After I signed my driver with the Equifax cross-cert from Microsoft, the trust chain went all the way up to the Microsoft Root Authority, and the test box successfully verifies the signature on boot.
This is just conjecture, but I’m guessing that signtool was somehow picking the wrong one and using it. It would have been nice if it had let me know that there was more than one and let me pick the one I wanted to use, but that’s beyond my control.
I’d like to thank everyone who replied and tried to help. I asked the same question on one of the MSDN Managed Newsgroup forums, and got zero replies. You guys are the best!
I’d like to thank everyone who replied and tried to help. I asked the same question on one of the MSDN Managed Newsgroup forums, and got zero replies. You guys are the best!
To be honest, most of us participate in both groups, but I see this
mailing list 8 hours a day every day, whereas I only check the
newsgroups every other evening. When I see a newsgroup thread that’s
already being handled here, I tend to leave it alone.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.