As certificate-based authentication continues to increase, ensuring that these certificates are valid and trustworthy is of extreme importance. Bad actors and threats are becoming increasingly sophisticated, so the way we monitor and validate certificates has needed to be developed to maintain the security of our precious data. In the following, we’ll explore what these protocols are, why they’re so important, how they’re different, and why the contemporary Security Engineer should become familiar.
CRLs (Certificate Revocation Lists) (yes, another acronym) are lists maintained by certificate authorities that aggregate all the certs that have been revoked before their expiration period. Basically, even if a certificate appears to be valid, it could be revoked or invalid for various reasons such as the private key being compromised, fraudulent issuance, domain control discrepancies, or a change in operational policies rendering the cert invalid and marking it for revocation.
CRLs are regularly published and updated by the CA. If a certificate is found on the CRL, the system will reject, or at least warn about that certificate, even if its expiration date hasn’t passed. Each entry typically includes data like the serial number, the date of revocation, and the reason it was revoked (if applicable).
While CRLs have been a great way to monitor and validate certificates for quite some time, it’s not without its shortcomings. The operational overhead associated with constantly fetching CRLs, especially in large-scale deployments, is quite lofty.
OCSP is the acronym for “Online Certificate Status Protocol.” It’s the protocol designed specifically for retrieving the revocation status of individual certificates. It’s an alternative to CRLs and is a more efficient way to check if a certificate has been revoked before its expiration date, as it’s only checking for 1 as opposed to scanning the entire list from a CA.
Here’s the ELI5 as to how it works:
1) Client sends a request to an OCSP responder, asking about the status of a specific certificate.
2) The OCSP responder, maintained by the CA, checks the status of the certificate in question.
3) The responder sends a response indicating the status as Good, Revoked, or Unknown.
Unlike CRL, which requires the download of lists, the OCSP offers a more real-time solution. With OCSP, apps can query the revocation status of an individual certificate on-the-fly. Instead of retrieving a whole list, the OCSP responder provides the status of a single certificate. While both CRL and OCSP address the same issue, they go about it in fundamentally different ways.
Efficiency: OCSP only checks the status of a specific certificate, thus avoiding the overhead of downloading large CRLs. This saves you money!
Timeliness/Latency: OCSP provides near real-time responses, while CRLs depend on periodic updates and can be outdated. This means stuff (naughty certs) could be slipping through the cracks.
With our cloud-based PKI solution, there’s absolutely no need to set up two servers for both CRLs and OCSP! One of the cool things about EZCA is that deciding between CRL and OSCP is as easy as clicking a button. Remove the guesswork from the equation and get started with the best native azure based PKI today! Learn more about how your colleagues in the security development community are using our certificate monitoring tool to ensure the security of their organizations’ data.
