Practical Windows Code and Driver Signing discussion

Question

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:

Practical Windows 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

Answer 1

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: http://www.windrvr.com Blog: http://msmvps.com/blogs/WinDrvr

Answer 2

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

Answer 3

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

Answer 4

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

Answer 5

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?

Answer 6

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

Answer 7

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)?

Answer 8

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

Answer 9

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.

Answer 10

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.

Regards

Randy

---

Randy Feingersh

Answer 11

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.

Answer 12

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 https://certs.godaddy.com/anonymous/repository.seam.  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

Answer 13

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:

http://msdn.microsoft.com/en-us/library/windows/hardware/hh967734%28v=vs.85%29.aspx

//************

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.

Questions:

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.

Thanks

Randy

---

Randy Feingersh

Answer 14

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:

http://support.microsoft.com/kb/931125

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

Answer 15

David,

Thanks!

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

---

Randy Feingersh

Answer 16

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

Answer 17

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

Answer 18

Thanks, we have gone the same way.

Answer 19

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.

regards

Jaswinder

Answer 20

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.

Jaswinder

Answer 21

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.

Answer 22

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

Requirements:-

• 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

Where:-

”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 http://timestamp.globalsign.com/scripts/timestamp.dll” “C:\UsbDriver\wlh\cyusbmos.cat"

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\cyusbmos.cat”

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.

Regards

Jaswinder

Answer 23

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.

Answer 24

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 ( http://www.silabs.com/products/mcu/pages/usbtouartbridgevcpdrivers.aspx ).  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 ( https://github.com/pbatard/libwdi/wiki ).  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

Answer 25

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.

Answer 26

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.

Alex.

Answer 27

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

Answer 28

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.
Alex.

Answer 29

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

Answer 30

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: http://www.windrvr.com Blog: http://msmvps.com/blogs/WinDrvr

Answer 31

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

Answer 32

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
ign.com/scripts/timestamp.dll icvac.cat
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: icvac.cat

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.

Alex.

P.S.

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.

-------------------Update------------------------------------------------

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]
Name=icvac.cat                                                              

[CatalogFiles]

<hash>InfFile=icvac.inf
<hash>DrvFile64=x64\icvac.sys
<hash>DrvFile86=x86\icvac.sys

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.

Alex.  

Answer 33

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

Answer 34

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.

Answer 35

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

Answer 36

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

Answer 37

+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.

Answer 38

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

Answer 39

I write a similar docs ,but due to security issue I can not make it into public ...

---

Best Regards, Mike

Answer 40

Thanks. One of the best articles available on this subject.

Answer 41

One of the best articles available on this subject.

Thanks!  If you find an article that is better, let me know!

---

--David Grayson

Answer 42

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?

GB 

Answer 43

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.

Answer 44

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

Answer 45

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?

Answer 46

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.

Regards,

-- pa

Answer 47

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!

Thanks,

Andy

Answer 48

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.

Answer 49

I used your guide along with the PixCL guide your referenced to get the Silicon Dust Labs drivers I customized to work. Good stuff.

http://pixcl.com/Signing_Windows_8_Drivers.htm

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.

Answer 50

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

Answer 51

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

Answer 52

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

Answer 53

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

Answer 54

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?

Thanks!

Monte---

Answer 55

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

Answer 56

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!

Answer 57

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,

Monte---

Answer 58

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.

Answer 59

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

Answer 60

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?

Answer 61

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.

 

Answer 62

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:

http://timestamp.verisign.com/scripts/timstamp.dll

so I've used this one instead:

http://timestamp.globalsign.com/scripts/timstamp.dll

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

Thanks

Answer 63

There is a hotfix to make SHA2 Authenticode certificates work on Vista:

http://support.microsoft.com/kb/2763674

---

Yuhong Bao

Answer 64

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

Thanks

Answer 65

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

Answer 66

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

Answer 67

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

Answer 68

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

Answer 69

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)

https://technet.microsoft.com/en-us/library/security/2949927

-Greg

Answer 70

FYI: Globalsign says they're no longer doing the individual deal, and won't sell to a DBA (must be incorporated)...

Answer 71

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 slabvcp.cat 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?

Thanks,

Daniel Blackmon

---

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

Answer 72

Thank you for the article, it sums up the topic excellently and helped me greatly!

Answer 73

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 ;)

Answer 74

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

Answer 75

RzRDigo, yes, as long as you meet all the requirements that I documented in the "Signature Requirements" section, it should work.

http://www.davidegrayson.com/signing/#reqs

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

Answer 76

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.

Answer 77

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:

1) 

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

2) 

signtool sign /ac
\\[ServerPath]\GlobalSign_Root-CA.crt /as /f \\[ServerPath]\OS*_SHA256.pfx /p
[PASS] /tr http://timestamp.globalsign.com/scripts/timestamp.dll 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 :(

Answer 78

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!

Answer 79

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:
http://pixcl.com/Signing_Windows_8_Drivers.htm

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

Answer 80

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

Answer 81

Hi David,

Great write up, thanks for sharing your experience!.

I am looking to do the same thing as your drivers on https://www.pololu.com/docs/0J7/2

