Bus driver certificate relation qn

NTDEV
1

we have two drivers, one is a volume filter and another a driver that
attaches to the toor bus and creates a PDO and several FDOs.

we sign both these drivers with the same verisign issues SHA1 certificate.

when we try to install these drivers, the volume filter is installed
without any prompts, but the bus driver complains taht the cert used is not
trusted, and whether we want to add the same to the trusted certs list.

this happens on win8.1 rtm build. yes we understand that win8.1 needs
sha256 certs, but it also does support sha1 and we plan to apply for whql
signatures later on in teh release cycle as it is.

but the real qn for me is is there a difference between the cert
requirements for volume filters vs rott bus based drivers? if so, what kind
of cert do we request verisign to issues us to resolve this problem?

B

2

Nope.

If you have a Verisign Class 3 Code Signing Cert that you’re using to sign those drivers, and you’re signing the driver *and* the driver package correctly and with the correct cross-certs, you should be good to go.

There aren’t different types/class of certificates for signing different types of drivers.

Peter
OSR

3

Peter,

Thank you for confirming this. It is indeed a verisign class 3 cert.

Here is the signtool command we use to sign the cat file

cmd = ‘cmd /c “signToolPath sign /v /ac crossCert /s certStore /n certName
/t timeServer targetFile”’

where:

signToolPath = the path of where signtool.exe is located.

timeServer = ‘http://timestamp.verisign.com/scripts/timestamp.dll’
targetFile = the path for the catalog file.

certStore = ‘my’
certName = My Company Name
crossCert = full path for the verisign class 3 certificate file

before signing the cat file we create it and it contains 3 hashes, teh
.sys, the inf and the wdfcoinst.dll as it is a KMDF based root bus extender.

this produces a properly signed package. I have one observation though:

the signed cat file can be double clicked and opened and we can view the
cert inside it and trace it to the root.
One can also right click on the cat file go to properties and select
Digital Signatures to view a cert. Now, for some strange reason, this cert
is different from the cert seen when I open the cat file. And this cert is
*not* a valid one.

Questions:

  1. Is it always like this? the cat file will have an embeded cert as well
    as one which can be seen by navigating through properties->Digital
    Signatures?
  2. In the case of the working volume driver, I see both methods described
    as above yield the same valid cert.
  3. Where did this other cert get from? For signing the only code we use is
    pasted above.
  4. Both drivers get the same cert in the variable CrossCert and are built
    in the same build machine.

what are we doing wrong?

On Tue, Dec 3, 2013 at 8:09 PM, wrote:

>


>
> Nope.
>
> If you have a Verisign Class 3 Code Signing Cert that you’re using to sign
> those drivers, and you’re signing the driver and the driver package
> correctly and with the correct cross-certs, you should be good to go.
>
> There aren’t different types/class of certificates for signing different
> types of drivers.
>
> Peter
> OSR
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> 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
>