>>
I get no errors when signing the cat or sys files, and the signatures verify fine with the signtool. I have loaded the certs in trusted root store, but not the trusted publisher store – I will try that next.
<<
This is a bit abstracted, but it should help understanding this process.
Silent installation of the driver requires a trusted publisher. That is why the KMCS document says to put the certificate there. Even if the root for your certificate says you can be trusted we will still verify each time someone who is not a trusted publisher tries to put something on a machine.
You have to put it in root, because even if you’re a “trusted publisher” we can’t be sure it’s really you if the certificate chain ends in an unknown [hence untrusted] root. A self-signed cert has no chain, so it has to be both places. (BTW [I could be wrong about this part- the rest I am quite sure of] this bit about adding to root may only work when test signing mode is enabled).
>
Windows Vista solves these problems by allowing vendors and IT departments to sign and publish drivers by using an Authenticode signature. IT departments can configure Windows to treat drivers that they signed as equivalent to drivers that were signed by Microsoft, thus allowing an IT department to silently deploy drivers across their corporation, even updating in-box drivers. Vendors can quickly deploy emergency fixes to their customers without waiting for a signature from Microsoft. Meanwhile, because these drivers are signed, IT departments and end users can be secure, knowing that the drivers have not been altered in any way since they were published. Further, users know the source of the drivers because the signature also identifies the publisher.
These third-party signatures complement the signatures that Windows Hardware Quality Labs (WHQL) gives. The third-party signatures guarantee driver integrity, but do not imply any level of testing or quality. The signatures that are given as part of the Windows Logo Program not only verify driver integrity, but also indicate a level of quality that is based on tests run by WHQL.
<<
Yes, this is how it is supposed to be. To address another issue mentioned a couple of times here, let’s be clear.
You start out untrusted. WHQL starts out trusted (call it an “inbox certificate”). So as far as this silent install thing goes- yes, THE VERY FIRST TIME we see something from you, they’ll get a popup asking if you can be trusted (or you need an install procedure that installs your certificate appropriately, and that action will also require their approval, so the first one is never free without WHQL).
But if you’ve got a proper cross-certified certificate and they elect to make you a trusted publisher, then you chain to that “inbox” stuff, and we will trust you from henceforth- so all future drivers from you [not just that one] will install silently.
I know this works- I use a multiport serial card with Authenticode (not WHQL) signed drivers on the X64 machine I’m writing this from, and if I mark the checkbox saying to trust all future content from them when I install the main driver, it silently installs all the ports after the adapter’s driver starts. If I don’t, then I get asked again to verify trust for each of the ports as it gets enumerated.
>
Also did not work. Looking at references from MS (from above) I should be able to do this:
<<
Yes you should- the people providing my multiport serial card could, and as I said before, I’ve been doing it myself (in the self-signed test form) for a really long time now.
There are also aids provided to help you and I diagnose problems when they arise.
One of those is the setupapi logs I mentioned before, which, beginning with Vista, provide a lot more detail about what is going on when things like this break. What does that log say is wrong? You seem to be focused on the mechanics of the certificate, but it’s not clear from the information presented so far, that this is what the problem actually is here.