I have used SiLabs USB Driver Customization Utility (AN220 - http://www.silabs.com/products/interface/usbtouart/Pages/usb-to-uart-bridge.aspx) 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 slabvcp.cat 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.cat, 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!

Answer 82

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:

del plluvcp.cat
"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 http://tsa.starfieldtech.com /n "Pololu Corporation" /r "Go Daddy Class 2 Certification Authority" plluvcp.cat
"C:\Program Files (x86)\Windows Kits\8.0\bin\x64\signtool" sign /v /t http://tsa.starfieldtech.com /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 http://tsa.starfieldtech.com /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: http://www.davidegrayson.com/signing/img/win8_download_prompt.png (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: http://www.davidegrayson.com/signing/img/win8_elevation_prompt.png

Because it installs a driver that wasn't signed by Microsoft or one of their agents:
http://www.davidegrayson.com/signing/img/inf_install_prompt_win8_pgm03a.png

---

--David Grayson

Answer 83

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.

Regards,
- Dave L.

Answer 84

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 http://timestamp.globalsign.com/scripts/timstamp.dll /td SHA1 "DRIVER_FILE_HERE"
signtool sign /v /as /fd SHA256 /ac "MSCV-GlobalSign.cer" /n "CERT_NAME_HERE" /tr http://timestamp.globalsign.com/scripts/timstamp.dll /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.

Regards,
- Dave L.

Answer 85

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.

Regards,
- Dave L.

Answer 86

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

Answer 87

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

Answer 88

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. http://blogs.msdn.com/b/windows_hardware_certification/archive/2015/04/01/driver-signing-changes-in-windows-10.aspx

Answer 89

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

Answer 90

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

Answer 91

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.

Answer 92

Thanks, strandec.  I added those!

---

--David Grayson

Answer 93

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'

Thanks,

Alessandro

Answer 94

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.

Answer 95

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.

Answer 96

Thnx, loved the artical!

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

http://download.microsoft.com/download/9/c/5/9c5b2167-8017-4bae-9fde-d599bac8184a/Authenticode_PE.docx

Answer 97

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

Answer 98

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

Answer 99

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

Answer 100

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.

Fred

Answer 101

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 https://technet.microsoft.com/en-us/library/cc732443.aspx?f=255&MSPPError=-2147217396.  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

Answer 102

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.

Regards,

Fred

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

Answer 103

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

Answer 104

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 (social.msdn.microsoft.com/forums/windowsdesktop/en-us/0d0c7f5f-60bb-477a-b491-01cbc250c5c6/driver-signing-problem-pnputilexe-0xe0000242):

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.

Regards,

Fred

Answer 105

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?

Answer 106

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?

Answer 107

Hi David, Jim,

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

support.microsoft.com/en-us/kb/2921916

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.

Regards,

Fred

Answer 108

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:

http://arstechnica.com/security/2015/10/sha1-crypto-algorithm-securing-internet-could-break-by-years-end/

Answer 109

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:

https://technet.microsoft.com/library/security/2880823?f=255&MSPPError=-2147217396

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

Answer 110

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

Answer 111

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 http://social.technet.microsoft.com/wiki/contents/articles/32288.windows-enforcement-of-authenticode-code-signing-and-timestamping.aspx 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

http://blogs.msdn.com/b/windows_hardware_certification/archive/2015/04/01/driver-signing-changes-in-windows-10.aspx

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 tohttps://technet.microsoft.com/en-us/library/Dn375961.aspx  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.....

Answer 112

Thanks for the great links, Bill.  I have added that first one as a reference in the References section of my document.

---

--David Grayson

Answer 113

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?

Thanks

Chris

Answer 114

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

help!

thanks

mitch

Answer 115

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:

http://www.davidegrayson.com/signing/#reqs

http://blogs.msdn.com/b/windows_hardware_certification/archive/2015/04/01/driver-signing-changes-in-windows-10.aspx

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

Answer 116

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

Answer 117

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

Answer 118

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!!

Link: http://support.microsoft.com/en-us/kb/2921916

Answer 119

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

Answer 120

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 https://technet.microsoft.com/en-us/library/Dn375961.aspx). But stay tuned.

Answer 121

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?

Chris

Answer 122

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 http://timestamp.globalsign.com/?signature=sha2 /td sha256"

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

"/tr http://timestamp.entrust.net/TSS/RFC3161sha2TS /td sha256"

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

"/td sha256 /tr http://timestamp.geotrust.com/tsa";
"/td sha256 /tr http://timestamp.comodoca.com/rfc3161";

Anyone got any others I can try? 

thanks, 

---

John Dallman

Answer 123

Chris (IQTech2),

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

http://blogs.msdn.com/b/windows_hardware_certification/archive/2015/04/01/driver-signing-changes-in-windows-10.aspx

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

Answer 124

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:

http://www.davidegrayson.com/signing/#howto

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

Answer 125

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 http://timestamp.globalsign.com/scripts/timstamp.dll";
"/tr http://timestamp.globalsign.com/scripts/timstamp.dll /td sha256";
"/td sha256 /tr http://timestamp.globalsign.com/scripts/timestamp.dll";
"/tr http://timestamp.globalsign.com/scripts/timestamp.dll /td sha256";

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

"/tr http://tsa.starfieldtech.com /td sha256";

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

"/tr http://timestamp.globalsign.com/?signature=sha2 /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

Answer 126

"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:  https://dcsoft.wordpress.com/2015/12/14/renew-your-windows-code-signing-certificates-by-december-31-2015/

Thanks,
David

Answer 127

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.

Answer 128

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!!)	7/1/2016	1/1/2017	1/1/2020
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!

Bill

Answer 129

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

:Continue1
REM See http://social.technet.microsoft.com/wiki/contents/articles/32288.windows-enforcement-of-authenticode-code-signing-and-timestamping.aspx#Testing
REM and https://technet.microsoft.com/en-us/library/Dn375961.aspx
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.
echo Registry keys set successfully.
echo.
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


:BitchAtThem
echo.
echo THIS BATCH FILE MUST BE RUN ELEVATED
echo.
goto Done



