Problem signing kernel mode driver with a GlobalSign issued certificate

Hello,

I have posted regarding this issue on another fairly recent thread:

http://www.osronline.com/showThread.cfm?link=244849

At that point I was trying to install my filter driver, which is a modification of the toaster sample’s generic filter driver and installs as an upper level filter Image class filter driver, like this:

sc create wlfilter type= kernel start= demand binPath= system32\drivers\filter.sys

devcon classfilter image upper =-wlfilter

upon installation I would get an “unsigned driver” type of popup and the filter driver would show up as unsigned in the drivers listing of my camera. See below for the specific dialogs:

http://fotios.org/files/unsigned_popup.png

http://fotios.org/files/drivers.png

An additional problem was that due to the fact that I was not using an inf file for the installation (and therefore embedding the signature in the sys file instead of generating and signing a cat file) I was not getting any log entries in my setupapi log file (under C:'windows\inf) and therefore debugging was difficult (not sure if the installation process gets logged elsewhere when an inf file is not used).

I am installing this on a Win8 x64 box.

So, what I did is I created an inf file for my filter driver and looking into my setupapi log after installation I found out what the problem probably is (see further down for full inf file listing):

! 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.

This sounds like a good hint yet after looking into it carefully I am fairly certain that my driver is properly signed. Here is the signtool verification output:


C:\dc>signtool verify /kp /v filter.cat

Verifying: filter.cat
Hash of file (sha1): E19281C77C94F8A266D767574652D570874762D4

Signing Certificate Chain:
Issued to: GlobalSign Root CA
Issued by: GlobalSign Root CA
Expires: Tue Jan 28 14:00:00 2014
SHA1 hash: 2F173F7DE99667AFA57AF80AA2D1B12FAC830338

Issued to: GlobalSign CodeSigning CA - G2
Issued by: GlobalSign Root CA
Expires: Sat Apr 13 12:00:00 2019
SHA1 hash: 9000401777DD2B43393D7B594D2FF4CBA4516B38

Issued to: xxxxxx Software Limited
Issued by: GlobalSign CodeSigning CA - G2
Expires: Fri Jun 17 17:39:54 2016
SHA1 hash: 550E6D812F3310EA64F5F4B35EFF747DAC590EC4

The signature is timestamped: Sat Sep 21 08:15:33 2013
Timestamp Verified by:
Issued to: GlobalSign Root CA
Issued by: GlobalSign Root CA
Expires: Tue Jan 28 14:00:00 2014
SHA1 hash: 2F173F7DE99667AFA57AF80AA2D1B12FAC830338

Issued to: GlobalSign Timestamping CA - G2
Issued by: GlobalSign Root CA
Expires: Fri Jan 28 14:00:00 2028
SHA1 hash: C0E49D2D7D90A5CD427F02D9125694D5D6EC5B71

Issued to: GlobalSign TSA for MS Authenticode - G1
Issued by: GlobalSign Timestamping CA - G2
Expires: Mon Sep 23 02:00:00 2024
SHA1 hash: 8CE69F5012E1D1A8FB395E2E31E2B42BDE3B343B

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

Issued to: GlobalSign Root CA
Issued by: Microsoft Code Verification Root
Expires: Thu Apr 15 22:05:08 2021
SHA1 hash: CC1DEEBF6D55C2C9061BA16F10A0BFA6979A4A32

Issued to: GlobalSign CodeSigning CA - G2
Issued by: GlobalSign Root CA
Expires: Sat Apr 13 12:00:00 2019
SHA1 hash: 9000401777DD2B43393D7B594D2FF4CBA4516B38

Issued to: xxxxxx Software Limited
Issued by: GlobalSign CodeSigning CA - G2
Expires: Fri Jun 17 17:39:54 2016
SHA1 hash: 550E6D812F3310EA64F5F4B35EFF747DAC590EC4

Successfully verified: filter.cat

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

This looks like it should work - yet it does not. Besides my Win8 x64 box I also tried it on WinXP x32 and there, after getting the “This driver has not been tested for Windows logo” alert dialog, the filter still shows up as unsigned in the camera’s drivers list.

So, I am pretty much without a hint really as to why this driver won’t install as signed.

Please see below for full inf file and setupapi log listings. I would IMMENSELY appreciate any hints as to what is going on.

Could it somehow be related to a problem with my GlobalSign certificate? My certificate is active and I have confirmed with GlobalSign that it is capable of kernel mode code signing.

Cheers,
A


;/*++
;
;Copyright (c) 2013 xxxxxx Software Limited All rights Reserved
;
;Module Name:
;
; filter.INF
;
;Abstract:
; INF file for installing the Image class upper filter driver
;
;–*/

[Version]
Signature = “$WINDOWS NT$”
Class = Image
ClassGuid = {6bdd1fc6-810f-11d0-bec7-08002be2092f}
Provider = %xxxxxx%
DriverVer=09/20/2013,23.35.13.149
CatalogFile = filter.cat

;*****************************************
; xxxxxx Filter Install Section
;*****************************************

[Manufacturer]
%xxxxxx%=Microsoft,NTamd64

[DestinationDirs]
DefaultDestDir = 12

; For XP and later
[Microsoft.NTamd64]
%wcsFilter.DeviceDesc%=xxxxxxFilter, {6bdd1fc6-810f-11d0-bec7-08002be2092f}\wcsFilter

[xxxxxxFilter.NT]
CopyFiles=xxxxxxFilter.NT.Copy

[xxxxxxFilter.NT.Copy]
filter.sys

[xxxxxxFilter.NT.HW]
AddReg = xxxxxxFilter.NT.HW.AddReg

[xxxxxxFilter.NT.HW.AddReg]
HKLM, System\CurrentControlSet\Control\Class{6bdd1fc6-810f-11d0-bec7-08002be2092f}, UpperFilters, 0x00010008, “wcsFilter”
;HKR,“UpperFilters”,0x00010008,“wcsFilter”
;HKR,“UpperFilters”,0x00010000,“wcsFilter”

[xxxxxxFilter.NT.HW.DelReg]
HKLM, System\CurrentControlSet\Control\Class{6bdd1fc6-810f-11d0-bec7-08002be2092f}, UpperFilters, 0x00018002, “wcsFilter”

;*****************************************
; xxxxxx Filter Service Section
;*****************************************

[xxxxxxFilter.NT.Services]
;Do not specify SPSVCINST_ASSOCSERVICE on filter drivers.
AddService = wcsFilter, filter_Service_Inst

[filter_Service_Inst]
DisplayName = %wcsFilter.SvcDesc%
ServiceType = 1 ; SERVICE_KERNEL_DRIVER
StartType = 3 ; SERVICE_DEMAND_START
ErrorControl = 1 ; SERVICE_ERROR_NORMAL
ServiceBinary = %12%\filter.sys

;*****************************************
; Default Installation/Uninstallation
;*****************************************

[DefaultInstall]
OptionDesc = %DefaultInstallationDesc%
CopyFiles = xxxxxxFilter.NT.Copy
AddReg = xxxxxxFilter.NT.HW.AddReg

[DefaultUninstall]
OptionDesc = %DefaultUninstallationDesc%
DelFiles = xxxxxxFilter.NT.Copy
DelReg = xxxxxxFilter.NT.HW.DelReg

[DefaultInstall.Services]
AddService = wcsFilter, filter_Service_Inst

[DefaultUninstall.Services]
DelService = wcsFilter,0x200 ;0x200 flag ensures service is stopped before deleting

;*************************
; Source file information
;*************************

[SourceDisksNames]
1 = %DiskId1%,“”

[SourceDisksFiles]
filter.sys = 1,

;
;— xxxxxx Filter Coinstaller installation ------
;
[DestinationDirs]
;ImageClassInstallerCopyFiles = 11
xxxxxxFilter_CoInstaller_CopyFiles = 11

[xxxxxxFilter.NT.CoInstallers]
AddReg = xxxxxxFilter_CoInstaller_AddReg
CopyFiles = xxxxxxFilter_CoInstaller_CopyFiles

[xxxxxxFilter_CoInstaller_AddReg]
HKR,CoInstallers32,0x00010000, “WdfCoInstaller01011.dll,WdfCoInstaller”
;HKLM, System\CurrentControlSet\Control\Class{6bdd1fc6-810f-11d0-bec7-08002be2092f}, CoInstallers32, 0x00010000, “WdfCoInstaller$KMDFCOINSTALLERVERSION$.dll,WdfCoInstaller”

[xxxxxxFilter_CoInstaller_CopyFiles]
WdfCoInstaller01011.dll

[SourceDisksFiles]
WdfCoInstaller01011.dll=1 ; make sure the number matches with SourceDisksNames

[xxxxxxFilter.NT.Wdf]
KmdfService = wcsFilter, Filter_wdfsect

[Filter_wdfsect]
KmdfLibraryVersion = 1.11

[wdffeatured_wdfsect]
KmdfLibraryVersion = 1.11

[Strings]
SPSVCINST_ASSOCSERVICE = 0x00000002
xxxxxx = “xxxxxx Software Limited”
;Mfr = “xxxxxx”
ClassName = “Image”
DiskId1 = “xxxxxx Upper Level Image Class Filter Installation Disk #1
wcsFilter.DeviceDesc = “xxxxxx Upper Level Image Class Filter Driver”
wcsFilter.SvcDesc = “xxxxxx Upper Level Image Class Filter Driver Service”
DefaultInstallationDesc = “Install xxxxxx Filter Driver”
DefaultUninstallationDesc = “Uninstall xxxxxx Filter Driver”


>> [Device Install (DiInstallDriver) - D:\DRIVER\signed-no-timestamp\filter.inf]
>> Section start 2013/09/21 01:22:51.209
cmd: “C:\Windows\System32\InfDefaultInstall.exe” “D:\DRIVER\signed-no-timestamp\filter.inf”
inf: {SetupCopyOEMInf: D:\DRIVER\signed-no-timestamp\filter.inf} 01:22:51.303
sto: {Import Driver Package: D:\DRIVER\signed-no-timestamp\filter.inf} 01:22:51.691
sto: Driver Store = C:\Windows\System32\DriverStore [Online] (6.2.9200)
sto: Driver Package = D:\DRIVER\signed-no-timestamp\filter.inf
sto: Architecture = amd64
sto: Flags = 0x00000000
inf: Provider = xxxxxx Software Limited
inf: Class GUID = {6bdd1fc6-810f-11d0-bec7-08002be2092f}
inf: Driver Version = 09/20/2013,23.35.13.149
inf: Catalog File = filter.cat
inf: Version Flags = 0x00000001
flq: Copying ‘D:\DRIVER\signed-no-timestamp\filter.sys’ to ‘C:\Users\Fotios\AppData\Local\Temp{3ba54231-88f5-5b48-91c0-8233bc0de77c}\filter.sys’.
flq: Copying ‘D:\DRIVER\signed-no-timestamp\WdfCoInstaller01011.dll’ to ‘C:\Users\Fotios\AppData\Local\Temp{3ba54231-88f5-5b48-91c0-8233bc0de77c}\WdfCoInstaller01011.dll’.
flq: Copying ‘D:\DRIVER\signed-no-timestamp\filter.cat’ to ‘C:\Users\Fotios\AppData\Local\Temp{3ba54231-88f5-5b48-91c0-8233bc0de77c}\filter.cat’.
flq: Copying ‘D:\DRIVER\signed-no-timestamp\filter.inf’ to ‘C:\Users\Fotios\AppData\Local\Temp{3ba54231-88f5-5b48-91c0-8233bc0de77c}\filter.inf’.
pol: {Driver package policy check} 01:22:53.294
pol: {Driver package policy check - exit(0x00000000)} 01:22:53.295
sto: {Stage Driver Package: C:\Users\Fotios\AppData\Local\Temp{3ba54231-88f5-5b48-91c0-8233bc0de77c}\filter.inf} 01:22:53.296
inf: {Query Configurability: C:\Users\Fotios\AppData\Local\Temp{3ba54231-88f5-5b48-91c0-8233bc0de77c}\filter.inf} 01:22:53.300
inf: Driver package uses WDF.
inf: Driver package ‘filter.inf’ is configurable.
inf: {Query Configurability: exit(0x00000000)} 01:22:53.306
flq: Copying ‘C:\Users\Fotios\AppData\Local\Temp{3ba54231-88f5-5b48-91c0-8233bc0de77c}\filter.sys’ to ‘C:\Windows\System32\DriverStore\Temp{40bd780e-8bf5-604c-82e1-5d00daf39971}\filter.sys’.
flq: Copying ‘C:\Users\Fotios\AppData\Local\Temp{3ba54231-88f5-5b48-91c0-8233bc0de77c}\WdfCoInstaller01011.dll’ to ‘C:\Windows\System32\DriverStore\Temp{40bd780e-8bf5-604c-82e1-5d00daf39971}\WdfCoInstaller01011.dll’.
flq: Copying ‘C:\Users\Fotios\AppData\Local\Temp{3ba54231-88f5-5b48-91c0-8233bc0de77c}\filter.cat’ to ‘C:\Windows\System32\DriverStore\Temp{40bd780e-8bf5-604c-82e1-5d00daf39971}\filter.cat’.
flq: Copying ‘C:\Users\Fotios\AppData\Local\Temp{3ba54231-88f5-5b48-91c0-8233bc0de77c}\filter.inf’ to ‘C:\Windows\System32\DriverStore\Temp{40bd780e-8bf5-604c-82e1-5d00daf39971}\filter.inf’.
sto: {DRIVERSTORE IMPORT VALIDATE} 01:22:53.323
sig: {_VERIFY_FILE_SIGNATURE} 01:22:53.332
sig: Key = filter.inf
sig: FilePath = C:\Windows\System32\DriverStore\Temp{40bd780e-8bf5-604c-82e1-5d00daf39971}\filter.inf
sig: Catalog = C:\Windows\System32\DriverStore\Temp{40bd780e-8bf5-604c-82e1-5d00daf39971}\filter.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)} 01:22:53.566
sig: {_VERIFY_FILE_SIGNATURE} 01:22:53.567
sig: Key = filter.inf
sig: FilePath = C:\Windows\System32\DriverStore\Temp{40bd780e-8bf5-604c-82e1-5d00daf39971}\filter.inf
sig: Catalog = C:\Windows\System32\DriverStore\Temp{40bd780e-8bf5-604c-82e1-5d00daf39971}\filter.cat
sig: Success: File is signed in Authenticode™ catalog.
sig: Error 0xe0000241: The INF was signed with an Authenticode™ catalog from a trusted publisher.
sig: {_VERIFY_FILE_SIGNATURE exit(0xe0000241)} 01:22:53.587
sto: {DRIVERSTORE IMPORT VALIDATE: exit(0x00000000)} 01:22:53.597
sig: Signer Score = 0x0F000000
sig: Signer Name = xxxxxx Software Limited
sto: {DRIVERSTORE IMPORT BEGIN} 01:22:53.601
sto: {DRIVERSTORE IMPORT BEGIN: exit(0x00000000)} 01:22:53.602
cpy: {Copy Directory: C:\Windows\System32\DriverStore\Temp{40bd780e-8bf5-604c-82e1-5d00daf39971}} 01:22:53.606
cpy: Target Path = C:\Windows\System32\DriverStore\FileRepository\filter.inf_amd64_32925c27c5bfaf39
cpy: {Copy Directory: exit(0x00000000)} 01:22:53.616
idb: {Register Driver Package: C:\Windows\System32\DriverStore\FileRepository\filter.inf_amd64_32925c27c5bfaf39\filter.inf} 01:22:53.618
idb: Created driver package object ‘filter.inf_amd64_32925c27c5bfaf39’ in DRIVERS database node.
idb: Created driver INF file object ‘oem71.inf’ in DRIVERS database node.
idb: Registered driver package ‘filter.inf_amd64_32925c27c5bfaf39’ with ‘oem71.inf’.
idb: {Register Driver Package: exit(0x00000000)} 01:22:53.625
idb: {Publish Driver Package: C:\Windows\System32\DriverStore\FileRepository\filter.inf_amd64_32925c27c5bfaf39\filter.inf} 01:22:53.625
idb: Activating driver package ‘filter.inf_amd64_32925c27c5bfaf39’.
cpy: Published ‘filter.inf_amd64_32925c27c5bfaf39\filter.inf’ to ‘oem71.inf’.
idb: Indexed 2 device IDs for ‘filter.inf_amd64_32925c27c5bfaf39’.
idb: {Publish Driver Package: exit(0x00000000)} 01:22:53.633
sto: {DRIVERSTORE IMPORT END} 01:22:53.635
sig: Installed catalog ‘filter.cat’ as ‘oem71.cat’.
sto: {DRIVERSTORE IMPORT END: exit(0x00000000)} 01:22:54.261
sto: {Stage Driver Package: exit(0x00000000)} 01:22:54.873
sto: Driver Store Filename = C:\Windows\System32\DriverStore\FileRepository\filter.inf_amd64_32925c27c5bfaf39\filter.inf
sto: {Import Driver Package: exit(0x00000000)} 01:22:55.273
inf: Driver Store Path: C:\Windows\System32\DriverStore\FileRepository\filter.inf_amd64_32925c27c5bfaf39\filter.inf
inf: Published Inf Path: C:\Windows\INF\oem71.inf
inf: {SetupCopyOEMInf exit (0x00000000)} 01:22:55.295
<<< Section end 2013/09/21 01:22:56.080
<<< [Exit status: SUCCESS]

