> http://www.microsoft.com/whdc/driver/install/drvsign/kmcs-walkthrough.mspx
Read this, understand it, experiment, read again, experiment more, read
up on PK, certificates and certificate chains, experiment more.
This will take a few days, but is necessary and well worth the effort.
Make sure you ask your certificate provide if it does support kernel
mode signing.
The “Class-3 Code Signing” certificates itself are not the problem.
But you need to make sure Microsoft offers a cross certificate for your
provider’s CA for the driver-embedded signatures.
(Signatures embedded in the driver SYS file are *required* for boot-time
kernel drivers like HDD drivers. But I’m not completely sure you need
them for non-DRM PnP drivers like for a simple BulkUSB-derived one.
We add one anyway, because this allows users to perform a very simple
integrity check on the driver binary: cert valid -> binary OK.)
Other pitfalls:
(1) On the PC you use for signing, you can’t install-test if a signature
was embedded correctly.
Because all necessary certificates will also be in the PC registry,
Windows always finds a correct path to a “trusted root” certificate.
=> You need to test your signed drivers on a “clean” test machine.
(2) You need to ensure you get your embedded signature certificate chain
*complete*. On Win7/x64, *if* there is a certificate embedded in a SYS
file, not only this itself must be valid, but also the complete chain to
the “MS Code Certification Root” must be embedded.
One example where this can fail:
With our cert provider WDK’s signtool.exe used the “newer” (longer
valid) root certificate of two provided ones. It would normally be a
good idea to use the longest-valid and newest cert you can find.
However, the chosen cert was not valid for the Microsoft cross
certificate from our provider to the “MS Code Certification Root”.
Win7/64bit happily *installed* the driver, but it did not work. In
device manager a little triangle with an exclamation mark in was shown
next to the driver symbol. Driver properties stated than “no chain to a
trusted root” could be found.
The temporary solution was to manually remove the newer (=longer valid)
root certificate (and one intermediate cert) of the CA we use. Then the
(correct) older one was used for signing the driver binary, and then
signtool.exe also included the cross-certificate. Win7/64bit was happy.
(Using the older cert was not a problem because we also time-stamp SYS
and CAT files. When you sign and timestamp in 2010, it does not matter
if the CA’s cert is valid until 2014 or 2028.)
The final solution will be a new, matching, Microsoft cross cert issued
to the provider’s CA [hopefully within the next three years :-)].