:Done
pause

HTH

Bill

Answer 130

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.

Thanks,
David

Answer 131

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

Answer 132

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.
echo SHA-1 Enforcement does NOT seem to be enabled YET
echo (%SearchText% registry values not found)
echo.
goto Done

:FoundIt
echo.
echo ***************************************************
echo SHA-1 Enforcement appears to be ENABLED NOW!
echo (%SearchText% registry values found!)
echo ***************************************************
echo.
goto Done

:Done
pause

HTH

Bill Cumming

Answer 133

As of Patch Tuesday (1/12/2016) Microsoft has now turned on SHA-1 deprecation.

See https://support.microsoft.com/en-us/kb/3123479 and https://technet.microsoft.com/library/security/3123479.

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 http://social.technet.microsoft.com/wiki/contents/articles/32288.windows-enforcement-of-authenticode-code-signing-and-timestamping.aspx (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

Answer 134

(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".

Answer 135

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

Answer 136

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

Answer 137

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.

Answer 138

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

Answer 139

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.

Answer 140

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?

Answer 141

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. 

Answer 142

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.

Answer 143

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.

HTH

Bill Cumming

Answer 144

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 1.3.6.1.4.1.311.2.4.1 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.

Answer 145

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

Answer 146

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

Answer 147

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?

Answer 148

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!

Answer 149

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

Answer 150

DStone2016: Well, I'm glad you were able to find a solution.

---

--David Grayson

Answer 151

Thank you Mr. Grayson for all your work to keep this up to date.  

The link to https://msdn.microsoft.com/en-us/windows/hardware/dn913721 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

Answer 152

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!

---

KM

Answer 153

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.

--

Gabe

Answer 154

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.

Answer 155

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.

---

KM

Answer 156

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. 

Answer 157

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!

Answer 158

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.

Answer 159

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: https://gallery.technet.microsoft.com/scriptcenter/SHA1-Certificate-Signature-22c94da9. 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

Answer 160

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 http://sha256timestamp.ws.symantec.com/sha256/timestamp" 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

Answer 161

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

Answer 162

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:

http://www.davidegrayson.com/signing/#timestamp

---

--David Grayson

Answer 163

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

Answer 164

Thank you for pointing to the GlobalSign ressource (https://support.globalsign.com/customer/portal/articles/1491089-kernel-mode-driver-signing-%E2%80%93-windows-7-8) 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.

Answer 165

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 

thanks

Answer 166

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:

https:// msdn.microsoft.com/windows/hardware/drivers/install/cross-certificates-for-kernel-mode-code-signing

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 ?

Thanks,

FredTGB

Answer 167

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"?

Answer 168

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).

FredTGB.

 

Answer 169

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:

https:// msdn.microsoft.com/windows/hardware/drivers/install/cross-certificates-for-kernel-mode-code-signing

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 ?

Thanks,

FredTGB

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.   

Answer 170

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:

https:// msdn.microsoft.com/windows/hardware/drivers/install/cross-certificates-for-kernel-mode-code-signing

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 ?

Thanks,

FredTGB

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.

FredTGB

Answer 171

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

Answer 172

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

Answer 173

Read your page: http://www.davidegrayson.com/signing/

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.  

Answer 174

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 https://certs.godaddy.com/repository), 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 http://tsa.starfieldtech.com /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

Answer 175

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 - https://msdn.microsoft.com/en-gb/library/windows/hardware/dn707976(v=vs.85).aspx).

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?

Thanks,

Answer 176

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  (http://security.stackexchange.com/questions/133660/why-does-microsoft-use-a-digital-signature-catalog-instead-of-a-signature-in-the) 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

Answer 177

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 is ok and the driver installs correctly.

Is it only a "display" error, or am I doing something wrong?

Thanks a lot.

Answer 178

Hey, everyone!  It's been a while since I answered questions here.

John Dallman: Thank you for reporting your findings.  I did not know that SHA-512 was supported by signtool, so I have added some mentions of it to my article.

John Dallman:  I don't know what is going on with the Microsoft catroot stuff.  As far as I know, Windows does not check signatures of a CAT file when you try to run an executable.  If it really does that, how does it work?  Instead of using inf2cat, you might try using MakeCat to make such a CAT file, but I don't know if that will really be useful.

John Dallman:  One issue with signing executables is that it might give users the wrong idea about what they are trusting.  If a user sees that signature, they might think the executable is safe to run.  But if the executable immediately loads a bunch of DLL files without checking their signatures (as most executables do), then those DLLs could execute malicious code.  Therefore, I tend to think that you should not sign individual executables and DLLs but you should sign the standalone installers that contain those things.  I'd be interested to hear what you think of that and continue this discussion.

Leemy1123:  I'm not really sure what to say.  Do you have any specific questions?  If you're looking for a step-by-step guide, check out the guide from Adafruit, although it only signs an INF file, not a kernel module:  https://learn.adafruit.com/how-to-sign-windows-drivers-installer/overview

jimbr32: We have not used GoDaddy/Starfield certificates in years, so my memories about how their certificates are set up are pretty hazy.  However, the problem you are experiencing is well-explained and sounds real.  Windows tries to update new root certificates from the internet but somehow it just is not fast or reliable.  Your signature might look bad the first time, but then later when Windows has finished downloading the ceritifcate it will look good.  It is best to go with root certificates that are already installed on the typical user's machine, though I don't have an authoritative list of those.  Since you said other timestamp servers work, maybe just use one of GlobalSign's timestamp servers.  And in general, GlobalSign's certificates work better than GoDaddy/Starfield certificates so you might consider buying from them the next time you renew.  You might also see if you can find a cross certificate that goes from "Starfield Class 2 Certification Authority" to "Starfield Root Certificate Authority - G2"; that way the root of your timestamp would be the same as the root of your main signature.  You would install the cross certificate on your computer by double-clicking on it, and then signtool would (hopefully) include it automatically when making the signature.  I'm not sure if it does that for timestamps though, and it's pretty hard to tell what certificates are actually in the signature as opposed to being on your computer.

VinayBondade:  I'm glad you found it useful!  I have not done any Windows HLK or HCK stuff, and I have never submitted any drivers to Microsoft in any way, so I don't have much to say about your questions.  The value of using a custom usbser.sys-based driver on Windows 10 is that you can get your product's name to show up in the Device Manager.  If your customers use usbser.inf (it's hard to prevent them from doing it) then it will just say "USB Serial Device" in the Device Manager.

enrikk: That's a strange error that I have not seen before.  Could you share the commands you run to generate your signature?

---

--David Grayson

Answer 179

An important piece of news that doesn't seem to have been publicized at all: 

The "Certificate Authority Security Council", a trade body, decided on 1st December that "best practice" for code signing certificates was to embed them in hardware devices. OK, that's a best practice. But they and Microsoft have decided that signing certificates for Windows can only be sold in hardware form from 1st February, or for use in an cloud-based signing service. The only one of those I've found so far is Symantec's Secure App Service, which claims to integrate with signtool.exe via a Cryptographic Service Provider. 

https://casecurity.org/2016/12/08/leading-certificate-authorities-and-microsoft-introduce-new-standards-to-protect-consumers-online/

https://www.symantec.com/content/en/us/enterprise/fact_sheets/SAS-CSP.pdf

---

John Dallman

Answer 180

David: The main reason for signing executables is that, for applications, Microsoft wants you to do it. This doesn't necessarily imply that it's a good idea, but they have a lot of control. 

You mentioned: 

"But if the executable immediately loads a bunch of DLL files without checking their signatures (as most executables do), then those DLLs could execute malicious code."

How could an executable check signatures on DLLs that it's directly linked to? They get dragged in when the executable loads, and can execute code via DLLMain() before the executable gets control.

I've found the /IntegrityCheck option of link.exe and editbin.exe, but I haven't so far managed to get an example program to run if it uses a DLL linked with /IntegrityCheck and signed with the /ph option that the /IntegrityCheck document describes.

http://social.technet.microsoft.com/wiki/contents/articles/255.forced-integrity-signing-of-portable-executable-pe-files.aspx

Is this only usable for device drivers? 

---

John Dallman

Answer 181

John: Thanks for the information.  I do not know of any compiler toolchain that makes it easy to verify your DLLs before loading them, but it could be done if you load all your DLLs at runtime using the Windows equivalent of dlopen or something fancy like that.

You linked to two documents and only one had the word "hardware" in it.  It said: "companies must either store keys in hardware they keep on premise or ...".  So, does a PC disk drive count as hardware?  I would think so, since they didn't use additional keywords like "USB" or "token".

---

--David Grayson

Answer 182

David: Sadly, loading the DLLs with LoadLibrary (equivalent of dlopen) also requires you to retrieve pointers to all the functions individually. Since the code I work on is a DLL with several hundred exported functions, nobody wants to use it that way. 

"Storing keys in hardware" is interpreted by GlobalSign as "in a USB token or another kind of hardware security module." They say they can't sell us certificates in files after the end of January. This article says "FIPS 140-2 level two HSM or equivalent."

https://redmondmag.com/blogs/the-schwartz-report/2016/12/digital-cert-code-signing-requirements.aspx

---

John Dallman

Answer 183

John:  That's a huge change that could impact a lot of workflows for people.  I am surprised it is happening so soon and I haven't heard about it from more people.  Thanks for the information.  Luckily, our company's code-signing certificate lasts for another 2.5 years so I won't have to worry about this too soon.  If you get your USB token working and find information that would be useful to add to Practical Windows Code and Driver Signing, let me know.  (I maintain the document by editing the HTML by hand, so feel free to download it, edit it yourself, and email me your edits or something.)

---

--David Grayson

Answer 184

John:  I've looked into how DLLs get imported into Windows a little bit before.  If I recall correctly, there is a table referenced from the header of the executable (the PE header) called the address import table (IAT).  The IAT basically tells Windows: "ok, load this DLL, and get these entry points from it, and stick pointers to those entry points at these specific locations in my memory space".  I suspect that with enough low-level knowledge of Windows and your compiler toolchain, one could make the IAT be empty, load the DLLs yourself and verify them somehow, and store the function pointers in the right place so that you don't have to edit or even recompile the rest of your code that uses the DLL.

There would be some legal implications for licenses like the LGPL but nothing insurmountable.

I don't think anyone will really expect you to do that as as software developer, but it seems like something that the compiler vendors might want to implement some day, or maybe you can get that IntegrityCheck feature you found on the Microsoft compiler to work.

---

--David Grayson

Answer 185

 I suspect that with enough low-level knowledge of Windows and your compiler toolchain, one could make the IAT be empty, load the DLLs yourself and verify them somehow, and store the function pointers in the right place so that you don't have to edit or even recompile the rest of your code that uses the DLL.

Sort of this does already exist: the delay-loading:

Linker Support for Delay-Loaded DLLs

With enough motivation, developers can modify the runtime routines of delay-loader and do whatever they want.

Regards

-- pa

Answer 186

Greetings!

Long story short; after literally absorbing every official and unofficial article about proper kernel-mode driver signing I struggle with one simple quest: to support "older" Windows versions like 8.1, 8 and 7 using the Hardware Lab Kit.

I seek your guidance, don't want to waste more hours on my own, I consider myself stuck =[

Regards,
Benjamin "Nefarius" Höglinger

Answer 187

Benjamin Hoeglinger:

I'm actually not too familiar with the Hardware Lab Kit.  Are you trying to submit your driver to Microsoft to be tested?  For Windows 7, 8, and 8.1, is there any reason to do that instead of just signing the driver yourself with your own code-signing certificate?

---

--David Grayson

Answer 188

It is now possible to create SHA-1 "collisions" - two separate documents, with different content, and the same SHA-1 hash. It is currently quite expensive, but it will get cheaper. SHA-1 hashes are severely contra-indicated for code signing. 

https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html

---

John Dallman

Answer 189

I cannot thank you enough for your efforts here- you've saved me so much time, effort and stress.

Answer 190

slaphead99_uk:  Thank you, that is very nice.  That is why I wrote the article in the first place and continue to maintain it. 

John Dallman: Indeed, SHA-1 is really broken now.  There is even a tool that generates colliding PDFs with different images in them and you can specify what images to use.  But Microsoft's Inf2Cat tool only uses SHA-1 and there is no option to use a better hash as far as I know!  For every other part of the signature, you can ditch SHA-1, but not for that part.

---

--David Grayson

Answer 191

Hi David,

This is about the "Signature requirements" section. For the "portal" description, we can read:

However, there is a really nice loophole in the Microsoft announcement. 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 for GlobalSign was issued long before Windows 10 and it expires on 2021-04-15. Therefore, you should be able to sign kernel-mode drivers for Windows 10 with a regular GlobalSign code-signing certificate until then.
On 2016-07-26, Microsoft announced that this rule will only be enforced on Windows 10 systems that were freshly installed at build 1607 or later, with Secure Boot on.

Actually Microsoft has changed the text, now it is:

To summarize, on non-upgraded fresh installations of Windows 10, version 1607 with Secure Boot ON, drivers must be signed by Microsoft or with an end-entity certificate issued prior to July 29th, 2015 that chains to a supported cross-signed CA.

So, the date in the Policy really applies to the user/company certificate and not the CA one.

I contacted sysdev support and the answer I got when I mentioned the first policy text:

CA certificate usually has 10 – 20 years period of validity. The policy will make no sense if it is pointing CA certificate here…

Also we experienced the case with Secure Boot on Windows 10: our drivers were no longer installing when using a fresh certificate and signing as before. We had to submit them to the portal for a Microsoft signing.

Regards,

FredTGB

Answer 192

Hello, FredTGB.

Yes.  I was looking into this matter just now to see if the loophole still exists and I'm afraid it does not.  There are two relevant blog posts by Joshua Baxter that attempt to document the portal:

In this earlier blog post, which was about the initial Windows 10 release, the loophole is clearly documented, or at least I thought it was clear the first time I read it and it might have changed because it doesn't seem so clear anymore:

https://blogs.msdn.microsoft.com/windows_hardware_certification/2015/04/01/driver-signing-changes-in-windows-10/

This later blog post makes it clear that the loophole will not exist in fresh installs of build 1607 with Secure Boot enabled:

https://blogs.msdn.microsoft.com/windows_hardware_certification/2016/07/26/driver-signing-changes-in-windows-10-version-1607/

Given the current wording of both of these blogs posts, I can see that my interpretation is wrong.  I think Joshua edited both of those posts since they were posted but I can't prove it.  I've also been getting emails from someone who is having trouble using the loophole in practice.  

Also, by the way, the "Testing" section in my document has always recommended testing your kernel-mode drivers on a Windows 10 system that was freshly installed at version 1607 and has Secure Boot enabled ever since I saw Joshua's second blog post, so people reading my whole article could at least avoid releasing bad drivers into the world.

TLDR: You really do need to use the portal if you are going to do kernel-mode drivers in 2017.  Personally, I probably won't be using the portal because I don't need it for my work, so it will be hard to help anyone who is using it.  But I'll keep it in mind and update the article accordingly.

---

--David Grayson

Answer 193

Hi David,

Thanks for looking into that matter.

Another information regarding the portal: we have detected that the drivers signed through the portal are specific to Windows 10, they don't work on Windows 8. So, when packaging a solution, it is necessary to embed two sets of drivers so support both versions.

Regards,

FredTGB

Answer 194

FredTGB:  That goes against what the Microsoft documentation has said; do you have more information to back that up?  Do you know what signature requirements the driver was missing that prevented  it from working on Windows 8?  Were you able to submit test results for driver on Windows 8/7 and/or select Windows 8/7 in the user interface of the portal?  Before you submitted your driver to the portal, did you sign it with a signature that was good enough to work on Windows 8?  Did the portal remove your signature and replace it with its own?

---

--David Grayson

Answer 195

do you have more information to back that up?

=> no I don't. It is only based on some quick tests I've performed. I have tried two times, with the same result. Maybe I missed something to have drivers compatibles.

Do you know what signature requirements the driver was missing that prevented  it from working on Windows 8?

=> No, I didn't investigate further at this time as we decided to deliver several set of drivers, and the installer chooses the right set of drivers to use based on the Windows version (and actually because of the SHA2 issue for Windows 7, we have now 3 sets of drivers, just differing by signatures).

Were you able to submit test results for driver on Windows 8/7 and/or select Windows 8/7 in the user interface of the portal?

=> No I won't, the portal propose the following checkboxes, i.e. only Windows 10:

• <label>Windows 10 Client versions 1506 and 1511</label>
• <label>Windows 10 Client versions 1506 and 1511 x64                                </label>
• <label>Windows 10 Client version 1607</label>
• <label>Windows 10 Client version 1607 x64</label>
• <label>Windows 10 RS2 Client
  </label><label></label>
• <label>Windows 10 RS2 Client x64</label>

Before you submitted your driver to the portal, did you sign it with a signature that was good enough to work on Windows 8?

=> yes I did, because it is the same drivers (without Microsoft signature) we are using for Windows 8, and they work fine. For Windows 10, we just have an extra step to embed the Microsoft signature, but binaries (including our signature) are exactly the same.

Did the portal remove your signature and replace it with its own?

No, It didn't. The portal process simply adds a second signature which is visible when looking to file properties. Its name is "Microsoft Windows Hardware Compatibility Publisher".

Regards,

FredTGB

Answer 196

FredTGB: OK, there must be something happening here that I don't understand, because it sounds like the portal only added a signature, without removing any signatures, but then the addition of that signature broke the driver for Windows 8.  That's too bad.

Also, I looked into why the Portal is only letting you select Windows 10.

This blog post from Joshua Baxter has a FAQ about how to sign a driver for Windows 7 through 10.

This interview with James Murray has some more details.  The key part is that "you need to use the Hardware Compatibility route (that is, you need to pass the HLK tests); by design, the new "attestation" route only supports Windows 10."  OK, so I learned something new today.  I didn't really know that there were two different routes you could go through in the portal, but it makes some sense now that I think about it.

The Hardware Compatibility route existed a long time ago and was used by people who wanted to get their drivers distributed in Windows Update.  The attestation route is this new thing with less stringent requirements but it only supports Windows 10, and I don't know what mechanism it is using to only support Windows 10.

---

--David Grayson

Answer 197

Hi David,

Thanks for your investigations and your reply.

Yes, I confirm I'm using Attestation Signing. We are not providing drivers for a specific hardware. Our drivers are only used by our application, so we didn't need the HLK route.

Regards,

FredTGB

Answer 198

Hi David and all,

first of all: thanks for all the valuable information you all share.

I(we) did driver signing using a GlobalSign cross signing certificate and we were fine with Windows 7. Now, turning to win10, I want to go with EV certificate and do attestation signing through the portal. I know that this works for Win 10 only (Win7 / 8.1 will not be supported)

2 questions here:

• Can I use the EV certificate as well to cross-sign a package for use with Win7/8.1, as I did before with the conventional certificate?
  
• I am not sure what portal to use for driver submissions. My understanding was the new HW Dev Center dashboard replaced the Sysdev portal. But now, I read on http://docs.microsoft.com/en-us/windows-hardware/drivers/dashboard/ that the Sysdev portal is still to be used for attestation signing. Any comments/experiences here?

Thanks a lot!

Answer 199

Hello, GernotB.

I would expect GlobalSign's EV certificates to work for cross signing.  If you compare the standard certificates and the EV ones in GlobalSign's marketing material, they don't make it sound like you are losing any features, only gaining features.  You should, of course, test your signatures on the operating systems you care about.  Does GE have a computer lab you can use with Windows 7 and 8 machines?  It seems like they ought to.

I'm not really sure about the differences between the portals, but the Microsoft page you linked to makes it sound like you have to use the old sysdev portal to do your attestation signing.

---

--David Grayson

Answer 200

Hello,

I have a printer driver package that has been signed with :

- Symantec SHA256 TimeStamping Signer - G2

which references 

- Symantec Class 3 SHA256 Code Signing CA

which references 

VeriSign Class 3 Public Primary Certification Authority - G5

When installing the driver on a server, i have the popup "Would you like to install this device software" with "Always trust software from "..." ".

Clicking on "Always trust software from"..." then Install will add the certificate into the Trusted Publisher of the server, but i though that it will be recognized and will not prompt me this pop-up neither install any more certificate... My server is Windows Server 2008 R2 Standard 64bits.

Then, I cannot deploy the printer via Group Policy within the domain, i have the error "0x80070bcb".

Even with certified driver package, it is not installing on my windows 7 machine via GPO.

Can you tell me where i misunderstand something ? Thank you very much for the help !

Answer 201

Shah75:

I'm afraid I don't know much about distributing a driver via GPO on a Windows domain.  I always just make drivers that users download and it's not a big deal if they have to click through a prompt.

---

--David Grayson

Answer 202

0x8007yyyy is the OLE HRESULT wrapping of Windows error 0x0000yyyy.  Windows error 0x00000bcb == 3019 is "The specified printer driver was not found on the system and needs to be downloaded"

Not that I know much about this error message, but it could be related to the recent security fixes about fake print servers tricking computers into downloading malware infected fake printer drivers.  Maybe one of those fixes now interfere with the automatic download of printer drivers via whatever GPO mechanism you tried.

However if its just the trusted publishers issue, maybe you need to use a GPO to push the relevant publisher certificate (the one the driver was signed with) into the "trusted publishers" certificate store of the client PCs before deploying the driver itself.

Answer 203

David!

THANK YOU for taking the time to write your original article and the support you're giving here.  

The article was wonderfully done.

Answer 204

Hey, Ted.  I'm glad my article was useful to you!  It's been over 5 years since I put up the first version and a lot has changed since then, but I keep updating it.  There have been lots of cool people sending feedback and updates to me over the years (including the people in this thread), so that made my job easier, and they deserve some thanks too.  :-)

