Must-staple is an option for certificates. Certificates can be issued either with or without must-staple (subscriber decides).
For certificates with must-staple, OCSP stapling must be operative on the server.
OCSP is a protocol to obtain the current status (revoked/not-revoked) of a certificate. OCSP status updates "responses" are generated by the CA (Let's Encrypt) periodically.
The default workflow of obtaining OCSP responses works like this:
- The client establishes a TLS connection to a server
- Server sends its certificates
- The client contacts the CA and asks for the current OCSP status for the certificate(s) just received.
- CA responds with OCSP status
- TLS connection continues (some clients don't wait for the OCSP response in this configuration and just continue straight away).
This workflow has a few disadvantages:
- The client needs to contact the CA. This adds additionally latency to connections and also leaks some information about the client (OCSP runs over plain HTTP, so any listener or the CA can see what server the client is connecting to).
- If some connection error happens, the client doesn't know what to do. Usually it is just ignored.
- The CA server gets hit with a lot of OCSP queries, because every single client of any subscriber server fetches the OCSP response.
There is however a much better workflow, called OCSP stapling. The workflow for stapled OCSP is like this:
- Prior to the connection, the server obtains one or more OCSP responses for its certificates.
- The client connects to the server, indicating that it would like an OCSP response.
- The server responds with the certificates and the cached OCSP response(s) for the certificates.
- Client validates certificates and OCSP responses together.
This has the obvious advantage, that the CA is never contacted by the clients - only by the server, which usually owns the certificate anyway. This improves privacy and latency of the connection and reduces overall load on infrastructure.
The disadvantage is that the server is now responsible for obtaining and serving OCSP responses. OCSP servers naturally have hiccups and return weird data. Servers need to handle this correctly, and ensure they always have up-to-date OCSP responses.
When a certificate contains the must-staple attribute, conforming clients will reject the handshake, if no OCSP response was send by the server.
This usually happens, either because
- the server was not (correctly) configured to send up-to-date OCSP responses
- the server did not have any (valid) OCSP response available at the time the client connected
Some server implementations (for example nginx) do lazy-loading of OCSP responses. They do not obtain OCSP responses at startup, but only after the first client requested one. This doesn't play well together with must-staple, as the OCSP response must always be available, even at the very first connection.
Generally it is very difficult to get OCSP must-staple to work well, as many server implementations aren't that good at handling OCSP. Often it is required to employ external solutions that handle OCSP.
The easiest way to get around this is by simply disabling OCSP must-staple. You can still send stapled OCSP responses even without must-staple, the difference is that this is no longer required and clients will not fail, if OCSP responses are (temporarily) omitted. The downside is marginally decreased security, because an active attacker could temporarily inject a compromised certificate and suppress the OCSP response for that certificate. It is a remote attack scenario though.
PS: Sorry for the text wall, didn't realize how long this got.
