Preface: Components of a PKI
Public key infrastructure (PKI) is a core technology in the identity and security stack. This technology uses encryption to allow entities such as an individual or device to be uniquely identifiable and able to store or transmit information securely. All modern organizations use PKI in some form or another. The digital certificate on a website that protects customers’ privacy and data is an example of PKI in action.
Fortunately, the fundamentals haven’t changed significantly since PKI was formally introduced in the X.509 standard in 1988. In this five-part blog series, we cover a few of the most important PKI components:
- Digital Certificates
- Certificate Authorities and CA Hierarchies
- Certificate Revocation
- Active Directory Certificate Services
- Hardware Security Modules
Part 3: Certificate Revocation
One important function of a Certificate Authority (CAs) that’s mentioned briefly in Part 2 of our “Components of a PKI” blog series is the ability to perform certificate revocation , or the CA’s ability to revoke certificates it issued previously. For example, if an attacker compromises a code signing certificate and is signing malicious executables on behalf of an organization, the ability to revoke the rogue code signing certificate is important to trusting the CA.
Not all CAs implement revocation checking, nor do all clients enforce revocation checking. Certain use cases such as network authentication (EAP-TLS) or smart card logon are intended to be stricter with revocation checking.
What Is Certificate Revocation and When Should I Use It?
Certificate revocation occurs when a certificate is deemed untrustworthy for various reasons. These reasons could include the compromise of the private key associated with the certificate, the issuance of a certificate to an entity no longer considered trustworthy, or the discovery of a vulnerability that affects the certificate’s security. Once a certificate is revoked, it is no longer considered valid, and any systems relying on that certificate for secure communications should stop trusting it.
CAs play a crucial role in the revocation process. When a compromised certificate or expired certificate needs to be revoked, the CA adds it to a Certificate Revocation List (CRL) or publishes its status to an Online Certificate Status Protocol (OCSP) responder. These mechanisms allow systems to check the status of a certificate and determine whether it has been revoked before establishing a secure connection. Certificate lifecycle management, which includes the issuance, renewal, and revocation of certificates, is vital to maintaining the integrity of digital communications. Effective certificate lifecycle management ensures that only valid certificates are in use and that revoked certificates are promptly removed from circulation.
Revocation should be used whenever there is any indication that the security of a certificate has been compromised. This could be due to a breach, key exposure, or any other situation where the certificate’s integrity is in question. With proper certificate management, organizations can protect themselves and their users from potential security threats, ensuring that their digital communications remain secure and trustworthy.
What Is a Certificate Revocation List?
A Certificate Revocation List (CRL) is a digitally signed record of all certificates that have been revoked by a CA. The CRL is published in a location that all clients (both subscribers or entities authenticating subscribers) would be able to retrieve, such as a web server or an LDAP container.
Due to the nature of certificate revocation checking, CRLs are supported only for HTTP and cannot be served via HTTPS. Chain building would fail when attempting to access a URI that requires revocation checking as well. Since the CRL is digitally signed, clients have assurance that the CRL was published by the CA regardless of communication over untrusted or hostile networks. Without compromising the CA’s private key, it would be computationally unfeasible to generate a CRL on behalf of a CA.
When a certificate is revoked from the CA, the next CRL published by the CA will include the serial number, revocation date, and CRL reason code of the revoked certificate. Figure 1 shows an example.
How Are Certificate Revocation Lists Configured on Certificates?
When we discussed the anatomy of a certificate in Part 1 of our “Components of a PKI” blog series, you may have noticed that the www.ravenswoodtechnology.com certificate was configured with two URIs in the CRL Distribution Point (CDP) extension, as Figure 2 shows. If this field isn’t present on a certificate, then the CA hasn’t implemented CRL revocation checking.
When a CA is configured, the CDP extension is used to populate the URIs of CDPs on issued certificates. Figure 3 shows an example of configuring the CDP extension on a Microsoft Active Directory Certificate Services (AD CS) Enterprise CA. (For more information about AD CS, see Part 4 of this blog series.)
What Is OCSP?
One of the major limitations of CRLs is that the files will become extremely large in environments with substantial certificate issuance and revocation. The size of the CRL can impact performance for bandwidth-limited clients such as mobile devices. By the end of 1999, Online Certificate Status Protocol (OCSP) was formally introduced in RFC 2560 as an alternative to the traditional method of using CRLs for determining revocation status.
OCSP relies on implementing OCSP responders, which are web servers from which clients can request the revocation status of individual issued certificates during certificate verification. The client will submit a certificate serial number to the OCSP responder, and the OCSP responder provides a digitally signed response confirming the revocation status.
OCSP responses are a fixed size on the network, and most modern clients (e.g., your cell phone) will attempt to communicate to the OCSP responder before verifying the CRL. In a scenario in which both OCSP and CRL are configured on a certificate and OCSP is offline, the client will fail the authentication.
Figure 4 illustrates the architecture of CRL/OCSP revocation checking with the following steps:
- CA digitally signs a CRL with the CA’s private key and publishes it to the CRL web server.
- CA issues an OCSP signing certificate to the OCSP web server.
- OCSP web server downloads the CRL periodically to have the latest revocation status information available for any OCSP clients.
- CA issues a client certificate that includes the CRL and OCSP URIs.
- Client downloads the digitally signed CRL from the CRL web server and checks if the issued certificate’s serial number is revoked.
- Client sends a signed OCSP request with the issued certificate’s serial number to the OCSP server.
- OCSP server returns a signed OCSP response with the issued certificate’s revocation status back to the client.
What is OCSP Stapling?
OCSP stapling is a crucial component of cybersecurity protocols aimed at enhancing the security and efficiency of online communication. This technique enables web servers to proactively provide clients with the status of digital certificates without requiring them to independently query the Certificate Authority’s OCSP (Online Certificate Status Protocol) responder. By “stapling” the OCSP response to the initial TLS handshake, servers streamline the authentication process, reducing latency and potential vulnerabilities associated with external OCSP queries. OCSP stapling not only bolsters security by ensuring the timely validation of certificate statuses but also enhances privacy by minimizing the exposure of client information to third-party OCSP responders. As a result, OCSP stapling serves as a proactive measure in safeguarding against potential security risks and optimizing the performance of secure online interactions.
How Is OCSP Configured on Certificates?
When we discussed the anatomy of a certificate in Part 1 of our “Components of a PKI” blog series, you may have also noticed that the www.ravenswoodtechnology.com certificate was configured with a single OCSP URI in the Authority Information Access (AIA) extension, as Figure 5 shows. If this field isn’t present on a certificate, then the CA hasn’t implemented CRL revocation checking.
When a CA is configured, the AIA extension is used to populate the OCSP URIs on issued certificates. Figure 6 shows an example of configuring the AIA extension on a Microsoft AD CS Enterprise CA. (For more information about AD CS, see Part 4 of this blog series . ) As you can see in Figure 5 (see “[2]Authority Info Access”) and Figure 6 (see “Include in the AIA extension of issued certificates”), the AIA extension is also used to publish the issuer certificate for clients to be able to automatically build the certificate chain if the issuer certificates aren’t present on their device.
Final Remarks
Certificate revocation is often the most overlooked aspect of an organization’s PKI solution. Implementing certificate revocation isn’t necessary in all situations and comes with the responsibility of having a reliable revocation publishing infrastructure. (Note that an expired or unreachable Certificate Revocation List will prevent the client from authenticating successfully.) Revocation checking may be required for organizations that authorize access to a corporate identity or network with their internal PKI certificates. If you aren’t sure whether your PKI is implementing certificate revocation correctly, Ravenswood Technology can help. Contact our team today!
Read more in Part 4 of this blog series: Active Directory Certificate Services.
