Before understanding the OCSP, we must know about the CRL.
CRL (Certificate Revocation List)
The definition lines on its name, Certificate Revocation List also you can call “blacklist of X.509 digital certificate”. It contains a list of revoked digital certificates from certificate authorities before their assigned expiration dates that should no longer be trusted.
CRLs provide a method of confirming the status of digital certificates by adding certificate serial numbers to a list that is signed and maintained by a Certification Authority. It also includes the date and time it was revoked, and the reason.
Certificates can be revoked for several reasons. For example, if a user uses a certificate for authentication and the user leaves the company and to make sure no one can use that certificate for authentication, we revoke the certificate.
Simple, isn’t it? Of course!!!
BUT! BUT! BUT!
Over the period, this list can get large depending on the number of certificates issued and revoked. This can have a negative impact on network performance because many clients have to download CRLs. The Windows clients will timeout after 15 seconds while trying to download CRL.
The main issue with CRLs is that they contain information about all revoked certificates, which can be an excessive amount of data. This is problematic because an application or operating system may only need to know the revocation status of a few specific certificates.
To use a CRL, the application or OS has to download the entire CRL and then parse through it to find a match for the serial number of the certificates. This process can be inefficient and resource-intensive, especially when dealing with a large number of certificates.
Now what??? I got you.
With the limitations of CRL, OCSP comes into play. Now let’s talk about it,
It stands for Online Certificate Status Protocol, which is used to return the revocation status of an X.508 digital certificate. It is a real-time check of a website certificate’s revocation status. The OCSP responder then sends back one of three certificate status responses — good, revoked, or unknown — and the client can then react accordingly.
How it works?
– Client sends a request to the OCSP responder or calls it OCSP Server with the serial number of the certificate to check its status.
– The responder first checks if it has a cached response for that certificate, if not it checks if it has CA’s CRL cached locally.
– If the CRL is cached, it checks the revocation status and sends the signing response, if not it retrieves the CRL from the CA’s location then parses the CRL, determines the status, and sends a signed response.
– The response is signed with the OCSP responder; ‘s certificate.
Reference: https://www.thesslstore.com/blog/wp-content/uploads/2020/07/certificate-revocation-ocsp.png
We have now understood the CRL and OCSP. Now, let’s see how we can setup the lab on Windows Server in this article.
Reference:
1. https://www.thesslstore.com/blog/crl-explained-what-is-a-certificate-revocation-list/
4. https://www.thesslstore.com/blog/ocsp-ocsp-stapling-ocsp-must-staple/
3. https://blog.ascertia.com/what-is-ocsp-and-how-does-it-work
