Strange Driver Signing Issue

Hi,

We have developed a Mux driver based on the sample provide by the DDK. The driver is digitaly signed by our own certificate, (which works on other dirvers perfectly). However when installing this driver, we get the dreaded “Window can’t verify the publisher of this driver software”. I have checked all the files on the driver package and they are all signed with our cross certificate, verified by looking at the properties of the file and checking the certificates. On the same install we install a lower miniport driver which is also signed by the same certificate, and presents us with the correct “do you trust this provider dialog with our certificate presented”. So is there something we are missing in the signing of a mux driver. to clarify the process of signing, we;

  1. time stamp both infs

  2. call inf2cat with finds both inf’s and produces the cat,

  3. Sign the cat

  4. Sign the notification object dll

  5. Sign the driver.

?? really at a loss as to why windows 7 Utlimate is popping up this message. It also indicates in the device manager that the driver is not signed YET! the properties of the files say different? What is going on?

Thanks
Steve

I only sign the cat - if you reverse and sign driver, dll and then the cat, will it work?


From: “xxxxx@bemac.com
To: Windows System Software Devs Interest List
Sent: Friday, March 25, 2011 10:12 AM
Subject: [ntdev] Strange Driver Signing Issue

Hi,

We have developed a Mux driver based on the sample provide by the DDK. The driver is digitaly signed by our own certificate, (which works on other dirvers perfectly). However when installing this driver, we get the dreaded “Window can’t verify the publisher of this driver software”. I have checked all the files on the driver package and they are all signed with our cross certificate, verified by looking at the properties of the file and checking the certificates. On the same install we install a lower miniport driver which is also signed by the same certificate, and presents us with the correct “do you trust this provider dialog with our certificate presented”. So is there something we are missing in the signing of a mux driver. to clarify the process of signing, we;

1. time stamp both infs

2. call inf2cat with finds both inf’s and produces the cat,

3. Sign the cat

4. Sign the notification object dll

5. Sign the driver.

?? really at a loss as to why windows 7 Utlimate is popping up this message. It also indicates in the device manager that the driver is not signed YET! the properties of the files say different? What is going on?

Thanks
Steve


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

modifying anything in the catalog (e.g. inf, or sys) after signing the
catalog will break it.

So don’t sign the driver after the cat, sign it before generating the
catalog.

On 25/03/2011 10:12 p.m., xxxxx@bemac.com wrote:

Hi,

We have developed a Mux driver based on the sample provide by the DDK. The driver is digitaly signed by our own certificate, (which works on other dirvers perfectly). However when installing this driver, we get the dreaded “Window can’t verify the publisher of this driver software”. I have checked all the files on the driver package and they are all signed with our cross certificate, verified by looking at the properties of the file and checking the certificates. On the same install we install a lower miniport driver which is also signed by the same certificate, and presents us with the correct “do you trust this provider dialog with our certificate presented”. So is there something we are missing in the signing of a mux driver. to clarify the process of signing, we;

  1. time stamp both infs

  2. call inf2cat with finds both inf’s and produces the cat,

  3. Sign the cat

  4. Sign the notification object dll

  5. Sign the driver.

?? really at a loss as to why windows 7 Utlimate is popping up this message. It also indicates in the device manager that the driver is not signed YET! the properties of the files say different? What is going on?

Thanks
Steve


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer


Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

Hi,

Thanks for the responses, have checked out the order, and I can only find one thing wrong which was signing the dll after the cat, but after changing it, and performing a resign of everything it still fails on the test machine. The only thing I have noticed on the test machine is that it does not have all the latest updates for Win7 on it. The new signing order is

  1. Time stamp Infs

  2. Sign driver

  3. sign dll

  4. infs to cat

  5. sign cat

Can you resign the driver files or do I have to go back to unsigned files? i.e. the sys and the dll,

note: I delete the cat each time.

Regards

Steve

You’re trying this on a CLEAN test machine, right?

Repeatedly testing the installation process on the same machine – installing the driver, then uninstalling it, and then trying to install it again – is a common cause of misdiagnosis. When you elect “uninstall” from device manager, you really don’t COMPLETELY remove the driver (or its INF file) from the system.

Just a tip,

Peter
OSR

Hi Peter,

Yes we use macrium reflect to reload the image, Hopefully its a clean image :slight_smile: I will perform a few checks.

P.S. I have check the driver signature using the verify option and it all looks fine. So gettig to the point to put a call into MS.

Flippin Signature :slight_smile:

Cheers
Steve

xxxxx@bemac.com wrote:

Hi,

Thanks for the responses, have checked out the order, and I can only find one thing wrong which was signing the dll after the cat, but after changing it, and performing a resign of everything it still fails on the test machine. The only thing I have noticed on the test machine is that it does not have all the latest updates for Win7 on it. The new signing order is

  1. Time stamp Infs
  2. Sign driver
  3. sign dll
  4. infs to cat
  5. sign cat

How are you installing this, exactly?

And which error do you get, exactly? Given this sequence, you should
see a dialog that asks “Do you trust this publisher?” That is
completely correct and entirely to be expected. The only way to
eliminate that is to submit your driver for the WHQL signature.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Hi All,

Thanks for all your responses, it made me take a long look at the installer code and check out all the files, view the setupapi logs etc… and DOH!!! found it wasnt copying the cat file to the required place. It now works as expected, and device manager now say’s it it signed. But interestingly Windows 7 obviously still allows the driver to run up , (as it is signed) and install even if the cat file is missing, you would of thought it would pop up a dialog stating that there is a missing file? but that would be too logical.

and Yes we will need to submit the driver to remove the “do you trust the publisher dialog”

Thanks
Steve

xxxxx@bemac.com wrote:

Thanks for all your responses, it made me take a long look at the installer code and check out all the files, view the setupapi logs etc… and DOH!!! found it wasnt copying the cat file to the required place. It now works as expected, and device manager now say’s it it signed. But interestingly Windows 7 obviously still allows the driver to run up , (as it is signed) and install even if the cat file is missing, you would of thought it would pop up a dialog stating that there is a missing file?

CAT files are optional. Always have been. You can install using just
an INF and a SYS, if you are willing to put up with the “cannot verify
the signature” warnings (as you found out!).


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

On Fri, 25 Mar 2011 11:08:00 -0400 (EDT)
xxxxx@bemac.com wrote:

Yes we use macrium reflect to reload the image, Hopefully its a clean
image :slight_smile: I will perform a few checks.

For situations like this I’ve found Rollback Rx
(http://www.rollbacksoftware.com/) to be a great solution - it only
takes a few seconds to take a snapshot, and about half a minute to
restore it.


Bruce Cran