we developed a driver and signed the cat and sys file with our company's Verisign signature (SHA1 + SHA256, including certificate chain). We tested it under Windows 7 and 10 both 32 and 64 bit versions. Now we have some random customers that report that our device is not recognized correctly in device manager and that error 52 shows up:
Windows cannot verify the digital signature for the drivers required for this device. A recent hardware or software change might have installed a file that is signed incorrectly or damaged, or that might be malicious software from an unknown source. (Code 52)
Setupapi.dev.log shows this error:
_!!! dvi: Device not started: Device has problem: 0x34 (CM_PROB_UNSIGNED_DRIVER), problem status: 0xc0000428
But this message in Setupapi.dev.log is also present at working installations.
Sign tool shows that the signature is valid, same does the properties page on windows explorer.
What is the reason for this behavior?
Potential solutions to this were not dual signing the cat file and checking the root certs of the customer's pcs. I also learned that the error message in setupapi.dev.log is perfectly normal
After some research with a lot of apparently contradictory Microsoft documentation I finally landed at https://docs.microsoft.com/windows-hardware/drivers/install/kernel-mode-code-signing-policy--windows-vista-and-later- where it says:
And it turned out that Secure Boot was enabled on none of our testing machines, but exactly on the customer machines that had the problem.
Now we have to perform a WHQL certification with the driver. Fortunately there are companies which offer this as a service, so we don't have to maintain a certification machine pool.