I am reading about how certificates work in the context of X.509, SSL/TLS/HTTPS. According to Wikipedia, the client (e.g. a browser) is supposed to check the revocation status for each non-root certificate as a part of certification path validation. The preferred way (see comment) of doing this is an OCSP request or OCSP stapling. Wikipedia also says that an OCSP response is signed by the CA that issued the certificate in question (item 6 below):

  1. Alice and Bob have public key certificates issued by Carol, the certificate authority (CA).
  2. Alice wishes to perform a transaction with Bob and sends him her public key certificate.
  3. Bob, concerned that Alice's private key may have been compromised, creates an 'OCSP request' that contains Alice's certificate serial number and sends it to Carol.
  4. Carol's OCSP responder reads the certificate serial number from Bob's request. The OCSP responder uses the certificate serial number to look up the revocation status of Alice's certificate. The OCSP responder looks in a CA database that Carol maintains. In this scenario, Carol's CA database is the only trusted location where a compromise to Alice's certificate would be recorded.
  5. Carol's OCSP responder confirms that Alice's certificate is still OK, and returns a signed, successful 'OCSP response' to Bob.
  6. Bob cryptographically verifies Carol's signed response. Bob has stored Carol's public key sometime before this transaction. Bob uses Carol's public key to verify Carol's response.
  7. Bob completes the transaction with Alice.

It is also said that the CA can certify a third party to provide revocation checks for certificates that the CA issued:

The key that signs a response need not be the same key that signed the certificate. The certificate's issuer may delegate another authority to be the OCSP responder. In this case, the responder's certificate (the one that is used to sign the response) must be issued by the issuer of the certificate in question

I have the following questions.

  1. If the CA does not delegate OCSP responses related to certificates it issued, how is creating OCSP responses different from creating short-lived certificates and re-issuing them?

OCSP responses have to be produced for each certificate every x minutes or days, and so would be the certificates. If the subject's key pair or identity is compromised, then revoking the issued certificate via OCSP is equivalent to not extending a short-lived one. If the CA's key pair is compromised, a malicious actor could fake a favourable OCSP response with these keys. Also, if the client chooses to soft-fail when a revocation check is unavailable, they can equally accept a short-lived certificate that expired just recently. From the subject's perspective, OCSP stapling seems equivalent to attaching short-lived certificates. I can't see any substantial difference at all.

  1. If the CA involves an intermediate party (or an intermediate certificate of its own) in handling OCSP responses, what are advantages of this? Again, how would it be different from the same intermediate entity or certificate issuing short-lived certificates for subjects?

It could be that I completely misunderstand the point of revocation checks, in which case I'd appreciate an explanation.

  • 2
    Who says OCSP is preferred? CABforum recently revised their Baseline Requirements (in practice used for most TLS, though their members only 'control' HTTPS) to make OCSP optional, CRL required, and NO revocation for short-lived certs (max 10 days for a transition period then 7 days); see thesslstore.com/blog/… . But major browsers actually manage the CRLs themselves rather than naively downoading them: ssl.com/blogs/… Jan 31 at 4:29

2 Answers 2


An OCSP response without a corresponding certificate is meaningless. All it provides is a certificate ID, the revocation status, a validity interval and possibly some extensions. You cannot use this information for establishing a TLS connection, because there's no public key and no indication which host the public key belongs to. For this, you need the certificate itself. In the context of TLS, X.509 certificates bind a public key to a particular host, identified either through DNS names or IP addresses. This allows a client a establish a TLS connection and be sure they're actually communicating with the host in question rather than, say, a man-in-the-middle attacker.

The procedures for issuing certificates and creating an OCSP response are also entirely different. For an OCSP response, the CA just has to perform some database lookup and check whether or not they've revoked a particular certificate. To issue a certificate, the CA has to go through a more or less complex identity verification to ensure that the requester does in fact control the DNS name or server which the name points to.

Of course one could envision an infrastructure with very short-lived certificates which are re-issued every day or even every few minutes. The problem is that on a large scale, this would require a lot of resources just to perform identity verifications all the time and constantly replace the certificates. For example, in 2021, Let's Encrypt reported they're issuing around 2 million certificates per day. They've also estimated that if they had to immediately re-issue all certificates due to a catastrophic bug, they would have to issue around 200 million certificates in 24 hours. This possible scenario lead them to significantly beef up their infrastructure. Now imagine every CA had to re-issue every certificate every day -- this would be a major undertaking with enormous costs. Servers would also have to obtain and install new certificates all the time.

So this wouldn't be realistic. CAs like Let's Encrypt have already moved to relatively short-lived certificates with a 90-day validity period, but I doubt they'll make it much shorter than that in the near future.

As to the second question: The advantage of outsourcing OCSP operations to a separate CA is that this can increase security and allow CAs to use their infrastructure more efficiently. OCSP responders are by definition reachable over the network all the time, so there's a relatively high risk they'll be compromised. To reduce the effects of an attack, it makes sense to create a separate CA which is only allowed to sign OCSP responses (not issue new certificates) and has a short validity period. CAs may also want to use different hardware for issuing certificates and creating OCSP responses, since those involve two very different procedures, as explained earlier.

  • Thanks! Besides identity verification, is there anything else that makes issuing a certificate a significantly more costly procedure compared to OCSP responses? Also, in response to the 2nd question, when you mention a "separate CA", do you refer to a legal entity (an organisation) or an abstract entity identified with a key pair? Or it does not matter? Jan 31 at 2:52
  • 1
    With separate CA, I mean a separate key pair with a corresponding certificate. Each organization typically has a hierarchy of certificates with one root certificate at the top (which has a very long validity and may be stored in browsers) and several sub-certificates which are signed with the root certificate and can be used for different purposes (issuing certificates, signing OCSP responses, signing CRLs, maybe more). Of course it's also possible to have a separate legal entity take care of the different tasks, but from a technical standpoint, it's irrelevant who is behind the certificates.
    – Ja1024
    Jan 31 at 4:24
  • 1
    Besides identity verification, there's nothing particularly expensive about issuing certificates. Cryptographically, it's all just signature calculation.
    – Ja1024
    Jan 31 at 4:24
  • 200 million certificates in 24 hours. Jan 31 at 8:45

Many servers still aren't set up for automatic certificate rotation. If their CA issued only very short-lived certificates, those servers would require a lot of ongoing maintenance to keep them supplied with valid certificates. Obviously, one would hope that automation would quickly come to take care of this, but it's not trivial. Shared hosting platforms don't always allow sites to execute the agents necessary for automatic certificate renewal (the newer ones support renewal automatically, at least for some CAs like LetsEncrypt).

Cryptographically, issuing a new certificate or a new OCSP response are basically identical procedures. Operationally, though, they really aren't. Typically, issuing a certificate:

  1. starts with the requester generating a key pair
  2. then a Certificate Signing Request (CSR)
  3. then sending the CSR to the CA
  4. then the CA verifies the requester's identity
  5. then the CA produces the signed cert (which gets sent to the requester and also listed in Certificate Transparency logs)
  6. then the requester installs it where it's needed.

Some of these steps can be skipped when re-issuing certificates (for example, if you don't expect the private key is compromised, it's OK to re-use the key pair) and many can be automated, but it's still considerably more complex than issuing an OCSP response. Additionally, sometimes you can't just renew the certificate; in any situation where normally you would revoke it, you have to complete much or all of the standard issuing process again. In many cases that still won't be terribly operationally expensive, and even in the worst case it's probably no worse than revoking the cert using OCSP, but it is a process that you need to be ready for, or else the site effectively goes offline until the replacement cert is issued and installed.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .