I've been looking into OCSP stapling for HTTPS, which looks pretty interesting. From what I can tell, it's essentially a way of offloading CRLs from the CA to the server, allowing for everything to be done in one connection, which mitigates some privacy issues. How does the process work from a high-level perspective?

I'm mainly interested in:

  • Where / how does OCSP stapling get flagged as enabled? Is it something the CA does?
  • How does the server get the updated CRL from the CA? How does it know when to update?
  • What stops someone from stripping the "OCSP is enabled" flag from the handshake?
  • If the SSL connection is compromised (e.g. through BEAST or a private key leak) does it open up an opportunity for the attacker to cause long-term problems by manipulating the CRL?

1 Answer 1


A CRL is an object which contains the list of serial numbers of certificates which have been revoked by a given CA. It is a signed object; the CRL issuer is usually the CA itself (with the same key) but this power can be delegated.

An OCSP response is what an OCSP responder returns when it receives a request about the revocation status of a certificate. The request / response protocol is specified in RFC 2560. The responses themselves are signed by the responder and they can have an independent life; this means that a given OCSP response can be considered as a specialized CRL which talks about a single certificate.

During certificate validation, the verifier (e.g. a Web browser, when validating the server's certificate) must build a chain of certificate, from one of its trust anchor (aka root certificates), verify all the signatures and names and extensions, and then proceeds with ascertaining the revocation status of each certificate in the chain. This last step entails obtaining CRL and/or OCSP responses, validating them (which means verifying the signatures on them), and reading their contents. This raises two distinct types of question:

  1. How does a verifier check that a CRL or OCSP response is genuine and up-to-date and really applies to the certificate at hand ?
  2. How does a verifier obtain the CRL or OCSP response in the first place ?

CRL / OCSP match with a certificate

Let's concentrate on the following setup: the verifier wants to obtain the revocation status of certificate T (as "target"). He has already built and verified a chain of certificates which ends with CA certificate C followed by T, which means that the signature on T matches the public key in C. Also, the revocation status of C has been verified, and it is now T which the verifier is interested in. T can be an end-entity certificate (e.g. the SSL server's certificate) or another CA certificate as part of a longer chain, which extends beyond T.

