Why is there a need for pre-produced OCSP Responses

Normally OCSP responses are produced on a per request basis. That means that for each client which poses a question about the status of a certificate, the Validation Authority (VA) checks that status and sends it back in a signed response - naturally this sets a heavy burden on the HSM used by the VA. Some VA maintainers have traditionally solved this using stapling, i.e. caching the response for each certificate at the proxy layer for a set amount of time. While this does solve the problem, it’s not always acceptable and requires the added responsibility of making sure that a valid response is delivered from the VA to the proxy.

In EJBCA 7.4.0, PrimeKey introduced the support for pre-produced (i.e. canned) OCSP responses. This feature is described in RFC 6960 section 2.5, which states that “OCSP responders MAY pre-produce signed responses specifying the status of certificates at a specified time”.

Using the pre-produced OCSP responses in EJBCA, the VA can be configured to - at selected intervals - sign and cache OCSP responses for a configured subset of certificates, optimally taking place during projected traffic lulls, and during traffic peaks allowing the VA to respond to OCSP requests without needing to perform a signature for each. Additionally, the EJBCA VA can also be configured to pre-compute an end-of-life OCSP response with an indefinite validity, for PKIs (such as eIDAS, see EN 319 411-2 (OCSP)) that require VA’s to continue to answer OCSP requests long past the CA’s own validity.

OCSP Response Pre-Production in EJBCA