none
Automatic root certificate update problems when verifying my signed INF driver package

    Question

  • Hello.  I have a simple INF file that uses usbser.sys, and I am trying to make a signed driver package with it.

    Here is the signed driver package: driver.zip (pololu_usb_to_serial.inf, pololu.cat).

    I have two goals:

            • The driver should be installable on Windows XP/Vista/7/8 by right-clicking on the INF file and selecting install.  This goal has been achieved.
            • When the driver is installed on Windows Vista/7/8, instead of seeing the red "Windows can't verify the publisher of this driver software" dialog box, I want the users to reliably see the nicer dialog box that identifies our company (Pololu Corporation) as the publisher and asks "Would you like to install this device software?".

    The driver installation seems to work nicely on the Windows 8 preview machine I have tested, but it does NOT work nicely on a variety of Windows Vista and Windows 7 machines that I have tried.  It seems like in Windows 7 I have to install the "Starfield Root Certificate Authority - G2" (sfroot-g2.crt) into the Trusted Root Certificate Authorities list or else I will usually get the unverified publisher warning when I try to install the INF file by right-clicking and selecting "Install".  Sometimes, depending on what certificates are installed, I get the unverified publisher warning the first time I try to install the driver and then I get the correct dialog box the next time, after Windows succeeds in fetching the Starfield G2 root certificate from Windows Update.

    Since the signature works in Windows 7 when the right certificates are installed, I think I am not doing anything fundamentally wrong.  I suspect that Windows is just not doing a good job of updating the root certificates in a timely manner.  I have provided verbose log files from CAPI2 for debugging.

    Does anyone know what is going wrong here?  Am I or Go Daddy doing something wrong?  Is there a good way to work around this problem?  Thank you in advance!

    Dialog Boxes

    For reference, this is the "verified publisher" / successful dialog box that I want my users to see:

    This is the "unverified publisher" / unsuccessful dialog box that I do not want:

    Details of my procedure

    I bought a Driver Signing Certificate from Go Daddy, and installed it into the Personal certificate store for the Current User.

    This is my INF file: pololu_usb_to_serial.inf .  It is a slightly-modified version of a driver we have been using successfully for many years on Windows XP, Vista, Vista 64-bit, 7, and 7 64-bit.

    I tried to run chkinf on pololu_usb_to_serial.inf but I got an error ( chkinf_bug.txt ) which seems to have nothing to do with my INF file.

    This is my batch script for generating the .cat file and signing it:

    "C:\Program Files (x86)\Windows Kits\8.0\bin\x64\inf2cat" /v /driver:%~dp0 /os:XP_X86,Vista_X86,Vista_X64,7_X86,7_X64,8_X86,8_X64

    "C:\Program Files (x86)\Windows Kits\8.0\bin\x64\signtool" sign /v /fd sha256 /t http://tsa.starfieldtech.com /n "Pololu Corporation"  pololu.cat

    As you can see, the batch file generates pololu.cat and signs it using signtool.  It runs without any errors.

    The verification output from "signtool verify ..." looks good to me, and shows the chains of trust: signtool_verify.txt

    I am always careful to have pololu.cat and pololu_usb_to_serial.inf in the same directory, and to regenerate the .cat file if I ever change the .inf file.

    Here is a verbose event log from CAPI2 on a Windows 7 64-bit machine showing the signature failing: run1_no_sfroot-g2_verbose.evtx.  My procedure to generate this failing event is as follows:

    1. Enable verbose CAPI2 logging as documented in http://www.microsoft.com/en-us/download/details.aspx?id=18844 .  Clear the CAPI2 operational log.
    2. Using the Microsoft Management Console (mmc) Certificates snap-in, for Current User and Local Computer, remove every instance of "Starfield Root Certificate Authority - G2".  It is usually found in Trusted Root Certification Authorities but sometimes in Intermediate Certification Authorities as well.
    3. Right-click pololu_usb_to_serial.inf and select "Install".  Verifying the publisher fails and Windows opens up the unverified publisher dialog.
    4. Wait 30 seconds to make the log more understandable.
    5. Click the X in the unverified publisher window to close it.
    6. Save the CAPI2 operational log entries from Event Viewer (right click, Save All Events As...).

    However, on the same computer, if I download sfroot-g2.crt from https://certs.godaddy.com/anonymous/repository.seam and install it, then everything goes as expected and I get the friendly dialog box instead.  Here is a log file showing what happens in that successful case: run2_sfroot-g2_trusted-root_verbose.evtx

    Possible Issues

    Because I can get the correct dialog box to appear in Windows 7 pretty reliably if I install the root certificate correctly, I think I am fundamentally doing things correctly.  However, there are some things you could object to:

    The timestamp chain of trust and the main chain of trust are rooted at different certificates, and the timestamp certificates do not use SHA256.

    I am using DefaultInstall INF section, and according to the documentation of DefaultInstall you are not supposed to use that for a signed driver package.  I think this documentation is wrong.  I did try removing that section and just using the SetupCopyOEMInf function at an earlier point and I had similar results.

    I am not using a cross certificate.  There is a cross certificate available from Go Daddy that would establish a chain of trust from the Microsoft Code Verification Root to the Starfield Root Certificate Authority - G2, but my understanding is that this would have no affect because the Microsoft Code Verification Root certificate is not a Trusted Root Certificate Aurhority.

    I have asked this question on StackOverflow and I have been in contact with Go Daddy support, and I have learned a lot through that, but have not been able to solve the underlying problem.  I would really appreciate an expert opinion!

    A person who answered my StackOverflow question claims that Go Daddy Driver Signing Certificate do not work with Windows 7 but they do work fine if the right certificate is present.


    --David Grayson




    • Edited by DavidGrayson Wednesday, October 03, 2012 1:04 AM
    Wednesday, October 03, 2012 1:00 AM

Answers

  • win7 by default doesn't support sha256.  there are updates to the OS that allow it to support it, but I don't think you can rely on those to be present. your life should be much simpler if you chose to sign with a sha1 cert

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

    • Marked as answer by DavidGrayson Thursday, October 04, 2012 5:09 PM
    Thursday, October 04, 2012 1:52 AM

All replies

  • Signing is perhaps the least suitable area to show off creativity and independent thinking. Just the opposite. Try to follow the instructions precisely.  If the instructions tell to use the cross certificate, use it. No matter what they scribble at Stack Overflow -  the WDK documentations says the ultimate truth (when updated, of course).

    -- pa

    Wednesday, October 03, 2012 1:32 AM
  • also, right click install of a pnp driver is not supported. it was made to work on win8, but it doesnt' do what you think it does (it imports the driver package, it doesnt' necessarily force an install), but on all previous versions of windows right click install does not work at all.

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

    Wednesday, October 03, 2012 3:34 AM
  • Hello Pavel and Doron, and thank you for the quick responses!

    I am not trying to show off and I am sorry if it came across that way.  In this post I will try again, following the instructions as closely as possible.  If I have to deviate from them or figure out something that is not in the instructions, I will let you know.

    First of all, is the SHA256 hashing algorithm supported on Windows 7?  According to http://msdn.microsoft.com/en-us/library/windows/hardware/hh967734%28v=vs.85%29.aspx the answer is no.  According to http://blogs.technet.com/b/pki/archive/2010/09/30/sha2-and-windows.aspx the answer is yes, which makes more sense to me because I was able to get my signature to work on Windows 7 under the right conditions and the Starfield certificates in my chain of trust seem to be using SHA256.

    As a side note, I tried to follow the instructions from http://msdn.microsoft.com/en-us/library/windows/hardware/hh967734%28v=vs.85%29.aspx to add two signatures to the CAT file, but I am not using Visual Studio so had to translate them to the Command Prompt.  The command I ran was

    "C:\Program Files (x86)\Windows Kits\8.0\bin\x86\signtool" sign /fd sha256 /ph /as /sha1 c9bf08a397c22f1b35355224372d2566d959174d /ac mscvr-cross-sfroot-g2.crt pololu.cat

    but it only seems to have added one signature to the .cat file, and I can't find documentation for the /as option for "signtool sign".  I also tried the pair of commands:

    "C:\Program Files (x86)\Windows Kits\8.0\bin\x86\signtool" sign /ph /as /sha1 c9bf08a397c22f1b35355224372d2566d959174d /ac mscvr-cross-sfroot-g2.crt pololu.cat
    "C:\Program Files (x86)\Windows Kits\8.0\bin\x86\signtool" sign /fd sha256 /ph /as /sha1 c9bf08a397c22f1b35355224372d2566d959174d /ac mscvr-cross-sfroot-g2.crt pololu.cat

    ----

    The main instructions I will try to follow are from Digital Signatures for Kernel Modules on Windows (kmsigning.doc), from July 25, 2007.  I also compared these instructions to the newer Windows 7 WDK Documentation installer and they seem pretty much the same, but I could not find a Windows 8 WDK Documentation installer.

    The instructions do not specify what versions of the Windows SDK and WDK to install, but I want my driver to work on Windows 8 so I am guessing that I should install the latest versions.  I installed the latest version (8.0) of the Windows Driver Kit (WDK) and then installed the latest version (8.0) of the Windows Software Development Kit (SDK) for Windows 8, about a month ago.

    The instructions do not specify what kind of build environment I should use and I don't see any good-sounding options in my Start menu.  I am guessing it is OK to use the Command Prompt and just type full paths to the signtool and inf2cat utilities (e.g. "C:\Program Files (x86)\Windows Kits\8.0\bin\x64\inf2cat"), but please let me know if I cam wrong.

    I am using Windows 7 Professional, 64-bit, Service Pack 1.

    Here is the INF file: pololu_usb_to_serial.inf
    Since yesterday, I have removed the DefaultInstall section to comply with http://msdn.microsoft.com/en-us/library/windows/hardware/ff547356(v=vs.85).aspx and I have changed the DriverVer version number to 6.0.1.0 to comply with kmsigning.doc.  (I am unsure about DriverVer because the kmsigning.doc says to put a space after the comma, but http://msdn.microsoft.com/en-us/library/windows/hardware/ff547394(v=vs.85).aspx says to NOT put a space after the comma.)

    Here is my batch file for signing the drivers:

    "C:\Program Files (x86)\Windows Kits\8.0\bin\x86\inf2cat" /driver:C:\Users\david.POLOLU\Desktop\sign\sign_inf_121003\ /os:XP_X86,Vista_X86,Vista_X64,7_X86,7_X64,8_X86,8_X64

    "C:\Program Files (x86)\Windows Kits\8.0\bin\x86\signtool" sign /v /ac "mscvr-cross-sfroot-g2.crt" /s MY /n "Pololu Corporation" /t http://timestamp.verisign.com/scripts/timestamp.dll pololu.cat

    The only meaningful difference between my commands and the example commands in kmsigning.doc are that I have more operating systems in my list.  (I am even using Verisign instead of Starfield for the timestamp.)  The cross certificate was downloaded from https://certs.godaddy.com/anonymous/repository.seam but I used diff to make sure it was identical to the version from http://msdn.microsoft.com/en-us/library/windows/hardware/gg487315.aspx .

    Here is the resulting driver package: driver.zip

    Now, to install the driver package, I use rundll32 to invoke a little C++ DLL that calls SetupCopyOEMInf(L"pololu_usb_to_serial.inf", NULL, SPOST_PATH, 0, NULL, 0, NULL, NULL); .  We have been using this method for years in our installers, so I think it is OK, but I am open to trying other methods.  I also tried "devcon dp_add ..." but I have the same results.

    Before installing, I use certmgr.msc to remove "Starfield Root Certificate Authority - G2" from all stores for the current user, to simulate what will happen when the driver is installed on a fresh Windows 7 machine.  I am using the same computer to sign and test at this point, and I hope that is not a problem.

    When I try to install it on my Windows 7 computer, I still get the unverified publisher warning and these verbose CAPI2 log entries are generated:  verification_failed.evtx .  I don't understand the log file much, but I have read a lot of Troubleshooting PKI Problems on Windows Vista (TSPKIWindowsVista.doc) and that was useful.  The error that jumps out at me is the one with EventRecordID 20493.  I think it is saying that CertGetCertificateChain failed and the error codes are CERT_TRUST_IS_NOT_VALID_FOR_USAGE, CERT_TRUST_REVOCATION_STATUS_UNKNOWN, CERT_TRUST_IS_OFFLINE_REVOCATION, and CERT_TRUST_IS_PARTIAL_CHAIN.

    If I preinstall "Starfield Root Certificate Authority - G2" into the Trusted Root Certification Authorities store (sfroot-g2.crt from https://certs.godaddy.com/anonymous/repository.seam ) then I get the nice dialog box instead.

    My understanding from KB 931125 and http://technet.microsoft.com/en-us/library/cc749331.aspx is that Windows should download the Starfield G2 root certificate automatically from Windows update when I try to install the driver package, and so the nice dialog box should be shown.  The computer is connected to the internet and I ran the "Check for Updates" command under Control Panel > System and Security > Windows Update to make sure that it can contact Windows Update.  I also went to gpedit.msc > Computer Configuration > Administrative Templates > System > Internet Communication Management to make sure that automatic root certificate update is not disabled.

    Sorry for the long post, but I want to include any detail that could possibly be useful.  Please let me know if I am doing something wrong or if you would like more information!

    --David Grayson



    • Edited by DavidGrayson Wednesday, October 03, 2012 11:30 PM
    Wednesday, October 03, 2012 11:23 PM
  • win7 by default doesn't support sha256.  there are updates to the OS that allow it to support it, but I don't think you can rely on those to be present. your life should be much simpler if you chose to sign with a sha1 cert

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

    • Marked as answer by DavidGrayson Thursday, October 04, 2012 5:09 PM
    Thursday, October 04, 2012 1:52 AM
  • Thank you for clearing that up, and thanks for the advice.  It sounds like this MSDN doc is out-of-date then.

    I plan to get a new certificate that uses SHA1 so that it will work nicely on all recent versions of Windows.  I also will make sure that the certificate's chain of trust is rooted in a certificate that will already be in everyone's Trusted Root Certification Authorities store, so that it will work nicely on computers that are disconnected from the internet and computers where the automatic root certificate update is not working seamlessly.

    I think there is a problem with the automatic updating of root certificates as described in my last post, and I hope Microsoft will look into it at some point (but I am not going to wait).


    --David Grayson


    Thursday, October 04, 2012 6:15 PM
  • >  I also will make sure that the certificate's chain of trust is rooted in a certificate that will already be in everyone's Trusted Root Certification Authorities store, so that it will work nicely on computers that are disconnected from the internet

    *This* is what the cross-certificate does. Just use it.

    -- pa

    Thursday, October 04, 2012 11:02 PM
  • Thanks for the advice, but according to Digital Signatures for Kernel Modules on Windows (kmsigning.doc), the cross certificates aren't actually used during driver package installation (but they are used when code is loaded into the kernel).  It says:

    When a driver is installed on a system, Windows verifies the digital signature on the driver package. During installation, the contents of the driver package are copied to the correct system locations and the system configuration is updated. However, the driver is not actually loaded into the running kernel. To verify the driver package, the digital signature on the driver package is verified and each certificate in the certificate path is checked, up to a known trusted root CA. For driver installation checks and Device Manager signature checks, the known trusted root authorities are defined in the local machine Trusted Root Certification Authorities certificate store.

    When a driver is loaded into kernel memory, Windows Vista verifies the digital signature of the driver image file. Depending on the type of driver, this can be either the signed hash value in the catalog file or an embedded signature in the image file itself. The cross-certificates that are used when signing the kernel driver package are used for the load-time signature verification; each certificate in the path is checked up to a trusted root in the kernel. The load-time signature check does not have access to the Trusted Root Certificate Authorities certificate store. Instead, it must depend on the root authorities that are built into the Windows Vista kernel. The Microsoft Code Verification Root is one of the root authorities trusted by the Windows Vista kernel and operating system loader.

    Page 9 of that document has a diagram that makes it pretty clear.

    What you say makes sense and I would have liked it if Windows worked that way, but I have tried the cross certificate many times (see my last long post) and in my experience the cross certificate hasn't helped.  The cross certificate establishes a chain of trust to the Microsoft Code Verification Root, but that is not one of the Trusted Root Certification Authorities.


    --David Grayson


    Friday, October 05, 2012 4:53 PM
  • Hi David,

    Did you ever resolve this issue? I need to do pretty much the same thing as you, sign a usb driver for XP, Vista, 7, and 8.   Is the issue that GoDaddy cannot issue an SHA1 cross certificate, which is required for Vista and 7?   Thanks for your detailed post.

    Tuesday, October 30, 2012 5:31 PM
  • Hey Cynergizer.  Sorry for the late reply; I was not configured properly to receive alerts for this thread.  I am glad you found my posts useful; developers like us are going to need a lot of help to figure out this driver signing stuff for Windows 8.

    At my company, we are going to go with a regular old SHA1 "Code Signing Certificate" from Go Daddy.  The chain of trust for the certificate is:

    1. Go Daddy Class 2 Certification Authority ( 27 96 ba e6 3f 18 01 e2 77 26 1b a0 d7 77 70 02 8f 20 ee e4 )  (will be a trusted root CA on your user's computer)
    2. Go Daddy Secure Certification Authority ( 7c 46 56 c3 06 1f 7f 4c 0d 67 b3 19 a8 55 f6 0e bc 11 fc 44 )
    3. My company

    Although I haven't fully tested it or released it to customers yet, the Code Signing Certificate appears to work fine for signing INF files and executables alike.  To sign those types of files, you need to establish a chain of trust back to one of the certificates in the Trusted Root Certification Authorities list on your user's computer.  I wish I could find a list of exactly which Trusted Root Certification Authorities come with fresh installs of Windows XP/Vista/7/8; I think the Go Daddy Class 2 Certification Authority would be on that list, which is what you want.  You want to establish a chain of trust back to some certificate that is guaranteed to be on everyone's computer already, so that you do not have to rely on the automatic update facility which has proven unreliable in my experience.

    I looked in the Go Daddy certificate repository and the Microsoft list of Cross-Certificates for Kernel Mode Code Signing but I didn't see any cross certificate for it at all, so I will not use a cross certificate and my understanding is that we will NOT be able to use it to sign kernel components (.sys files).  To sign a .sys file, you need to establish a chain of trust back to the Microsoft Code Verification Root.

    --------

    EDIT: The strategy below is wrong.  The .sys file is generally signed through the .cat file, so you need to have one signing plan, not two.  I'm still learning!

    I am NOT in a position to try the following plan, but I bet you could probably get everything to work with a SHA2 Go Daddy "Driver Signing Certificate".  Go Daddy has a "Go Daddy G1 to G2 Cross Certificate" (gdroot-g2_cross.crt) which establishes a chain of trust from the "Go Daddy Class 2 Certification Authority" to the "Go Daddy Root Certificate Authority - G2".  It FINALLY dawned on me that this is the right cross certificate to use when signing an executable or INF file, because it establishes a chain of trust back to a certificate in the Trusted Root Certifications Authorities list on your computer.

    In summary, to sign an executable or INF file, you could probably use the Go Daddy G1 to G2 Cross Certificate (gdroot-g2_cross.crt) along with your Go Daddy SHA2 Driver Signing Certificate, and your chain of trust would look like:

    1. Go Daddy Class 2 Certification Authority ( 27 96 ba e6 3f 18 01 e2 77 26 1b a0 d7 77 70 02 8f 20 ee e4 ) (will be a trusted root CA on your user's computer)
    2. Go Daddy Root Certificate Authority - G2 ( 84 1d 4a 9f c9 d3 b2 f0 ca 5f ab 95 52 5a b2 06 6a cf 83 22 )  (supposed to be a trusted root CA, but it depends on Windows Update working reliably)
    3. Go Daddy Secure Certificate Authority - G2 ( 27 ac 93 69 fa f2 52 07 bb 26 27 ce fa cc be 4e f9 c3 19 b8 )
    4. Your company

    To sign a .sys kernel-mode driver, you should use the Microsoft to Go Daddy G2 Cross Certificate (mscvr-cross-gdroot-g2.crt) along with your Go Daddy SHA2 Driver Signing Certificate, and your chain of trust would look like:

    1. Microsoft Code Verification Root ( 8F BE 4D 07 0E F8 AB 1B CC AF 2A 9D 5C CA E7 28 2A 2C 66 B3 )
    2. Go Daddy Root Certificate Authority - G2 ( 84 2c 5c b3 4b 73 bb c5 ed 85 64 bd ed a7 86 96 7d 7b 42 ef )  (different thumbprint because different issuer)
    3. Go Daddy Secure Certificate Authority - G2 ( 27 ac 93 69 fa f2 52 07 bb 26 27 ce fa cc be 4e f9 c3 19 b8 )
    4. Your company

    Does this make sense?

    Of the many people who tried to help me, no one ever suggested using the Go Daddy G1 to G2 Cross Certificate, and I am not sure why.


    --David Grayson







    • Edited by DavidGrayson Wednesday, November 28, 2012 7:48 PM
    Wednesday, November 07, 2012 10:49 PM
  • In case anyone is following this:

    I wanted the possibility of signing driver packages that contain .sys files in the future, so I re-keyed my Code Signing Certificate from Go Daddy to be SHA-2.  Now I sign our .cat files using that certificate along with the Go Daddy G1 to G2 Cross Certificate (gdroot-g2_cross.crt), so the chain of trust looks like:

    1. Go Daddy Class 2 Certification Authority ( 27 96 ba e6 3f 18 01 e2 77 26 1b a0 d7 77 70 02 8f 20 ee e4 ) (will be a trusted root CA on your user's computer)
    2. Go Daddy Root Certificate Authority - G2 ( 84 1d 4a 9f c9 d3 b2 f0 ca 5f ab 95 52 5a b2 06 6a cf 83 22 )  (supposed to be a trusted root CA, but it depends on Windows Update working reliably)
    3. Go Daddy Secure Certificate Authority - G2 ( 27 ac 93 69 fa f2 52 07 bb 26 27 ce fa cc be 4e f9 c3 19 b8 )
    4. Our company

    This has been working great for our needs, but unfortunately, that plan does not allow us to sign driver packages that contain Kernel-Mode .sys files, because the chain of trust is not rooted in the Microsoft Code Verification Root.  Based on my reading of kmsigning.doc, the correct way to sign your .cat file if you have kernel-mode driver files is to use the Microsoft to Go Daddy G2 Cross Certificate (mscvr-cross-gdroot-g2.crt).  I haven't actually gotten that to work yet, but that will be another discussion.


    --David Grayson

    • Proposed as answer by BrandonYoung Thursday, December 13, 2012 1:50 PM
    Thursday, November 29, 2012 12:50 AM
  • Thank You!!!

    I found this mid day yesterday but didn't follow it the first time through.  Got me pointed in the right direction to learn what I needed.  When I came back and was better able to follow you're thoughts this was exactly what I needed to be able to get my driver signed and recognized on Windows 8 and Windows 7.  I expect XP and Vista will work now to, just need to finish testing.  

    I expect I would have been days getting this to work and with your help was able to complete it in a single day.

    Thanks again.

    Brandon Young

    Thursday, December 13, 2012 1:56 PM
  • You're welcome Brandon!  I am working on a document that should explain all the pitfalls and caveats of Windows code and driver signing, and save everyone a lot of time.  But in the mean time I need to give you some advice because I have learned some things since my last post.

    I hope you are not planning to use SHA-2.  There are two reasons:

    1) In my experience, Windows Vista silently chokes on executables (EXE or MSI) signed using any kind of SHA-2 when the user tries to run them by double-clicking, but ONLY if they were downloaded from the internet.  When the user tries to run the file, nothing happens.  Make sure you test your files after they have been downloaded from the internet!

    2) In my experience, for the purposes of loading a driver into the kernel, Windows 7 and Windows Vista do not recognize signatures that use SHA-2.  It works fine for driver package installation, but doesn't work when Windows tries to load the driver into the kernel.  (If you are only using WinUSB or usbser.sys, you don't have any kernel-mode code so that wouldn't be a problem.)

    Issue #2 is probably why people say that Go Daddy certificates don't work for kernel-mode driver signing:  their SHA-1 option doesn't work because there is no cross-certificate to make the chain of trust go back to Microsoft Code Verification Root, and their SHA-2 option doesn't work because Windows Vista and Windows 7 cannot handle SHA-2 for the purposes of verifying a signature for kernel-mode code.

    Also, please note that unlike what I said in a previous post, you can't just use a different signature for the CAT file and the SYS files:  the signature for the SYS files is normally supposed to actually be on the CAT file, except in the case of a boot-start driver (see kmsigning.doc for a reference).

    Subscribe to this thread so you can get more updates!


    --David Grayson





    Friday, December 14, 2012 4:58 PM
  • Hello everyone!  I have compiled everything I have learned about signing into one big document:  Practical Windows Code and Driver Signing.  Check it out!  Please post comments about it in the new thread.

    --David Grayson



    • Edited by DavidGrayson Wednesday, December 26, 2012 7:01 AM
    Wednesday, December 26, 2012 6:52 AM
  • Hi David,

    Wow, what a great thread, and doc! Thanks for publishing it.

    I am experiencing a similar issue with code signing a driver package. However, my signtool output indicates the driver package files have been signed correctly (i.e. no errors). But when I install the driver on a target (also a different) machine, I see the following error message in the target machine's SetupApi.dev.log file:

    !    sig:           Verifying file against specific (valid) catalog failed! (0x800b0109)
    !    sig:           Error 0x800b0109: A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider.

    My thread for this issue is at the link below if you're interested:

    http://social.msdn.microsoft.com/Forums/en-US/wdk/thread/b5fea469-b886-4e90-a521-5686197fb3bb

    I would appreciate any insight you have about this if you have the time.

    Thank you.

    Geoff

    Wednesday, March 06, 2013 8:04 PM