Driver signing works for some machines only

Question

I developed a kernel-mode driver and signed it with a "standard" code signed certificate because at this time I do not know about Win 10 driver signing.

I tested the driver on many systems from Win7 up to different Win10 machines (real machines and VMs too). The curious thing is: the driver works well on every test setup.

Now, I got some reports that the driver doesn't work on some Win10 machines due to a singning problem.

I tried to install the driver on my own machine and discovered the same problem: Installation using dpinst works without problems. But the Device Manager shows

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)

Verifying the driver using signtool for kernel mode divers states:

> .\signtool.exe verify /kp driver.cat
File: C:\Users\...\driver.cat
Signature Index: 0 (Primary Signature)
Hash of file (sha1): 1CF4B984575F15AC0A2CAF3C3B138F8B58867E35

Signing Certificate Chain:
    Issued to: VeriSign Class 3 Public Primary Certification Authority - G5
    Issued by: VeriSign Class 3 Public Primary Certification Authority - G5
    Expires:   Thu Jul 17 01:59:59 2036
    SHA1 hash: 4EB6D578499B1CCF5F581EAD56BE3D9B6744A5E5

        Issued to: Symantec Class 3 SHA256 Code Signing CA
        Issued by: VeriSign Class 3 Public Primary Certification Authority - G5
        Expires:   Sun Dec 10 01:59:59 2023
        SHA1 hash: 007790F6561DAD89B0BCD85585762495E358F8A5

            Issued to: #############
            Issued by: Symantec Class 3 SHA256 Code Signing CA
            Expires:   Tue Mar 21 01:59:59 2023
            SHA1 hash: C0AF3235EF9FAABE789A306C4AC9F20E80DE7BDB

The signature is timestamped: Wed Apr 27 09:56:50 2022
Timestamp Verified by:
    Issued to: DigiCert Trusted Root G4
    Issued by: DigiCert Trusted Root G4
    Expires:   Fri Jan 15 14:00:00 2038
    SHA1 hash: DDFB16CD4931C973A2037D3FC83A4D7D775D05E4

        Issued to: DigiCert Trusted G4 RSA4096 SHA256 TimeStamping CA
        Issued by: DigiCert Trusted Root G4
        Expires:   Mon Mar 23 01:59:59 2037
        SHA1 hash: B6C8AF834D4E53B673C76872AA8C950C7C54DF5F

            Issued to: DigiCert Timestamp 2022 - 2
            Issued by: DigiCert Trusted G4 RSA4096 SHA256 TimeStamping CA
            Expires:   Tue Mar 15 01:59:59 2033
            SHA1 hash: 8508F386515CB3D3077DB6B4B7C07F1B4A5E41DE

SignTool Error: The signing certificate is not valid for the requested usage.

Number of files successfully Verified: 0
Number of warnings: 0
Number of errors: 1

If I'm right, I need a EV code signing certificate to sign the driver for Win10? If yes, the result of the verification using signtool is not unexpected.

Nevertheless - I'm confused because I can install and run the driver on serveral Win10 test machines without any problem. It seems that there is no difference if the system is up-to-date or not. There are x86 and x64 systems, Home and Pro versions, activated and not-activated setups. On almost all devices the driver still works very well.

That means it is not really necessary to use a "specific" certificate or messed I something up?

Answer 1

The different behaviour of the test setup is caused by Secure Boot. If this is enabled, the driver will be rejected.