Looking further into it I noticed the following:

GlobalSign Root CA cert published by GlobalSign (here: https://secure.globalsign.net/cacert/root.crt) has this hash: 2f 17 3f 7d e9 96 67 af a5 7a f8 0a a2 d1 b1 2f ac 83 03 38

Windows Auto-Update GlobalSign Root CA cert hash is : ?b1 bc 96 8b d4 f4 9d 62 2a a8 9a 81 f2 15 01 52 a4 1d 82 9c

Yet Microsoft (here: http://msdn.microsoft.com/en-us/library/windows/hardware/dn170454(v=vs.85).aspx) publishes a cross-cert for a GlobalSign Root CA cert with this hash: cc 1d ee bf 6d 55 c2 c9 06 1b a1 6f 10 a0 bf a6 97 9a 4a 32

And Microsoft China publishes a cross-cert (here: http://www.microsoft.com/china/whdc/winlogo/drvsign/crosscert.mspx) for the the same root CA cert GlobalSign itself publishes (same hash as the first one above).

The way I understand this is that for a valid chain of trust to be established the cross-cert used in signing the driver (with the /ac signtool option) has to be a cross-cert for the same root CA cert that is to be found in the root store of any Windows computer, i.e. the one that we get in the store when the “auto-update root certs” option in on.

This would explain why my driver shows up as not signed: I am signing my driver with a cross-cert for a different GlobalSign Root CA cert than the one I have in my trusted root CAs store.

Still why wouldn’t this error show when I run “signtool verify /v /kp filter.cat” ? The only thing I can think of is that keytool does not do the same strict chain checking the installer does and therefore the fact that the signing cross-cert is for a different cert than the one in the root CA store eludes it.

My theory is that if I had a Microsoft issued cross-cert for the same GlobalSign root CA that signed the intermediate GlobalSign cert which in turn signed my SPC it would all work. Still I am having trouble understanding what is sgned by what since I have seen the “certification path” of my SPC show as “valid” while ending in GlobalSign Root CA certs with different thumbprints (depending which one I have in my root store); which means that certification path is not determined purely by signature verification.

Unfortunately the cross-certs Microsoft publishes are not for the one with thumbprint: b1 bc 96 8b d4 f4 9d 62 2a a8 9a 81 f2 15 01 52 a4 1d 82 9c

Any comments? Where do I have it wrong?

xxxxx@gmail.com wrote:

Looking further into it I noticed the following:

The way I understand this is that for a valid chain of trust to be established the cross-cert used in signing the driver (with the /ac signtool option) has to be a cross-cert for the same root CA cert that is to be found in the root store of any Windows computer, i.e. the one that we get in the store when the “auto-update root certs” option in on.

That’s not my understanding. “signtool” traces your chain back to some
root, and that chain has to be present on the computer doing the
signing. The “cross certificate” has to match that root, and that then
starts another chain that eventually terminates in the Microsoft Code
Verification Root. Again, that’s all on the machine doing the signing.
As long as “signtool” can link things back to the Microsoft Code
Verification Root, that should be all you need. Theoretically.

This would explain why my driver shows up as not signed: I am signing my driver with a cross-cert for a different GlobalSign Root CA cert than the one I have in my trusted root CAs store.

I don’t think that’s the issue. The fact that “signtool verify /v /kp”
shows the Microsoft Code Verification Root is a pretty solid indication
that the cross-certificate linkage went OK. Remember that KMCS doesn’t
check the entire chain; it only cares that the Microsoft Code
Verification Root is in there. It trusts that “signtool” did the rest
of the work.

Still why wouldn’t this error show when I run “signtool verify /v /kp filter.cat” ?

You said this was a filter driver, installed via registry hack, right?
You don’t own the entire driver stack? In that case, the CAT file
signature is irrelevant. It’s decorative. You aren’t doing a PnP
install here. The driver file itself has to be signed. Are you doing
that?


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

Hi Tim,

I tried signing the driver itself as well (which is what I was doing before I had a working inf anyway) and the result is pretty much the same.

Please take a look at the following portion of the setupapi log:

sig: {_VERIFY_FILE_SIGNATURE} 00:58:20.529
sig: Key = filter.inf
sig: FilePath = C:\Windows\System32\DriverStore\Temp{0bfb37c7-b41b-1d49-8737-fb0b11101839}\filter.inf
sig: Catalog = C:\Windows\System32\DriverStore\Temp{0bfb37c7-b41b-1d49-8737-fb0b11101839}\filter.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)} 00:58:20.604
sig: {_VERIFY_FILE_SIGNATURE} 00:58:20.605
sig: Key = filter.inf
sig: FilePath = C:\Windows\System32\DriverStore\Temp{0bfb37c7-b41b-1d49-8737-fb0b11101839}\filter.inf
sig: Catalog = C:\Windows\System32\DriverStore\Temp{0bfb37c7-b41b-1d49-8737-fb0b11101839}\filter.cat
sig: Success: File is signed in Authenticode™ catalog.
sig: Error 0xe0000241: The INF was signed with an Authenticode™ catalog from a trusted publisher.
sig: {_VERIFY_FILE_SIGNATURE exit(0xe0000241)} 00:58:20.642

As you can see half of the signature verification fails and half succeeds. Interestingly the result of the whole operation, as logged by setupapi, is “SUCCESS”. Alas, the driver shows up as unsigned and of course does not run.

Any idea what this could mean? What do these two separate verification steps check?

Cheers,
Alex

On 9/24/2013 12:10 AM, xxxxx@gmail.com wrote:

Hi Tim,

I tried signing the driver itself as well (which is what I was doing before I had a working inf anyway) and the result is pretty much the same.

Please take a look at the following portion of the setupapi log:

sig: {_VERIFY_FILE_SIGNATURE} 00:58:20.529
sig: Key = filter.inf
sig: FilePath = C:\Windows\System32\DriverStore\Temp{0bfb37c7-b41b-1d49-8737-fb0b11101839}\filter.inf
sig: Catalog = C:\Windows\System32\DriverStore\Temp{0bfb37c7-b41b-1d49-8737-fb0b11101839}\filter.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)} 00:58:20.604
sig: {_VERIFY_FILE_SIGNATURE} 00:58:20.605
sig: Key = filter.inf
sig: FilePath = C:\Windows\System32\DriverStore\Temp{0bfb37c7-b41b-1d49-8737-fb0b11101839}\filter.inf
sig: Catalog = C:\Windows\System32\DriverStore\Temp{0bfb37c7-b41b-1d49-8737-fb0b11101839}\filter.cat
sig: Success: File is signed in Authenticode™ catalog.
sig: Error 0xe0000241: The INF was signed with an Authenticode™ catalog from a trusted publisher.
sig: {_VERIFY_FILE_SIGNATURE exit(0xe0000241)} 00:58:20.642

