Driver with expired certificate

NTDEV
1

I have a question about device drivers with expired certificates. Mainly are there any problems installing or running a device driver with a certificate that’s expired?

Here’s my situation. My company had a VeriSign certificate which expired several days ago. Instead of renewing the certificate my company decided to get a new certificate from Go Daddy. This all happened without my knowledge. Since Microsoft does not have a cross-certificate for Go Daddy I cannot use the new certificate to sign my device driver (http://msdn.microsoft.com/en-us/windows/hardware/gg487315.aspx). I can continue to sign using the old certificate, although it requires me to manually adjust my computer’s clock back. So I guess my questions are:

  1. Is there a problem with signing a device driver like this (manually adjusting my computer’s clock)?

  2. Are there any known issues with installing and/or running a device driver with an expired certificate?

Thanks.

2

xxxxx@gmail.com wrote:

I have a question about device drivers with expired certificates. Mainly are there any problems installing or running a device driver with a certificate that’s expired?

Here’s my situation. My company had a VeriSign certificate which expired several days ago. Instead of renewing the certificate my company decided to get a new certificate from Go Daddy. This all happened without my knowledge. Since Microsoft does not have a cross-certificate for Go Daddy I cannot use the new certificate to sign my device driver (http://msdn.microsoft.com/en-us/windows/hardware/gg487315.aspx). I can continue to sign using the old certificate, although it requires me to manually adjust my computer’s clock back. So I guess my questions are:

  1. Is there a problem with signing a device driver like this (manually adjusting my computer’s clock)?

Yes, there is. The signing process includes a timestamp. Usually, you
use the /t parameter of signtool to specify a certified time source
(like timestamp.verisign.com). When you do that, the real current time
gets embedded. Your computer’s time is irrelevant. As long as the
certificate is valid at the time get the timestamp, you’re OK. In your
case, you are screwed.

If you do not use /t, then the client cannot rely on the signing time
(as witnessed by your hacking), so the signed package expires when the
certificate expires. In your case, you are screwed.

Your company needs to get a Verisign or GlobalSign certificate to
satisfy KMCS. There are no shortcuts.

  1. Are there any known issues with installing and/or running a device driver with an expired certificate?

It will behave like an unsigned package. I can be installed – with
warnings – and it will run on 32-bit systems, but not on 64-bit systems.

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

3

“Tim Roberts” wrote in message news:xxxxx@ntdev…
> xxxxx@gmail.com wrote:

>> 2. Are there any known issues with installing and/or running a device
>> driver with an expired certificate?
>
> It will behave like an unsigned package. I can be installed – with
> warnings – and it will run on 32-bit systems, but not on 64-bit systems.
>

So the KMCS Walkthrough does not cover the case. But my experience and
common sense tells me that you got that wrong. You can continue installing
and loading the driver with the expired certificate without problems. You
cannot use the certificate to sign new driver binaries. If not this would
require us to hysterically update our packages and distribute them
continously thus creating a support nightmare for software vendors.

//Daniel

4

On Thu, Jul 21, 2011 at 2:27 PM, wrote:
> “Tim Roberts” wrote in message news:xxxxx@ntdev…
>> xxxxx@gmail.com wrote:
>
>>> 2. ?Are there any known issues with installing and/or running a device
>>> driver with an expired certificate?
>>
>> It will behave like an unsigned package. ?I can be installed – with
>> warnings – and it will run on 32-bit systems, but not on 64-bit systems.
>>
>
> So the KMCS Walkthrough does not cover the case. But my experience and
> common sense tells me that you got that wrong. You can continue installing
> and loading the driver with the expired certificate without problems.

Provided that you do the proper timestamp. I’ve seen an company
(Atmel) forgot to do that, paid the money and got the WHQL for one
of their driver packages (Atmel FLIP, based on old libusb-win32 0.1.12),
but only to find out that the driver package become useless after the
certificates got expired.

I know this is an exceptional case but it happens.

> You cannot use the certificate to sign new driver binaries. If not this would
> require us to hysterically update our packages and distribute them
> continuously thus creating a support nightmare for software vendors.
>

You are of course right here.

But if you read the OP’s question and Tim’s response more closely,
the OP wants to sign the driver with an expired certificate by using
tricks like changing the computer clock, that will of course not work.

–
Xiaofan

5

“Xiaofan Chen” wrote in message news:xxxxx@ntdev…
>> You cannot use the certificate to sign new driver binaries. If not this
>> would
>> require us to hysterically update our packages and distribute them
>> continuously thus creating a support nightmare for software vendors.
>>
>You are of course right here.
>But if you read the OP’s question and Tim’s response more closely,
>the OP wants to sign the driver with an expired certificate by using
>tricks like changing the computer clock, that will of course not work.

That’s not how I understood the OP’s question. But anyhow, not wanting to
create any confusion, what I was discussing here was a properly signed and
timestamped driver of which the certificate that was used for signing after
time has expired. I was not talking about the fruitless effort of attempting
to sign a driver with an expired certificate of which Tim pointed out that
it cannot be time stamped.

//Daniel

6

On 7/20/2011 11:15 PM, Tim Roberts wrote:

The signing process includes a timestamp. Usually, you use the /t
parameter of signtool to specify a certified time source (like
timestamp.verisign.com).

When you do that, the real current time gets embedded.

Please allow me to add my puny 2 cents:

  • The timestamp server embeds “their” time in the timestamp.

  • RFC3161 (Time-Stamp Protocol, TSP) states, the TSA (Time Stamp
    Authority) needs “to use a trustworthy source of time”.

(=> VeriSign - the MS doc suggestion - will certainly do this!)

This explains that (and why) not any random timestamping server will
do, but why it has to be trusted by Microsoft’s certificate chain.

[It will also be interesting to see what happens when a certificate from
the time-stamp authentication chain expires. Or the top-level one. :slight_smile: ]

7

Thanks for all the quick responses. Everything you said here makes perfect sense. However, real-world testing is giving me different results.

For starters, I always sign using the /t option. My original timestamp URL was tsa.starfieldtech.com, but I’ve tried timestamp.verisign.com as well, they both work. If I try and sign with the orrect time on my system’s clock, signtool fails with error code CERT_E_EXPIRED (0x800b0101). If however I back up my system’s clock the file is signed with no warnings or errors. What’s more, I can load this signed driver on Windows 7 x64.

Just as a sanity test I tried loading my UNSIGNED driver on Windows 7 x64, that failed. So as far as I can tell, my driver which is signed several days after the signing period is working just fine.

FWIW, VeriSign certificate expired on July 18th 2011, only 3 days ago. Maybe there’s some sort of grace period built into this, although that wouldn’t make much sense.

8

On 21-Jul-2011 18:48, xxxxx@gmail.com wrote:

Thanks for all the quick responses. Everything you said here makes perfect sense. However, real-world testing is giving me different results.

For starters, I always sign using the /t option. My original timestamp URL was tsa.starfieldtech.com, but I’ve tried timestamp.verisign.com as well, they both work. If I try and sign with the orrect time on my system’s clock, signtool fails with error code CERT_E_EXPIRED (0x800b0101). If however I back up my system’s clock the file is signed with no warnings or errors. What’s more, I can load this signed driver on Windows 7 x64.

Just as a sanity test I tried loading my UNSIGNED driver on Windows 7 x64, that failed. So as far as I can tell, my driver which is signed several days after the signing period is working just fine.

FWIW, VeriSign certificate expired on July 18th 2011, only 3 days ago. Maybe there’s some sort of grace period built into this, although that wouldn’t make much sense.

Is the target win7 machine, by chance, in test-sign mode or with windbg
connected?

–pa

9

xxxxx@gmail.com wrote:

Thanks for all the quick responses. Everything you said here makes perfect sense. However, real-world testing is giving me different results.

For starters, I always sign using the /t option. My original timestamp URL was tsa.starfieldtech.com, but I’ve tried timestamp.verisign.com as well, they both work. If I try and sign with the orrect time on my system’s clock, signtool fails with error code CERT_E_EXPIRED (0x800b0101). If however I back up my system’s clock the file is signed with no warnings or errors. What’s more, I can load this signed driver on Windows 7 x64.

That would seem to indicate a pretty serious failure in the KMCS
signature checking…

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

10

> Is the target win7 machine, by chance, in test-sign mode or with windbg connected?

I’ve triple-checked the machine is not in test-signing mode. It is a fresh installation of Windows 7 Professional SP1 x64.

That would seem to indicate a pretty serious failure in the KMCS signature checking…

At this point I don’t see how I could have messed this up. Using Explorer to look at the digital signature in my driver I see the signing timestamp is current. So that means the /t option worked correct, it picked up the current timestamp from the web and not my system clock, which was purposely set wrong.

The only other thing I’m doing which is less typical (but still valid) is I dynamically install the device driver at runtime using CreateService(). We do not have or use an INF file. However, I’ve confirmed dynamic installation of a device driver with no signature fails. I wonder if I have found a security hole in Windows. I’m going to run some more tests, and try other platforms (like Vista and 2008) to see what happens. If anyone else out there has an expired certificate and could test this, that would be helpful.

I believe I have two unexplained issues:

  1. Signtool.exe is allowing me to sign using an expired certificate if I manually adjust my clock. In signtool’s defense, it is putting the correct sing time into the binary.

  2. Windows 7 SP1 x64 is allowing me to load a device driver that was signed after the certificate expired. I don’t know about other platforms and/or SP levels.

11

xxxxx@gmail.com wrote:

I believe I have two unexplained issues:

  1. Signtool.exe is allowing me to sign using an expired certificate if I manually adjust my clock. In signtool’s defense, it is putting the correct sing time into the binary.

That one doesn’t bother me too much. I don’t think I expect signtool to
check your time against the timestamp time. It is correctly embedding
the validated time.

  1. Windows 7 SP1 x64 is allowing me to load a device driver that was signed after the certificate expired.

That one surprises me, and I’ll bet our friends in Redmond will be
interested in it.

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

12

>> 2. Windows 7 SP1 x64 is allowing me to load a device driver that
was signed after the certificate expired.
>
> That one surprises me, and I’ll bet our friends in Redmond will be
> interested in it.
>

Tis true. Windows doesn’t check whether the certificate was expired.
You can also load drivers that were signed by and expired certificate
without a timestamp.

13

> -----Original Message-----

From: xxxxx@lists.osr.com [mailto:bounce-466400-
xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Thursday, July 21, 2011 3:20 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Driver with expired certificate

xxxxx@gmail.com wrote:
>
> I believe I have two unexplained issues:
>
> 1. Signtool.exe is allowing me to sign using an expired certificate if
I
manually adjust my clock. In signtool’s defense, it is putting the
correct
sing time into the binary.

That one doesn’t bother me too much. I don’t think I expect signtool to
check your time against the timestamp time. It is correctly embedding
the validated time.

Don’t you think signtool should get grumpy about signing with a certificate
that expired before *the timestamp time*? I certainly think it should.

Still, I suspect that there is something else going on with the test
machine.

Phil

Philip D. Barila

14

On 7/21/2011 11:02 PM, xxxxx@gmail.com wrote:

I’ve triple-checked the machine is not in test-signing mode. It is a
fresh installation of Windows 7 Professional SP1 x64.

…and you did not use this machine ever for signing your driver?

This is important, because signtool.exe will import any signatures you
give it in an external file into the local machine cert store.
To my knowledge, you cannot prevent this.

And once your signatures are in the cert store, everything works.
On this machine.

I’ve been bitten by this - a luckily a co-worker did not have the
certs installed that I use for signing and pointed out a driver load
failure (caused by an incomplete embed-signing chain).

15

> Tis true. Windows doesn’t check whether the certificate was expired.

You can also load drivers that were signed by and expired certificate
without a timestamp

Then… it may mean that KMCS does not check timestamp “by design”,
for example, to allow setting system time way to past or future,
or if the clock is broken.

A user can set the clock to several years back, before the win7 has been released,
or ahead, when all existing certificates would expire.
When the OS boots, it has no other time references besides the BIOS (or whatever) clock.
So they might have decided to just let it boot.

–pa

16

I’m not sure I understand the issues here. Here’s what I understand, somebody tell me if I’m missing something:

Given: You have an expired certificate that is otherwise valid, and was obtained legitimately from an “approved” CA.

  1. You can’t sign drivers using that cert if the time on your system is a date after the certificate’s expiration.

  2. If you set the time on your system backwards, to a time before the cert expired, you can successfully sign drivers.

  3. If you can successfully sign it (again, given an appropriate certificate that has not been REVOKED), Windows will allow you to install or load it regardless of whether the cert has expired.

I don’t see any problem with ANY of this.

#1, above, is what I would expect.

#2, above, is effectively arbitrary. But no major harm done: The only one who loses here is Verisign, who loses money on renewing your certificate. You still are, presumably, who you said you were when the cert was issued. All the cert really does is attest to your identify. You COULD have bought a cert that was valid for multiple years… so it’s not like Verisign insists on annually conducting the minimal “background check” that they do before a cert is issued. So, bottom line, who cares if you can sign with an expired cert. You want the hassle of setting the time back on your system to save $500, I say “go for it.”

#3, above, is what I would expect, and precisely as it must be. You buy a cert today, you sign your driver tomorrow, you ship your driver to 150 million customers, they install your software over the next year or two. Meanwhile, six months from now, the cert expires. That simply can NOT result in customers not being able to install legitimately purchased and (at the time) signed software.

So, either I’m missing something or I don’t understand the controversy.

Peter
OSR

17

[snippety doo dah]

  1. If you set the time on your system backwards, to a time before the cert
    expired, you can successfully sign drivers.

[snippety ay]

#2, above, is effectively arbitrary. But no major harm done: The only one
who
loses here is Verisign, who loses money on renewing your certificate. You
still are, presumably, who you said you were when the cert was issued.
All
the cert really does is attest to your identify. You COULD have bought a
cert
that was valid for multiple years… so it’s not like Verisign insists on
annually conducting the minimal “background check” that they do before a
cert
is issued. So, bottom line, who cares if you can sign with an expired
cert.
You want the hassle of setting the time back on your system to save $500,
I
say “go for it.”

We’ll that’s the controversy for me. In pondering how to articulate it, it
seems that expired == invalid, at least in my mind. When I write it down
like that, it seems clear that’s not the case. Is it supposed to be?

Phil

Philip D. Barila

18

wrote in message news:xxxxx@ntdev…
>> Tis true. Windows doesn’t check whether the certificate was expired.
>> You can also load drivers that were signed by and expired certificate
>> without a timestamp
>
> Then… it may mean that KMCS does not check timestamp “by design”,
> for example, to allow setting system time way to past or future,
> or if the clock is broken.
>
> A user can set the clock to several years back, before the win7 has been
> released,
> or ahead, when all existing certificates would expire.
> When the OS boots, it has no other time references besides the BIOS (or
> whatever) clock.
> So they might have decided to just let it boot.

… and, since a Windows system should be groomed & patched anyway,
the maintainer can remove bad (expired or revoked) certs
as part of patching procedure.

–pa

19

xxxxx@osr.com wrote:

I’m not sure I understand the issues here. Here’s what I understand, somebody tell me if I’m missing something:

Given: You have an expired certificate that is otherwise valid, and was obtained legitimately from an “approved” CA.

  1. You can’t sign drivers using that cert if the time on your system is a date after the certificate’s expiration.

True.

  1. If you set the time on your system backwards, to a time before the cert expired, you can successfully sign drivers.

True. If one is using the /t parameter to embed a validated timestamp,
one could quite legitimately argue that signtool should fail in this
case. It has enough information to know what the REAL time is, from a
reliable and provably valid source. Maybe this is the real bug.

  1. If you can successfully sign it (again, given an appropriate certificate that has not been REVOKED), Windows will allow you to install or load it regardless of whether the cert has expired.

True.

I don’t see any problem with ANY of this.

#1, above, is what I would expect.

#2, above, is effectively arbitrary. But no major harm done: … So, bottom line, who cares if you can sign with an expired cert.

Microsoft should care, damn it! Otherwise, what’s the point of all of
this? The rest of us are getting ripped off for following the rules.
If they are going to make the rules, then they need to be consistent
about enforcing them.

#3, above, is what I would expect, and precisely as it must be.

No, you are missing the point. More in a moment…

…You buy a cert today, you sign your driver tomorrow, you ship your driver to 150 million customers, they install your software over the next year or two. Meanwhile, six months from now, the cert expires. That simply can NOT result in customers not being able to install legitimately purchased and (at the time) signed software.

So, either I’m missing something or I don’t understand the controversy.

Yes, you seem to be missing something. When we sign a driver, we have
the option of embedding a validated timestamp. If you do not embed a
validated timestamp, then the client has no way to know when you
actually signed the file. So, the expiration check has to be based on
the client’s current time. The signature becomes invalid when the
certificate expires, and the driver will not be loaded after that
point. We have evidence from earlier in this thread that Windows does
enforce this.

If you DO embed a validated timestamp using the /t parameter of
signtool, then you are saying “my certificate was valid at the time I
signed the driver, and I can prove it”. This, the client’s expiration
check uses the timestamp time. In this case, that expiration check
should fail, because the certificate was invalid at the time of the
signature. The evidence suggests this is NOT being done.

If this is not true, then the timestamping is a joke, and I’m really
annoyed that I’ve pissed away $800 on certificate renewals.

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

20

xxxxx@osr.com wrote:

#2, above, is effectively arbitrary. But no major harm done: The only one who loses here is Verisign, who loses money on renewing your certificate. You still are, presumably, who you said you were when the cert was issued.

That is a very dangerous presumption, and is perhaps the core of the
controversy. All of us have “disgruntled former employee” stories. We
(as employees) are all very mobile. There is no guarantee at all that I
still have the right to use the certificate I got last year. That’s why
the certificates expire.

All the cert really does is attest to your identify.

It attests to my company’s identity, and presumes that I have the
authority to speak for my company. It’s that second clause that
expiration addresses.

You COULD have bought a cert that was valid for multiple years…

Yes, but not an infinite number of years.

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