0

I'm working on making a silent installer of WinpkFilter driver. In my silent installation, I'm always getting a (not so silent) prompt that says "Windows can't verify the publisher of this driver software".

Rightfully so. The cert expired in 2013 and it's cert path is just itself, which isn't a CA.

So how does the real installation do it? When I test the real installation it installs and uses the same expired cert, but there's no aforementioned Windows prompt.

How does it do that?

Improve this question
8
  • Am I right in thinking that you're building (or modifying to create) your own version of the driver?
    – RoraΖ
    Commented Mar 4, 2015 at 12:31
  • No. I'm trying to follow the real driver's installation using the same exact files, certs, and registry-entries. The end result should look exactly the same; an installed WinpkFilter driver.
    – bzupnick
    Commented Mar 4, 2015 at 12:58
  • If you're writing a wrapper around the winpkfilter driver then your wrapper would have to be signed. I'm guessing its flagging your wrapper, and not the driver itself.
    – RoraΖ
    Commented Mar 4, 2015 at 13:08
  • So the process that installs the driver itself needs to be signed....?
    – bzupnick
    Commented Mar 4, 2015 at 13:29
  • Depending on which Windows version you're installing on, and the settings... yeah.
    – RoraΖ
    Commented Mar 4, 2015 at 13:48

1 Answer 1

Reset to default
2

From what I read in the comments and in chat I think this is related to timestamping. The driver has been signed at a time the certificate was valid. That signing time was confirmed by a certified timestamp server.

In that case, the driver is considered as trustworthy, since everything was fine at the time of signing.

To check for a timestamp, open the file properties in Windows Explorer, go to "Digital signatures" and check if there is a countersignature with the timestamp. It should look like this:

Digital signatures - countersignatures

Your application (installer), however, was

  • not timestamped at all
  • or the timestamp was not provided by a trusted timestamp server
  • or the certificate itself was revoked to a time before the timestamp was created
  • or the certificate is not trusted by a CA

so that a warning UAC dialog is shown.

Improve this answer
5
  • I have an UMDF driver that was signed with a valid certificate which is now expired. The timestamp in the "Digital Signature" tab shows an old date (2016). However I can still load the driver from my application. So if I understood correctly in this case nothing can prevent me from using the driver. Is it correct ? Is it now only a matter of TSA ? What if the TSA certificate that signed the timestamp expires ?
    – Bemipefe
    Commented Aug 28, 2019 at 15:48
  • 1
    @Bemipefe: I never read about that, but IMHO it would make sense if that scheme continued the same way "forever". That is: it would not matter if the TSA certificate expires as long as it was valid at the time providing the timestamp. However, if it is revoked for a point in time before that of the timestamp it claims to have proven, that timestamp would not be trusted and as a consequence, the client certificate would become invalid after its expiration.
    – Thomas Weller
    Commented Aug 28, 2019 at 19:55
  • @Thomas_Weller What checks are then performed during the driver loading ? The signing certificate expiration is not checked and the same applies to the TSA certificate. It looks like the only check performed is if the driver is signed or not. Signed ok, not signed ko ? Are UMDF drivers less restrictive ?
    – Bemipefe
    Commented Aug 29, 2019 at 8:40
  • 1
    @Bemipefe: there are several options a driver would not load: a) signed, no timestamp, certificate expired b) signed, no timestamp, certificate revoked c) signed, timestamp, certificate revoked before that timestamp d) signed, no timestamp, CA revoked e) signed, timestamp, CA revoked before that timestamp + maybe further more complex scenarios with the CA involved.
    – Thomas Weller
    Commented Aug 29, 2019 at 9:57
  • 1
    @Bemipefe: AFAIK the procedure is the same for kernel mode drivers and user mode drivers. The difference is just in the type of the certificate. For user mode stuff, you can use a "normal" certificate, while for kernel mode, you need an EV certificate (extended validation). For the EV certificate, they perform more checks of your identity and the cost will be higher. Similar to HTTPS in the browser, whether you see the name in the address bar or not.
    – Thomas Weller
    Commented Aug 29, 2019 at 9:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .