Practical Windows Code and Driver Signing discussion RRS feed

  • General discussion

  • Hello, my name is David Grayson and I work at Pololu Robotics & Electronics. I recently went through the process of signing all of our company's USB drivers and most of our installers for Windows. I encountered so many problems along the way that could have been easily avoided if someone had told me about them ahead of time. In response, I have written a 7000-word document that hopefully explains everything you need to know about code and driver signing:

    If you are going through the same process, I sincerely hope that this document can clear up all of your confusion and save you a lot of time. I learned the hard way and now you can learn the easy way.  The basic conclusion of it all is that you should probably stay away from Go Daddy's certificates and use GlobalSign, and I provide detailed justifications for that.  But with the new Microsoft driver signing portal, you might need to get a very specific (and expensive) type of certificate instead of using GlobalSign if you care about signing kernel-mode drivers. Click here to read the entire document.

    If you have any comments or questions, please post them here! If I missed anything or got anything wrong, let me know.  If you found the document useful and just want to thank me, then you can do that here too!

    Also, if you found this document helpful, please click on the little green arrow to the left!

    --David Grayson

    Wednesday, December 26, 2012 6:43 AM

All replies

  • Actually most firms I know of use Verisign since WHQL requires a Versign cert for some things and it is easier to use one account.  I haven't read the paper yet, but hopefully you recognize there are significant differences between Win8 signing and earlier WDK's.

    Don Burn Windows Filesystem and Driver Consulting Website: Blog:

    Wednesday, December 26, 2012 12:26 PM
  • Hello, Don.  Thanks for the information.

    My document doesn't cover the procedures of getting a WHQL signature because I haven't done that, and you can successfully distribute drivers without doing it.  However, I might add this fact to the document if I can somehow verify it.  I searched around on the internet for a little bit and couldn't find any indication that WHQL requires a Verisign cert for some things.  Is there an official document for Microsoft about that requirement?

    At $229 for one year, Globalsign's code signing certificate is less than half the price of Verisign's.

    --David Grayson

    • Edited by DavidGrayson Wednesday, December 26, 2012 5:53 PM
    Wednesday, December 26, 2012 5:51 PM
  • Hi David! Nice paper you wrote.

    We are facing problems with Globalsign code signing certificate in Windows 8. SmartScreen in Windows 8 doesn't trust our signed application while Windows 7 do it.

    Anyone have tried a certificate different than VeriSign over Windows 8?

    Antonio Sanchez

    Friday, December 28, 2012 12:32 PM
  • Hello, Antonio.

    Thanks!  It must be annoying to see the SmartScreen dialog take over your whole screen on Windows 8 when you try to run a signed installer downloaded from your website.  This was happening to us too, but after a few weeks or so it went away.  As people download and run your installer without reporting it as malware, your installer will gain SmartScreen reputation.  Eventually, the SmartScreen warning should go away and the user will actually see no warning on Windows 8.  In the mean time, your users can just click "More info" and "Run anyway" or something like that to run your installer.  There is more information in this blog post entitled Protecting you from malware by Steven Sinofsky.

    An Extended Validation Code Signing Certificate from Digicert is supposed to automatically give your software some SmartScreen reputation, but that sounds like a hassle.

    --David Grayson

    Friday, December 28, 2012 6:08 PM
  • One question.  Say you got both the driver signing cert and code signing cert from GoDaddy.  Couldn't you sign the catalog file with the SHA-2 driver signing cert and sign the .sys file with the SHA-1 code signing cert?
    Wednesday, January 2, 2013 5:02 PM
  • Kevin64A: I think you don't really want to put a signature on the .sys file itself unless you are doing a boot-start driver.  It might work, but you are really just supposed to put a signature on the catalog file, and that signature will be used both for driver package installation AND for verifying the SYS file before loading it into the kernel (if applicable to your driver package).  This is based on what I read in kmsigning.doc.  However, you could put two signatures on the catalog file.

    But the main reason why your suggestion wouldn't work is that the SHA-1 code signing certificate from Go Daddy does not have a cross-certificate available for it that will get your chain of trust to go back to the Microsoft Code Verification Root, so it just can't be used for the purpose of loading kernel modules.

    --David Grayson

    • Edited by DavidGrayson Wednesday, January 2, 2013 11:49 PM
    Wednesday, January 2, 2013 11:45 PM
  • I am dealing with a boot start kernel mode driver (it's a network driver) so I must have a signed SYS file as well as the catalog file.  After I asked the question I tested mixing a SHA-2 signed CAT file and SHA-1 signed SYS file, but I ran into the exact situation you described.  The code signing cert from GoDaddy can't be used for kernel signing of any sort since it doesn't chain to the Microsoft Code Verification Root.  I can validate that for Windows 8 the whole process works with a GoDaddy kernel signing cert as you describe.  On Vista and Windows 7 it's a total no go.  With boot start drivers signed with GoDaddy kernel signing certificates the OS actually disables them.  No way around that except to go with another cert vendor.

    How widely supported have you found the DigiCert kernel mode signing certs to be?  Any issues installing your driver on Vista or Win 7 (both 32 and 64 bit versions)?

    • Edited by Kevin64A Tuesday, January 8, 2013 6:34 AM spelling
    Tuesday, January 8, 2013 6:33 AM
  • Thanks, Kevin, it's always good to have more datapoints that confirm the assertions I have made in the document.  If you ever experience something that contradicts the document you should also report that so we can try to figure out the truth.  You got a Code 52 in the Device Manager after the driver package installation appeared to complete successfully, right?  Or was there some other symptom of signature failure?

    The Digicert code signing certificate will probably do the job for you.  They claim to support kernel mode and it's only $223 for one year.  I don't have any experience with it personally because I was able to meet all of my company's requirements with the SHA-1 Go Daddy certificate and we didn't get any certificates after that.  However, one person on StackOverflow said that Digicert worked for them, though I'm not sure if they were loading kernel modules.

    For the one driver my company distributes that has a kernel module, we haven't had any issues reported with it.  If there is an issue I will figure it out and update the document.  However, that driver was a pretty special case (see what I wrote about CP2102 in the document).

    Hopefully Go Daddy will give you a refund!

    --David Grayson

    Tuesday, January 8, 2013 6:50 AM
  • Thanks.  GoDaddy did give us a refund.  I'm going to go with the $99 special from VeriSign for WHQL.  If you ever want to submit for WHQL submission you'll need that cert anyway to signup, and it (like DigiCert) is SHA-1.  It's only good for a year, after which I'm assuming that it goes up to normal pricing, but the initial discount is substantial compared to the regular pricing.
    Wednesday, January 9, 2013 8:45 PM
  • David,

    Thank you, thank you.

    I'm also having the same issue. I only need to sign a Cat file and it works on Win 8 but not Win 7 (except my Win7 dev machine).

    I've been pulling my hair out as I'm (was) very uninformed on all things dealing with signing and certs. The more I read the more confused I got until I came across your contributions. I needed to start with basics and you provided that. Much appreciated!!

    I'm now concerned I might have another issue.

    You Write:


    n some cases, you might want to sign a driver package with two different signatures. For example, suppose you want your driver to run on Windows 7 and Windows 8. Windows 8 supports signatures created with the SHA256 hashing algorithm, but Windows 7 does not. For Windows 7, you need a signature created with the SHA1 hashing algorithm.<small style="font-size:12px;display:block;color:#999999;">Microsoft, from Signing a Driver for Public Release on MSDN</small>

    This is a half truth. In my experience, SHA-2 signatures on driver packages (i.e. CAT files) work just fine in Windows Vista and Windows 7 for the purpose of driver package installation.


    I am only signing a Cat file and I still cannot get it to work in Win7 (it works in Win8). I still get the "Unknown Publisher" error when installing.

    Please note the I'm using GoDaddy's "Driver Signing Product" not their "Code Signing Product". They claim this will still work if I double sign my Cat file. I assume that I need to sign the Cat file with the SHA1 format? From the doc you provided  I think this should work:

    Signtool sign /fd sha1/ph /as /sha256 XX...XX $(TargetPath)

    Using the certutil -dump utility I notice there is a primary and secondary hash code listed for my cert. Which one should I use?

    I'm concerned because I have no confidence in GoDaddy tech support (their phone support is useless) and you stated that their "Driver Signing Tool" will not work.

    Any input will be appreciated. 

    And thanks again for your efforts and contribution.



    Randy Feingersh

    Wednesday, February 13, 2013 8:04 PM
  • with respect to SHA1 and SHA2 signed binaries, if the sha1 cert is the first in the chain, it will always work. if sha2 is first in the chain, you need a pre win8 release which has been updated to handle sha2

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

    Wednesday, February 13, 2013 8:53 PM
  • Hello, Randy.  I am glad you found my contributions useful.  Would you mind making it official and upvoting the top post of this thread by clicking the little up arrow?

    I don't know anything about a Go Daddy "Driver Signing Tool"; maybe you found that statement elsewhere.

    Just to be clear, you are still able to install the driver package on Windows 7 and use it, right?  You just want your customers to see a more friendly message when they install the package?

    Your approach of double-signing the catalog file is unlikely to help, unless you buy two certificates from Go Daddy.  Right now, you have one certificate, and its chain of trust uses SHA-2.

    I think that SHA-2 isn't actually your problem.  I think you are facing the same problem I originally had.  Your chain of trust goes back to a certificate that is not already on the computer's list of Trusted Root Certification Authorities, so you have to depend on the computer downloading the certificate from Windows Update just in time.  In my experience, this automatic updating on Windows 7 has not been reliable.

    Here is something you should try:  Download the appropriate root certificate--either sfroot-g2.crt or gdroot-g2.crt--from  You should be able to verify that the certificate you download is the same as the root certificate in the signature on your CAT file.  Install that certificate, and then see if you get the friendly message when installing the driver.

    Feel free to post your signed driver package here so I can take a look at it!  (I don't think this forum has attachments but you could upload it to your own site and post a link.)

    --David Grayson

    • Edited by DavidGrayson Wednesday, February 13, 2013 11:38 PM
    Wednesday, February 13, 2013 11:33 PM
  • David, 

    Thanks! Sorry, I would have replied earlier but got diverted to the latest crisis.

    David Wrote:


    "I don't know anything about a Go Daddy "Driver Signing Tool"; maybe you found that statement elsewhere."


    My bad, I meant to say Godaddy's "Driver Signing Cert" as opposed to their "Code Signing Cert".

    And Yes, I followed your instructions and everything works fine on Win7 now that I installed the root certs you recommended!!

    Still I must find a way for my driver package to install without the warning message in Win7 without having users install the cert.

    Godaddy support (I have little confidence in them) swears up and down that I can double sign my Catalog file by following instructions here:


    Signing a driver package with two signatures

    In some cases, you might want to sign a driver package with two different signatures. For example, suppose you want your driver to run on Windows 7 and Windows 8. Windows 8 supports signatures created with the SHA256 hashing algorithm, but Windows 7 does not. For Windows 7, you need a signature created with the SHA1 hashing algorithm.

    Suppose you want to build and sign a driver package that will run on Windows 7 and Windows 8 on x64 hardware platforms. You can sign your driver package with a primary signature that uses SHA1. Then you can append a secondary signature that uses SHA256. You can use the same certificate for both signatures, or you can use separate certificates. Here are the steps to create the two signatures using Visual Studio.

    • In the Solution Explorer window, right-click Solution SolutionName, and choose Configuration Manager. For the driver project and the package project, set Configuration to Win7 Release, and set Platform to x64.
    • Open the property pages for the driver package. Navigate to Configuration Properties > Driver Signing > General. In the Sign Mode drop-down list, select Production Sign. For Production Certificate, enter the path to your signing certificate.
    • In the property pages for the driver package, navigate to Configuration Properties > Custom Build Step > General. For Description, select Performing Custom Build Step. For Execute After, selectDriverProductionSign. For Command Line, enter this command.

      Signtool sign /fd sha256 /ph /as /sha1 XX...XX $(TargetPath)

      where XX...XX is the hash of the certificate you are using for the the secondary signature.

      Note  To see the hash (also called the thumb print) of a certificate, open a Command Prompt window and navigate to the directory that contains your certificate. Enter the command certutil -dump CertName.pfx, whereCertName.pfx is the name of your certificate.


    From what I gather, the issue is:

    1. Godaddy's "Driver Signing Certs" defaults to signing with a SHA 256. For whatever reason, most Win7 installations do not have the appropriate root cert installed to support SHA 256.

    2. According to Godaddy if I resign my Catalog file again with SHA1 then everything should work. They claim they have done this with other users.

    3. According to Microsoft the  Signtool utility used with following parameters will resign a Catalog that's already signed with SHA1 to SHA256.

    Signtool sign /fd sha256 /ph /as /sha1 XX...XX $(TargetPath)

    But I need to resign to SHA1. If I can resign to SHA1, then everything should work properly with the GoDaddy root that's installed normally in Win7 machines.


    1. Is Godaddy giving me bad info? According to them I can sign my Catalog file twice with the same cert. According to you I will need another cert.

    2. If I can double sign the Cat file, what are the proper Signtool parameters to make sure its signed again with SHA1.
    The Microsoft sample is for going from SHA1 to SHA256, but I'll need to go from SHA256 to SHA1. If I was using Godaddy's Code Signing Cert this would be an issue.



    Randy Feingersh

    Friday, February 15, 2013 10:52 PM
  • Randy Feingersh wrote: "And Yes, I followed your instructions and everything works fine on Win7 now that I installed the root certs you recommended!!"

    Randy, the root certificate you installed is *supposed* to be delivered automatically by Microsoft over the internet when Windows 7 checks the signature on your driver, as explained in this document from Microsoft:

    As you can see, the download is not happening in a reliable and timely manner.  Maybe it isn't even happening at all on your Windows 7 test machine.  Your machine is connected to the internet, right?

    To Microsoft: Randy and I have each encountered this problem with the automatic root certificate updating, so I am more confident now that it is a bug in Windows.  You can see the details of my problems with it here.

    Randy, I was in the exact same situation as you not long ago.  Instead of asking Go Daddy for a refund, I asked them if I could switch over to their Code Signing Certificate product, which is the same price.  They allowed me to do it, and that certificate worked for me.  As far as I can tell, the Code Signing Ceritifcate from Go Daddy offers a superset of the features of the Driver Signing Certificate because it lets you choose SHA1 or SHA2.  If you choose SHA1, your certificate is rooted to a certificate that will already be installed on Windows 7.

    Yes, I think Go Daddy is giving you bad info.  You can probably sign your catalog file twice with the same cert, but it will NOT help because that certificate's chain of trust still goes back to the problematic root certificate which is not getting downloaded correctly onto Windows 7, no matter how you choose to sign your files.  You should read my document instead.

    --David Grayson

    • Edited by DavidGrayson Saturday, February 16, 2013 4:36 PM
    Saturday, February 16, 2013 4:35 PM
  • David,


    One - I am really perturbed at the incompetent support from Godaddy. I have numerous emails from their advanced support team that double signing with the Driver Signing Certs I purchased from them will work. They provide the same Microsoft link I posted in my last post of the model to use. Also it was Godaddy that recommended I use their "Driver Signing Cert" as opposed to their "Code Signing Cert" when I initially told them what I wanted to do - sign a catalog file.

    Two - I really hope someone at Microsoft chimes in. If this is just a matter of not having the correct root certifcate download when it should then this should be addressed.

    I'm still open that there might be more to this issue and I apologize in advance to both Godaddy/Microsoft if this is the case.


    Randy Feingersh

    Saturday, February 16, 2013 5:42 PM
  • Hello, everyone.  The claim I made about SHA-1 being required to get your driver loaded into the kernel in Windows Vista and Windows 7 might be false.  A developer at PiXCL Automation Technologies has contacted me and basically said that he was able to get his driver loaded into the kernel in Windows 7 using a SHA-2 Driver Signing Certificate from Go Daddy. He just had to sign it twice, using the /fd sha1 option to support Windows 7 and the /fd sha256 option to support Windows 8. I have not had the resources to verify his claim, but he seems pretty competent and convincing to me. You can read his new tutorial on Signing Windows 8 Drivers.  I have updated my document to add some references to his work, but I am not totally convinced yet.

    --David Grayson

    Tuesday, March 12, 2013 5:09 AM
  • Hello again, everyone.  I have a received an email from another developer who we can call "Landon".  Landon says he had a Go Daddy certificate and tried to use the tutorial from PiXCL for double-signing but it did not work for him.  However, he was using WDK 7.10 instead of using the latest one, so that probably doesn't mean too much.

    Landon ended up getting a refund from GoDaddy and going with Digicert.  He said that Digicert's systems and customer support were much better than Go Daddy, and he was able to successfully get his driver signed, installed, and loaded.

    --David Grayson

    Saturday, April 20, 2013 7:17 PM
  • Thanks, we have gone the same way.

    Tsang Chan

    • Edited by Tsang Chan Tuesday, September 17, 2013 2:38 AM
    Monday, April 22, 2013 3:55 AM
  • Hi

    Great article.

    I used your advice and went for the GlobalSign's Code Signing Certificate. 

    I needed to sign the Cypress CYUSB driver. I modified the inf more multiple OS support and for it to load the correct cyusb.sys.

    Working on a Win7 x64. I used the Inf2cat.exe to create a .cat file for 7_X86,7_X64,8_X86,8_X64

    I then signed and timestamped this file using SignTool.

    When I load the driver (on the same Win7 x64) I trust the company but then I get a code 52 as in your article. Thinking that the cyusb.sys file needed signing

    I signed the cyusb.sys (x64 and x86) files. I used SignTool verif and all was ok.

    Again when I install the driver I get code 52 error.

    I spoke to GlobalSign and there answer was that I can't use this to sign hardware drivers.

    Is this correct, wndering if anybody else is having any issues. Note all was ok signing the .cat and .sys files.

    Any advice/help much appreciated.



    Wednesday, May 1, 2013 4:58 PM
  • Hi

    Initially I only signed the .cat file but I get a code 52 error when loading the driver. I signed the .sys file as well, although it verified ok, it didn't help.

    what causes the code 52 error? I'll tru again without signing the sys files.


    Wednesday, May 1, 2013 5:02 PM
  • Hello, Jaswinder.  The Code 52 happens when Windows would like to load your SYS file into the kernel but it refused to because it cannot find a good signature for the SYS file.  The standard place for the signature is on the CAT file that you redistribute to your users, not the SYS file itself, though that is an option.  Here are some ways to troubleshoot this:

    1) Make sure your INF file refers to the catalog file using a CatalogFile directive.

    2) Make sure that the generated catalog file contains a hash for the SYS file you wish to load.  You can double-click on it to inspect it.

    3) Make sure that the signature on your catalog file meets all the requirements that I specified.  Feel free to post the catalog file here in this thread and I will take a look at it for you!

    4) Make sure that the catalog file is present in the same directory as the INF file when you are installing the driver.

    5) Make sure that after installation your catalog file is present in C:\Windows\System32\catroot or one of its subdirectories.

    If you do all of these things, I think it should work, but it is always possible that there are more gotchas that I did not know about.

    The person you talked to at GlobalSign is probably wrong: their datasheet claims that their code signing certificates offer "Vista Kernel Support".  Anyway, just post your signed cat file here and I can see if the signature would be good.  You don't have to post any other files if you don't want to, but I and others in the community can learn a lot by looking at your catalog file.  It will help us evaluate GlobalSign's certificates.

    Thursday, May 2, 2013 10:43 PM
  • Hi

    Ok I have finally got it sorted.

    The certificate I had from GlobalSign was the Code Signing Certificate.

    After speaking to a person on their support team who said it wasn't the right one, I cancelled the order because it was coming upto the 7 day refund period.

    Anyway after reading David's article again (amazing what you pick up reading stuff 2nd, 3rd... time), along with one or two others I decided to check the GobalSign Root Certificate I had, It didn't chain back to Microsoft. I then again spoke to a support guy at GlobalSign (lot more clued up than the last), he said yes there is no reason why I cannot use this to sign my driver.

    So I decided to give it another go today. BTW the driver I'm trying to sign is the Cypress cyusb.

    If it helps anybody else this is what I did:-


    • Signing PC. GlobalSign recommend that I use a 32-bit PC, but the software is installed on a Win 7 x64, so I used that.
    • Code Signing Certificate (bought from GlobalSign (£178.80)
    • Cross Certificate (Downloaded from Mirosoft FOC )
    • WDK 8.0 (Downloaded from Microsoft FOC )
    • Driver package containing the inf, sys files and access to the cross certificate and the .pfx file I received from GlobalSign.

    Create a catalog file

    I’ve created a multi OS inf file and this contains the name of the catalog file and references the sys files for correct OS.

    1. Open an elevated command prompt. (Right-Click and select Run as administrator).
    2. Change directory to “Program Files (x86)\Windows Kits\8.0\bin\x64”.

    Note: there is also a x86 folder but I used the x64 folder to run the tools from.

    1. Need to use the Inf2cat executable to create a catalog file (.cat) from the install file (.inf). The .cat file produced will be unsigned.

    The command I used was:-

    Inf2cat /driver:”c:\UsbDriver\wlh” /os:7_X86,7_X64,8_X86,8_X64


    ”c:\UsbDriver\wlh”is the path to the inf file and 7_X86,7_X64,8_X86,8_X64are OS’s I want to install this driver on.

    Sign the catalog file

    The Inf2Cat produces an unsigned catalog file, now I want to sign it with the certificate from GlobalSign (.pfx file) and the GlobalSign cross certificate I downloaded from microsoft.

    signtool.exe sign /v /ac "c:\UsbDriver\wlh\crt\GlobalSign Root CA.crt" /f “c:\UsbDriver\wlh\elx\XXXX.pfx” /p <MyPassword> /t” “C:\UsbDriver\wlh\"

    That’s it.

    I verified the signed catalog file using the verify option of the signtool utility.

    signtool.exe verify /v /kp /debug /a ”c:\UsbDriver\wlh\”

    So now when I install the driver for our usb device, I just point it to the inf file folder. No more warnings and more importantly x64 OS loads the sys without any problems.

    So in short the Code Signing Certificate from GlobalSign was the right one, I just didn't have the correct cross certificate.



    Friday, May 3, 2013 2:35 PM
  • Hi David.

    Excellent article.  Extremely helpful.  I notice in your article that one should expect the Windows Security prompt that asks, "Would you like to install this driver software?" which has the check box to always trust software installed by the publisher. 

    Is there any way to make this message go away during the installation on each client in our domain?  We want to have a completely silent install with no user prompts at all.

    Tuesday, May 14, 2013 8:33 PM
  • Hello Sprockrates278.  Thank you!  For our purposes, the "Would you like to install this device software?" dialog was acceptable so I did not put too much effort into getting rid of it.  However, I did find two things that might be helpful to you:

    First, the Virtual Com Port (VCP) drivers for the CP2102 can be installed without triggering that warning message ( ).  I believe these drivers were WHQL-signed.  I don't know much about the WHQL process, but it involves sending your drivers to a Windows Hardware Quality Lab to be tested.  When you pass the test, they sign the drivers for you.  Based on that, I believe that if you get the drivers WHQL signed then anyone can install them without that warning.

    Secondly, you should check out libwdi ( ).  It claims to have a way of installing drivers with no security warnings.  I think it works by generating its own certificate and installing the public key into one of the certificate stores on the user's computers.  Maybe you could just use libwdi or you could implement something similar yourself.  I would be interested to know what your experiences with it are.  Since you are deploying this to people on a domain, maybe you could use the domain to put the certificate on everyone's computer ahead of time.  Then there would only be one certificate on each computer instead of one certificate for every time a driver is installed.

    If you solve this problem, please let us know!  Sharing is cool!

    --David Grayson

    Wednesday, May 15, 2013 4:58 PM
  • Thank you!  WHQL or installing our own into the cert store. Looks like we'll look into option two, since we don't want to go through the Windows Logo testing at this time.  I appreciate the reply.

    Wednesday, May 15, 2013 5:35 PM
  • First, I want to express my appreciation for publishing the very useful article on this overcomplicated issue. I was with you (the author) till the section "Loading the kernel module". The phrase that  "Some driver packages contain kernel-mode code (SYS files)" seems to me confusing. My relatively modest experience says that all drivers that I came across contained SYS extension and you covered this question in the previous section "Driver package installation in in Windows 7 and Vista". Actually, I am confused because I am not sure what to do. I need to sign a new audio driver that has 2 flavors (two SYS modules): for 64 and 32-bit. I was ready to start the process with GlobalSign. I prepared a package with INF, CAT and 2 SYS files where INF file contains the info about SYS files' location and CAT file was created by Inf2Cat utility. Now, my question is do I have to load and install GlobalSign cross-certificate and if I do, should I install it into Personal/Certificates? From your section I think that the answer is 'yes', I have to. At the same time we are using a similar audio driver that we purchased from a vendor and which works perfectly. Trusted path for this driver looks: VeriSign Class 3 Public Primary CA                                                                        VeriSign Class 3 Code Signing  2009-2 CA                                                                           NTONIX, Ltd

    It looks for me that this chain does not contain VeriSign cross-certificate. Please advise.


    Friday, May 17, 2013 7:02 PM
  • Hello, Alex.

    Lots of people, including me, create driver packages that do not contain SYS files.  The INF file in the driver package can refer to a SYS file that comes with Windows, such as usbser.sys or winusb.sys.  This is very convenient because then we don't have actually write a real Windows driver and the signing requirements for that driver package are less strict since we are not loading any new code into the kernel.

    In your case, it sounds like you do have two SYS files in your driver package.  In that case, you should download the cross certificate from Globalsign, put it in a directory on your computer, and refer to it using "/ac" parameter of signtool when you are signing the driver.  Go back and read my How to sign section for more information.  You not need to "Install" the cross certificate; just put it on your hard drive and refer to it with the "/ac" parameter.

    When you inspected the signature from the other vendor by clicking around in Windows, it might not have shown the cross certificate.  I think Windows generally doesn't show the cross certificate, which is too bad.  I think you could use signtool with the "verify" and "/kp" options to better see what is going on in their signature.

    --David Grayson

    Saturday, May 18, 2013 6:01 PM
  • Hi David,

    Thank you for your fast and very educational response. I will follow your recomendations and share my experience about GlobalSign after I buy the certifiacte later next week.

    Saturday, May 18, 2013 6:35 PM
  • David:

    Our solution was to distribute our certificate and certmgr.exe from the the latest Microsoft Windows SDK with our installer.  We then called certmgr to install our certificate before our installer installed the drivers.  The command used:

    certmgr.exe -add OurCertificate.cer -s -r localMachine trustedpublisher
    Wednesday, May 22, 2013 6:33 PM
  • You do realize that certmgr.exe is not in the redist directory of the SDK, so should not be redistributed without acquiring a license from Microsoft to do this?

    Personally I consider installing a cert in a machines certificate store without telling the customer to be less than ethical.  I sometimes review software for large firms and they all rejected a small software firm that tried this.  This is why you WHQL.

    Don Burn Windows Filesystem and Driver Consulting Website: Blog:

    Wednesday, May 22, 2013 7:44 PM
  • Hello, Don.  Spockrates278's first post explains that he is just trying to do this for all the computers on his domain.  I don't think he is distributing it.

    Thanks for the tip, Sprockrates278!  So certmgr.exe can do its job without prompting or warning the user at all?  That is kind of surprising.  So any installer could do the same thing I suppose; once it has administrator privileges it can load any kind of code into the kernel, unless I am missing something.

    --David Grayson

    Wednesday, May 22, 2013 8:10 PM
  • Hello David,

    I have purchased the code signing certificate for my 64/32 bit drivers from GlobalSign. I followed their recommendations:

        Please use a 32bit Windows XP machine to perform the signing operation. Vista and Windows 7 64bit machines do not yield a successful signing result.
        Ensure the GlobalSign Root certificate is removed from the certificate store on the local machine. If the GlobalSign Root is present, Signtool will fail to embed the cross certificate.
        Ensure the cross certificate is available to the Signtool application.
        Ensure the GlobalSign ObjectSign end entity certificate is available in the local certificate store.

    I had "successful" installation:

    C:\winddk\7600.16385.1\src\general\icvac>Signtool sign /v /ac "C:\certificate\cr
    oss\GlobalSign Root CA.crt" /s my /n "IC Manage Inc" /t http://timestamp.globals
    The following certificate was selected:
        Issued to: IC Manage Inc
        Issued by: GlobalSign CodeSigning CA - G2
        Expires:   Fri May 23 10:11:28 2014
        SHA1 hash: 50801CBC143AEFD0DB8F9AE7AA09DECF1A35C2AD

    Cross certificate chain (using machine store):
        Issued to: Microsoft Code Verification Root
        Issued by: Microsoft Code Verification Root
        Expires:   Sat Nov 01 06:54:03 2025
        SHA1 hash: 8FBE4D070EF8AB1BCCAF2A9D5CCAE7282A2C66B3

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

                Issued to: GlobalSign CodeSigning CA - G2
                Issued by: GlobalSign Root CA
                Expires:   Sat Apr 13 03:00:00 2019
                SHA1 hash: 9000401777DD2B43393D7B594D2FF4CBA4516B38

                    Issued to: IC Manage Inc
                    Issued by: GlobalSign CodeSigning CA - G2
                    Expires:   Fri May 23 10:11:28 2014
                    SHA1 hash: 50801CBC143AEFD0DB8F9AE7AA09DECF1A35C2AD

    Done Adding Additional Store
    Successfully signed and timestamped:

    Number of files successfully Signed: 1
    Number of warnings: 0
    Number of errors: 0
     But actually it is a failure. I have exactly the same "Unknown Publisher" message and "Driver load" error that I used to have with an unsigned driver. It looks like GlobalSign support is not a great help. The could not help me although they escalated the issue. I certainly can cancel my order. I still have time left but I need to sign my driver. It blocks the whole project.

    Please advise.



    Something else. When I look at the trusted chain I can see my companies certificate only in "Personal" store where I put it when I imported PFX file. I don't see it in any other store.


    Finally I got through. I think the problem was related to my INF file and the way how utility Inf2Cat works. It successfully created CAT file for me and I successfully signed this file (after my forum question I checked the signature of the CAT file and it looked OK). BUT the driver's installation did not work as I described above. I took another approach and created very simple CDF file:[CatalogHeader]                                                              



    Then I used Makecat utility. When I signed the new CAT file, my installer installed the 64 bit driver without any problem. I am going to check now how the installation goes on 32 bit version of Win. 7.

    I have a new question: can I use the same certificate to sign my executable file that uses installed driver? Another question is how long can I use the given certificate for signing?

    Thank you in advance.


    • Edited by AlexSerge Thursday, May 23, 2013 4:44 AM
    Wednesday, May 22, 2013 9:44 PM
  • Hello, Alex.  I am glad you figured out your problem.  Unfortunately, I don't understand why you had to write your own CDF file, but I am glad it worked for you.

    Based on my experience I think two of the instructions from GlobalSign that you quoted are probably not necessary:

    "Please use a 32bit Windows XP machine to perform the signing operation. Vista and Windows 7 64bit machines do not yield a successful signing result."
    "Ensure the GlobalSign Root certificate is removed from the certificate store on the local machine. If the GlobalSign Root is present, Signtool will fail to embed the cross certificate."

    Yes, you should be able to use the same certificate to sign your executable files and your installer.  You wouldn't need the cross certificate for that, but it doesn't hurt to have it.

    When you bought your certificate, you paid for a certain time period, i.e. your certificate probably expires a year from now.  You can see the expiration date pretty prominently if you view it in certmgr.msc; it says "Valid from ____ to ____" in the left-most tab.  If you try to sign something with that certificate 13 months from now, it probably will not work.  However, as long as you use timestamps on your signatures, the signed files you distribute should keep working indefinitely.  I see you are getting a timestamp from Globalsign's server, so that is good.

    --David Grayson

    Thursday, May 23, 2013 5:56 AM
  • Fantastic article.  Thank you very much for writing it.  (And upvoted.)

    I did notice that, at some point in the last two years, Vista got an update to fix the issue where double-clicking a downloaded SHA-2-signed executable silently fails.

    Wednesday, July 10, 2013 6:56 PM
  • David... thanks for posting this information. It was incredibly helpful to me... like you, I'm using the "fake modem" driver and simply need to sign the .inf for use with Windows 8. You saved me a ton of time... and made a little revenue for Go Daddy on the side. --Jim, Austin, TX
    Monday, September 16, 2013 9:23 PM
  • Thanks, Josh!

    Jim, I am glad the article was helpful to you.  The Go Daddy certificates will work for you and I can understand the desire to pick the same thing that worked for me.  However I should just say that GlobalSign's certificates seem to be better and that's what I recommend.  :)

    --David Grayson

    • Edited by DavidGrayson Tuesday, September 17, 2013 3:05 AM
    Tuesday, September 17, 2013 3:05 AM
  • +1, very good article.

    Starting on September 2013, and after the installation of a security patch from Microsoft, our installers (.msi files) cannot be verified because of a failure to verify GoDaddy root certificate.

    I've contacted GoDaddy technical support and they insist the problem is in the parameters I'm using for signing the file and timestamping it but I've tested with SHA2, SHA1 all with the same result. The problem is not the algorithm but the root certificate authority no longer trusted by Microsoft.

    At this time I'm requesting certificates from GlobalSign (SHA-2 certificates) and also from Verisign. Our code is not a driver and does not contains kernel code.

    Note, the certificate was working from July 2013 to September 2013, and it started facing problems after the installation of a security update from Microsoft.

    If you have further information I'll be happy to read it.

    • Edited by IgHR Friday, September 20, 2013 11:45 AM typos
    Friday, September 20, 2013 11:42 AM
  • Hello IgHR, and thanks for your information!

    It is very interesting that your problem started happening around September 2013, because I and a bunch of other developers started having a similar problem with the Go Daddy signatures in Internet Explorer around that time.  Please see my other thread:  Why does IE10 tell my users that my executable download signature is "corrupt or invalid"?

    What happens if you use the /pa option during the verify step?  As I discussed in my article, I think that is the correct option to use if the signature is for an executable.  Do you see the "GO Daddy Root Certificate Authority - G2" in your Trusted Certification Authorities (TRCA) list in certmgr.msc?  What clues made you think it was a security update, and have you identified it yet?

    --David Grayson

    Friday, September 20, 2013 3:42 PM
  • I write a similar docs ,but due to security issue I can not make it into public ...

    Best Regards, Mike

    Sunday, September 22, 2013 10:46 AM
  • Thanks. One of the best articles available on this subject.
    Sunday, October 6, 2013 7:27 AM
  • One of the best articles available on this subject.
    Thanks!  If you find an article that is better, let me know!

    --David Grayson

    Monday, October 7, 2013 1:15 AM
  • Hi David,

    Have you used DPINST with your installation setup? I have found that on some XP installs DPINST fails with the message Install Failed (usbser) not signed. I'm paraphrasing as I don't recall the wording exactly. My best guess is that usbser.sys is not in the Windows directory already, but instead in some Microsoft install package. This is on XP SP3. I've been following your method very closely and it works great on Win7 and Win8 and some XP installations. When DPINST works it's great on Win7 and Win8 because to the user it's as nice as plugging in an HID. On XP there are still too many dialogs, so maybe I shouldn't even bother?


    Wednesday, October 30, 2013 3:29 AM
  • Well I think I have answered my own question. I'm not a software developer by trade, so if anyone has a better explanation please chime in. What worked for me was to include the /lm (legacy mode) switch on the DPINST command line. I think what is happening is that the older versions of USBSER.sys such as on XP are not signed. And since I'm referencing them in a signed installer, then that causes a problem.

    And here is the information when it failed, in case anyone is web searching this issue.

    Cannot Complete the Device Driver Installation Wizard
    (usbser) Install failed (unsigned)

    Finally DPINST.LOG in the WINDOWS directory was of some help.

    Thursday, October 31, 2013 6:00 PM
  • Hmm, MSDN failed to email me about either of your posts and I'm not sure why!  I have not used DPINST with usbser.sys, so I haven't experienced the problem you had.  I am glad you were able to solve it.

    I think your guess about usbser.sys not being in the right place in the Windows directory beforehand is probably right; I think winusb.sys and winusb.dll are in some other place and they get copied (to C:\Windows\system32 C:\Windows\system32\Drivers) the first time it is needed on Windows XP.

    --David Grayson

    Monday, November 11, 2013 9:53 PM
  • Hi! Your signing guide is awesome! Bit I have a problem. Could you please explain this sentence:

    This is not particularly surprising if you think about it: the dangers of loading code into the kernel depend only the code itself, not the device or INF file it is being used with.

    I have a driver package that was signed by "Microsoft Windows Hardware Compatibility Publisher". But the .inf file was changed to configure installation. Now Windows rejects it's installation, because it's "not signed". Old .cat files doesn't work anymore with this driver. New .cat file wich I created using Inf2Cat doesnt have a digital signature and obviously doesn't work as well. Is it possible to make my driver work without purchasing a certificate?

    Thursday, November 21, 2013 1:05 PM
  • Hello, Григорий ОПБ,

    The digital signature covers the INF file itself as well. If you change even a single bit in the inf, it will break the signature.  So yes, it must be signed again and must get some valid certificate. 

    Unlike the proverb, there is only one way to sign a .cat ;)  but there are few ways to get the certificate. Buying online is the simplest, but you could request that the client for whom you do the work, provides the cert.

    As to your question on thinking about the dangers - it is very interesting, but not technical.


    -- pa

    Thursday, November 21, 2013 1:41 PM
  • Thanks for the fantastic article David!

    Question:  When creating drivers for windows 8/8.1, do you always have to use the latest 8.1 DDK, or can 7.1 suffice to sign an existing windows 7 driver?

    The MS download site for DDK 8.1 says that I require to first buy VS2013 before I can use the DDK.  Is there any way around this?  I don't really want to upgrade our development system just to sign a few bits of code to get legacy products working in Win 8!



    Wednesday, December 4, 2013 1:28 PM
  • Thanks for your guide.  It helped me get a vendors device (which came with an old version of a 3rd party usb to serial driver) to install on windows 8 using the latest windows 8 serial driver with a modified inf file signed with our corporate CA.

    Tuesday, December 31, 2013 8:36 PM
  • I used your guide along with the PixCL guide your referenced to get the Silicon Dust Labs drivers I customized to work. Good stuff.

    I can confirm that you need to sign Windows 8 drivers with SHA256 to get them to install. SHA1 was fine for Windows 7. So you have to sign the catalog file you create with both.

    In short we used a Godaddy Code signing certificate with a SHA2 signature. Exported to PFX and signed with that. I added the Microsoft cross-signing certs for Godaddy but I don't think they were necessary. If you use a PFX file you can export the certificate chain along with it, btw.

    • Edited by SonofSmog Wednesday, June 8, 2016 5:33 PM
    Friday, January 10, 2014 4:47 PM
  • Thank you for the informative tutorial.  I had my employer get a GlobalSign code signing certificate (SHA-1).  I used the latest Win 8.1 SDK and DDK (you do not need Visual Studio).  The batch file should include the full path to the inf2cat and signtool as they rely on files in the SDK/DDK install folders.  The root certs from Microsoft was easy to get also.  As long as your inf file is correct, the batch file will create a clean signed CAT file and you have a driver that works for Windows 8.1.  I have one of the new "Atom 2" tablets (Dell Venue 8 Pro) and Dell uses bitlocker on the flash so an unsigned Win8.1 driver will not install, even in recovery.  With your steps I created a driver that installs cleanly from Control Panel/Explorer.  Thanks again, Mike

    WHS OEM, Celeron2.0, 1GB, 7 JBOD (3.0TB), Vista/XP mix clients + xbox360

    Thursday, January 16, 2014 2:11 AM
  • Hello, Григорий ОПБ.

    Sorry I didn't see your message for so long.  That sentence of mine you quoted was just an intuitive justification for the interesting behavior I described above it in the article.

    Basically, Windows has one rule for deciding if it will let you install a driver package (i.e. INF file), and another rule for if it will allow a piece of code (i.e. SYS file) can be loaded into the kernel.  The rules are independent of eachother, and the rules can be satisfied by different signatures made by different companies.

    If you want your modified INF file to work in Windows 8 without making your customers modify the security settings of their system, you will need to purchase a certificate.

    --David Grayson

    Friday, March 7, 2014 7:30 PM
  • Hello, Andy.

    I have not tried too many different versions of the DDK.  I think Microsoft always encourages you to use the latest one, and that is generally a good idea in case they fixed any bugs in it.  However, I suspect you could use the DDK for Windows 7 and successfully sign things for Windows 8 and 8.1.

    --David Grayson

    Friday, March 7, 2014 7:32 PM
  • Hello, SonofSmog.  Thanks for the feedback!  I am glad you got things working.

    Could you explain what exactly went wrong in Windows 8 when you didn't use SHA256?  If you have a sample of the bad driver, I could take a look at it and maybe figure out what went wrong.

    The reason I ask is because I still think you don't need SHA-2 to get a driver working on Windows 8.  My evidence is that I was able to get our CP2102 drivers working on Windows 8.  The two signed CAT files in there both use SHA1.  I have not tested Windows 8.1 though.

    --David Grayson

    Friday, March 7, 2014 7:40 PM
  • Very informative! Thank you.

    We have a CDC (RS-232) device with our own VID/PID and it should work with the usbser.sys and a proper inf configuration. Does this still need to be signed even though that there are no new drivers being installed?



    Tuesday, May 13, 2014 10:25 PM
  • Hello, Monte.

    Yes, starting with Windows 8 you need to sign that serial driver even though it is just a simple INF file using a driver that is part of Windows.

    INF files are actually pretty powerful; they can copy files, run DLLs (e.g. coinstallers), and add things to your registry.  I think Microsoft just wants to make sure it can track down any problems that are caused by faulty INF files on a customer's computer.

    --David Grayson

    Wednesday, May 14, 2014 10:23 PM
  • Thanks for the excellent article and for starting this discussion thread. I only wish I had found it much earlier.

    Just wanted to share my experience- hopefully this will help someone in the future.
    I'm an independent developer and operate under a Sole Proprietorship. I had 2 .sys files that needed signing.

    Go Daddy gave me nothing but headaches as I tried to get through their verification process. At first they told me I cant get a cert as a Sole Proprietor, then they changed their mind when I asked for a refund.. it was an entire month of frustration.

    Eventually I got in touch with DigiCert's support, was very happy with all the answers, purchased their "standard" code signing cert (as opposed to Go Daddy who seem to only do full EV) and had the cert in a couple days!
    Signing the .sys/.cat files, as well as the installer .exe, all worked as expected and the drivers install/load on Win 8 just fine.

    Digicert has my vote!

    Sunday, May 18, 2014 12:34 AM
  • Again - this seems like a good source of information! Thanks!

    I noted that GlobalSign has a requirement of using IE, ActiveX to sign files and it has to be from the profile where the account was made. I was wondering how other services allow you to sign files such as Go Daddy and Symantec (Verisign) to sign files. Is it a web-app or client? This information seems to be allusive.

    Thanks again,


    Monday, May 19, 2014 5:54 PM
  • Success, but boy was it painful.

    Some notes from the process I underwent

    1. It seems that IE11 generates the CSR when re-keying a certificate (at least at GoDaddy).  So you don't need to generate it manually.  Although Firefox will generate it, GoDaddy will not enable the Download option in Firefox.  So I had to use IE11 to re-key and download the certificate (pfx) file.

    2. I used the export function (Internet Options, Content, Certificates, Export) in IE11 to generate the .pfx file.  This only works if you had first installed the certificate in IE11 (part of the GoDaddy download process).

    3. I used InstallShield (version 2011) to create an installer for the inf and cat driver files.  Initially I would get the unfriendly message from Windows 7 that the drivers where not signed.  This led me down the path of thinking that the signing of the drivers did not work properly.  When in fact they had.  I needed to sign the setup.exe (specify the Digital Certificate File and Certificate Password in Releases, Release, Signing) generated by InstallShield as well to get Windows to be happy.

    Thank you for your guidance in this area.

    This process is way more difficult than it should be.

    Saturday, May 24, 2014 1:00 AM
  • Hello, RumJungle.

    Maybe you were looking at GlobalSign's Installation Guide?  I think the only point of using ActiveX is to help you generate and install the certificate onto your computer and then after that you would use the usual utilities like SignTool to actually make the signatures.  I wouldn't worry about it.

    --David Grayson

    Wednesday, June 18, 2014 9:29 PM
  • Thanks for this write-up David (found blog post originally). I especially found it useful to see the visuals/symptoms of not signing the different permutations. One area I am not finding much information about is what it looks like when your certificates expire and you did not properly timestamp. I have tried to reproduce the scenario naively by setting my system clock past the expiration date, but this doesn't seem to cause any problems. Are you aware of a way to reproduce that scenario?
    Wednesday, August 6, 2014 12:54 PM

  • The answer is "It depends"

    I see that this thread (and the original article) primarily focuses on inf based installs. What you need to probably explore is, getting away from this "inf based install" and come up with a scheme that basically does the equivalent of what the inf does. All this, assuming that your .sys file is signed.... Ill give you two examples: one simple and the other, slightly more elaborate.

    At its most fundamental level, a driver is just a special windows service whose code gets loaded in the kernel. So naturally this means that just like any other service you basically need 2 things 1. a service entry and 2. the service binary i.e. the .sys file. Once these 2 are in place, "starting the driver service" is as straight forward as "net start xyz" or "sc start xyz"... furthermore, assuming the driver is signed, the "driver service" would be started without any popup. See, the popup is the aspect of "inf based" install logic. The fundamental requirement is that your .sys has to be signed for the "system" to be able to load it. And that is the reason why an embedded signature is required for boot start drivers. So basically I can write a legacy style driver, mark its service entry to start at boot time and then demand load it AT THE TIME of "driver registration" on an up and live machine (to differentiate it from inf based install).

    Now, lets take a more realistic example of a PnP based filter driver stack; say a filter driver to disk class devices. Typically inf based install for this class would throw a prompt to reboot the machine at the end.. and rightly so because, for your filter to attach to all device stack instances (ones which were already PnP'ed at boot time i.e. prior to the "inf based install" taking place) a fresh build up of all existing PnP stacks is required. Now in this case, if you have to get away from the inf and cat based install then you'd have to manually write to the upper/lower filters key (as the case might be), register the driver's service entry ans copy the .sys to System32\drivers folder (and it seems that, but for demand load drivers, the .sys for every other type has to go into the System32\drivers folder). That is it. At this point, if your custom inf handler decides not to reboot then what's gonna happen is that all disk devices which would be exposed on the system AFTER this manual registration would get an instance of your filter driver while all disk stack instances which were already PnP'ed BEFORE your manual registration, would fail to get an instance of the filter. You can continue to offer your filter's services for all new disk devices till the point a reboot happens (explicit or implicit). Whether that is practical or not is a different issue all together... Idea is to understand what your inf is doing and attempt to replicate it outside the scope of SetupAPI. If you can do that and if your .sys is signed then you can load it.. bye for now.

    Thursday, August 7, 2014 9:23 AM
  • Hi David,

    I must join the others and thank you again for this fine article.

    I'm trying to resolve the issue when downloading a binary via IE and getting the "corrupt or invalid" message.

    I've tried your recommendation of using the /tr switch instead of /t, however I still get the same problem.

    I'm using the signtool.exe from SDK 8.1 and IE version 10.0.9200.17028

    I've tried using the following timestamp server but it did not responded:

    so I've used this one instead:

    but eventhough I still get the "corrupt or invalid"  message.


    Monday, September 1, 2014 2:54 PM
  • There is a hotfix to make SHA2 Authenticode certificates work on Vista:

    Yuhong Bao

    • Edited by Yuhong Bao Wednesday, September 3, 2014 7:39 AM
    Wednesday, September 3, 2014 7:36 AM
  • Hi Yuhong Bao

    thank you for replying, however I'm facing the problem on a windows 7 platform and this hotfix is relevant for Vista


    Sunday, September 7, 2014 3:30 AM
  • Hello, jdart.  Sorry for the delay in getting back to you.  I think if your certificate has expired and your signature has no timestamp, then most of the parts of Windows that look for signatures will just consider the signature to be missing, and act the same as if there was no signature.  If you look at the properties of the signature in Windows then I think there should be an error message about the certificate having expired.  I'm afraid I don't have a screenshot of it, but I remember that the Arduino IDE recently came with a driver that lacked a timestamp.  I tweeted to them about it on 2014-01-17, so if you can work out what version of the Arduino IDE was available at that time, you should be able to find drivers in there with expired signatures.

    --David Grayson

    Saturday, September 13, 2014 1:42 AM
  • Hello, nirfra.  I'm sorry you are having trouble with Internet Explorer downloading your file.  It's quite possible that you are encountering an issue that I haven't faced before.  What company did you get your certificate from and do you know if it uses SHA1 or SHA2?  Could you post an example of your signed executable here so I can try it out?  If you don't want to give away your executable on the internet, or if it's larger than a few megabytes, you could just compile a simple "hello world" app and sign that.

    --David Grayson

    Saturday, September 13, 2014 1:49 AM
  • Yuhong Bao, thank you for telling me about KB2763674.  I updated my article to mention it.  Do you know if there was a similar fix to allow SHA-2-signed kernel modules to be loaded in Windows Vista 64-bit and Windows 7?  If there is, then it should be safe to switch over to SHA-2.  If not, then I'm going to keep hanging onto my SHA-1 certificate.

    --David Grayson

    • Edited by DavidGrayson Saturday, September 13, 2014 2:21 AM
    Saturday, September 13, 2014 2:21 AM
  • Pavel A: What kind of signatures are you talking about?  There are at least three different kinds of signature checking that Windows does: executable signature checking, driver package signature checking, and kernel module signature checking.  The last time I looked into it (2012), SHA-2 appeared to work for only 2 out of 3 in Windows 7, as described in my article.

    Can you provide a link to an official Microsoft document saying that SHA-2 is supported in Windows 7 and/or Windows Vista 64-bit for the purpose of loading a kernel module?  If so, that would be helpful because everyone needs to switch to SHA-2 by 2016.

    --David Grayson

    • Edited by DavidGrayson Monday, September 22, 2014 10:50 PM
    Saturday, September 13, 2014 2:24 AM
  • Hi David,

    An update was published on October 16th that added SHA-2 support for kernel drivers in Windows 7 and Windows 2008 R2 (not Vista or lower, or 2008 R1 & lower)


    Thursday, October 23, 2014 11:28 AM
  • FYI: Globalsign says they're no longer doing the individual deal, and won't sell to a DBA (must be incorporated)...

    Thursday, October 23, 2014 3:16 PM
  • David,

    Your article was a life saver. Another thing I discovered was that I had to install the CP210x_VCP_Windows drivers as well as the signed driver package I created in order to get silabser.sys loaded. The driver package that the "CP210x Driver Customization Utility" created does not include the file for whatever reason.

    I will try to get a sample of that Windows 8 driver that required SH256 to install.

    Maybe I can just add it?


    Daniel Blackmon

    God help me I am trying to work in VB.NET 2005

    • Edited by SonofSmog Thursday, November 6, 2014 7:15 PM
    Thursday, November 6, 2014 7:07 PM
  • Thank you for the article, it sums up the topic excellently and helped me greatly!
    Monday, November 24, 2014 7:59 AM
  • For me it still is not clear, will SHA1 certificates work for kernel mode drivers signature in Windows 8??

    PS: Very good article, helped a lot to understand the matter. This question might be something you could add to the paper too David ;)
    Tuesday, December 16, 2014 3:33 PM
  • Daniel, your story about the CP210x doesn't seem too surprising, given the things I described in the article about how the kernel modules (SYS files) just need to have some valid signature and it doesn't necessarily have to be related to the signature on the INF file that is using the kernel module.  I'm not sure what you're talking about when you refer to a "Windows 8 driver that required SH256 to install".

    --David Grayson

    Tuesday, December 16, 2014 9:12 PM
  • RzRDigo, yes, as long as you meet all the requirements that I documented in the "Signature Requirements" section, it should work.

    Why did you have doubts about it working?  Microsoft is usually pretty good with backwards compatibility, so I expect properly-signed SHA-1 drivers with timestamps to keep working for many years, probably even on the upcoming Windows 10.

    --David Grayson

    Tuesday, December 16, 2014 9:14 PM
  • Thanks David!

    I had the doubt because nowhere it mentioned that Windows 8 accepted the SHA1 nor the backwards compatibility (not the resources I read). I thought the drivers for Windows 8 and later would have to be signed again with a SHA256 certificate for them to work.

    Wednesday, December 17, 2014 3:39 PM
  • Hi David and all other here ;)

    After i found the reason why our code signed driver is not working on Win7, i found that post and your website...

    Some of our costumers with Win7 have big problems with the installation of our SHA256 signed drivers.

    Now we can sign the drivers with SHA1, but as a read on Microsoft site, SHA1 would be deactivated in 2016.

    If that, all our costumers will ring our phone on this date - that's not good ;)

    My solution to fix that issue was to certificate the driver with SHA1 AND SHA256 with the help of the SignTool /as command.

    Now i have another problem - the additional cert is not valid...why ever.

    If i use our command line fot SHA256 OR SHA1 all certificates are okay, but if i use a additional of booth there shown a message with invalid signature.

    These command terms i used at the moment:


    signtool sign /ac
    \\[ServerPath]\GlobalSign_Root-CA.crt /f \\[ServerPath]\OS*_SHA1.pfx /p [PASS]
    /tr c:\SIGN\*.*


    signtool sign /ac
    \\[ServerPath]\GlobalSign_Root-CA.crt /as /f \\[ServerPath]\OS*_SHA256.pfx /p
    [PASS] /tr c:\SIGN\*.*

    After i certificate booth, the second one will be displayed error.

    If i use booth certificates separate and without /as it will worked.

    Did anybody have a solution of our problem?

    I'm a bit confused at the moment :(

    • Edited by Bjoern Ge Thursday, January 8, 2015 11:03 AM
    Thursday, January 8, 2015 11:02 AM
  • Updated:  I have removed my inf file to make this post smaller as I figured out the problem!  You can't have any spaces in your inf file name.  Apparently it is still 1999.  I'm surprised you can have more than 8 characters!

    Hi David!

    First off, fantastic article!  I wish I had found it sooner while trying to get everything working, probably would have saved me a bit of time.  Either way though, it got my over my last hump of "why isn't this working?!?!?!"/

    I do have one final thing that isn't working that I'm hoping you'll be able to help me out with.  My driver is properly signed and can install on Windows 7 and Windows 8 and when you go to the Driver tab in the Device Manager, it says that it is digitally signed with the correct company name (the same that the .cat file says).  However, when installing it, it pops up with the dialog box that says "Do you want to install this device?"  The name is "Unidentified Device" and the Publisher is "Unknown Publisher".

    I found on your site where it said to use the DriverPackageDisplayName field, but it doesn't seem to do anything for me.

    What am I missing?  Am I missing an INF field or mistyping something?

    Unrelated question that maybe you know the answer to.  I built my .cat file with 7_X86,7_X64 as I am on a Windows 7 machine so that seemed the most reasonable thing to do while testing.  However, I ran out to the lab and tested it on a Win 8.1 machine and it worked fine... What does building it with the 8_X86,8_X64 do for me?

    Thanks for your time and thank you for the very detailed document!

    • Edited by Jimmy Kaz Wednesday, January 21, 2015 10:59 PM
    Thursday, January 15, 2015 12:13 AM
  • Hello Bjoern Ge.

    Sorry for the late response; I still don't know why MSDN isn't emailing me when people post in this thread.  I want to encourage people to post here so that the world can benefit from seeing the discussion, but it's probably a good idea to also shoot me a short email with a link to your post if you want me to see it soon.

    I have several comments about your situation, Bjoern:

    1) What makes you think that all SHA-1 signed drivers will suddenly stop working in 2016?  Microsoft would get a lot of calls if that happened, it's not just your company.  Microsoft Security Advisory 2880823 just says that they are going to stop issuing SHA-1 certificates around that time.  For the sake of backwards compatibilty, I expect SHA-1 drivers will keep working for many years, and maybe even be supported in Windows 10.

    2) I have never tried to sign my software or drivers twice.  You might check out this tutorial from PiXCL to see if it helps.  They used one certificate somehow, but they signed it in two different ways so it could work on multiple versions of Windows:

    3) Your SHA-1 and SHA-256 certficates should have totally different chains of trust; it seems like you would not be able to use the same cross certificate for both of them, like you are doing in the commands you posted.

    4) If this stuff doesn't help, then maybe you could post your signed CAT file and a more detailed description of the error you are seeing and how exactly you reproduced it.

    --David Grayson

    Sunday, February 8, 2015 6:04 PM
  • Thanks for the tip, Jimmy!  I never tried using an INF file with spaces in the name, but I have confirmed that you can have more than 8 characters, like you said.  At my company we have a general principle to avoid spaces in file names.  I added your tip (and a link to this comment) in the Signing Requirements section of my article, in case it helps anyone else.  Thanks!

    Could you clarify what error the spaces caused on the two different versions of Windows?  Did you get the same message in Windows 7 and Windows 8?  Did it look like this image, except with an unidentified device and unknown publisher?

    With regards to the 8_X86,8_X64 options for inf2cat: No, I don't know what it gets you.    Since the CAT file is basically just a mapping of filenames to hashes, maybe those options control the set of files we be inside the CAT file.  I would imagine that if you are making a driver release that is only supposed to work on Windows 7, then inf2cat would only make hashes of the files needed for that version. It's also possible that the OS options don't do anything and they are just there in anticipation of some change in the future.  In general, Microsoft tries to make later versions of Windows support drivers and software that worked on earlier versions so that's why you didn't see an error when you tried the driver on Windows 8.

    --David Grayson

    Sunday, February 8, 2015 6:25 PM
  • Hi David,

    Great write up, thanks for sharing your experience!.

    I am looking to do the same thing as your drivers on

    I have used SiLabs USB Driver Customization Utility (AN220 - to create my own VCP drivers for a device with custom VID/PID.  As mentioned in SonofSmog's reply, it doesn't generate a .cat file.  However, from your section regarding Kernal loading, I was able to successfully use from their original drivers - rename it and make appropriate changes to the inf of my custom drivers to reflect the rename.  So I have a functioning driver that installs on both Win7 32/64-bit system and the device operates as it should for both.

    My question is regarding the removal of the yellow warning UAC and the Red Win Security window to "Install driver anyway" to make everything nice and pretty for the end-user.

    If I'm understanding your write-up correctly, signing both the "..._x64.exe" and "..._x86.exe" files will get rid of the yellow UAC warning windows only and not the Red Windows Security window.  Does this generate a .cat file, is this where sign.bat comes from, or is the signing embedded into the .exe's?

    Removing the Red Win Sec window seems to occur when you sign the entire driver package/folder (x64/x86 folders, dpinst.xml, ..._x64.exe, ..._x86.exe,, slabvcp.inf)

    Could you explain in more detail your process for removing the UAC and Win Sec warnings and where your company .inf, .cat and sign.bat fit in to this process?

    Thanks for your continued support!

    • Edited by RichieStu Friday, March 13, 2015 2:34 PM
    Thursday, March 12, 2015 4:57 PM
  • Hello, RichieStu.  Thanks for emailing me separately, because MSDN still is not notifying me about these replies.

    In order for the user to launch your executables (*x86.exe and *x64.exe) without scary warnings, there needs to be a proper signature embedded inside each executable.  You would use signtool to make that signature, and the CAT file would not be involved.  Note that signtool actually modifies the executable file.  This is what I document in the "Running an Executable" section of my guide.

    In order for the user to actually install your driver after the executable has started running, you need to use inf2cat to generate a CAT file that has cryptographic hashes of all the files involved, and then you need to use signtool to add a proper signature to that CAT file.  The properties of this signature are what I document in the "Installing a Driver Package" section of my guide.

    Then in order for the user to actually succeed in using your driver when they plug in a matching device, there needs to be a signature for the .SYS files somewhere, but it doesn't have to be the same signature that was used to convince windows to install the drivers, as described in the last paragraph.  If your certificate isn't good enough, you can piggy back off of the signature provided by Silicon labs.  This is described in the "Loading a Kernel Module" section of my guide.

    So as you can see, there are three different types of signatures involved in your project, and each is documented in my guide.  Your project involves all three types, so you need to know about all of them.

    The sign.bat file you found in the Pololu CP2102 driver download creates the first two types of signatures.  For the third type, we rely on Silicon Labs.  For reference, in case we take it down at some point, here is sign.bat:

    "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 /t /n "Pololu Corporation" /r "Go Daddy Class 2 Certification Authority"
    "C:\Program Files (x86)\Windows Kits\8.0\bin\x64\signtool" sign /v /t /n "Pololu Corporation" /r "Go Daddy Class 2 Certification Authority" pololu-cp2102-setup-x86.exe
    "C:\Program Files (x86)\Windows Kits\8.0\bin\x64\signtool" sign /v /t /n "Pololu Corporation" /r "Go Daddy Class 2 Certification Authority" pololu-cp2102-setup-x64.exe

    I don't really know how to get rid of all the warnings, but you can at least make those warnings friendlier.  If you have questions about a specific warning, please post a screenshot of it and say what version of Windows you are talking about.  In Windows 8, the typical user will see all of these warnings when installing your driver, if you follow the same type of path that I did:

    Because it was downloaded from the internet they might see something like this: (or more likely, it will be one of those SmartScreen dialogs that takes over the entire screen and requires a few clicks to override).

    Because it requires administrator privileges:

    Because it installs a driver that wasn't signed by Microsoft or one of their agents:

    --David Grayson

    Thursday, March 12, 2015 5:48 PM
  • Thanks for emailing me separately, because MSDN still is not notifying me about these replies.

    Just something to check in case you haven't already.  There is thread in the "Forum Issues" section where this was the accepted answer:

    "Have you checked the alert address set for your forum profile? That's set by clicking on the 'Quick access' dropdown in the upper left (under the 'Ask a question' button) and choosing 'My settings'. There's a 'Configure alerts' section there where you can specify an address to use for alerts."

    Credit to the forum moderator, Mike Laughlin if it works for you.

    - Dave L.

    Friday, March 13, 2015 11:10 PM
  • Hi David,

    Thanks for the post. I found it to be good reading as I am preparing to transition to SHA-256 code signing certificates.  I need to sign kernel mode drivers and continue to support Windows 7 x64.

    Microsoft indicates on their Signing a Driver for Public Release page that: "Windows 8 supports signatures created with the SHA256 hashing algorithm, but Windows 7 does not. For Windows 7, you need a signature created with the SHA1 hashing algorithm. ... You can sign your driver package with a primary signature that uses SHA1. Then you can append a secondary signature that uses SHA256. You can use the same certificate for both signatures, or you can use separate certificates."

    Based on the above, my understanding is that one can use a SHA-256 code signing certificate in any case as long as the driver file signature is generated from the certificate's private key as a SHA-1 hash.  Furthermore, the Signing Windows 8 Drivers tutorial that you linked to by PiXCL Automation Technologies suggests that while Microsoft's documentation for SignTool's /fd command-line argument may state that SHA-1 is the default file digest algorithm, in practice the algorithm must be specified explicitly.  I might speculate that this caveat is one of the main stumbling blocks for those who have switched from a SHA-1 certificate to a SHA-256 and found that their newly signed drivers no longer work.  However, I have yet to actually begin my testing of drivers signed with a SHA-256 certificate in Windows 7.

    Actually, I am hoping that you get around to your own SHA-256 certificate transition and update your Practical Windows Code and Driver Signing document in the mean time so that I'll have a good reference to follow.  ;)

    I want to highlight one issue I've had thus far.  I have a SHA-256 certificate from GlobalSign (although they currently say that a SHA-1 certificate should be used for Windows 7 support).  And I have the latest code signing tools from the Windows Driver Kit 8.1 Update 1. Using these, I have attempted to dual-sign some driver files using both a primary SHA-1 signature and a secondary SHA-256 signature.  The signing commands are similar to the following:

    signtool sign /v /fd SHA1 /ac "MSCV-GlobalSign.cer" /n "CERT_NAME_HERE" /tr /td SHA1 "DRIVER_FILE_HERE"
    signtool sign /v /as /fd SHA256 /ac "MSCV-GlobalSign.cer" /n "CERT_NAME_HERE" /tr /td SHA256 "DRIVER_FILE_HERE"

    Note that in both cases, the digest algorithm is set explicitly (using /fd for the file signature and /td for the time-stamp signature), and /tr is used for RFC3161 compliant time-stamping.  Another important thing to note is that, while only one cross-certificate can be specified, all certificates in the trust chain have already been imported into my Personal Certificate Store--including the MSCV-GlobalSign Root cert and the GlobalSign SHA-256 Root CA cert.  The second command only adds the /as parameter indicating that SignTool should append the SHA-256 signature as a secondary signature rather than replacing the previously attached SHA-1 signature.

    I subsequently verify the driver file signatures using a command similar to:

    signtool verify /all /kp "DRIVER_FILE_HERE"

    When I perform the above commands for a .SYS file, the signing commands report success, and the verify command also reports success (showing both a SHA-1 primary and SHA-256 secondary signature).  However, when I perform the above commands on a catalog (.CAT) file, then the signing commands report success, but the verify command reports an error for the SHA-256 secondary signature: "SignTool Error: No signature found."

    This is where I'm stuck until I get around to further testing, or someone can point out the solution.  Maybe the drivers will just work anyway?  I don't know.  There's also the chance that Microsoft will get KB2949927 working to support SHA-256 kernel mode driver signatures in Windows 7/Vista so that we don't strictly have to dual-sign as long as the end-user has applied the update.

    - Dave L.

    • Edited by dmlilienthal Saturday, March 14, 2015 5:15 PM Formatting
    Saturday, March 14, 2015 5:12 PM
  • Update to my above post...

    I finally tested and found that the 64-bit drivers I signed with a SHA-256 certificate from GlobalSign, either using a SHA-1 signature or dual SHA-1 and SHA-256 signatures, failed to load on Windows 7 x64.  I tried some variations on the SignTool command-line parameters, but was unable to get the drivers to load in any case.  The same drivers both installed and loaded fine in Windows 8 x64.  32-bit drivers signed with the SHA-256 certificate using the same SignTool commands successfully installed and loaded in all 32-bit Windows versions from Windows 2000 to Windows 7 (I did not test Windows 8 x32, but I imagine they would work there too).  This appears to match David Grayson's original findings.  I've failed to reproduce the success of PiXCL Automation Technologies, but there are at least two differences from their case: 1) they are using a GoDaddy certificate; and 2) they are using WDK 8.0 tools with VS2012 while I am using WDK 8.1 with VS2013.  There seems to be a difference in the command-line arguments between WDK 8.0 and WDK 8.1.  But it may be that the extra certificate in the trust chain required by the SHA-256 GlobalSign certificates is the culprit.

    Anyway, I went back to a SHA-1 certificate from GlobalSign and signed the 64-bit drivers with a single SHA-1 signature, and the drivers once again installed and loaded fine on Windows 7 x64.  I have not tried dual-signing using the SHA-1 cert for the primary SHA-1 signature and the SHA-256 cert for the secondary SHA-256 signature, but I suspect that would work as well--as long as the certificate for the primary signature is a SHA-1 cert.

    The latest news is that Microsoft released KB3033929 last week (10-Mar-2015).  This patch supersedes the previously removed KB2949927 patch and again adds support for SHA-256 to Windows 7 and Server 2008 R2.  I tested my 64-bit drivers dual-signed with the SHA-256 GlobalSign certificate again after installing that patch, and they were finally able to load.  So, at least there's that.  I still prefer having driver files that will work across all Windows versions without depending on that patch, so for now I'm planning to stick with the SHA-1 certificate.

    - Dave L.

    • Edited by dmlilienthal Tuesday, March 24, 2015 4:59 PM typo fix
    Friday, March 20, 2015 9:39 PM
  • Dave, thank you for all the information.  I have updated the note at the top of my article with information about KB-3033929!

    --David Grayson

    Saturday, March 21, 2015 2:28 AM
  • I have just updated the document to support SHA-2 and Windows 10.  I have also reversed my opinion on timestamping: think it should be done with /t instead of /tr because /tr doesn't seem to work for Windows Vista.  Also, I have added some insight into how intermediate certificates work, and how they could be useful.

    This is the biggest change I have made to the document since I released it in January 2013.  Enjoy!

    --David Grayson

    Thursday, July 16, 2015 5:07 PM
  • Hi David, thank you for this great document. Have you looked into the new Windows 10 driver signing requirements from Microsoft? All kernel drivers now need to be signed by Microsoft as well.
    Thursday, July 16, 2015 5:50 PM
  • vparthas, thanks for pointing that out!  I had heard about it before but then forgot about it.  I'll update the article.  

    I think I actually got my kernel-mode driver working on Windows 10 preview without submitting it to Microsoft; maybe they haven't really added that requirement yet but they will before Windows 10 is released.

    --David Grayson

    Monday, July 20, 2015 8:30 PM
  • vparthas, I have updated my article now.  Does it look good?  I haven't actually been able to find the portal and try it out, and Microsoft is not answering any of the questions on their announcement of the portal.  I wonder if they will change their policies before Windows 10 really comes out.

    --David Grayson

    Friday, July 24, 2015 6:35 AM
  • Hi David,

    This is a great document you've put together! I found it very helpful working through an update to our driver library (from Silicon Labs).

    I'm using the Windows 10 SDK/DDK, and I noticed that inf2cat has a couple of os options that you don't list in your example script, namely "6_3_X86" and "6_3_X64". Apparently these are for Windows 8.1 which is a different version from Windows 8. Thought you might want to add those for completeness sake.

    Thursday, August 6, 2015 9:58 PM
  • Thanks, strandec.  I added those!

    --David Grayson

    Saturday, August 8, 2015 12:32 AM
  • Hi David,

    Had to follow these steps to sign a driver package you very well describe in your guide. Unfortunately it was in 2007, so your writings didn't exist yet. It would have saved a lot of headaches to me :-)

    My driver package was for a PnP USB device. The 64-bit version was cat and sys signed, and works fine up to Windows 10. The 32-bit version wasn't signed, because at the time of development the basic requirement was to let the driver load on 64-bit platforms, the only ones where Microsoft announced to enforce a digital signature at the time of Vista.

    About 32-bit platforms, it's still unclear to me whether a digital signature is needed or not. From my company's customer care reports it seems NO, provided "driver signature enforcement" is not turned on. This somewhat contradicts your guide where you say a digital signature is needed since Windows 8, not mentioning 32/64 so letting the reader assume it's for both. Is there a clear statement from Microsoft about this?

    BTW, do you know if something changed across Windows versions about the default driver installation policy for unsigned drivers - "Ignore", "Warn", "Block"? This could explain the increasing number of digital signature issues we are experiencing on most recent Windows'



    Monday, August 24, 2015 10:32 AM
  • Hi David,

    Great article.  The information definitely glued together a lot of my fragmented knowledge on the subject of driver signing.  I don't see a whole lot of people annoyed by the dialog box prompting the user to Install/Don't install.  I have an Installation package that has been working great (for 2 years) until I went to Sha256 for my code signing cert.  On windows 7 x64, with my code, the MSI, the setup.exe and .cat file all signed with a SHA1 coding signing cert my installation sails through with no warning/"friendly" boxes.  This includes both the standard GUI driven install and a silent install.  However, when I sign all elements with my new SHA256 cert, I do indeed receive the "Would you like to install this device..." dialog box.  Additionally, it is the signed .cat file that is causing the popup box.  I am trying to figure out a way around this.  My customers favor silent installs.  Here are some more details:

    I do install the cert (.cer file) before the driver install: certutil.exe -addstore "TrustedPublisher" "mycert.cer"

    The above line is placed in a batch file just before this:

    rundll32 printui.dll, PrintUIEntry /ia /m "AFClient PS" /h "x64" /v "Type 3 - User Mode" /f "ps.inf" /F "%windir%\inf\ntprint.inf"

    Again, The above has been working great for a few years now.  Many hours of research went into getting my install to work "quietly" and the above code was very key in getting that done.  But..., switching to a new SHA256 cert is the only difference and I would like to know what I can do to make this extra dialog box (that does not show with SHA1) disappear.

    Monday, August 24, 2015 12:46 PM
  • Hi David,

    Great article.  The information definitely glued together a lot of my fragmented knowledge on the subject of driver signing.  I don't see a whole lot of people annoyed by the dialog box prompting the user to Install/Don't install.  I have an Installation package that has been working great (for 2 years) until I went to Sha256 for my code signing cert.  On windows 7 x64, with my code, the MSI, the setup.exe and .cat file all signed with a SHA1 coding signing cert my installation sails through with no warning/"friendly" boxes.  This includes both the standard GUI driven install and a silent install.  However, when I sign all elements with my new SHA256 cert, I do indeed receive the "Would you like to install this device..." dialog box.  Additionally, it is the signed .cat file that is causing the popup box.  I am trying to figure out a way around this.  My customers favor silent installs.  Here are some more details:

    I do install the cert (.cer file) before the driver install: certutil.exe -addstore "TrustedPublisher" "mycert.cer"

    The above line is placed in a batch file just before this:

    rundll32 printui.dll, PrintUIEntry /ia /m "AFClient PS" /h "x64" /v "Type 3 - User Mode" /f "ps.inf" /F "%windir%\inf\ntprint.inf"

    Again, The above has been working great for a few years now.  Many hours of research went into getting my install to work "quietly" and the above code was very key in getting that done.  But..., switching to a new SHA256 cert is the only difference and I would like to know what I can do to make this extra dialog box (that does not show with SHA1) disappear.

    Monday, August 24, 2015 12:48 PM
  • Thnx, loved the artical!

    you may want to look in to/add the following reference document too:

    Wednesday, August 26, 2015 10:19 PM
  • Hi Alessandro! It's nice to hear from someone who has been doing this for longer than I have. I made my first USB driver in 2009, but didn't need to worry about signing until 2012 when we were making Windows 8 work.

    Alessandro Donati wrote:
    About 32-bit platforms, it's still unclear to me whether a digital signature is needed or not. From my company's customer care reports it seems NO, provided "driver signature enforcement" is not turned on. This somewhat contradicts your guide where you say a digital signature is needed since Windows 8, not mentioning 32/64 so letting the reader assume it's for both. Is there a clear statement from Microsoft about this?

    If we are talking about Windows 7 and above, my understanding is that there is no difference between the 32-bit behavior and 64-bit behavior. Both of them require signatures on kernel modules (SYS files), but both of them have an option for disabling driver signature enforcement to get around that. The driver signature enforcement is enabled by default on any system that supports it, right? My goal was to make drivers that did not require the user to disable driver signature enforcement.

    I confess I did not test any 32-bit systems when I did a major update to this article a few months ago. I didn't think there would be important differences to test. Anyone developing a driver these days really should support 64-bit systems, so it's not particularly useful for me to find new ways of using drivers that only work for 32-bit systems, but if I come across compelling evidence of a quirk of the 32-bit systems then I might add it to my article.

    BTW, do you know if something changed across Windows versions about the default driver installation policy for unsigned drivers - "Ignore", "Warn", "Block"? This could explain the increasing number of digital signature issues we are experiencing on most recent Windows.

    I am not sure what policy you are talking about, but my article explains that unsigned INF-only drivers were installable just fine from Windows XP to Windows 7. Then that stopped in Windows 8. Is there some active directory group policy thing that affects that behavior?

    --David Grayson

    Wednesday, September 2, 2015 12:55 AM
  • Hi, Jim.

    Which company provided your old SHA-1 certificate and your new SHA-2 certificate? Sharing information like that will help other developers.

    My understanding is that if the user clicks the "Always trust software from" checkbox when installing a driver package, the certificate that signed the .cat file will be added to the Trusted Publishers list in the certificate store, and the user will no longer see prompts when installing drivers signed by the certificate. You are trying to avoid the prompts altogether, so you are trying to use certutil.exe to install the drivers into the store ahead of time.

    I haven't used certutil.exe, but I do know that Zadig has some functionality for adding certificates to the certificate store. So, for what it's worth, it should be possible to do it from a C/C++ program without using a separate executable.

    I am also not familiar printui.dll and all those options you are passing to it. But I suppose it might be similar to calling SetupCopyOEMInf or the other ways of installing a driver that I mentioned in my article.

    As a first step to debugging this: are you sure that certutil.exe actually succeeded in installing the certificate? You can look in certmgr.msc to see if it worked.

    Your SHA-2 certificate presumably has a chain of trust that goes back to a different root than the SHA-1 certificate. It might be problematic if that trusted root certificate is not in the Trusted Root Certification Authorities (TRCA) ahead of time. You might try using certutil.exe to install that root certificate and any needed intermediate certificates before installing your own certificate.

    If the root certificates are the issue, installing an appropriate SHA-1 to SHA-2 intermediate certificate on the computer that performs the signing could help too, and might be an alternative to calling certutil.exe twice as I suggested above. See my article section about intermediate certificates.

    When you figure all this out, please do everyone a favor and share the name of the company that provided the certificate, and the exact commands you used to generate the drivers and install them. Thanks!

    --David Grayson

    • Edited by DavidGrayson Wednesday, September 2, 2015 5:15 PM
    Wednesday, September 2, 2015 1:10 AM
  • Thanks, IdiotZ42_1.  I will add that as a reference.  It will be very useful if anyone wants to write a proper signature checker that doesn't have the numerous problems that "signtool verify" has.

    --David Grayson

    Wednesday, September 2, 2015 1:12 AM
  • Hi David and Jim,

    First, thanks David, for gathering all information about Driver Signing in one great article. It is very helpful.

    We also encounter an issue regarding silent installation.
    I can provide some new information.

    We are signing our driver with a new Digicert Certificate which contains an SHA2 signature. Before we were using a VeriSign Certificate (SHA1 signature) and we had no issue at all.

    After signing our driver with the new certificate, installation (with prompt) and loading driver is OK. Of course for Windows 7 we need KB3033929.

    The issue comes when we select the checkbox "Always trust the software from <Our Company>" at driver installation time. This has no effect on Windows 7, when we re-install our driver later, the popup again appears, the installation is not silent.
    This problem affects only Windows 7, for Windows 8 and 10 it is working fine.

    I've compared the certificate chain between Windows 7 and 8, it is the same:
    DigiCert (CN=DigiCert High Assurance EV Root CA) => Digicert EV Code Signing CA (SHA2) (CN=DigiCert EV Code Signing CA (SHA2)) => Our Certificate.
    The chain is reported as valid by Windows 7 and 8. "Digicert" is properly located in TRCA on both.
    However I've found a difference, when looking for "Digicert EV Code Signing CA (SHA2)":
    - for windows 7: it is located in Intermediate Certification Authority.
    - for windows 8: I'm not able to find it in certificate store. I've looked at Machine level also. I don't know where is located this certificate (however it is valid and accepted).
    It is weird I can't find it for working case...

    For driver installation, we have derived a program from DevCon WDK sample application (which uses SetupCopyOEMInf). We are not using printui.dll. Our driver is a virtual network adapter.

    Thanks for any suggestion/comment regarding this issue.


    Monday, September 21, 2015 7:11 AM
  • Hi David,

    thanks very much for responding!  My initial SHA1 cert was provided by Thawte.  The cert. chain looks like this:

    Thawte (CN = thawte Primary Root CA) => Thawte (CN = Thawte Code Signing CA - G2) => Our Certificate.

    The new cert (SHA2) was also provided by Thawte:

    (CN = thawte Primary Root CA)(SHA1) => (CN = thawte SHA256 Code Signing CA) => Our Certificate (SHA2).

    The certutil.exe application I have been using is working correctly.  I've been using it will success for a while and after running the utility I visually inspect the cert store to verify.  Here is some light reading  The app is installed on Windows already.

    The printui.dll app comes with Windows and enables me to install a postscript driver in an OS independent manner.  Well independent with respect to Windows versions only (XP, VISTA, Win7...).  The utility takes an INF file as input but looks for a CAT file which I generate using: inf2cat.exe /driver:.\  /os:7_X64,Server2008_X64,Server2008R2_X64,Server8_X64,8_X64.  I then sign the CAT file.  My installer does many tasks during an install, but it is the installation of this Postscript driver (supplied by Windows) that causes the message box.

    I believe it is quite possible that this is a thawte issue.  The root cert is SHA1, the intermediate cert is SHA2 and my cert is SHA2.  They recommend this as most compatible.  I have tried SHA2 root as well, but switched back since the behavior was the same.  I am in the process of purchasing another cert from Semantec (Verisign).  I will resign everything and then run some more tests.

    Also, during any given installation once I proceed past the message box by clicking "INSTALL", I am not bothered again when I do the next install.  This does not solve my problem since I need the correct behavior on the first installation.  Thawte's support team told me my issues may be a reputation problem.  Not sure what that means.

    Also note, I have tried to install the root and intermediate certs with my cert ahead of time (not during installatioin).  I have tried several different combinations including installing all certs (manually) before running my installation.  I wanted to eliminate any potential issues with installing certs from within an InstallShield setup.exe. 

    Thank you FredTGB for you post.  I do not "check" the box during my testing.  I will try to run some more tests to see if all certs in my chain get installed if I check the box.  Seems to me I have seem similar issues to what your are experiencing.

    thanks all

    Monday, September 21, 2015 12:56 PM
  • Hi Jim,

    Thanks for the new information.

    Did you test on Windows 8 or 10 ? Just to confirm the problem is similar to ours (only Windows 7 and Vista affected).

    We are in a process to get a new SHA1 certificate from digicert, so we will be able to determine if the problem is related to SHA2, or if the problem is related to Digicert/our signing process.

    To us, the first step is to have the Publisher known when checking the box and installing the same driver again. If this doesn't work, adding manually the Publisher before doing the installation, will not work either.



    Update: We got our SHA1 certificate from Digicert, and the problem disappears: the driver installation is again silent when the Publisher is known.

    • Edited by FredTGB Tuesday, September 22, 2015 2:29 PM
    Tuesday, September 22, 2015 6:25 AM
  • FredTGB:  Thanks for letting us know you solved the problem.  Is it fair to summarize your issue like this?

    "Silent installation of driver packages that are signed with a Digicert SHA-2 certificate do not work on Windows 7 and below, resulting in the user seeing an unwanted prompt.  Switching to a SHA-1 Digicert certificate fixed the problem."

    FredTGB: What are you going to do when SHA1 certificates are no longer available?

    Hopefully your advice can help Jim solve his problem.

    --David Grayson

    • Edited by DavidGrayson Tuesday, September 22, 2015 6:22 PM
    Tuesday, September 22, 2015 6:21 PM
  • Hi David,

    Yes, you can summarize our issue like this. However, I think it is not specific to Digicert, probably Jim encounters the same issue with Thawte. Also before reading this discussion I had found another occurrence with GoDadddy (

    Maybe "Silent Installation" has to be defined, there are 2 cases:

    1. Not silent the first time => the user check the box, and next installations with the same Publisher will be silent

    2. Before doing the driver installation, the Publisher certificate is placed into the "Trusted Publisher" store, and then any installation (including the first) is silent.

    Another information: for Windows 10, we observe that when installing the first time (not in silent mode) the prompt appears with the check box ticked by default. This is a change compare to Windows 7 and 8.

    To answer your last question, we don't know yet what will do when SHA1 certificate are no longer accepted under Windows 7. We have also created an incident on Microsoft Support, so maybe a fix or workaround will be available if the issue is confirmed by Microsoft (it is not the case right now).

    We have understood that until the end of 2015 we can sign (with timestamp) driver signed with SHA1 certificates. So, we have some time to see what will happen exactly.



    Wednesday, September 23, 2015 6:39 AM
  • Thanks to David Grayson for the original post and Dave L. for his discussion of different signing digests. I've been trying to test various combinations of OS (32 bit and 64 bit) with signing digest and certificate:

    SHA1 sign, SHA1 cert

    SHA1 sign, SHA2 cert

    SHA1 sign followed by SHA2 sign, SHA2 cert

    SHA2 sign, SHA2 cert

    SHA2 sign followed by SHA1 sign, SHA2 cert

    And I've been testing all of those above combinations with:

    1. Copy signed file over the network, check digital signatures for presence and validity, try running EXE, try running EXE as Admin.

    2. Same as 1, but download the EXE from a web page (so it gets marked as Downloaded From The Web which enforces different rules)

    3.  Open a web page that requires downloaded (signed!) CAB files to run.

    4. Install a signed driver, check driver status for Code 39 / Code 52 et al

    5. Test running a (signed) Click Once app downloaded from the web.

    I'm here to tell you it's a hot mess of some combinations work in some OS's and some don't. I'm STILL testing.... Needed an Excel spreadsheet to track it all. I'll upload it when I get a little more data.

    David Grayson: can you clarify (if you know) EXACTLY what the Microsoft deprecation policy is? From their blog post it looks like Win7 and above (Server 2008R2 and above?) starting 1/1/2016 they will no longer accept (newly signed) code that is signed with an SHA1 CERTIFICATE. It says nothing about the DIGEST method. Do BOTH have to be SHA2 to be acceptable?

    Thursday, September 24, 2015 3:32 PM
  • Whoo boy this gets a LOT messier. I've discovered that even SignTool 10.0 (Win10 SDK / Studio 2015) does NOT support dual signing of MSI files.

    And Mage.exe, used for creating, updating and signing both app manifests and deployment manifests for Smart Client apps (required) similarly does not support dual signing at all. Not even Mage 4.6 in the Win10 SDK. (And better yet mage 4.6 doesn't support my older .Net 2.0 app manifest, which is yet another problem. Apparently manifest handling inside Studio 2015 DOES support .Net 2.0 apps, but they didn't rebuild mage to let you specify the target framework!)

    So the issue of whether Win7 and later will tolerate apps with an SHA1 signature METHOD and an SHA2 CERTIFICATE. If not, then Houston we have a HUGE problem. My XP and Server 2008 VMs won't tolerate downloading CAB files in IE if signed with SHA2 method only. And that's a situation where you can't really have two separate builds. You'd need two separate WEB SITES.

    Any suggestions?

    Thursday, October 1, 2015 9:55 PM
  • Hi David, Jim,

    I finally got an answer from Microsoft, regarding the "untrusted Publisher" issue: KB2921916 fixes it.

    After applying this hotfix, if the Publisher (with an SHA2 certificate) is in the Certificate Store, then the dialog box no longer comes when the driver is installed.

    I hope this KB will be automatically deployed before SHA1 depreciation will be effective.



    Thursday, October 8, 2015 3:05 PM
  • I opened a support incident with Microsoft (via MSDN) to get some answers. So far I think the following rules apply to Win7 and above:

    1. Legacy apps (already signed and timestamped BEFORE 1/1/2016) will be accepted until 1/1/2020.

    2. Apps newly signed after 1/1/2016 must use an SHA2 CERTIFICATE. File hash and timestamp can still be SHA1.

    3. Apps newly signed after 1/1/2017 must use SHA2 for certificate, file hash AND timestamp.

    4. Web site SSL certs must be SHA2 after 1/1/2017. If your SHA1 cert expires after that you still need to get a new SHA2 cert before 1/1/2017.

    5. MSI files cannot be dual-signed, period. You should dual-sign the setup.exe file and that should solve the problem.

    6. Win10 will require NEW drivers to be submitted through their Windows Hardware Developer Center Dashboard portal.

    7. Existing drivers signed with SHA1 from BEFORE the release of Win10 will still be accepted by Win10.

    Hope that helps. I still have a number of questions they have yet to answer about what to do regarding having a single app that works in both Win7+ and Server2008- (that don't seem to tolerate SHA2 signatures or certs very well). Once SHA2 is required for cert/hash/timestamp on 1/1/2017 I'm wondering whether a web app needs to be deployed to separate web sites for Win7+ clients and Server 2008- clients!!!

    Better yet, see the article warning of the possibility of exploits of SHA1 vulnerabilities by year's end:

    Monday, October 12, 2015 9:27 PM
  • Hello, Bill.  Thank you for all your efforts and for sharing your knowledge with the community.

    All I know about Microsoft's SHA-1 deprecation comes from their announcement on 2013-11-12:

    The key sentence is "The new policy will no longer allow root certificate authorities to issue X.509 certificates using the SHA-1 hashing algorithm for the purposes of SSL and code signing after January 1, 2016."

    A key phrase is "root certificate authorities": I interpret this to just be a rule they are imposing on root certificate authorities (the companies that issue certificates to folks like us); it does NOT tell us that any digital switches in Windows itself are going to be flipped on 2016-01-01.  I think that this deprecation of SHA-1 is really just words on paper at this point.  I don't know if Microsoft even has any way to enforce the deprecation besides kicking a disobeying root certificate authority out of the Microsoft Root Certificate Program and issuing revocations of their certificates.

    A key word in this sentence is "issue".  You might be able to get a SHA-1 certificate issued to you right now, and you can use it to make signatures for some number of years until it expires, even if it expires after 2016-01-01.

    Another key word is "certificate": they are only talking about the certificates, not the signatures that you produce with such certificates.  I heard a rumor that Microsoft was more worried about the certificates being compromised, not individual signatures.  So I believe that you can keep using SHA-1 as the digest method for your signatures for many more years.

    (I'll keep reading your posts and respond to individual points in them in separate messages.)

    --David Grayson

    Monday, October 26, 2015 7:07 PM
  • Hello, Bill.

    I'm not familiar with mage.exe or its interaction with Visual Studio.

    I am surprised/skeptical that signtool does not support double-signing MSI files.  What error do you get when you try to do it?

    According to my tests, Windows 7 works fine with a SHA-2 certificate, regardless of whether you use a SHA-1 signature or a SHA-2 signature.  If you are signing a driver package with a kernel-mode driver (.sys file), the user just needs to install KB3033929 beforehand.  If not, then I think there are no caveats.  This is all documented in the tables in the "Signature requirements" section of my document.

    Bill, I am sorry that you are still trying to support Windows XP long after Microsoft stopped.  Any Windows XP computer that is connected to the internet in order to access your website is probably vulnerable to all sorts of exploits by now anyway.

    --David Grayson

    Monday, October 26, 2015 8:11 PM
  • If you try to use SignTool v10.0.10240.16384 from the Windows Kits for Win10 to dual sign an MSI file, the first signature works fine but the second signature (after sorting through the available certs) reports:

          SignTool Error: Multiple signature support is not implemented for this filetype.

    This was also confirmed by Microsoft / MSDN tech support. They suggest dual signing setup.exe (which would work) but this doesn't help for Group Policy deployments that require the use of MSI files. On the bright side I think Group Policy is capable of determining the type of client (e.g. Win7, Server 2008, etc.) and could hopefully deploy a different MSI to each client type. I don't know if Group Policy would (or whether the client system would if Group Policy deployed) enforce the SHA1 deprecation policy.

    See for a fairly complete summary of the new enforcement rules, including:

    Effective January 1, 2016, Windows (version 7 and higher) and Windows Server will no longer trust any code that is signed with a SHA-1 code signing certificate and that contains a timestamp value greater than January 1, 2016. This restriction will not apply to the timestamp certificate or the certificate’s signature hash until January 1, 2017, after which time, Windows will treat any SHA-1 timestamp or signature hash as if the code did not have a timestamp signature.

    I'm not 100% sure WHICH versions of Windows will enforce this (Win8 and Win10?) and whether it ONLY applies to files with the Mark Of The Web (downloaded from the web). Also not sure how this applies to kernel mode drivers.

    My summary of this is the following:

    Legacy apps (signed BEFORE 1/1/2016) signed with SHA1 certificate and SHA1 file hash and timestamp

    Accepted until 1/1/2020

     Apps signed AFTER 1/1/2016

    Must be signed with SHA2 CERTIFICATE. Either SHA1 or SHA2 timestamp and file hash are acceptable.

    Seems to apply especially to downloaded files i.e. with the “Mark Of The Web” file attribute

    Apps signed after 1/1/2017

    Must be signed with SHA2 certificate AND SHA2 file hash and timestamp

    Web site SSL certs after 1/1/2017

    MUST be SHA2 even if expiration date is after 1/1/2017

     MSI files cannot be dual-signed, period.

     Not sure about dual-signing app / deployment manifests for Smart Clients. Doesn't look hopeful.

     Drivers and Win 10

    Beginning with the release of Windows 10, all new Windows 10 kernel mode drivers must be submitted to and digitally signed by the Windows Hardware Developer Center Dashboard portal.  This requires the use of an Extended Validation code signing certificate.

    That said, Microsoft Tech Support confirmed that legacy drivers signed BEFORE the release of Win10 WILL be accepted. I tried a driver I built for Win8 and it installed fine.

    The first URL above has a small amount of information about testing deprecation policy enforcement. Better yet, the page contains a link that points to  which tells you how to set the policies for enforcement NOW so you can test your app. I haven't gone that far yet, but I'm very tempted.

    XP is much less my concern than Server 2008 (not R2) which we have to support for a very old app that will never be updated enough to run on Server 2008 R2 (and therefore 64-bit). But for both XP SP3 and Server 2008 when downloading a SHA2-signed (only) CAB file required by a Web site we deploy both clients generate an error "Windows has found a problem with this file" and the download is blocked even if the site is added as a trusted site. Works fine if signed SHA1 then SHA2, but I'm not yet sure that works for all other situations.

    I'm still waiting for a response from Microsoft regarding SmartScreen in Win8.1 and Win10 initially blocking the execution of an EXE downloaded from a web site if the EXE is signed with an SHA2 cert (SHA1 signature, SHA1 then SHA2, SHA2 only, SHA2 then SHA1 - all fail). You get a warning "Windows SmartScreen prevented an unrecognized app from starting" but you also get the option to accept the risk and run it (which permanently unblocks it). I would like to find a way to avoid the harassment. Microsoft has hinted that using an Extended Validation code signing cert (more expensive than the "regular" code signing cert, but also required for Win10 drivers since it uses dual factor authentication via a dongle you must use with the cert) would immediately "establish a reputation" that would pass SmartScreen muster, but I'm waiting for them to confirm this.

    What a hot mess this is.....

    Wednesday, October 28, 2015 2:44 PM
  • Thanks for the great links, Bill.  I have added that first one as a reference in the References section of my document.

    --David Grayson

    Wednesday, October 28, 2015 10:54 PM
  • Hi David

    First, thank you for all your work posting the information to help educate those of us who are coming new to driver signing.

    I have a situation where we would like signed drivers to work on Windows 7 through 10, and the drivers do load kernel modules from SYS files.

    Is my understanding correct that in order for these drivers to work with Windows 10, we need to get an EV certificate and pass through the signing process with Microsoft using the Windows Hardware Developer Center Dashboard Portal?

    Once we have done that, would it be your expectation that these (signed) drivers would also work with Windows 7 through 8.1, given the caveat about SHA-2 and KB3033929 on Windows 7?



    Tuesday, November 3, 2015 9:39 PM
  • Im so confused...

    in my case im just signing .inf files.... do i need to get a new cert, with the EV? 

    i need to get this sorted, i have a godaddy SHA1 code signing cert, and it expires next month, i not sure if i should renew

    i sign .inf files today, and they seem to work fine on my windows 10 (from 8.1) machine




    Saturday, November 7, 2015 12:57 AM
  • Hello, Chris.  Yes, it sounds like you will need to use the Windows portal.  I document this requirement in the "Signature Requirements" section of my document, and I provide a link to the Microsoft announcement about it:

    The portal should sign your driver with the right options to make it work in Windows 7 and above.  I have not actually used it, but it sounds like it has a UI that allows you to select which operating systems you want to support.

    --David Grayson

    Monday, November 9, 2015 10:56 PM
  • Hello, Mitch.  You should sign and test your drivers ASAP.  If you wait until January 2016 to do it, some versions of Windows might reject your driver signatures (see the posts from Bill Cumming).  At some point, you should get a SHA-2 certificate and learn how to use that one though.

    --David Grayson

    Monday, November 9, 2015 11:00 PM
  • SHA-1 phase-out update.

    Hello everyone.  I should admit I don't really know whether it's best to use SHA-1 in a signature these days.  As far as I can tell, you have to use SHA-1 to make your signature be recognized by Windows Vista, and SHA-2 causes a bad bug in versions of Windows Vista that have not received Windows update KB2763674.

    However the article Windows Enforcement of Authenticode Code Signing and Timestamping talks about how Windows 7 and up will stop accepting SHA-1 in various ways.  There will be changes to SHA-1 support in Windows on 2016-01-01, 2017-01-01, and there will be changes at some unspecified later date if SHA-1 preimage attacks become possible.  However, the language in that article is confusing so I am not sure exactly what changes will be made.

    If you care about your software working in the future on modern versions of Windows and you don't care about Windows Vista too much, it might be better to just switch entirely over to SHA-2 right now.  You will need to make sure you are using SHA-2 as the main file digest and also using it for your timestamp.  Windows Vista users without KB2763674 will have a hard time running signed executables from you, and they might see warnings about an untrusted publisher when running your software or installing your drivers, but other than that, things will probably keep working for them.  This strategy puts you ahead of the game; you don't have to re-sign and re-test your software and drivers in the future as Microsoft continues to deprecate SHA-1.

    If you care about fully-supporting Windows Vista, you can probably use a SHA-2 code-signing certificate but make a SHA-1 file digest and use SHA-1 for the timestamp signature.  I think this is what the article recommends.  However, I am not sure how long that will work; it might stop working as early as 2017-01-01.

    Another factor to consider is how often you are making new releases of your software.  If you make a new release of all of your software every few months, it's not a big deal to keep using SHA-1 file hashes for now, and switch to SHA-2 when it becomes necessary.  However, if you maintain a lot of different software packages and each one requires careful testing, it might be better to switch to SHA-2 now and accept the degraded support of Windows Vista so that you don't have to re-sign and re-test all of your software at some point in the future.

    --David Grayson

    Tuesday, November 10, 2015 2:06 AM
  • In reference to the last post by FredTGB, applying the HOTFIX from microsoft (KB2921916) DID solve my issue.  Very happy.  Thank you David and FredTGB.  Just to recap.  I have a signed Installshield project that includes a signed .cat file amoung other executables.  The .cat file is one file needed to install the Windows build-in postscript driver.  This project worked perfectly during a silent install when I signed everything with a SHA1 cert.  However, after moving to a SHA256 cert this year, my silent install now displays the "friendly" windows security dialog prompt with a checkbox to "always trust...".  The installation of the Postscript driver (the signed .cat file) was now a problem with SHA256.  I tried many test scenarios including buying another code signing cert.  Nothing worked until now.  Applying the patch before hand and restarting the system achieves what I need - A truely silent installation of my product.  What's interesting about the HOTFIX is that it describes a slightly different scenario than mine but it still worked.  In my case, during first attempt at installing I get the dialog prompt.  I do NOT check the box about trusting but do click the installl button.  The install finishes correctly.  I then uninstall my product and install again.  During my second attempt I do NOT get the prompt.  Weird.  Thanks all!!


    Tuesday, November 10, 2015 9:39 PM
  • Jim:  Thanks for the clear explanation of your problem and how you fixed it.  I'm sure others will find KB2921916 useful if they are trying to do silent driver installations.  --David

    --David Grayson

    • Edited by DavidGrayson Wednesday, November 11, 2015 12:19 AM
    Wednesday, November 11, 2015 12:18 AM
  • Here's the latest from MS Tech Support regarding SmartScreen blocking the execution of apps downloaded from the web (NOT Smart Clients - that's a separate beast):

    If your app is signed using a Extended Validation Code Signing Certificate it will gain an instant "reputation" with SmartScreen and not be blocked. So they say. Haven't actually tried it.

    I'm still trying to get an answer on the EXACT definition of how the SHA1 deprecation will be enforced. I strongly suspect it involves the HKLM\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 0\CertDllCreateCertificateChainEngine\Config registry key and the CERT_CHAIN_DISABLE_xxxx flag bits to enforce the policy (see But stay tuned.

    Tuesday, December 1, 2015 7:11 PM
  • David

    Now I'm confused, which seems pretty typical! I re-read your article. Does this statement still apply?

    "However, there is a really nice loophole. For backwards compatibility, kernel-mode drivers signed with a valid cross-certificate that pre-dates Windows 10 will continue to pass signing checks in Windows 10. The cross-certificate from Globalsign was issued long before Windows 10 and it expires on <time style="box-sizing:border-box;color:#333333;font-family:'Helvetica Neue', Helvetica, Arial, sans-serif;font-size:14px;line-height:18.1818px;">2021-04-15</time>. Therefore, you should be able to sign kernel-mode drivers for Windows 10 with a regular GlobalSign code-signing certificate until then."

    Does this really mean that I could sign a kernel-mode driver package with a new Globalsign certificate and the existing cross-certificate, and it would work with Windows 10? In which case I would not need to go through the portal signing?


    Tuesday, December 1, 2015 9:26 PM
  • Thanks very much for this splendid document. It's pointed out several things that I wasn't doing right. My situation is simpler than most people on this thread, since I am only signing application EXEs and DLLs, no drivers or kernel modules. I also don't have any need to support Windows Vista. However, I do need my signatures to remain valid for as long as possible. So I'm trying to use SHA-2 for everything.

    The important thing that I learned today is that you need to use Windows Explorer to find out for sure what digests are being used for the file and the timestamp (the /fd and /td options). You also need to use it to examine the certificates in the signing certificate and timestamp certificate chains of trust. When "sign tool verify /v" displays a chain of trust, like this:

    The signature is timestamped: Fri Dec 11 17:51:37 2015
    Timestamp Verified by:
        Issued to: Thawte Timestamping CA
        Issued by: Thawte Timestamping CA
        Expires:   Thu Dec 31 23:59:59 2020
        SHA1 hash: BE36A4562FB2EE05DBB3D32323ADF445084ED656
            Issued to: Symantec Time Stamping Services CA - G2
            Issued by: Thawte Timestamping CA
            Expires:   Wed Dec 30 23:59:59 2020
            SHA1 hash: 6C07453FFDDA08B83707C09B82FB3D15F35336B1
                Issued to: GeoTrust 2048-bit Timestamping Signer 1
                Issued by: Symantec Time Stamping Services CA - G2
                Expires:   Tue Dec 29 23:59:59 2020
                SHA1 hash: D71D4562C633367C34E366CFB76FB97B05AF34B4

    Those "SHA1 hash:" lines are certificate fingerprints, not hashes involved in the signing.

    I have a Verisign SHA-2 code signing certificate, but the root certificate at the top of its chain is an SHA-1 certificate. So I'm not sure if signatures made with my SHA-2 will still be considered valid from January 1st 2017?  

    I've tried several RFC3161 timestamp servers. I get an SHA-2 timestamp digest, and SHA-2 certificates to the top of the timestamp chain from

    "/tr /td sha256"

    I get an SHA-2 timestamp digest, but the root certificate of the timestamp chain is SHA-1 from:

    "/tr /td sha256"

    These ones gives me RFC3161 sha-1 signatures and ignore /td sha256:

    "/td sha256 /tr";
    "/td sha256 /tr";

    Anyone got any others I can try? 


    John Dallman

    Friday, December 11, 2015 6:28 PM
  • Chris (IQTech2),

    Yes, I believe my statement is still true.  Please see the April Fools Day announcement from Microsoft:

    It says:

    "To ensure backwards compatibility, drivers which are properly signed by a valid cross-signing certificate that was issued before the release of Windows 10 will continue to pass signing checks on Windows 10."

    So I think you don't have to use the portal for some time.

    --David Grayson

    Friday, December 11, 2015 8:06 PM
  • John:

    Thank you for your information.  Given your situation, I think you are making the right decision to try to use SHA-2 for everything. 

    I have a small list of timestamp servers in the How To Sign section of my guide; you can try those:

    I think it's probably OK to have some SHA-1 certificates in your chain of trust for now, but I'm not totally sure.  See the "Intermediate Certificates" section in the link above where I explain why I wanted to get a SHA1 certificate from GlobalSign in my chain of trust because it is better supported on older computers that are not connected to the internet.

    --David Grayson

    Friday, December 11, 2015 8:14 PM
  • David:

    I've tried your list of timestamp servers. These ones all ignore the /td parameter and produce an RFC 3161 SHA-1 timestamp, with SHA-1 certificates back to the root of the timestamp chain. 

    "/td sha256 /tr";
    "/tr /td sha256";
    "/td sha256 /tr";
    "/tr /td sha256";

    This one produces an SHA-2 RFC3161 timestamp, but has an SHA-1 certificate at the root of the timestamp chain:

    "/tr /td sha256";

    So the only timestamp that gives me SHA-2 to the root of the timestamp chain remains:

    "/tr /td sha256"

    I have a question in with MS Premier Support about the acceptability of SHA-1 certificates in the chain of trust. It certainly is OK as of now, and seems that it will be during 2016. It's the situation after 01-JAN-2017 that I'm asking them about. If I get a solid answer, I'll try to get permission to share it here.

    John Dallman

    Monday, December 14, 2015 2:49 PM

  • "To ensure backwards compatibility, drivers which are properly signed by a valid cross-signing certificate that was issued before the release of Windows 10 will continue to pass signing checks on Windows 10."

    So I think you don't have to use the portal for some time.

    --David Grayson

    Continuing David's thought, if you are interested in using a SHA-1 certificate, the last day to purchase a new or renewed one is December 31, 2015.  I've written a post here:


    Monday, December 14, 2015 3:44 PM
  • Thank you David Grayson!

    Excellent, Excellent Article.  Thank you for monitoring the subject and contributing so much.

    Thank you David Ching!

    A new story pointing at your blog forced me to look at this issue. 

    I don't have to do anything now, but your articles showed the way.

    Friday, December 18, 2015 2:51 AM
  • Here is the latest clarification from Microsoft Tech Support on the deprecation of SHA-1 code signatures:



    SHA-1 Deprecation Summary

    1/1/2016 (THIS FRIDAY!!)




    Apps with Mark Of The Web (downloaded from the Web)

    SHA-2 Code Cert required (Win7 and above) but beware Windows SmartScreen (see below)


    SHA-2 Code Cert and SHA-2 timestamp now required (Win7 and above) but beware Windows SmartScreen (see below)

    Signatures before 1/1/2016 no longer accepted

    Apps installed locally or referenced over the network

    Not sure. First they said Win7 and above will display warning if SHA-1 code cert but will not block the file. Then then said it won’t be enforced.


    Not sure. First they said Win7 and above will display warning if SHA-1 code cert or timestamp but will not block the file. Then then said it won’t be enforced.

    Signatures before 1/1/2016 no longer accepted

    Kernel Drivers

    SHA-1 not enforced in Win7/Win8 (but signing still required). Win10 requires new driver submission through HWDC Portal


    No change

    No change

    Smart Client manifests

    SHA-1 not enforced (but signing still required). Cannot be dual-signed.


    No change

    No change

    MSI files

    Same rules as EXE files above. Cannot be dual-signed.


    Same rules as EXE files above. Cannot be dual-signed.

    Same rules as EXE files above. Cannot be dual-signed.

    Web SSL certs


    SHA-2 SSL Web Certs likely to be required by most browsers (Chrome, Firefox, IE)



    Internal Certificate Authority client certs

    Not affected


    Not affected

    Not affected



    Note there is still a documented problem with the OS blocking the download of SHA-2 signed CAB files from Web sites when the client is running Server 2008.


    Win7 and above includes Server 2008 R2 and above.


    Downloaded files correctly signed with SHA-2 will still be harassed in Win8 and Win10 with "Windows SmartScreen prevented an unrecognized app from starting" but you will have the option to accept the risk and run it (which permanently unblocks it). MS Tech Support claims this can be solved by signing with an Extended Validation Code Signing cert (which costs twice as much) to gain an “instant reputation”.


    From what I can tell the file hash (signature hash) doesn’t matter for Win7 and above. But for older OS’s (Server 2008) the file hash matters a LOT since they do not “see” the signatures that use SHA-2 file hashes. Dual-signing with SHA-1 followed by SHA-2 file hash signatures can solve that for most files, but you can’t dual sign MSI files or Smart Client manifests.

    Hope that helps!


    Monday, December 28, 2015 10:08 PM
  • Another tidbit: if you want to test the SHA-1 deprecation policy, you can use the Batch file below which is intended to mimic the policy to be enforced on 1/1/2017, I think. To mimic the policy for 1/1/2016 change the hex value to 0x80800000. To mimic the policy of 1/1/2020 I'm guessing you need to set the "@1/1/2016" to "@1/1/1970" so that no old signatures are accepted.

    @echo off
    REM This must be run elevated
    REM See
    REM and
    REM Combine CERT_CHAIN_ENABLE_WEAK_SETTINGS_FLAG (0x8000000 - required to enable it all)
    REM with CERT_CHAIN_DISABLE_MOTW_TIMESTAMP_WEAK_FLAG (0x08000000 - require SHA2 timestamps),
    REM and CERT_CHAIN_DISABLE_MOTW_CODE_SIGNING_WEAK_FLAG (0x00800000 - require SHA2 code signing certs)
    REM and CERT_CHAIN_DISABLE_SERVER_AUTH_WEAK_FLAG (0x00100000 - require SHA2 SSL web certs).
    REM This is the same enforcement as is currently used against MD5 signatures.
    REM This sets WeakSha1ThirdPartyFlags REG_DWORD in HKLM\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 0\CertDllCreateCertificateChainEngine\Config
    certutil -setreg chain\Default\WeakSha1ThirdPartyFlags 0x88900000
    if %ERRORLEVEL% NEQ 0 goto BitchAtThem
    REM Enforce on any app signed after this date. Apps signed BEFORE this date are grandmothered and allowed.
    REM This sets WeakSha1ThirdPartyAfterTime REG_BINARY in HKLM\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 0\CertDllCreateCertificateChainEngine\Config
    certutil -setreg chain\Default\WeakSha1ThirdPartyAfterTime @1/1/2016
    if %ERRORLEVEL% NEQ 0 goto BitchAtThem
    REM You have to restart the service for this to take effect.
    REM Note this will fail if you are not running on a Certificate Authority domain controller.
    echo Registry keys set successfully.
    Choice /C YN /M "Restart CertSvc (only needed if on Certificate Authority server)? "
    if %ERRORLEVEL% EQU 2 goto Done
    net stop CertSvc
    net start CertSvc
    goto Done
    goto Done



    Monday, December 28, 2015 10:45 PM
  • Bill, do you have a link to your table above?  Is that based on a MS article?  

    I disagree with the Kernel Drivers advice.  SHA-1 is accepted on Windows 10, use of the portal is recommended but not required.  I have documented this on my blog.


    Tuesday, December 29, 2015 10:47 PM
  • Finally got around to testing the SHA-1 deprecation that will be enforced by the WeakSha1ThirdPartyFlags and related values in the  HKLM\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 0\CertDllCreateCertificateChainEngine\Config registry key. (See my posts above for more details and a script to test this)

    1.    SHA1 deprecation enforcement only applies to use of Code Signing Certs for the 1/1/2016 deadline and additionally to timestamp hashes for the 1/1/2017 deadline.

    2.    The File Hash method did not matter.

    3.    Win8 / Win10 make the enforcement even more obnoxious with the use of SmartScreen. In some cases (downloading CAB files required by a web page) I have not yet found a way to bypass it. MS Tech Support has said that using Extended Validation code signing certs is the only way to "establish a reputation" so that SmartScreen will let them through, but I haven't tried that yet (those certs are twice as expensive as the normal ones and require a dongle to do the signing).

    4.    Enforcement only applies to files downloaded from the web. This is confirmed by my tests where files were unblocked (which removes the Download From The Web attribute) and thereafter ran without warnings.

    You can see my ridiculous spreadsheet that shows all the different tests on all the different OS's using almost all possible combos of File Hash, code signing cert and Timestamp Hash at Spreadsheet of SHA-1 deprecation tests and SHA-2 code signing

    If anyone has updates to this information please let me know!! This is an iceberg about to hit for some of us.....

    Bill Cumming

    Thursday, January 7, 2016 7:53 PM
  • I should clarify a slight detail: I did all my testing with files signed in 2015 using my (now expired) SHA1 code signing cert, so I set the WeakSha1ThirdPartyAfterTime to @1/1/2015 to make the enforcement kick in (any downloaded file signed / timestamped after that date is supposed to be checked).

    I just ran a sanity check and set WeakSha1ThirdPartyAfterTime to @1/1/2016, and the files signed with SHA1 in 2015 are NOT flagged or harassed, as expected.

    MS Tech Support (and the web pages I cited above) have consistently said that files signed / timestamped BEFORE the 1/1/2016 deadline will NOT have the SHA1 deprecation enforced - they will be grandmothered in (i.e. tolerated) as legacy files. This suggests that Microsoft will soon (this coming Patch Tuesday 1/12/16?) set WeakSha1ThirdPartyAfterTime to @1/1/2016.

    In the vein of "Trust But Verify" you each may want to periodically run the following batch file:

    @echo off
    erase ExportedSHA1DeprecationRegistryKey.reg
    reg export "HKLM\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 0\CertDllCreateCertificateChainEngine\Config\Default" ExportedSHA1DeprecationRegistryKey.reg
    set SearchText="WeakSha1"
    find /I %SearchText% ExportedSHA1DeprecationRegistryKey.reg
    if %ERRORLEVEL% EQU 0 goto FoundIt
    echo SHA-1 Enforcement does NOT seem to be enabled YET
    echo (%SearchText% registry values not found)
    goto Done
    echo ***************************************************
    echo SHA-1 Enforcement appears to be ENABLED NOW!
    echo (%SearchText% registry values found!)
    echo ***************************************************
    goto Done

    Bill Cumming

    Friday, January 8, 2016 6:26 PM
  • As of Patch Tuesday (1/12/2016) Microsoft has now turned on SHA-1 deprecation.

    See and

    Apparently the Windows Update (first link above) is different for 32-bit vs 64bit and for each version of Windows, so there must also be some tweaks in the kernel to tolerate / implement the enforcement. As promised, this affects Win7 (Server 2008 R2) and later.

    If you run the Windows batch file I list above it will now indicate that SHA-1 enforcement is turned on.

    Note that (one of the better MS documents) has been updated early this morning, and includes the following rather important tidbits (underlining from me):

    Effective January 1, 2016, Windows (version 7 and higher) and Windows Server will no longer trust new code that is signed with a SHA-1 code signing certificate for Mark-of-the-Web  related scenarios (e.g. files containing a digital signature) and that has been time-stamped with a value greater than January 1, 2016. This cut-off date applies to the code-signing certificate itself.

    This restriction will not apply to the time-stamp certificate used to time-stamp the code-signing certificate or the certificate’s signature hash (thumbprint) until January 1, 2017. After this time, Windows will treat any code with a SHA-1 time-stamp or SHA-1 signature hash (thumbprint) as if the code did not have a time-stamp signature.

    Note when I did testing on this with my "best guess" of the registry values used to enforce this it seemed like the signature hash (file hash) didn't matter. So stay tuned.

    And BTW, MS is now changing all references from "SSL" to "TLS". Bah.

    We all knew it was coming, so hang onto your seats girls and boys!

    Bill Cumming

    Wednesday, January 13, 2016 10:23 PM
  • (I think this is the best thread to ask in)

    I am trying to make Windows 8.1 (with the SA3123479 policy update) actually reject a new SHA-1 signed file, just to demonstrate the need to switch to dual signing.  However Windows just keeps accepting it.  I have tried putting it on a web server and downloading it with IE.  No warning.  Checked the downloaded file: Yes, it does have mark of the web.  Tried running it.  No warning.  Tried running it straight from IE.  No Warning.  Right clicked to check signature via properties.  No Warning, sha-1 signature valid.  Tried turning on SmartScreen before these tests.  No warning.  Checked that the policy bits are indeed set (certutil -getreg chain\...) . Examined the certificate chains all the way to the issuer public root: SHA-1 all the way.

    So how is one supposed to actually get the warning?

    And how is one supposed to test that an SHA-2 signed file was signed correctly when so many checking methods will not reject an incorrect (under the new policy) signature?

    Would have been so much easier if they didn't try to include "Mark-of-the-web" and other such things into the mix and had just said "if signature is SHA-1 and timestamp absent or after 2016-01-01T00:00:00 and OS doing the checking would actually accept SHA-256".

    Thursday, January 14, 2016 6:27 PM
  • There are some signs emerging this week (starting on 2016-01-12) that Internet Explorer's security scan started rejecting executable downloads signed with SHA-1 certificates even though they were signed and timestamped before 2016.  This rejection makes it hard (but not impossible) for the user to run the executable they just downloaded.  See this post in another thread.  Skype actually updated their installer just yesterday to have dual signing with a SHA-1 certificate and SHA-2 certificate.  However, like 74JBlw, I have not been able to reproduce any problems with SHA-1 signatures myself (though I haven't tried too hard, and I only tried on Windows 8.1).

    I too wish that Microsoft would provide clear documentation about how their operating systems behave with regards to signature verification, and I wish that documentation would focus on the actual developers who have to make signatures and deal with the consequences, rather than focusing on the certificate authorities.

    --David Grayson

    Tuesday, January 19, 2016 10:05 PM
  • I've just tested 12 files generated with different options (I've created a script to test different parameters to signtool)

    1) Digital Certificate issued with SHA1 algorithm

    2) Digital Certificate issued with SHA256 algorithm

    3) Timestamp using /t 

    4) Timestamp using /tr and SHA256

    5) Timestamp using /tr and SHA1

    None of them works. At this time I need to contact Verisign and Go Dady Technical Support and see if they know what's going on

    Wednesday, January 20, 2016 8:56 PM
  • David,

    Thanks for all your hard work on this, it has been tremendously useful.    While I understand the need for signing a new USB driver, it drives me nuts that everyone must go through this process only to have a "glorified" usb-serial bridge with a company name on it.   I really think Microsoft could address this specific case with VCP better, especially if known drivers are not actually changed which in most cases they are not.  Makes a lot of folks jump to FTDI and Prolific to bypass this issue all together.

    Friday, January 22, 2016 4:40 PM
  • Dan_27: Thank you!  You might be happy to know that if your device conforms to the USB CDC ACM specification, it will work in Windows 10 without any drivers supplied by you, due to the new usbser.inf that they added in Windows 10.

    --David Grayson

    Saturday, January 23, 2016 1:51 AM
  • Just another note: I have successfully dual-signed MSI files by using our in-house signing automation tool (which I cannot release).  Fundamentally, our code does *exactly* the same it does for EXE files etc., with only the specific differences that also apply to single signing MSI files rather than EXE files.

    As previously stated I have been unable to check how the "weak signature policy" code responds to a dual signed MSI file (because it doesn't object to anything on the test machine), however the File Properties dialog (in file Explorer) correctly reports the file as dual signed and confirms the validity of both the SHA-1 and SHA-256 signature (and their timestamps).

    So I am unsure why signtool (or its underlying undocumented API) refuses to do this, maybe there is some corner case that doesn't accept such signatures and Microsoft has just omitted a needed feature without documenting the reason.

    Friday, January 29, 2016 6:40 AM
  • I'm having compatibility issues with Vista after changing the digital signature from SHA-1 to SHA-2. You mention that KB2763674 is a possible solution to this problem. I have that particular update installed and the installation is still invalidated. Do you have any compatibility suggestions you could provide if I need to have SHA-2 and also support Vista?
    Tuesday, February 2, 2016 12:23 AM
  • First, I really appreciate the information you've provided, David. You've been an incredible help.

    I'll concur with the advice to avoid the GoDaddy certificate. I've been using a code signing certificate for many years to sign .exes. I purchased an SHA-2 certificate in June of 2014, it's still valid. I used it as an SHA-1 to protect our Vista users but recently had to create a new .exe and discovered the Windows10 issue.

    I've followed all the instructions to create an SHA-2 exe, but no matter what I do, when I look at the digital signature details on the finished .exe, the digital algorithm is still SHA-1. I've even downloaded  the certificate again and started over.

    Going to the certmgr.msc, when I look at the certification path for my certificate, the highest level certificate is SHA-1. Everything downstream is SHA256. Is it possible to sign SHA256 when the starting authority is SHA-1?

    I tried GoDaddy SSL support, but they acknowledged that they don't know a lot about the code signing certificates. There are only 5 months left on my certificate, I'll cut my losses and started with GlobalSign.

    Thank you again, David. 

    Wednesday, February 3, 2016 1:25 AM
  • Kudos on figuring out how to dual-sign MSI files - MS Tech Support said it wasn't possible!!

    Are you able to post either explicit source code or at least an outline of how you dual-signed the MSI? It would be a great help to the community.

    Wednesday, February 3, 2016 3:32 PM
  • I don't mean to complicate things, but I do want to clarify terminology here. There are a BUNCH of places in the digital signing process / result where you can have SHA1 versus SHA256 (or both).

    1. There is the code signing certificate itself, all of which should now have a "signature hash algorithm" of SHA256.

    2. There are all the certificates in the certification path for that code signing cert, each of which has its own signature hash algorithm. Ideally they should all be SHA256 all the way back to the root cert, but you should check!

    3. There is the signing method used by signtool.exe et al. (the "file hash") to sign the file, which can be SHA1, SHA256, and others. You can have more than one signature (see all the comments above about dual-signing).

    4. For each signature / file hash, there is a timestamp signature from a timestamp authority.

        a. That signature has a Digest Algorithm, which can be SHA1, SHA256, ....

        b. That signature is associated with a certificate, which has a signature hash algorithm and a certification path (see items 1 and 2 above). But BEWARE: see the many comments above that point out that only a very few of the timestamp authorities that provide SHA256 SIGNATURES (like only 1 or 2) have a certification path that is fully SHA256 all the way back to the root cert.

    So when anyone says they "signed a file as SHAxxxx" you need to ask:

    1. Using what code signing cert (is it SHA1 or SHA256)?

    2. Using what file hash method (SHA1 or SHA256)?

    3. Using what timestamp signature method (SHA1 or SHA256)?

    For now (2016) the enforcement only focuses on the code signing cert being SHA256, and mostly on files downloaded from the web (almost entirely enforced by IE - not sure what Firefox et al. do).

    Starting in 2017 the timestamp signature becomes part of the picture. Not sure about the file hash.


    Bill Cumming

    Wednesday, February 3, 2016 3:46 PM
  • Sorry, but I can't post the source code.

    Here is the outline:

    1. Extract the "signable stream form" of the MSI file, in Microsoft's tool this is done by the special SIP handler for MSI files.  This is the same as when doing a single signature.  This step is specific to the MSI file format, but may be shared with other file formats based on OLE Structured Storage.

    2. Hash this stream with the desired hash(es). This is the same as when doing a single signature, except doing it more than once.

    3. Format each hash into the SpcIndirectDataContext blob used in authenticode signatures.  This is the same as when doing a single signature, except doing it more than once.  Some details of this step are specific to the MSI file format, but may be shared with other file formats based on OLE Structured Storage.

    4. Set up the Authenticated attributes for the first/outer (SHA-1) signature as usual.  This is the same as when doing a single signature.

    5. Set up the Authenticated attributes for the additional/inner (SHA-256 etc.) signatures as usual, but also add a unique authenticated attribute of type sequencenumber (see RFC2985 section 5.3.5) ranging from 1 to the number of such additional signatures.

    6. Generate (and timestamp) the additional/inner (SHA-256 etc.) signatures as usual one by one.  This is the same as when doing a single signature, except possibly doing it more than once.

    7. Collect the DER encoded additional signatures into a DER encoded (and thus sorted) ASN.1 SET.

    8. Add this SET as an additional Unauthenticated attributes of type in the first/outer signature.

    9. Generate (and timestamp) the first/outer (SHA-1) signature as usual.  This is the same as when doing a single signature.

    10. Put the first/outer signature (with the additional/inner signatures in its Unauthenticated attributes) in the "\005DigitalSignature" stream in the MSI file.  This is the same as when doing a single signature.  This step is specific to the MSI file format, but may be shared with other file formats based on OLE Structured Storage.

    Friday, February 5, 2016 2:25 AM
  • pjfune: I am sorry you are having trouble with SHA-2 on Windows Vista.  What kind of file are you signing?  How are you testing it?  What error message are you getting?  Do you see any errors when you right-click on the file, go to Properties, and inspect its signature?  In case it matters, do you have a SHA-2 certificate, a SHA-2 file digest, or both?  (You can choose SHA-1 or SHA-2 independently for the certificate you purchase and the signature you generate.)

    --David Grayson

    • Edited by DavidGrayson Wednesday, February 10, 2016 10:11 PM
    Wednesday, February 10, 2016 10:09 PM
  • DStone2016: You should be able to make a SHA-1 signature using a SHA-2 certificate.  If you could give the details about how you are signing the file and perhaps show a screenshot of the problem then maybe I would have some idea of how to fix it.  By the way, the certification path you see in the properties is a function not only of what certificates are in the executable, but also a function of what intermediate and root certificates are installed on your computer.

    --David Grayson

    Wednesday, February 10, 2016 10:14 PM
  • I have a driver package that I've successfully signed and deployed on Win7, Win8 and Win10. But there are a few machines that are getting Code 52 errors. In fact, if you search you'll see people occasionally getting Code 52 errors with iphone and other mass market products, and these seem to be related to an SP1 issue where the Code 52 started showing up after the SPI1. 

    My question is this: Have you seen a yellow asterisk/Code 52 getting reported in Device Manager on a small subset of machines? And if so, any idea the cause and how to fix? Thanks!

    Edit 15-Feb-2016: On one of the Win7x64 machines that is giving a Code 52 error, I can take the same install package and delete the CAT file. And then update the driver and point to the new install package and the machine will give the red dlg warning, but then accept the unsigned when told to do so. Next, I can boot the machine in F8 mode (disable signing enforcement), and the signed version that previously gave a Code 52 works fine. That is expected, but I don't understand why a x64 machine would give a red dlg warning on an unsigned driver and not just reject it altogether. Any ideas?

    Thursday, February 11, 2016 7:56 PM
  • David: My note wasn't clear. I was making SHA-1 code signings with a SHA-2 certificate. The problem was making a SHA-2 signature with that same GoDaddy SHA-2 certificate. I couldn't, and GoDaddy couldn't help me. I've been successful since then using the GlobalSign certificate.  Thank you!
    Tuesday, February 16, 2016 12:26 AM
  • DucksUnlimited: I assume you are signing a kernel driver. I'm afraid I don't know why you would see Code 52 on a small subset of your machines, while it works on other machines with the same operating system.  I haven't seen anything like that.

    Keep in mind that the signature checks done at the time when your INF file (driver package) is installed are very different from the checks that are done when Windows decides whether to actually load your kernel-mode driver (SYS file) into the kernel.  That's why I covered those two cases separately in my article.  By default Windows 7 lets you install unsigned driver packages (with a red warning dialog).  But it requires kernel modules to be signed before they get loaded into the kernel.  If the signing of the kernel module is bad, you get a Code 52.

    --David Grayson

    Monday, February 22, 2016 11:08 PM
  • DStone2016: Well, I'm glad you were able to find a solution.

    --David Grayson

    Monday, February 22, 2016 11:10 PM
  • Thank you Mr. Grayson for all your work to keep this up to date.  

    The link to for the Win10 SDK/WDK may have changed, I don't think the steps 1-4 are there anymore.  Your individual links to the kits work well so there is no immediate issue.

    Regards, Mike

    WHS OEM, Celeron2.0, 1GB, 7 JBOD (3.0TB), Vista/XP mix clients + xbox360

    Saturday, February 27, 2016 11:11 AM
  • DucksUnlimited: We just started dual-signing, and have seen the Code52 warnings on a subset of machines also (Win10 and Win7).  But it is even down to a particular set of sys files.  Some will load and some won't on the same machine with the same dual SHA1/SHA256 signature.  A file that fails can be repaired by re-signing with just a SHA1 certificate.  So I guess you are not the only one, but I don't have an answer!


    • Edited by kpatm Wednesday, March 2, 2016 5:37 PM
    Wednesday, March 2, 2016 5:37 PM
  • Does this really mean that I could sign a kernel-mode driver package with a new Globalsign certificate and the existing cross-certificate, and it would work with Windows 10? In which case I would not need to go through the portal signing?

    Have you tested this with the latest Windows 10 builds?  The code integrity enforcement has been enabled on (1) new installs of the latest Windows 10 previews on (2) systems with Secure Boot enabled.  I tried to install a driver that I signed in the traditional manner with our EV cert that was issued after Win10 RTM, using a Verisign cross-cert that was issued a long time ago and that expires on 23-May-2016.  This driver failed to load with a Code 52.  The same driver signed with our old SHA-1 certificate (issued well prior to Win10 RTM) or signed via the Microsoft Hardware Dev Portal loaded without problem.

    I may have tripped up in the process and done something slightly wrong (I'll attempt to duplicate these results again tomorrow), but it looks to me like the issue date of the cross-cert has no impact.



    Tuesday, March 8, 2016 10:07 PM
  • David,

    Thanks for your quite useful research!  I refer to it often as we navigate these murky driver signing waters.

    I do have a couple of corrections I want to offer.

    My understanding is that you have to pay a lot of money to Microsoft or some third party and in exchange they will test your driver.

    No longer!

    WHQL is never actually required for your software or drivers to work
    This appears to be changing with Windows Server 2016.  It looks like Server 2016 will default to allowing only HLK signed drivers.  (See the table at the bottom of this page.)  Perhaps administrators will be able to allow attested signed drivers in certain configurations?  It's not clear.

    Tuesday, March 8, 2016 10:26 PM
  • You all seem to be saying that we sign our drivers with sha256 and move on because it is all compatible with older OS's as long as they are up to date on their service packs.  We are seeing code 52 errors on random machines or failing to read the signature at all.  We have 1000's of systems to support and if we cannot get a half dozen of our own developer systems to work in a consistent manner then we are out of luck attempting that.  The only way I can see it working for us is to make two driver installs, one signed sha256 for Windows 10, and one signed sha1 for pre Windows 10 systems.  I would sure be happy to hear how anyone else is making their driver installs.


    Thursday, March 10, 2016 4:05 PM
  • I think I have solved the Code 52 issue, at least on a single machine that was giving us problems. To re-cap, it worked fine on a brand new Win10 machine out of the box and countless Win7/8/10 machines in the field and of various lineage. There was a Win8 machine that didn't work that had been upgraded to Win10 and it still didn't work. And there were a few machines in the field that didn't work either. All gave Code 52.

    This is for a Cypress FX2 USB CyUSB.SYS, among other things. It was the CyUSB.SYS that was giving problems looking in the INF log. 

    I contacted Verisign and got a free SHA256 to go with our SHA1 cert. Took about 15 mins. Dual signed everything. Still no go. Looked more into a signtool verifier that had been failing, and eventually traced that back to an out of date cross signing cert. Replaced that with the latest from Verisign's site and signtool was happy again. Previously I'd dismissed this because 1) it was working on 99% of machines, and 2) the cross signing cert indicated it was good until 2036 or something crazy like that. 

    Finally, I had been using a Win7 signtool. I moved to a Win8.1 SDK sign tool. That was required to dual sign. But I am now signing everything on a Win7 machine using 8.1 Signtool and in spite of some warnings that can't be done, it's working. I think those earlier warnings applied to a time before MSFT hadn't finished SHA256 support for Win7. But don't now for sure. 

    Summary for me: 1) Dual signing was quick and easy, you have to do it sooner or later anyway. 2) Get the latest signing tools. Newer tools should flag more errors 3) Run verify at every step. Lots of things seem to fail silently, and if you aren't explicitly checking along the way, these failures will eventually surface without any indication why. 

    Thanks to Mr. Grayson for hosting this message board, and his page on signing. It's a real asset. It's worth a thousand pages of Microsoft's usual shovelware on the topic. 

    Wednesday, March 16, 2016 4:37 PM
  • Hi David,

    Firstly, thank you for the work you've put into this subject, it's been really useful.

    Just wanted to ask about this paragraph:

    "You should decide which algorithm to use for the timestamp: SHA-1 or SHA-2. I recommend using SHA-2 because this article from Microsoft makes it sound like Windows 10 and up will start ignoring timestamps that use SHA-1 on 2017-01-01. However, SHA-2 timestamps do not work in Windows Vista, so if you want to keep supporting Windows Vista as much as possible, you should probably use SHA-1."

    Can I just clarify if you are talking about sha2 certificate chains or sha2 digests?  It seems that sha2 cert chains are recognised on both Vista and Windows XP (or at least XP patched up to the last patch level released by MS), but XP in particular has problems with digests for the authenticode part, so I would assume (but haven't tested) that it would also have issues with the sha2 digest in the TS.  Yes, some of us poor people have to still support XP, even if Microsoft don't, there really are a staggering number of people still running it :-(.

    From the various Microsoft communications I've read about 2017-01-01 it seemed to me they were talking about the cert chains, not the digests, meaning that for files which are not dual-signed (e.g. MSIs), the best bet is sha1 digest and sha2 certs for maximum compatibility across the board.

    Unfortunately it's something of a challenge to find a TS server that both obeys the /td option properly, returns the correct digest, doesn't crash signtool.exe and is in the list of trusted root certs for my minimum target platform out of the box.  (Am I right in thinking that updates don't ever update the list of trusted roots?)

    Anyhow, I'm still looking for such a timestamp server, even though it was fairly straightforward to create my own by creating a webserver and getting it to spawn an instance of openssl with the 'ts' option.

    If anyone can help, please shout.  Thanks!

    Tuesday, March 22, 2016 10:42 AM
  • The person(s) at Microsoft who wrote the document about the SHA-1 deprecation schedule for Authenticode has a writing handicap that causes him to write certificate whenever he means signature, making the document very difficult to parse and leads to frequent misunderstandings.

    In order to get both SHA-1 and SHA-256 timestamps (with appropriate certificate chains), most of the global CAs now provide two different URLs for the two possibilities.  This is certainly true for both Symantec and GlobalSign.

    The SHA-1 timestamp should be generated in the historic RFC2985 format that was used by Authenticode in the past (the URLs often end in "timstamp.dll") in order to be recognized by the systems that require SHA-1 signatures, while the SHA-256 (or later) timestamps should be generated in the less efficient format derived from RFC3161 but deviating slightly.

    Note that neither the historic Authenticode signing protocol (that results in standard RFC2985 countersignatures) nor the standard RFC3161 protocol (that results in the new Authenticode specific timestamp attributes) have completely standardized ways for the client to tell the server which signature and signature hash algorithm is desired, hence the use of different URLs by the CAs.

    Tuesday, March 29, 2016 5:54 PM
  • I have a question in with MS Premier Support about the acceptability of SHA-1 certificates in the chain of trust. It certainly is OK as of now, and seems that it will be during 2016. It's the situation after 01-JAN-2017 that I'm asking them about. If I get a solid answer, I'll try to get permission to share it here.

    OK, Microsoft pointed me to a script that checks signatures on executables and DLL, which you can get from here: It needs PowerShell. 

    It seems that the 2017 changes will be for timestamps on Mark of the Web files, TLS certificates, and the OCSP protocol. Since I don't do any of those things, I'm happy. The script reckons that my SHA-1 signed, SHA-1 timestamped DLLs built as far back as 2009 will be OK until 2020. That's Microsoft's current notional date for stopping supporting any use of SHA-1 in signing, but it's definitely subject to change if SHA-1 gets cracked.

    They also said that SHA-1 root certificates are recognized by Windows having copies of them, rather than by signature, so they won't need to be blocked. Their checking script seems to agree with that: on a signature with SHA-256 everywhere except at the root certificate of the signing certificate, it said there was nothing SHA-1 involved. I'm still going for SHA-256 everywhere. 

    John Dallman

    Thursday, April 7, 2016 4:32 PM
  • In order to get both SHA-1 and SHA-256 timestamps (with appropriate certificate chains), most of the global CAs now provide two different URLs for the two possibilities.  This is certainly true for both Symantec and GlobalSign.

    Ah, that would be "/tr" for Symantec? That didn't exist when I was looking late last year, and I switched to GlobalSign. I'm going to buy my next batch of certificates from them too, simply because they were earlier with SHA-256. 

    John Dallman

    Thursday, April 7, 2016 5:32 PM
  • Gabe Jones,

    I am looking at that the table at the bottom of that page, and I don't fully understand it but it doesn't indicate that anything special changed in Windows Server 2016.  Windows Server 2016 has the same values in that table as Windows Vista, 7, 8, and 8.1.

    --David Grayson

    Thursday, April 14, 2016 11:44 PM
  • keeely

    You asked "Can I just clarify if you are talking about sha2 certificate chains or sha2 digests?"  I don't think I did enough experiments to get such a fine-grained result.  My paragraph only applied to timestamps, and I when I was testing different types of timestamps I think I tried to limit myself to ones that were done purely with SHA-1 (for both the digest and the certs) and ones that were done purely with SHA-2.

    If you are still looking for a timestamp server, I have updated my article with a short list of timestamp servers.  You can see it here:

    --David Grayson

    Thursday, April 14, 2016 11:54 PM
  • I really appreciate everyone who has been contributing to this thread and sharing the information they have learned about code signing.  Keep up the good work, everyone!

    John Dallman: I added your Symantec timeserver and the SHA1 signature checker powershell script to my article.

    Gabe Jones: I am no longer claiming in my article that WHQL requires money.  Thanks!

    --David Grayson

    Friday, April 15, 2016 12:08 AM
  • Thank you for pointing to the GlobalSign ressource ( that recommends installing the R1-R3 cross-certificate when using the new SHA-256 certificates from GlobalSign.

    I've found an alternative solution to avoid actually installing this additional cross-certificate. When signing with signtool.exe I pass the /ac switch to specify the cross-certificate file. This file contains two cross-certificates at one time! First the R1-R3 cross-cert and then the MS cross-cert.

    By doing this I could avoid manually installing this certificate in our build environment.

    Wednesday, June 29, 2016 2:01 PM
  • sad, but you will have to update:

    Myth: Kernel-mode drivers require WHQL testing

    With the last windows 10 update, finnaly they do!! with the exceptions you surely know:

    - previous windows 10 install

    - secureboot disabled

    - driver signed before july 29th 


    Friday, August 5, 2016 7:39 PM
  • To be more precise one of the exceptions is:

    "Drivers signed with cross-signing certificate issued prior to July 29th 2015, when the initial policy went into place, will continue to be allowed"

    And also from the original post:

    "To summarize, on non-upgraded fresh installations of Windows 10, version 1607 with Secure Boot ON, drivers must be signed by Microsoft or with cross-signed certificates issued prior to July 29th, 2015."

    I've checked all cross-signed certificates from:


    They are all issued before July 29th, 2015, and valid at least until 2021.

    So, does that means nobody is concerned with the new policy until 2021 ?



    Thursday, August 11, 2016 8:12 AM
  • I saw no direct mention of "WHQL" in the announcement though...

    Are you sure we are all talking about the same thing? Or perhaps did they change whql "callsign"?

    Tuesday, August 16, 2016 6:44 PM
  • I saw no direct mention of "WHQL" in the annoucement though...

    Are you sure we are all talking about the same thing? Or perhaps did they change whql "callsign"?

    WHQL is replaced by HLK/Dev Portal. So, I agree with FidelD65: it's no longer a myth that kernel drivers require signing from Microsoft (but some conditions apply).


    Wednesday, August 17, 2016 7:22 AM
  • To be more precise one of the exceptions is:

    "Drivers signed with cross-signing certificate issued prior to July 29th 2015, when the initial policy went into place, will continue to be allowed"

    And also from the original post:

    "To summarize, on non-upgraded fresh installations of Windows 10, version 1607 with Secure Boot ON, drivers must be signed by Microsoft or with cross-signed certificates issued prior to July 29th, 2015."

    I've checked all cross-signed certificates from:


    They are all issued before July 29th, 2015, and valid at least until 2021.

    So, does that means nobody is concerned with the new policy until 2021 ?



    I think the way the article is currently written is slightly misleading. Once you've confirmed that your organization's SHA-1 code signing cert was issued prior to 7/29/2015, the next date to be concerned with is when does your organization's code signing cert expire. In my case, the fact that the expiration date on the Thawte's Code Signing CA cert is 2/7/2020 is of little consolation to me considering my Thawte code signing cert expires November 2016. The signatures must also  include the timestamp and the signtool is not going to work if your cert is expired. Therefore, given that most code signing certs are issued with a 1-3 year life span, the 2021 date is effectively irrelevant for almost everyone.   
    Tuesday, August 23, 2016 3:06 PM
  • To be more precise one of the exceptions is:

    "Drivers signed with cross-signing certificate issued prior to July 29th 2015, when the initial policy went into place, will continue to be allowed"

    And also from the original post:

    "To summarize, on non-upgraded fresh installations of Windows 10, version 1607 with Secure Boot ON, drivers must be signed by Microsoft or with cross-signed certificates issued prior to July 29th, 2015."

    I've checked all cross-signed certificates from:


    They are all issued before July 29th, 2015, and valid at least until 2021.

    So, does that means nobody is concerned with the new policy until 2021 ?



    I think the way the article is currently written is slightly misleading. Once you've confirmed that your organization's SHA-1 code signing cert was issued prior to 7/29/2015, the next date to be concerned with is when does your organization's code signing cert expire. In my case, the fact that the expiration date on the Thawte's Code Signing CA cert is 2/7/2020 is of little consolation to me considering my Thawte code signing cert expires November 2016. The signatures must also  include the timestamp and the signtool is not going to work if your cert is expired. Therefore, given that most code signing certs are issued with a 1-3 year life span, the 2021 date is effectively irrelevant for almost everyone.   

    My understanding is: when you will renew your certificate in November 2016, and if the cross-certificate (not the CA one, I think it's different) doesn't change (the current Thawte's one is 2021 from the page I've mentioned above) then you still not require to submit your signed drivers to the HLK dashboard.

    Another comment: I'm not sure we are talking about SHA-1 code signing here. For Windows 10, my understanding is that SHA2 EV certificates are required.


    Wednesday, August 24, 2016 6:13 AM
  • Hello, FidelD75, FredTGB, Mark Drissel, mirh-.

    Yes, I saw the Microsoft announcement too, and I added links to it in my article.  Thanks for telling me about it.

    I have updated the myths section of my article today.  Does it sound good now?

    FredTGB: I think you only need EV if you are going to use the portal.  A regular SHA2 certificate with an appropriately old cross-certificate will probably work just fine for all driver signing needs on Windows 10.  But otherwise, yes, I agree with your understanding.

    --David Grayson

    Tuesday, September 6, 2016 5:21 PM
  • Thanks very much for this splendid document. It's pointed out several things that I wasn't doing right. My situation is simpler than most people on this thread, since I am only signing application EXEs and DLLs, no drivers or kernel modules. I also don't have any need to support Windows Vista. However, I do need my signatures to remain valid for as long as possible. So I'm trying to use SHA-2 for everything.

    I got my new GlobalSign certificate, and now I have SHA-2 in use for absolutely everything in my signatures. 

    Tinkering with the commands, I found that I can use SHA-512 for the file digest ("/fd sha512"), and that Windows 7 onwards, which are all that I need to support, are quite happy with that for application code EXEs and DLLs. So in the interests of signatures possibly lasting longer, I'm doing that. 

    John Dallman

    Thursday, September 15, 2016 1:07 PM
  • Read your page:

    Very good and comprehensive page for kernel-mode code signing. It help and would like to say thank you.

    This will allow me to sign my custom Cypress FX3 driver. Anyway, still a little bit confuse on the Windows 10 kernel-mode signing policy and do hope to get more info/update from you. Thank.  

    Tuesday, October 11, 2016 8:29 AM
  • Hello everyone,

    Great information here ... very helpful.  I'm hoping I can get some help with a question.

    I am using a code signing certificate from GoDaddy, and on several systems it seems like my application certificate is not valid because the root cert for the timestamp server certificate is not installed.  If I manually install the root (sfroot-g2.crt at, the application certificate is valid.   I don't have any problems if I use different timestamp servers, I've tried several.

    I use a signtool .bat file like this to sign my executable:

    signtool.exe sign /fd SHA256 /f MyCert.pfx /p xxxxxxx /n "My Company" /tr /td SHA256 %1

    The output of "signtool verify" is below ... my question is should the starfield timestamp certificate chain directly back to the G2 root cert?  Is there something I'm missing with signtool to have the timestamp certificate path look like the path for my application certificate?

    Signing Certificate Chain:
        Issued to: Starfield Class 2 Certification Authority
        Issued by: Starfield Class 2 Certification Authority
        Expires:   Thu Jun 29 13:39:16 2034
        SHA1 hash: AD7E1C28B064EF8F6003402014C3D0E3370EB58A

            Issued to: Starfield Root Certificate Authority - G2
            Issued by: Starfield Class 2 Certification Authority
            Expires:   Fri May 30 03:00:00 2031
            SHA1 hash: 9565B778C8A50EB4FEFD45C8A658DDE2411EAD0A

                Issued to: Starfield Secure Certificate Authority - G2
                Issued by: Starfield Root Certificate Authority - G2
                Expires:   Sat May 03 03:00:00 2031
                SHA1 hash: 7EDC376DCFD45E6DDF082C160DF6AC21835B95D4

                    Issued to: *********
                    Issued by: Starfield Secure Certificate Authority - G2
                    Expires:   Sat Dec 09 16:33:39 2017
                    SHA1 hash: B183AC3AB52677FAF58279CFCFE5249A8511D28C

    The signature is timestamped: Mon Oct 10 17:44:43 2016
    Timestamp Verified by:
        Issued to: Starfield Root Certificate Authority - G2
        Issued by: Starfield Root Certificate Authority - G2
        Expires:   Thu Dec 31 19:59:59 2037
        SHA1 hash: B51C067CEE2B0C3DF855AB2D92F4FE39D4E70F0E

            Issued to: Starfield Timestamp Authority - G2
            Issued by: Starfield Root Certificate Authority - G2
            Expires:   Tue Feb 16 03:00:00 2021
            SHA1 hash: 8D517FC99F3B23CEC36B3B0CB3B7E51ACD344BCE

    Successfully verified: Starfield.exe

    Number of signatures successfully Verified: 1
    Number of warnings: 0
    Number of errors: 0
    Tuesday, October 18, 2016 12:50 AM
  • Hi David,

    Thanks for the signing information. Much appreciated. It has made many things clear for me.

    Actually we are signing custom INF file that refers our VID and PID to load the usbser.sys in Windows 8.1 and earlier versions. But this iNF file is not required for Windows 10 as Windows 10 has inbuilt usbser.inf which load the usbser.sys file correctly when any USB Serial device is connected (see this -

    We are signing the package as we do not wish to have any user intervention for loading the drivers for our device in Windows. 

    My Question is towards using Win 10 HLK or Win 8.1 HCK for the submission. since our requirement is signing the INF file for Windows 8.1 and earlier versions, using HCK 2.1 should be fine for the submission? Or is it that we still have to go through the Windows hardware developer dashboard portal on Win 10 for the submission? If we have to use the portal then we will have to have the EV certificate too. Combine the HLK and HCK results during submission. Does getting our custom INF file certified for Win 10 going to add any value when Win 10 is going to use the default inbuilt usbser.inf file?


    Wednesday, October 19, 2016 1:40 PM
  • A new question. Lots of Windows' executables and DLLs don't seem to be signed, but have their hashes appearing in a signed catalog. This Stack Exchange question gave me the initial hint  ( and the idea is interesting. 

    Is it sensible to use this approach for ordinary Windows desktop applications? It has one very attractive feature: there's no need to alter the binaries, by adding a signature, after testing. Altering binaries tends to make QA people want to do the testing all over again, which is highly inconvenient, but signing before testing, in an automated build/test environment, makes it impossible to keep the signing certificate offline in a safe. 

    If it is sensible, how do I go about it? I've found instructions for Inf2Cat, but they're silent on creating an INF file for ordinary executables and DLLs. 

    John Dallman

    Friday, October 21, 2016 12:44 PM
  • Hi all,

    very usefull paper. But now I have a question... I signed my driver, dual sign is ok. I can see both SHA1 and SHA256 sign on the properties of my .cat file.

    But on "Details" of "sha256" sign, I have the message "No signature was present in the subject".

    Sign verify i