A CRL is signed; who signs it is a matter of a subtle distinction between X.509 and its PKIX interpretation in the context of the Internet. For the "original" X.509, a CRL is valid if it is signed by an entity who has a valid certificate and bears the same Distinguished Name as the CA. This works well if the CRL is signed by the same public key than T, i.e. the key of the CA C: at that point, C is a fully validated certificate so its public key can be "trusted" (the verifier is reasonably sure that the public key is really owned by an entity which goes under the name given in C's subjectDN field). However, it could be any other certificate with that name, and located at the end of a valid chain of its own (which may imply more path building, validation and processing of CRL). In X.509, distinguished names are everything, because X.509 was meant for the Directory, the worldwide LDAP-like server aggregate where everything is uniquely referenced by it distinguished name.

PKIX, the working group which deals with the Internet, has noticed that the Directory, marvelous as it may be, shares some characteristics with mythical beasts like the Mokèlé-mbèmbé, specifically that it does not appear to exist at all (at least, no confirmed sighting has been reported). Correspondingly, PKIX enforces a restriction to keep trouble contained: the certificate of the CRL issuer must be at the end of a path which begins with the same trust anchor as the path which ends with T. This should avoid trans-root issues when two distinct CA which do not know each other ended up using the same distinguished names (they could have noticed the issue right away if they had worked in the context of the Directory, if it had existed). This specific point is in RFC 5280, section 6.3.3, step (f).

The role of CRL issuer can be delegated, in which case the distinguished name of the CRL issuer is found in the CRL Distribution Points extension in T itself, and a matching Issuing Distribution Point extension is found in the CRL.

For OCSP responses, a similar system is used. The OCSP response may be signed by the CA itself (with the key in C); or there may be a dedicated issuer. Things are more constrained there: when there is a dedicated issuer, it must have a certificate which is directly issued by C itself, and bearing a specific extension which marks it as an OCSP responder (Extended Key Usage with the id-kp-OCSPSigning OID, see section of RFC 2560). The certificate for that responder can be attached to the OCSP response itself (outside of the signed area, but encoded within the same blob nonetheless).

The important point is that it does not matter how the CRL or OCSP response were obtained: they are signed object, verifying the signatures and all the name matching and extension contents is sufficient. The object themselves can travel over TCP connections, emails, USB keys, caravans of camels, learned by heart and declaimed by a Shakespearian actor, whatever. The signature abstracts these details away. Certificates, CRL, OCSP responses cannot be "manipulated" without invalidating the signature.

CRL and OCSP responses have validity dates. They both have a thisUpdate field which tells when they were issued (formally, the date at which the information they contain was gathered). They also have a nextUpdate field which is the date before which a newer version should be issued; thus, it serves as a kind of expiry date. It is expected that verifiers cache CRL and OCSP responses, using these dates to know whether the cached version is still usable, or a new one should be obtained.

How to locate CRL and OCSP responses

The way a CRL or OCSP response is distributed is not important for security, but, of course, a verifier cannot guess URL out of thin air. The URL at which CRL can be downloaded is encoded in the CRL Distribution Points extension of the certificate T (this extension has two roles: a validating role for delegation of CRL issuance power, and a descriptive role to give pointers to locations where the actual CRL could be downloaded). http:// URL are common, but also ldap:// URL (especially in closed environment like enterprise networks). An https:// URL for CRL download can lead to a loop (since the download entails validating the certificate of another SSL server) hence it will tend not to be supported well, or at all (Windows will not follow such URL).

Similarly, the URL at which an OCSP responder can be found is in the Authority Information Access extension in certificate T.

These URL are indicative only; the verifier can use any CRL or OCSP response it could obtain, regardless of its provenance, provided that all the signatures are verified. Since CRL and OCSP responses have a non-negligible lifetime, it makes sense to cache and reuse them. OCSP stapling is a way for a SSL server to obtain OCSP responses for his own certificate, and provide them to the client, under the assumption that the client may need them. This makes the whole process more efficient: the client does not have to open extra connections to get the OCSP responses itself, and the same OCSP response can be sent by the server to all clients within a given time frame. One way to see it is that the SSL server acts as a Web proxy for the purpose of downloading OCSP responses.

OCSP stapling is entirely up to the SSL server; the contents of the certificates and OCSP responses is unaffected. The CA or the OCSP responder need not be aware that stapling occurs at all.

"Removing" the OCSP stapling flag from the handshake would break the Finished messages at the end of the handshake, so this is not feasible for the attacker, unless this would allow him to break the whole handshake before the end. However, it does not: the lack of OCSP stapling does not mean that the client will not ascertain revocation status; it just means that the client will be on his own, and will have to obtain the CRL or OCSP responses by itself.

The unfortunate thing about OCSP stapling is that it is not yet widely supported. The idea is sound, though. Its security implications is that, with stapling, a SSL server has a powerful argument to convince the Web browser to actually do its job and not skip revocation status checks altogether, like many Web browsers are unfortunately prone to do (things change in that matter, but slowly).

Note: CRL / OCSP response lifetime usually ranges from a few minutes to a few days. The dates are verified with regards to the client notion of time; clients with out-of-date clocks can run into trouble.

  • 1
    First, great write up. One note, however. You say that OCSP stapling will "... provide them to the client, under the assumption that the client may need them". I found the below text in the RFC, and it seems to me that it will only provide it to the client if the client asks in the ClientHello. I may be missing something, but I just wanted to bring it up. Thanks. From RFC 6066, page 14 "Servers that receive a client hello containing the "status_request" extension MAY return a suitable certificate status response to the client along with their certificate. "
    – JZeolla
    Jan 25, 2013 at 18:25
  • 6
    OCSP stapling is a TLS extension. TLS supports extensions, but the client must announce that it supports each of them; the server is not allowed to use extensions which the client did not specifically allowed. Here, the client states in the ClientHello that it "supports" the OCSP stapling extension, i.e. that it will not crash if the server staples OCSP responses. This does not mean that the client will use the responses or even needs them; the client itself cannot know at that point (it has not seen the server's certificate yet). Jan 25, 2013 at 18:41
  • 1
    I read this today and it reminded me of this. For those who aren't familiar, the CA Security Council is a new conglomerate of CAs... Check it out. casecurity.org/2013/02/14/…
    – JZeolla
    Feb 14, 2013 at 22:01

You must log in to answer this question.

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