As you can see half of the signature verification fails and half succeeds. Interestingly the result of the whole operation, as logged by setupapi, is “SUCCESS”. Alas, the driver shows up as unsigned and of course does not run.

Any idea what this could mean? What do these two separate verification steps check?

I chased a similar problem today - it turned out that a coinstaller was
crashing and the error was logged in the Application Event Log and
Windows was apparently claiming it was a problem with signatures in the
SetupAPI logs. Maybe something to check?


Bruce Cran

Thanks Bruce - will check that too.

I am guessing the second (successful step) merely states that the my certificate is in the “Trusted Publishers” store which does not say much (i.e. I put it there)

xxxxx@gmail.com wrote:

Please take a look at the following portion of the setupapi log:

sig: {_VERIFY_FILE_SIGNATURE} 00:58:20.529
sig: Key = filter.inf
sig: FilePath = C:\Windows\System32\DriverStore\Temp{0bfb37c7-b41b-1d49-8737-fb0b11101839}\filter.inf
sig: Catalog = C:\Windows\System32\DriverStore\Temp{0bfb37c7-b41b-1d49-8737-fb0b11101839}\filter.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)} 00:58:20.604

I’m not clear on how you got into the DriverStore to begin with. Is
this a [DefaultInstall] INF file? Or are you specifying the function
driver as well as your filter driver?


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

What I think is going on (very tentative):

GlobalSign’s Root CA currently distributed with Windows in the “Trusted Root CAs” store (also the one that will come in through auto-update if you delete it - BTW root CA cert auto-update can be disabled in Win7/Win8 and perhaps Vista through gpedit) is R1.

R1’s thumbprint is: ?b1 bc 96 8b d4 f4 9d 62 2a a8 9a 81 f2 15 01 52 a4 1d 82 9c

But the cross-cert distributed by Microsoft (http://msdn.microsoft.com/en-us/library/windows/hardware/dn170454(v=vs.85).aspx) is for a GlobalSign root cert with thumbprint: cc 1d ee bf 6d 55 c2 c9 06 1b a1 6f 10 a0 bf a6 97 9a 4a 32

At the very top of the Microsoft page it is mentioned that the thumbprints should match. I am now trying to locate the cross-cert for the R1 root cert. Well, I’ll try anything really…

It is a [DefaultInstall] INF file - full listing of it at the top of the thread

xxxxx@gmail.com wrote:

It is a [DefaultInstall] INF file - full listing of it at the top of the thread

That’s what confuses me. A [DefaultInstall] INF is not a PnP INF. It
doesn’t need a CAT, it shouldn’t go in the driver store, and it
shouldn’t be possible to pre-install it. Device Manager is never going
to go looking for it, because it won’t ever match a hardware ID search.


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

I am guessing that as long as the driver is declared in the registry as an upper filter it will be loaded whenever the class device is started along with other filters. Would it matter if it is imported in the driver store or not?

I mean bottom-line seems to be, at least right now, that installation seems to stumble on the chain of signing issue.

xxxxx@gmail.com wrote:

I am guessing that as long as the driver is declared in the registry as an upper filter it will be loaded whenever the class device is started along with other filters. Would it matter if it is imported in the driver store or not?

No, it should not matter, as long as the .SYS file is signed.

I mean bottom-line seems to be, at least right now, that installation seems to stumble on the chain of signing issue.

But there shouldn’t BE any installation! Installation of a filter
driver requires:

  1. Copy the file
  2. Create a service
  3. Create an UpperFilters or LowerFilters registry key
  4. Restart the device

Until you get to #4, Device Manager is not involved in this at all.
That’s what I don’t understand. Why is there any installation stuff
going on at all?


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

> But there shouldn’t BE any installation! Installation of a filter driver requires:

  1. Copy the file
  2. Create a service
  3. Create an UpperFilters or LowerFilters registry key
  4. Restart the device Until you get to #4 Device Manager is not involved in this at all.

That’s what I don’t understand. Why is there any installation stuff going on at all?

Well, I guess installation stuff is going on because I am using an INF file with a [DeafaultInstall] section in it. Initially I had no INF file - I just signed the sys file (embedded signature), copied the file under System32\Drivers, created the service, used DevCon to register it as upper Filter to the Image class and restarted the device (the sys file would also verify correctly using “signtool verify”).

After doing all of the above, the Filter would not be allowed to run, and it would show up in the drivers list for my USB camera without the “signed” icon to the left of it: http://fotios.org/files/drivers.png. I would also get the “a signed driver is needed” type of popup.

I wanted to debug this but the type of filter installation as described just above does not generate very informative log entries in the event viewer and that is why put together the INF file and tried like that.

When running the INF file’s default install the setupapi log says this is a certificate chain trust issue (full setup api log at the top of this thread) but I now begin to think that this may be a misleading entry.

What I plan to do is try to sign and install one of the kernel driver samples that come with the WDK unmodified and see if that gets signed and installed without any issues. If it does then this would mean that my signing process is fine and that the problem lies elsewhere but I am wondering: what could possibly cause the Windows signature verification mechanism think this is a chain of trust issue when it is not?

Let me just mention that the filter runs just fine when it is unsigned and signature verification is disabled.

Cheers!
A

xxxxx@gmail.com wrote:

Well, I guess installation stuff is going on because I am using an INF file with a [DeafaultInstall] section in it. Initially I had no INF file - I just signed the sys file (embedded signature), copied the file under System32\Drivers, created the service, used DevCon to register it as upper Filter to the Image class and restarted the device (the sys file would also verify correctly using “signtool verify”).

Hmm. That should be all it takes, assuming you are using “signtool
verify /kp” and you are checking for the Microsoft Code Verification Root.

After doing all of the above, the Filter would not be allowed to run, and it would show up in the drivers list for my USB camera without the “signed” icon to the left of it: http://fotios.org/files/drivers.png. I would also get the “a signed driver is needed” type of popup.

I believe the “signed” icon in Device Manager is only present if you
have WHQL signature.

Let me just mention that the filter runs just fine when it is unsigned and signature verification is disabled.

Very odd.


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