Problems with installing a self-signed driver on some machines

Roman_Kudinov · August 26, 2015, 7:45am

Hi guys,

I have a virtual audio device driver (derived from a DDK samp). I have an Authenticode certificate from Comodo. I need to install VAD to Windows 7 x64.

I’ve made everything like described in docs. I’ve generated CAT file. I’ve signed the driver and CAT files using my Authenticode certificate and a cross-certificate. While there is no a cross-certificate for Comodo at this page https://msdn.microsoft.com/en-us/library/windows/hardware/dn170454(v=vs.85).aspx , but Comodo provides a certificate that uses AddTrust in the certification path. So I used that cross-certificate.

For the test purposes I use devcon to install the driver. While this works great on my developer PC and on the PC of our tester, but it doesn’t work at the PC of my chief. All of the machines are running Windows 7 Ultimate SP1 x64.

The first problem I encountered is that SetupDiCreateDeviceInfo fails with Access Denied. The user account has administrative privileges. I turned off UAC, but this didn’t help. The problem has gone when I set “Run as Administrator” flag for the devcon tool. While this is not a primary question but I wonder why it happens. Do I need to raise the privileges in the installer? If Yes, which privilege should I acquire?

The main question is that Windows doesn’t recognize the signature of the driver and doesn’t start the device. It is marked with a yellow exclamation sign in the Device Manger. The description of error says that the signature is wrong or absent.

But the same set of files can be successfully installed on my and tester’s PC’s. Are there any system policies that can prohibit installation of non-WHQL drivers?

Thanks in advance,
Roman

Roman_Kudinov · August 26, 2015, 7:50am

Do I need to install cross-certificate/Authenticode certificate at the end user PC? I know I can do this to avoid the security prompt during installation, but are then needed to run the driver?

Maxim_S_Shatskih · August 26, 2015, 11:15am

Look at setupapi.dev.log. Are you sure this is a cert issue?
Are you using 32bit devcon.exe? For 64bit OS, only use 64bit devcon.exe - SetupAPI is not correctly proxied by WOW64.
Is driver package install successful? bad cert should probably would fail driver package install and not SetupDiCreateDeviceInfo.
There is a Windows bug so that some optional Windows components (I think Services for UNIX or how they are called) break the PnP subsystem, after which no more drivers can be installed. The symptom of this: in setupapi.dev.log, you can see DrvInst.exe failure, and the exception code is 0xc00000xxx which is “DLL initialization failed”.

–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com

wrote in message news:xxxxx@ntdev…
> Hi guys,
>
> I have a virtual audio device driver (derived from a DDK samp). I have an Authenticode certificate from Comodo. I need to install VAD to Windows 7 x64.
>
> I’ve made everything like described in docs. I’ve generated CAT file. I’ve signed the driver and CAT files using my Authenticode certificate and a cross-certificate. While there is no a cross-certificate for Comodo at this page https://msdn.microsoft.com/en-us/library/windows/hardware/dn170454(v=vs.85).aspx , but Comodo provides a certificate that uses AddTrust in the certification path. So I used that cross-certificate.
>
> For the test purposes I use devcon to install the driver. While this works great on my developer PC and on the PC of our tester, but it doesn’t work at the PC of my chief. All of the machines are running Windows 7 Ultimate SP1 x64.
>
> The first problem I encountered is that SetupDiCreateDeviceInfo fails with Access Denied. The user account has administrative privileges. I turned off UAC, but this didn’t help. The problem has gone when I set “Run as Administrator” flag for the devcon tool. While this is not a primary question but I wonder why it happens. Do I need to raise the privileges in the installer? If Yes, which privilege should I acquire?
>
> The main question is that Windows doesn’t recognize the signature of the driver and doesn’t start the device. It is marked with a yellow exclamation sign in the Device Manger. The description of error says that the signature is wrong or absent.
>
> But the same set of files can be successfully installed on my and tester’s PC’s. Are there any system policies that can prohibit installation of non-WHQL drivers?
>
>
> Thanks in advance,
> Roman
>
>

Jan_Bottorff · August 26, 2015, 12:12pm

Not all Authenticode certificates can be used for driver signing, only ones that have a Microsoft cross certificate. As you say Microsoft does not have a cross cert for your brand of certificate, I’d guess you don’t own a certificate valid for kernel driver use, only user mode applications.

Jan

On 8/26/15, 4:44 AM, “xxxxx@lists.osr.com on behalf of xxxxx@rbcmail.ru” wrote:

>I’ve made everything like described in docs. I’ve generated CAT file. I’ve signed the driver and CAT files using my Authenticode certificate and a cross-certificate. While there is no a cross-certificate for Comodo at this page https://msdn.microsoft.com/en-us/library/windows/hardware/dn170454(v=vs.85).aspx , but Comodo provides a certificate that uses AddTrust in the certification path. So I used that cross-certificate.

