Sunday, December 18, 2016

PKI - ADCS: certificate revocation (review)

In my last two blog posts, I reviewed methods for the verification of PKI / ADCS health and then encountered (and later resolved) a problem with the publication of the CRL (certificate revocation list). I wanted to take that opportunity to review some of the fundamental aspects of certificate revocation, which is what I will do in the following paragraphs.


The "revocation" of a certificate prevents the use of the certificate in question.

The revoked certificate can no longer be used for its assigned role: client authentication, server authentication, code signing, etc..

When we revoke a certificate, the serial number of the certificate is added to a list called the "certificate revocation list" or "CRL"). This list is digitally signed by the certificate authority (CA) and published to the locations indicated in the CDP properties. This is usually a web share (the "http" location) and optionally in Active Directory (the "ldap" location):

Just like a certificate, the CRL has a validity period. However, this period is much shorter, often only a single day or several days. The CA must publish a new CRL at regular intervals to replace the previous CRL that has expired.

There are two types of revocation lists:
  • Base CRL: a complete list of certificate serial numbers revoked by the CA.
  • Delta CRL: a list of certificates revoked since the last base CRL publication.

Applications will verify certificates presented to them by consulting the CRL and reject any certificates on this list.

We can revoke a certifcate in the Certificate Authority MMC:

Unlike certificate expiration, which prevents the use of a certificate outside its validity period (and notably after), certificate revocation prevents the use of a certificate even if it has not yet expired.

Reasons for certificate revocation

A certificate may be revoked for a number of reasons. Here are some examples.

Loss of the private key (by theft or negligence)

The mobile device (laptop, tablet, smartphone) of a user is lost or stolen. The private key, stored on the device (by default), could be recuperated by someone with malicious intent. Since PKI consists in the interaction of the private and public key, we prevent this interaction by revoking the certificate containing the public key of the computer or user.

Compromise of the issuing CA

If the CA has been compromised, and notably its private key, an attacker could use that key to set up a new CA and issue certificates trusted by clients that trust the original or "real" CA. We would revoke the certificate of the compromised CA which would invalidate all certificates issued by the CA (since no certificate issued by this CA - or its clone - should be trusted).

Retired users and devices

When users retire or equipment is retired, it is best practice to revoke the associated certificates.

Replacement of old certificates with new certificates

We may need or want to replace old certificates with new ones. In this case, it is best practice to revoke the old certificates.

When we revoke a certificate, we can (and should) indicate the reason for which we are revoking the certificate:

Revocation is an irreversible act for all these reasons except "Certificate Hold". Although possible, it is not recommended to revoke certificates temporarily because it is difficult to determine at what time(s) the certificate was valid.

Note: it is better to revoke certificates based on a policy.

We must not decommission a CA if the certificates it issued are still meant to be used. Those less familiar with PKI may ask: "But why not? I'll just use some other CA to issue certificates in the future." We should remember that a CA not only issues certificates but also publishes a CRL of certificates it has revoked. If the CRL is not renewed at the interval determined at installation, the CA will no longer function. This is what we observed in a previous blog post. Please see the "Remarks" section below for more details.

Who can revoke a certificate?

Users granted the "Issue and Manage Certificates" permission. By default, administrators of the CA have this right. Domain and Enterprise administrators posess it as well.


The CRL is signed by the CA that publishes it.

This is very important concerning redundancy. When checking the revocation status of a certificate, we can only use the CRL published by the CA that issued that certificate. We cannot simply fabricate a list of serial numbers and make it available on the network. Once again, the CRL must be signed and only the signature of the same CA that issued the certificates to start with is valid. Clients cannot simply consult the CRL published by another CA.

If the CA is unavailable for a time exceeding the CRL validity period (plus whatever grace period - or "CRL overlap" - we have configured) the CA will go offline and stop functioning.

Note: we can obtain redundancy if we configure CA clustering which is an entirely different subject.

The Delta CRL is almost never necessary.

The client downloads the CRL associated with the certificate that it must validate. The file is so small (in KB) that there should be no effect on bandwidth, especially with 1 Gb or 10 Gb links. It is only if the CRL is exceptionnally large (this is apparently the case in some defense sectors) that a delta CRL may be useful.

Clients cache the CRL locally

 They only download the new CRL when the cached CRL expires.

This is advantageous concerning network bandwidth but creates a gap during which a very recently revoked certificate could still be accepted.

Imagine that the CRL is published at 12:01 AM (00:01) every day (so every 24 hours which is rather frequent). If a certificate is revoked at 12:05 AM, clients will only be informed almost 24 hours later. In the meantime, they will continue to use the cached CRL which does not contain the serial number of the very recently revoked certificate.

Each organization must evaluate the risk of such a delay versus the load on resources and notably bandwidth. Unless the CRL is very large, the effect on current systems should be negligeable.

We can see what is in the CRL cache with this command:

certutil -URLcache CRL

We can purge the CRL cache with this command:

 certutil –setreg chain\ChainCacheResyncFiletime @now

CRL overlap

When we set up our PKI, we can configure what is called "CRL overlap" with the post installation script . This is a sort of grace period during which our PKI will continue to function even though the CRL has expired. This might provide sufficient additional time to resolve a problem.

These are the CRL overlap settings that I configured for my subordinate CA in my first series of PKI blog posts:

certutil -setreg CA\CRLOverlapUnits 2
certutil -setreg CA\CRLOverlapPeriod "Days"

The overlap period cannot be longer than the validity period of the CRL. If the validity period was 3 days (which is what I configured elsewhere in the script), the overlap period could be 2 days at most.

OCSP (Online Certificate Status Protocol)

With this protocol, a client can validate single certificates as needed, via a web service, instead of downloading a CRL with the entire list of revoked certificates (most of which may not interest the client).  This is an optional function and I will not present it in this blog post.

No comments:

Post a Comment