---

--David Grayson

Answer 205

Hello,

I have USB device that is using FTDI chip. I assigned my own VID&PID to this USB device (chip). FTDI vendor provides WHQL certified drivers, but these drivers support only some default devices (default VID&PIDs).
As I have my own VID&PID, I had to edit this default drivers (edit ftdibus.inf file), removed default VID&PID, and added my own VID&PID. This change of cource caused WHQL sign to be invalid.
So I used Thawte Code Sign certificate to sign edited INF file, created new signed CAT file (ftdibus.cat). This "customized" driver is perfectly working on WinXP to Win10. This all was in year 2014.

Today, I need to edit these drivers again, add new VID&PID for new USB device, so I will need to sign these drivers again (so I need to purchase code sign certificate again).
But accidentally I found article, that "... all new Windows 10 kernel mode drivers must be submitted to the Windows Hardware Developer Center Dashboard portal (Dev Portal) to be digitally signed by Microsoft...".
I spent many hours searching what this means, if it concerns me, but now I'm quite lost.
I need to know, if using "Code Sign" certificate to sign changed INF file will still works on Winows 10 1607 (or newer), before I purchase new certificate.

Please note:
1) I need only to change ftdibus.inf file and then sign this change (create new signed ftdibus.cat file from modified ftdibus.inf file).
2) FTDI drivers are containing file ftdibus.sys (I suppose that this file is "kernel mode" part of driver), and this files is signed by FTDI and by "Microsoft Windows Hardware Compatibility Publisher". Here I'm not sure, when Windows (Win10 1607 or newer) is loading drivers, if Windows is checking only sign in ftdibus.sys file, or needs also signed (and WHQL certified?) CAT file (ftdibus.cat).

