Certificate Revocation, How it Works with CRLs or OCSP

SSL Certificate revocation plays a crucial role in maintaining the security and integrity of the Public Key Infrastructure (PKI) ecosystem.

When an SSL Certificate needs to be invalidated before its natural expiration date, the Certificate Authority (CA) must have reliable mechanisms to inform clients and browsers that the SSL Certificate should no longer be trusted.

This process helps protect users from compromised or fraudulent SSL Certificates that could otherwise remain active for months or years.

Understanding Certificate Revocation Lists (CRLs)

SSL Certificate Revocation Lists represent the traditional method of publishing information about revoked SSL Certificates.

A CRL is essentially a timestamped list signed by a Certificate Authority that contains the serial numbers of all revoked SSL Certificates that have not yet reached their expiration date.

When a browser encounters an SSL Certificate, it can download and check the relevant CRL to verify whether that SSL Certificate has been revoked.

CRLs are typically updated by Certificate Authorities at regular intervals, often every 24 hours or when an urgent revocation occurs. Each CRL contains critical metadata including the issuer name, effective date, and next update time.

While CRLs provide a comprehensive solution for SSL Certificate status checking, they can become quite large as they accumulate revoked SSL Certificates over time. This size issue can lead to increased bandwidth usage and potential performance impacts when clients need to download and process the lists.

Online Certificate Status Protocol (OCSP)

OCSP was developed to address the limitations of CRLs by providing real-time SSL Certificate status information.

Instead of downloading entire revocation lists, OCSP allows clients to query the current status of a specific SSL Certificate directly from the Certificate Authority. This approach significantly reduces bandwidth requirements and provides more immediate revocation status updates compared to CRL-based systems.

When a browser connects to a website secured with an SSL Certificate, it can send an OCSP request to verify the SSL Certificate status. The OCSP responder, operated by the Certificate Authority, will return a signed response indicating whether the SSL Certificate is valid, revoked, or unknown.

This process happens quickly and efficiently, typically requiring only a few kilobytes of data transfer.

OCSP Stapling and Modern Improvements

OCSP Stapling represents a significant enhancement to the traditional OCSP model. With OCSP Stapling, the web server periodically obtains an OCSP response from the Certificate Authority and includes (staples) this response directly in the SSL Certificate/TLS handshake.

This approach eliminates the need for browsers to make separate OCSP queries, reducing connection times and improving privacy by preventing the Certificate Authority from tracking individual SSL Certificate status checks.

Modern SSL Certificates issued by Trustico® support both CRL and OCSP revocation checking methods, ensuring maximum compatibility and security across different client systems.

Server administrators can configure their systems to use OCSP Stapling, providing optimal performance while maintaining robust SSL Certificate validation processes.

The implementation of these revocation checking mechanisms helps maintain the overall security of the SSL Certificate ecosystem and protects users from potentially compromised SSL Certificates.

Common Revocation Scenarios

SSL Certificate revocation typically occurs in several common scenarios. Private key compromise represents one of the most critical reasons for immediate SSL Certificate revocation, as it indicates potential unauthorized access to encrypted communications.

Other scenarios include organization name changes, server decommissioning, or the discovery of incorrect information in the original SSL Certificate request.

Certificate Authorities like Trustico® maintain strict procedures for handling revocation requests to ensure the integrity of the PKI system remains intact.