Chris_Aseltine · August 26, 2015, 1:12pm

Maxim S. Shatskih wrote:

There is a Windows bug so that some optional Windows
components (I think Services for UNIX or how they are called)
break the PnP subsystem, after which no more drivers can be installed.

Uhh, there is?

Maxim_S_Shatskih · August 26, 2015, 1:17pm

>> 4) There is a Windows bug so that some optional Windows

> components (I think Services for UNIX or how they are called)
> break the PnP subsystem, after which no more drivers can be installed.

Uhh, there is?

In most recent version (i.e. Win10) - probably there is no more, though Win10 has its own huge pile of tiny irritating bugs.

But, in the field, in Windows versions used by customers - yes, “there is”, and not “there was”.

–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com

Tim_Roberts · August 26, 2015, 3:08pm

xxxxx@rbcmail.ru wrote:

I’ve made everything like described in docs. I’ve generated CAT file. I’ve signed the driver and CAT files using my Authenticode certificate and a cross-certificate. While there is no a cross-certificate for Comodo at this page https://msdn.microsoft.com/en-us/library/windows/hardware/dn170454(v=vs.85).aspx , but Comodo provides a certificate that uses AddTrust in the certification path. So I used that cross-certificate.

If there’s no Comodo cross-certificate, then you can’t use your
certificicate for kernel drivers. You can check whether you have done
it right by doing this:

signtool verify /v /kp xxxxx.cat

If the chain ends at the Microsoft Code Verification Root, then you are
fine. If not, then you have the wrong certificate.

The first problem I encountered is that SetupDiCreateDeviceInfo fails with Access Denied. The user account has administrative privileges. I turned off UAC, but this didn’t help. The problem has gone when I set “Run as Administrator” flag for the devcon tool. While this is not a primary question but I wonder why it happens. Do I need to raise the privileges in the installer? If Yes, which privilege should I acquire?

You need to get requestedExecutionLevel set to “requireAdministrator” in
your manifest file. You can do that in Visual Studio project settings,
if you are using the VS UI.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Gary_Stephany · August 27, 2015, 12:00pm

If you have purchased the correct cert type, it should work for Windows 7 64-bit. In the past when I have signed drivers with a Comodo certificate I have done it as such;

signtool sign /v /ac “addtrustexternalcaroot_kmod.crt” /s my /tr http://timestamp.comodoca.com/rfc3161 MyDriver.cat

You should see the following output (at least this is what I typically saw, hopefully it’s not too dated)
The following certificate was selected:
Issued to: My Company
Issued by: COMODO RSA Code Signing CA
Expires: My cert expiration

Cross certificate chain (using user store):
Issued to: Microsoft Code Verification Root
Issued by: Microsoft Code Verification Root
Expires: Sat Nov 01 07:54:03 2025
SHA1 hash: 8FBE4D070EF8AB1BCCAF2A9D5CCAE7282A2C66B3

Issued to: AddTrust External CA Root
Issued by: Microsoft Code Verification Root
Expires: Tue Aug 15 14:36:30 2023
SHA1 hash: A75AC657AA7A4CDFE5F9DE393E69EFCAB659D250

Issued to: COMODO RSA Certification Authority
Issued by: AddTrust External CA Root
Expires: Sat May 30 04:48:38 2020
SHA1 hash: F5AD0BCC1AD56CD150725B1C866C30AD92EF21B0

Issued to: COMODO RSA Code Signing CA
Issued by: COMODO RSA Certification Authority
Expires: Mon May 08 17:59:59 2028
SHA1 hash: B69E752BBE88B4458200A7C0F4F5B3CCE6F35B47

Issued to: My Company
Issued by: COMODO RSA Code Signing CA
Expires: My cert expiration

Note that (as Tim pointed out), the chain ends at Microsoft Code Verification Root. The correct cross cert can be found at;
https://support.comodo.com/index.php?/Default/Knowledgebase/Article/View/962/93/kmcs-addtrust-external-ca-root

Gary

Gary_Stephany · August 27, 2015, 12:08pm

>Do I need to install cross-certificate/Authenticode certificate at the end user
PC?

No, you should not need to under most circumstances.

Are there any system policies that can prohibit installation of non-WHQL
drivers?

Yes. IIRC, you will find discussions regarding this if you search the list archives.

Roman_Kudinov · August 27, 2015, 2:29pm

Thanks to everyone for the answers. I think I’ve found what is wrong. The problem PC didn’t have KB3033929 installed
https://technet.microsoft.com/en-us/library/security/3033929
I don’t have the control over that PC, so the next test will be done tomorrow once the PC is updated.

Meanwhile while I’m awaiting for the PC here are the answers to the concerns:

