My primitive understanding of OCSP is that:

  • Assertions are signed by the CA and valid for a short period.
  • Stapling refers to the practice of pushing the OCSP request work onto the webserver, and then caching the (CA signed) response and spitting it back out to clients using the "status request" extension.
  • The OCSP server may be down, in which case it may not be possible to get a successful response to staple.

I'm seeing OpenSSL report that the server is sending this OCSP data:

OCSP response: 
OCSP Response Data:
    OCSP Response Status: trylater (0x3)

Why would this ever happen? Surely the webserver should be sending the last valid, successful OCSP response it has cached? Hell, isn't sending nothing at all (and having the browser do the request itself) preferable to stapling trylater?


The webserver behaviour described is undesirable and appears to be due to a Apache configuration default for the SSLStaplingReturnResponderErrors setting. There have been numerous online posts questioning the logic behind these configuration defaults.

Additionally, alternative webserver implementations do not follow suit. Caddy will not serve stapled responses if there was an error when calling ParseResponse which results from a non-success ResponseStatus such as TryLater. This ensures that the user gets the latest available OCSP staple which is valid.

The approach is clearly optimal for ensuring the user maintains access to the site even when OCSP responders are offline or having difficulties. There is a trade-off between security and site availability, but given the short lifetime of OCSP responses this seems quite a reasonable solution. The browser can decide if it's willing to accept the last-known-good response.

A response of "the CA said the cert was valid at $timestamp" will allow the user agent to make a much better, informed decision than a "OCSP server didn't give us anything, try later" response.

| improve this answer | |

The key is to give the authenticating client the most amount of information for that client to be able to determine what is acceptable. A positive status of tryLater is information that may be useful to the client: It may elect to try later, proceed but log the exception, use another mechanism/responder (e.g. CRL) or deny the connection.

If the responder is down, the server simply doesn't know what the security requirements are of the client, and given this could be a malicious act by MitM, the client shouldn't presume the server knows best.

This behaviour seems correct.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.