Windows driver signed using Vista and later methods installs just fine in XP, but it shouldn't?

Question

My company makes a measurement device that connects to the PC via USB and used to use the Windows in-box USB HID driver. I'm using a different driver now to control the device and I am in the process of signing these drivers for many Windows versions. The reason being we want our customers to be able to install our measurement software (which would pre-install these new drivers), plug in our measurement device, and have Windows trust and use our new driver in favor of the in-box USB HID driver. It would also have the added benefit of using this new driver each time the device is connected no matter what USB port is used or if the user connects a unit that has a different serial number in the descriptor.

I've read through and performed the steps outlined in the KMCS_Walkthrough written by Microsoft to perform Test Signing of this driver by creating a catalog file for Windows 7 x64 from the inf file and signing the catalog file with a self-signed certificate. Things seemed to work smoothly on a Windows 7 x64 machine when rebooted into Test Mode. What surprised me was that I was able to create an XP_x86 catalog file, sign it with my test certificate, import my test certificate into the Trusted Root store and get the driver behavior I wanted on a Windows XP machine. The default driver signing policy was set to the default (Warn - Prompt me each time to choose an action).

I'm surprised because all of the MSDN documentation I have been reading about signing drivers for public release for XP seems to have a strict stance on the drivers being WHQL certified in order for the drivers to be fully trusted as opposed to obtaining a code-signing certificate from a third party and using that to sign the driver. Is this not true? How could my self-signed drivers out-rank the in-box USB HID driver in Windows XP?

Answer 1

I think your experience is normal.

At my company, we have distributed USB drivers to Windows XP users and we never had to sign them to get them installed. We later starting signing them ourselves, but that did not really affect the Windows XP user experience.

Our drivers were usually INF-only or they used WinUSB, so that might be different from you if you are compiling binary drivers.

Without a WHQL signature, Windows XP users can still install your driver package as long at they click through this warning:

After the driver package is installed, in my experience there is nothing that prevents the kernel modules it contains from being loaded into the kernel. However, our users always had to go through the "Found New Hardware Wizard" whenever plugging a new device into their computer for the first time.

Perhaps your driver outranks the HID driver because you picked a more specific identifier string (i.e. one with a vendor ID and product ID in it).

For more information I recommend reading my article: Practical Windows Code and Driver Signing.

Answer 2

After A LOT more trial, error, and research, I've finally come to a conclusion.

The key in my initial question was that I was using a self-signed certificate. I generated the self-signed certificate in Windows using makcert and following the example in the KMCS_Walkthrough:

makecert -r -pe -ss PrivateStore -n CN=CompanyName MyCertificate.cer

The parameter which specifies what Enhanced Key Usages (EKUs) the certificate should be valid for (-eku) is not included. What I didn't know was that with this parameter missing, this creates a self-signed certificate with ALL EKUs. Most notably the EKU called "Windows System Component Verification (1.3.6.1.4.1.311.10.3.6)". This EKU is included in certificates for WHQL signing.

So, in fact, Windows XP was behaving appropriately. My driver was indeed WHQL signed, it was just a self-signed WHQL certificate that was used.