I’m using 64bit devcon for 64bit OS and 32bit devcon for 32bit OS
The certificate should be fine because it works great on some machines and doesn’t work on at least one another. I believe that if there was a problem with a certificate then it wouldn’t work at neither machines. Moreover Installation passes fine (it shouldn’t happen if the certificate is bad), the driver files are copied, but the device cannot be loaded.

Here is the output of signtool verify command:

----------------------------- CUT ---------------------------------------
Verifying: drv\mp4recordervad.cat
Signature Index: 0 (Primary Signature)
Hash of file (sha1): C6B8D957B41D608AEBE1056B5FD404A00436B6B8

Signing Certificate Chain:
Issued to: COMODO RSA Certification Authority
Issued by: COMODO RSA Certification Authority
Expires: Tue Jan 19 02:59:59 2038
SHA1 hash: AFE5D244A8D1194230FF479FE2F897BBCD7A8CB4

Issued to: COMODO RSA Code Signing CA
Issued by: COMODO RSA Certification Authority
Expires: Tue May 09 02:59:59 2028
SHA1 hash: B69E752BBE88B4458200A7C0F4F5B3CCE6F35B47

Issued to: Digital Samba SL
Issued by: COMODO RSA Code Signing CA
Expires: Thu Nov 28 02:59:59 2019
SHA1 hash: 360760935631D2D12A5588E0A773392CF0548D58

The signature is timestamped: Thu Aug 27 16:31:22 2015
Timestamp Verified by:
Issued to: UTN-USERFirst-Object
Issued by: UTN-USERFirst-Object
Expires: Tue Jul 09 21:40:36 2019
SHA1 hash: E12DFB4B41D7D9C32B30514BAC1D81D8385E2D46

Issued to: COMODO Time Stamping Signer
Issued by: UTN-USERFirst-Object
Expires: Fri Jan 01 02:59:59 2016
SHA1 hash: DF946A5E503015777FD22F46B5624ECD27BEE376

Cross Certificate Chain:
Issued to: Microsoft Code Verification Root
Issued by: Microsoft Code Verification Root
Expires: Sat Nov 01 16:54:03 2025
SHA1 hash: 8FBE4D070EF8AB1BCCAF2A9D5CCAE7282A2C66B3

Issued to: COMODO RSA Certification Authority
Issued by: Microsoft Code Verification Root
Expires: Mon Apr 12 01:16:20 2021
SHA1 hash: 106870659C069F248C8C0A05ACD871CABEB3CC38

Issued to: COMODO RSA Code Signing CA
Issued by: COMODO RSA Certification Authority
Expires: Tue May 09 02:59:59 2028
SHA1 hash: B69E752BBE88B4458200A7C0F4F5B3CCE6F35B47

Issued to: Digital Samba SL
Issued by: COMODO RSA Code Signing CA
Expires: Thu Nov 28 02:59:59 2019
SHA1 hash: 360760935631D2D12A5588E0A773392CF0548D58

Successfully verified: drv\mp4recordervad.cat

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

setupapi.dev.log on my PC and the problem PC differs, while in both cases there are warnings about the invalid signature

sig: {_VERIFY_FILE_SIGNATURE} 21:19:11.840
sig: Key = mp4recordervad.inf
sig: FilePath = drv\mp4recordervad.inf
sig: Catalog = drv\mp4recordervad.cat
! sig: Verifying file against specific (valid) catalog failed! (0x800b0109)
! sig: Error 0x800b0109: A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider.
sig: {_VERIFY_FILE_SIGNATURE exit(0x800b0109)} 21:19:11.889
sig: {_VERIFY_FILE_SIGNATURE} 21:19:11.892
sig: Key = mp4recordervad.inf
sig: FilePath = drv\mp4recordervad.inf
sig: Catalog = drv\mp4recordervad.cat
sig: Success: File is signed in Authenticode™ catalog.
sig: Error 0xe0000242: The publisher of an Authenticode™ signed catalog has not yet been established as trusted.
sig: {_VERIFY_FILE_SIGNATURE exit(0xe0000242)} 21:19:11.919

I want to outline such entries exist on my PC as well while installation passes fine and the device works. The difference is at the following section:
dvi: {DIF_INSTALLDEVICE} 21:19:20.019
…
dvi: {Restarting Devices} 21:19:20.215
dvi: Restart: ROOT\MEDIA\0000
dvi: Restart complete.
…
dvi: {DIF_INSTALLDEVICE - exit(0x00000000)} 21:19:20.250

On the problem PC there is one more line after “Restart complete”. Something like: “Failed to start the device, error XX, invalid signature”

Roman_Kudinov · September 3, 2015, 8:31am

Yes, definitely the problem appeared because KB3033929 wasn’t installed. Thanks to everyone for the help