Revocation checks are performed to verify the validity of digital certificates. These checks are performed when connecting to a secure website, validating a digital signature, or launching a signed executable. A certificate may be revoked if the certificate’s private key has been compromised. Scenarios like this may lead to impersonation of an entity or perhaps distribution of malicious code.
To better understand digital certificates and revocation checking, we can compare them to health and safety certificates in restaurants. A restaurant with a certificate would mean that the establishment was reviewed and found to be in good standing. Just like a TLS certificate, the health and safety certificate has a validity period. Suppose the health and safety certificate is valid for one year, what if a code violation happens 6 months into the certificate’s validity period? The start and end dates would still imply the restaurant is in good standing. This is where revocation checks come in.
When you connect to a website through your browser, the web server will send back its TLS certificate. Before the connection is complete, a series of validation checks are performed, including revocation checks. There are a few different methods for performing revocation checks, which method is used may depend on your browser, system, and/or server settings. This cohesion of checks and balances exist to manage risks to users and protect digital transactions, communications and assets.
Certificate Revocation Lists (CRLs)
Certificate Revocation Lists (CRLs) are essentially text files listing serial numbers of revoked certificates. If a client connects to www.example.com and the browser is configured to check CRLs, it will get the URL for the certificate revocation list from the CRL Distribution Point field in the TLS certificate. With this, your browser will download the entire revocation list and search through it for the serial number of the certificate in question. If it is on the list, the certificate is revoked. This process is executed each time a new visitor connects to the site.
In the restaurant example, this would be like visiting a restaurant and looking at the certificate on the wall, taking note of the serial number on the certificate and the location of the office that performed the certification. To see if the restaurant is still in good standing, someone in your party is sent to the Health & Safety Board’s office who will provide an inventory of serial numbers representing restaurants with poor scoring. If it's in the book, you shouldn't eat there.
This inventory cannot be shared, however, and each customer must repeat this process, retrieve their own copy, and perform the search themselves. The only thing that may expedite this process is if you decide to eat there the next day and presume, they are still in good standing because you just checked the previous day.
In practice, your operating system and browser cache certificate revocation last on average, for about 7 days. When you visit a site that refers to the same CRL, it can check locally instead of re-downloading the entire list. When you access a site that uses a different CRL or when your local copy expires, a fresh copy is downloaded.
This system does not scale well and very large CRLs may cause a performance hit.
Online Certificate Status Protocol (OCSP)
Online Certificate Status Protocol (OCSP), was developed as a replacement to Certificate Revocation Lists, though both remain in use today. As with CRLs, there is an address for the OCSP responder embedded in your certificate, this time in the Authority Information Access (AIA) field. Web browsers and operating systems can use this address to query the OCSP responder and find out the status of a certificate.
This addresses the scalability issue with CRLs as the entire list does not need to be downloaded. Instead, a server can be queried like a database for a quick response.
Returning to the restaurant example, this would be like visiting a restaurant and taking note of the serial number of the certificate on the wall as well as the phone number of the certification office. You call up the certification office and read off the serial number of the certificate. The certification office lets you know whether the certificate in question is on the list or not.
Again, if you visit this restaurant frequently, you may not check every single time. OCSP responses, like CRLs, are also cached by browsers and operating systems for quick retrieval later. The local copies also have a validity of about 7 days.
OCSP Stapling
OCSP Stapling builds upon OCSP further increasing performance. If you have OCSP Stapling set up, your server will periodically reach out to the OCSP responder to retrieve a signed, timestamped response that you can host yourself. This response is “stapled” and sent to connecting clients. This method eliminates the need for clients to send a separate request to a 3rd party server.
For the restaurant example, this would be like the establishment calling up the certification office every few days to request an official seal showing that they are still in good standing. The official seal would be dated and only be valid for a day or so. Upon entering the restaurant, visitors would see the certificate on the wall and an authentic seal with a recent date showing that it is still in good standing.
Checks and Balances
Ultimately, these processes exist to ensure a digital community of trust and to provide reliability of certificates, their clients, and their issuing CAs. Without this crucial step in creating a safe digital space, the trust hierarchies that are established as part of Root Ubiquity in the digital space would be meaningless. This system exists to create checks and balances within digital communications and provide a foundation of trust between CAs, browsers, and organizations.
Speak to our experts and create greater trust within your organization