thank you for any information,

Jiri Hlavica

Answer 206

This blog post from Joshua Baxter has a FAQ about how to sign a driver for Windows 7 through 10.

This interview with James Murray has some more details.  The key part is that "you need to use the Hardware Compatibility route (that is, you need to pass the HLK tests); by design, the new "attestation" route only supports Windows 10."  OK, so I learned something new today.  I didn't really know that there were two different routes you could go through in the portal, but it makes some sense now that I think about it.

The Hardware Compatibility route existed a long time ago and was used by people who wanted to get their drivers distributed in Windows Update.  The attestation route is this new thing with less stringent requirements but it only supports Windows 10, and I don't know what mechanism it is using to only support Windows 10.

That should be made clear.

I wandered too much to understand what this attestation signing even was. And it didn't help that MSDN was claiming it "still fine-ish" with previous Windows versions in some pages, incompatible in others.

Thankfully I found out this and this, clarifying out it's only gonna work (outside of W10) for that very selected few drivers that don't require a .inf.

Leaving only the HLK/HCK/WLK way for the "one single driver" philosophy. I am afraid that requires you to "go full WHQL" though? Am I wrong? Does this pose any further requirement on one's side? (that is, aside of passing tests ofc)

Answer 207

Hello, Jiri.

If you want to sign kernel-mode drivers these days, you need an Extended Validation (EV) code-signing certificate, according to the initial announcement:

