Tech Support > Microsoft Windows > Drivers > Software Publishing Certificate Certificate Authority
Software Publishing Certificate Certificate Authority
Posted by engrkurt on May 31st, 2007



You document KMCS_Walkthrough.doc says to purchase a “Software Publisher
Certificate from a commercial CA.” And “For a list of SPC CAs, see
“Resources” at the end of this paper.” There is no list of CAs in the
Resources at the end of the paper.

Later on your document says to go to
http://www.microsoft.com/whdc/winlog...crosscert.mspx
“This Web page includes:
• A list of Root Authority cross-certificates.
• A list of CAs that provide SPCs for kernel-mode code signing.”
But again there is no list of CAs, but I will assume that the companies in
the Cross-Certificate List are included in the CA list. I then picked
VeriSign to investigate purchasing a “Software Publisher Certificate”. But I
cannot find this certificate available from this source. Why is this so hard?
Please, tell me specifically what “certificate” or whatever to purchase in
order to sign kernel mode drivers. On one of the examples in the document it
says, “Issued by: VeriSign Class 3 Code Signing”. So I went to VeriSign but
the only information I could find says that this is for object signing for
Internet Explorer, etc. Why is this so hard? Does VeriSign sell what I need
or do I have to look elsewhere? Where should I look and what should I buy?
The only mention of Digital Signing and Microsoft talks about Microsoft
Authenticode to sign .exe, .cab, .dll, and .ocx. But, I want to sign a
kernel mode driver. Is this the certificate or is there some other
certificate? Why is this so hard?

Also is there an updated document and web page that has correct information?

Posted by Dcls on June 1st, 2007


"Why is this so hard?" I think that is a very good question!

A general question: how does the Windows Logo Program cost for a driver?

Thank you.



"engrkurt" wrote:

Posted by engrkurt on June 1st, 2007


realized this post may sound strange out of context. this is a copy of an
e-mail that I sent to signsup@microsoft.com after reading the document
KMCS_Walkthrough.doc - Kernel-Mode Code Signing Walkthrough. The automated
reply sent me to this newsgroup.

All I want to do is sign my drivers so Windows quits displaying those
annoying message to my customers. How do I do that?

"engrkurt" wrote:

Posted by usfinecats on June 1st, 2007


I use a verisign certificate for my driver, actually you end up signing a
..Cat file. You think this is hard, try figuring out how to get a File system
filter driver installed from within an MSI package . I've been fiddling with
this issue for well over a year.... But I digress.... So once you get the
cat file signed on some machines and at different times on the same machine
(both Xp and on vista) I still get the nasty messages, on others no
sweat....

We of little minds just can not fathom all the issues that Msft has created
around this mess
--
Gak -
Finecats


"engrkurt" wrote:

Posted by Tim Roberts on June 3rd, 2007


engrkurt <engrkurt@discussions.microsoft.com> wrote:

You submit your driver to WHQL, once you have followed all the rules, and
pay the required fee. Assuming your driver passes the WHQL testing, they
will return a signed .cat file that you may use to eliminate the warning.

Note, however, that the .cat file signature only applies to a single
version of the binary. If you change the driver, you need to resubmit, and
pay again.

http://www.microsoft.com/whdc/winlogo/
--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

Posted by engrkurt on June 5th, 2007


what i understand WHQL is not necessary - appears to be necessary to be part
of updates, etc. my drivers are from another era and most certainly will not
pass WHQL. but my users still complain. from what i understand i can get
them signed without the testing which is just fine for me. unfortunately no
one seems to want to explain how this is done...

"Tim Roberts" wrote:

Posted by Ian Blake on June 6th, 2007


On Thu, 31 May 2007 13:20:01 -0700, engrkurt
<engrkurt@discussions.microsoft.com> wrote:

Yes

It is that one.

Microsoft's information on how to sign seems straight forward enough.
The problem as you have noticed is identifying the 3rd party
terminology and products used by the Certificate Authorities(CA). They
do not speak Microsoft and definitely not Driver.

I can not comment on Verisign, I compared prices and chose Globalsign.
Cheaper and the only CA, I found, who even mentioned driver signing.
We ordered on the web. This installed an enrolment certificate on the
machine doing the ordering (not mine). We needed to send some company
documents to confirm our existance and trust. When they had these they
e-mailed me the certificate in PEM format. A web link was clicked
that took me to an installation page. This failed. I then went to
the machine that did the ordering then exported the enrolment
certificate and imported to my local machines certificate store. Tried
the web link again and the certificate installed. I downloaded the
cross certificate for Globalsign Objectsign from Microsoft. I can now
sign according to the help in the WDK using signtool and signability.

Note this will not give you the green tick in XP but will allow you to
install your 64bit drivers on Vista 64 bit versions.
You should also sign your user apps and dlls with it. You get a less
angry message from Vista UAC if they need admin mode.

Posted by Tim Roberts on June 7th, 2007


engrkurt <engrkurt@discussions.microsoft.com> wrote:
No, your understanding is wrong. The WHQL signature is the key to turning
off the "unsigned driver" warning.

There are two reasons to sign your drivers, and three different ways to do
it. The first reason to sign is Vista 64. An unsigned driver will not be
allowed to load at all on Vista 64, even if you are able to get it
installed (unless you have a kernel debugger attached; most users don't).
The 32-bit systems don't care about this.

You can satisfy this requirement by signing your drivers yourself, using a
Verisign code-signing certificate with Microsoft's cross-certificate. That
will allow your driver will be allowed to load on x64. You can also
satisfy this with a certificate of your own creation, if you add the
certificate to the certificate store on the test machine and turn on
/testsign mode. Both of these procedures are describes in the
KMCS_Walkthrough.doc that you referenced.

The second reason to sign is the dreaded "caution, you are about to install
an unsigned driver, it will probably explode and kill your family" warning.
Neither of the above steps will eliminate that. The only way is to get a
WHQL signature.
--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.


Similar Posts