A digital certificate has a limited validity period, but sometimes you want to “expire” a certificate before its expiration date. There is no way to know even how many copies of a given certificate there are, let alone where they are located. So, there is no way to reach out and delete them or change their expiration date (which would make the digital signature fail anyway).
The same problem happens with credit cards. Sometimes people don’t pay their bill, so you want to stop people from using them. Originally, credit card companies published booklets of revoked credit card numbers (sorted by card number to make it easier to look up). Clerks would check the booklet before accepting a card, which took time. If the number of the card they were checking was not listed, they would accept the card (the booklet is what is known as a “blacklist” – a “whitelist” would be a list of all the valid credit cards, which would be enormous).
Later, credit card companies provided little machines that could dial in to their computers, check for a revoked credit card number, and even verify if the current transaction was covered by available credit. This was much faster and did not require little booklets to be published frequently. That is still in use today, only many of the machines actually connect over the Internet.
With certificates, the first approach corresponds to using Certificate Revocation Lists (CRLs). The second approach corresponds to the Online Certificate Status Protocol (OCSP).
It is the responsibility of every relying application to check either CRL or OCSP for the current revocation status of a certificate before it is used.
Like credit cards, digital certificates have expiration (ValidTo) dates. They also have start (ValidFrom) dates, which most credit cards don’t have. Normally, the start date is the issue date, but it doesn’t have to be. You could start the validity period a week or a month after the issue date. The end date is normally one year (or however long you paid for) after the start date. The certificate is only valid between the start and end dates. It is up to the software that uses the certs to not use it outside of the validity period. There are times you have to use an expired cert (or the corresponding private key), for example, to open old encrypted messages in your email message store. One solution is when you renew your certificate to go through the message store and decrypt any encrypted messages with your old private key and then encrypt them again with your new public key. Once that is done, you can toss your old cert and private key (or at least archive them).
Certs can be issued for any validity period. It is common to issue them for one year, two years, or even three years. The longer the cert life, the less frequently you have to renew them, but the more likely it is that the information in the cert will no longer be current or accurate. Recently, some vendors (like Apple) have said that they will not accept certs longer than 13 months after their start date. Now this is standard industry practice.
You can ask a CA to renew your cert any time (usually for free if it is not yet expired). The end date will normally not change unless you paid for a cert lifetime longer than the original validity period. You don’t get additional certificate lifetime unless you paid for it. In some cases, you can even change the SubjectDN information when you renew (say if you changed your name or email address). Of course, the new information must be validated the same as for the initial issue.
Some people believe that CAs put expiration dates on certs just so they can charge you again for a new cert once a year. The real reason is to force the issuing CA to review the identifying information in the cert’s SubjectDN and update anything that is no longer valid or current. There is nothing that says the CA has to charge a full certificate price when they renew a cert or charge anything at all. Some CAs still sell two- and three-year certs and will renew them for free (for 13 months each time) until you have used up the lifetime you paid for.
Another reason for an expiration date is to keep the revocation list from growing without bound. Once a cert reaches its expiration date (actually a bit after that), it can be purged from the appropriate CRL (or OCSP database). Without expiration, CRLs could grow without bound.
Certificate Renewal
Once a cert has expired, if you want to continue using it, it must be renewed. Most cryptographic tools will reject expired certificates, just like most stores won’t accept an expired credit card. This is very similar to doing the initial certificate request. You can create a new CSR and new private key with the same info as the existing cert and submit it to the CA for signing as usual. If you happened to save the old CSR and private key, you can just resubmit it (which would be renewal with rollover).
There are two ways you can renew a cert:
Renewal with rollover – You keep the old public and private keys but create a new certificate with a later expiration date. I call this “old wine in new bottles.” In this case, you can still open all your old encrypted emails. You still need to update your cert in shared address books, since the old cert will now be rejected as “expired.” The downside is that the longer you use a given key pair, the more likely it is to have been compromised. At some point, you really should do renewal with replacement.
Renewal with replacement – You create a new key pair and use that to create the renewal CSR. I call this “new wine in new bottles.” In this case, you will need the old private key to open old emails (unless you bulk re-encrypt all old messages with the new public key). You also need to publish your new cert in any directories the old one was published in (and hopefully notify people using your cert to refresh their copy from the shared address book). The longer you use a given key pair, the more likely it is to be compromised. So, renewal with replacement limits the time you use a given key pair.
It is possible to construct a valid CSR from any existing cert (even ones from other issuers), and then the new CSR can be submitted for signing as usual. You can even make changes to the SubjectDN information before submitting it if needed. It can do it with key pair replacement or rollover. The CA will happily sign the certs either way. They don’t keep track of your old key material to compare your public key with.
Certificate Revocation
If you don’t pay your credit card bill, the credit card company will revoke your charging privileges. In some cases, if you present your card to a store after it is revoked, they may confiscate your card or cut it in half. If you only use your card online, there is no way anyone could seize or destroy your card.
Years ago, credit card companies published little booklets with a list of all revoked credit card numbers (sorted by card number). Before they would accept your card, stores would check if your card number was in that booklet, and if it wasn’t, they would accept your card (it was a blacklist, not a whitelist). Sorting the card numbers made it quicker to check for a given card.
A user could still charge things until a new booklet came out, which the card company might have to take a loss on. If a store didn’t check and the card number was already in the booklet, the store might be liable for bogus charges.
Certificate Revocation List (CRL)
Certificates have a similar scheme called Certificate Revocation List (CRL). A CRL is a list of all certificate serial numbers that have been revoked, but not yet expired. Once expired, the certs should not be accepted regardless, and the serial number can be removed from the CRL.
The CRL is specified in RFC 5280, “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile,” May 2008.
Each certificate hierarchy (e.g., DigiCert SHA2 Assured ID CA) has a separate CRL. Each certificate in that hierarchy will contain a CRL Distribution Point for CRLs for that hierarchy. You may have quite a few cached CRLs for different hierarchies on your computer at any given time, each with its own Next Update date and time. A public CA may have quite a few certificate hierarchies.
A certificate hierarchy
In this certificate, the End-Entity Cert (tz270.us.hughesnet.org) is a TLS server cert. It chains up to the Sectigo RSA Domain Validation Secure Server CA Intermediate Cert. That in turn chains up to the USERTrust RSA Certification Authority Intermediate Cert. Finally, that one chains up to the root of this hierarchy, the Sectigo AAA Root Cert. The entire hierarchy consists of the Root Cert, the two Intermediate Certs, and possibly thousands of End-Entity Certs.
Microsoft viewer for the CRL
From this, you can see that DigiCert issues a new CRL every week. Basically, if there are no CRLs cached on a given system for this certificate’s hierarchy, the next time you need to check a certificate from this hierarchy, you need to download the current CRL from the CRL Distribution Point in the certificate. You can use that CRL for this hierarchy until a new CRL is issued (which is in the CRL as Next Update). At that time, you need to obtain the new CRL and cache it.
The entire list of certificates that have been revoked
Each entry in this list has a 128-bit serial number of a specific certificate and the date and time it was revoked. Even though it is not shown here, it also includes a reason why the certificate was revoked.
The list is digitally signed by the CA when it is issued, so each client can know that it is the authentic CRL for this certificate hierarchy and has not been tampered with in any way since it was issued. Every time a client node uses a CRL, it checks that signature before trusting the information in the list.
Each computer has a separate CRL cache, so when my desktop downloads a new CRL, that new CRL isn’t available to my notebook computer, which must also download the new CRL the next time it has to check a certificate from that hierarchy.
As with credit cards, with CRLs, there is a delay between the time the CA revokes the certificate and the relying parties become aware of that revocation. The more frequently CRLs are issued, the shorter that delay is, but the more often CRLs have to be downloaded. It is common for CRLs to be reissued every 24 hours, but some CAs have premium service to reissue them every hour. Because of the “next issue time” and caching, CRLs don’t use that much bandwidth.
OCSP (Online Certificate Status Protocol)
Checking the revocation status of a card
CAs came up with a similar scheme, based on a new protocol called Open Certificate Status Protocol (OCSP). A new company called ValiCert split off from VeriSign and opened just down the street. They specialized in OCSP deployments. OCSP is currently specified in RFC 6960, “X.509 Internet Public Key Infrastructure Online Certificate Status Protocol – OCSP,” June 2014.
Anytime a relying party is presented with a cert, it can send just that serial number to the CA (based on information in the cert) via OCSP and get back a go/no-go status reflecting the current revocation status of that cert. Once it gets back a “revoked” status on a given cert, it can cache that, because once a CA revokes a cert, it will never “unrevoke” it.
In theory, this could reduce the delay from revocation to end users becoming aware of it to near zero, but many OCSP servers just provided another way to access the CRL information, so there was still a delay, but it was easier to determine revocation status.
OCSP queries can be the majority of the network traffic at a CA. Most people don’t request or renew certs all that often (typically once a year for a given cert), but OCSP could be used every time a cert is presented. It is possible to have a local cache that is queried instead of going all the way to the CA on every request. In practice, an OCSP response also includes a “next issue” timestamp, and each client can cache the OCSP response until the next issue time arrives. This holds down the traffic related to revocation checking significantly.
OCSP is simpler to implement than CRLs but can involve a lot more network traffic. If you want to minimize total network traffic, it is better to use CRLs.
Supporting Certificate Revocation on Your Own CA
If you deploy your own CA, for example, with Microsoft Certificate Services, you must generate CRLs and/or deploy an OCSP server to allow relying applications to check the current revocation status. Microsoft Active Directory Certificate Services takes care of all this for you, storing the information in your Active Directory and providing URLs to that information. It also periodically updates the CRLs in Active Directory. Every relying application needs to have access to the http or ldap servers that publish the CRLs or provide OCSP service.