https://blogs.msdn.microsoft.com/windows_hardware_certification/2015/04/01/driver-signing-changes-in-windows-10/

As far as I know, this policy has not changed, but you might as well try logging into the hardware portal and see how far you can get and see what rules are posted there.  I have never had to use the portal to sign a certificate so my experience there is limited.  I've never even seen screenshots of it.  If you could make a blog post of your own that walks people through the process, I'm sure lots of people would find that useful.

BUT, here is an important thing to note: I think you can probably install your old driver that was signed in 2014, and then install a new driver that contains the new USB IDs and refers to the same .sys file from before.  Then you'd be able to use a normal code-signing certificate to sign the new driver without going through the portal.  Signing requirements for getting a driver package installed are less stringent than for actually loading a .sys file, so Windows can use your 2018 signature to install your new driver package, and use your 2014 signature to load the .sys file into kernel memory.  Please see the information that I wrote in my article about the CP2102 in the "Loading a kernel module" section of my article for more information about how this works.  Note that it is kind not ideal because it would result in users seeing two driver installation prompts when installing their driver.

---

--David Grayson

Answer 208

mirh: Thanks for the push.  I updated my "Loading a kernel module" section to have more information about the Windows 10 portal, and links to helpful resources.  If you've gone through the portal already, maybe you could read the section and let me know if I got anything wrong.

