Why living in the future is bad when you're a CA server (aka the story of 0x800b0101 CERT_E_EXPIRED)

Windows Server 2008

I worked on the following case recently:

We can't seem to enroll for certificates from our Windows 2008 OCS Servers, the error we get is "A required certificate is not within its validity period when verifying against the current system clock or the timestamp in the signed file.".

We have no problems requesting certificates from the same template and same CA server from our Windows Server 2003 servers.

The error code being returned by the system was 0x800b0101 - looking that up in winerror.h (publicly available in any of the OS SDK's) it translates to this:

# for hex 0x800b0101 / decimal -2146762495
CERT_E_EXPIRED winerror.h
# A required certificate is not within its validity period
# when verifying against the current system clock or the
# timestamp in the signed file.
# 1 matches found for "0x800B0101"

This *usually* means that one of the CA server certificates in the chain has expired. So, we did the usual PKI troubleshooting bits....exported the certificates in the 3-tier CA server chain and checked the validity on them, all were valid for the next 6 months at least. We then ran certutil -verify -urlfetch <certname.cer> against them to check for revocation errors but everything was fine... all certificates in the chain passed revocation checks and there wasn't really anything wrong that we could see anywhere.

When we looked closer at this, we determined the following:

- The CA server issuing the certificates was 13 minutes ahead of the rest of the domain (the w32time time sync hierarchy was obviously broken within the domain).

- A change has been made to the W2k8 enrollment code so that it aborts the enrollment operation if *any* of the certificates in the chain (including the certificate being issued) is not (yet) valid.

In short; the CA server attempted to issue the certificate to the servers and stamped it to be valid 13 minutes into the future (from the client perspective). W2k3 servers won't mind (the certificate won't be valid for 13 minutes however) but W2k8 servers do care and they will reject the entire operation and log the message "A required certificate is not within its validity period when verifying against the current system clock or the timestamp in the signed file."

Once we resynced the time on the CA server with the rest of the domain, everything started working normally and W2k3 and W2k8 servers alike were able to enroll again.

As it turned out,this wasn't exactly ground-breaking stuff nor did it require Neil Armstrong-type of troubleshooting to resolve once we had identified the cause - but to me it does show the importance of checking the time on the CA and comparing it with the enrollee (in case Win32Time on the machine(s) is not synching with the domain as it should).

Edit: when a CA issues a certifiacte it is by default valid 10 minutes in the past to account for clock skew within the domain, you can increase or decrease this by using the ClockSkewMinutes registry key on the CA, see http://blogs.technet.com/b/pki/archive/2008/06/05/how-effectivedate-thisupdate-nextupdate-and-nextcrlpublish-are-calculated.aspx