Question

I recently faced a very strange problem. Compilation of our products includes signing the kernel-mode drivers and adding a countersignature. This is done using a call to signtool, included in the DDK (now WDK):

"%DDKBASE%\6001.18000\bin\SelfSign\signtool.exe" sign /T http://timestamp.globalsign.com/scripts/timstamp.dll /ac "path-to-countercert\MSCV-GlobalSign.cer" /s SPC /n "EldoS Corporation" %1

Everything worked fine until recently when we discovered that the countercertificate is just not added to the signed driver. signtool doesn't report any errors and silently omits the certificate. The signature itself and main certificate chain are applied properly, and it's only countercertificate that's missing.

SignTool from the later WDK (version 7600.16385.0) works fine using the same command line.

I tried to re-register capicom.dll, coming with signtool in question (it resides in the same folder) but this didn't help.

I am not sure if we can use signtool from 7600.16385.0 because I have a feeling that it might break compatibility with say Windows 2000.

So the question is whether anybody has an idea of what might have gone wrong?

Upd: Well, it looks like 7600 signtool works fine (i.e. drivers signed with that version work fine on XP and Windows 7), so we'll go that route for now and will replace signtool with our own homemade tools in future to avoid such surprises.

Was it helpful?

Solution

It is OK to use the 7600.16385.0 version of signtool. It will still work on Windows 2000. As for the issues with the 6001.18000 version, check to see if you have multiple certificates for your company in your certificate store. The wrong one may be selected.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top