I am not sure what differences are in the alphabet soup of HLK/HCK/WLK/WHQL.  I think maybe WHQL is where you pay Microsoft or a third-party to test the driver?  And I think one of those other acronyms is where you test the driver yourself.  I really couldn't say without doing further research, but please let us know what you find out.

---

--David Grayson

Answer 209

Hello @Shah75,

I have the same problem... Did you solve? How?

Thanks in advace... and thanks also to @DavidGrayson for the precious article!

Answer 210

Hi David,

Excellent resource on windows code and driver signing!

I am just starting on this journey so can provide more data later.

I did send you a separate email about a question I posted yesterday.

https://social.msdn.microsoft.com/Forums/windowshardware/en-US/c8de878f-44a5-4b78-adf2-97a0ab8d944f/pcie-hw-card-uses-microsoft-mfsys-serenumsys-and-serialsys-drivers-do-the-inf-files-need-to?forum=whck

Best Regards,

Jamey Anthony

Answer 211

Thank  you David for posting. I am completely new to the process. If you do not mind, I have a few quick questions and maybe you can help. 

My biggest issue is that our original developer (outsourced) went out of business 3 to 4 years ago and we are unable to really do much. With Windows 10, it is almost impossible to install our drivers (on the market since 1989 without any issues) without going through the process of Disabling secure boot and then enabling Test Signing. Eventually, after several updates from Microsoft, we need to re-do the process. 

Do you think we can actually get certification based on our our installation executables ? As mentioned our Outsource Supplier went out of business and we only have the Executables for the drivers and for the application. If you are not he right person, could you point me to the person or company?

I will spend more time to review your article to understand the process in the future. Many thanks Tsung

Answer 212

Hello, Tsung (T3KL2019).  I don't really know what you're talking about.  If you could go into more detail about the exact issue that you are having and what your plan is to fix it, then maybe I would have something to contribute.  I don't know what "certification based on our our installation executes" would mean.  You can sign executables if you want, and I go into a lot of detail in my article about how to do that.  But that is different from signing a driver.  And there are two different types of driver signing that are very different and have different requirements.  This is all explained in the article.

---

--David Grayson

Answer 213

"Storing keys in hardware" is interpreted by GlobalSign as "in a USB token or another kind of hardware security module." They say they can't sell us certificates in files after the end of January. This article says "FIPS 140-2 level two HSM or equivalent." https://redmondmag.com/blogs/the-schwartz-report/2016/12/digital-cert-code-signing-requirements.aspx

I should have reported back long ago on this. 

The rules have actually panned out as "EV certificates really are only sold in HSMs. Non-EV certificates are not supposed to be sold outside HSMs, but that rule is not being enforced at present, because it would be horribly disruptive."

I work for a company that products applications and toolkits, rather than drivers, but it produces a lot of applications. We've ended up buying PrimeKey's SignServer appliance product, which works pretty well, although it uses its own signing tools, rather than Microsoft signcode.exe. 

---

John Dallman

Answer 214

Thanks for the info, John!  I have been using a code signing certificate from K Software for nearly a year now, for signing of software and driver packages (but not kernel modules).  It can be stored on computers and its signatures haven't given me any problems.

K Software provides a special deal for us: just enter "CPNDEG" in the "Partner Coupon" field to get 10% off the price of their already cheap certificates.

Answer 215

The process is well-understood, if a bit tedious.  Your driver package has to be signed by Microsoft, either by passing the WHQL tests or by attestation signing (which you can look up).  Both of those require you to establish an account with the Microsoft Hardware Dashboard, and doing that requires that you acquire an EV (Extened Validication) Code-Signing Certificate, so Microsoft can know the files are coming from you.  The process is all described in the article and in Microsoft's documentation.  You just need to dig in.

---

Tim Roberts | Driver MVP Emeritus | Providenza &amp; Boekelheide, Inc.

Answer 216

Hi Tim,

I have an internally developed motherboard that utilizes an MCU with a USB interface.  By itself, the driver is signed, but we changed the PID/VID to make it unique and allow the motherboard to be recognized by our part number.  For years we were able to get by as you mention in your article without signing the driver and when Windows 10 came along it now requires signing unless you go through the long process of disabling the security feature which is undesirable.

So...we worked to sign the driver for Windows 7, 8, 8.1, and 10 and verified it on multiple PCs.  However, one particular PC running Windows 10 has an issue with the signed driver and gives the Code 52 error that you mention in your article.  It had previously had the unsigned driver installed.  The unsigned driver was uninstalled and then the new signed driver was installed.  After many uninstalls/reinstalls it was clear that particular PC was not going to work with the signed driver.  At that point I disabled driver signing security and installed the driver.  It worked...until the next reboot and will no longer work and gives the Code 52 error.

I did yet another install on a different PC running Windows 10 (but with same company image) that had not previously had the driver installed in any form and it installed and has no issues.  Windows 10 does not complain about the driver certificate.  

Do you or anyone else here possibly have an idea of what could be causing the issue on this one PC?  All other PCs seem to have no issue.

Thank you!!

Answer 217

Hi Tim,

I have an internally developed motherboard that utilizes an MCU with a USB interface.  By itself, the driver is signed, but we changed the PID/VID to make it unique and allow the motherboard to be recognized by our part number.  For years we were able to get by as you mention in your article without signing the driver and when Windows 10 came along it now requires signing unless you go through the long process of disabling the security feature which is undesirable.

So...we worked to sign the driver for Windows 7, 8, 8.1, and 10 and verified it on multiple PCs.  However, one particular PC running Windows 10 has an issue with the signed driver and gives the Code 52 error that you mention in your article.  It had previously had the unsigned driver installed.  The unsigned driver was uninstalled and then the new signed driver was installed.  After many uninstalls/reinstalls it was clear that particular PC was not going to work with the signed driver.  At that point I disabled driver signing security and installed the driver.  It worked...until the next reboot and will no longer work and gives the Code 52 error.

I did yet another install on a different PC running Windows 10 (but with same company image) that had not previously had the driver installed in any form and it installed and has no issues.  Windows 10 does not complain about the driver certificate.  

Do you or anyone else here possibly have an idea of what could be causing the issue on this one PC?  All other PCs seem to have no issue.

Thank you!!

Well, I actually just found the fix (at least on my PC). I did an install of the driver for the MCU device that is used on our board for the USB interface(which is signed).  It did not recognize the device driver either so I went back and installed our signed driver again….and VOILA! It is now working.  My suspicion is that there was some corrupt file somewhere that was overwritten when I tried to install the MCU driver because it was different than ours.  Once I did that and then tried to install our driver the “corrupted file” had changed because it had been overwritten by the MCU file…now that the file was different our driver files installed and overwrote those.  I did a reboot and still have a working driver.  I never cease to be amazed by the craziness of software…