Online Certificate Status Protocol (OCSP) is a mechanism for browsers to check the validity of certificates presented by HTTPS websites. This guards against revoked certificates. This has been an issue for big websites, which had bad certs issued (for their domain to entities other than the owning company) and had to be revoked upon complaints to the cert issuer. Google has stated its intent to begin distrusting Symantec certs in 2018. A counterpoint to Google appears in this interesting article which notes deficiencies in Chrome’s implementation of OCSP, and of privacy issue for the website visitors with OCSP checks.

Let’s look at what Mozilla is doing about this, as they have attempted to implement OCSP correctly.

https://bugzilla.mozilla.org/show_bug.cgi?id=1366100

Telemetry indicates that fetching OCSP results is an important cause of slowness in the first TLS handshake. Firefox is, today, the only major browser still fetching OCSP by default for DV certificates.

In Bug 1361201 we tried reducing the OCSP timeout to 1 second (based on CERT_VALIDATION_HTTP_REQUEST_SUCCEEDED_TIME), but that seems to have caused only a 2% improvement in SSL_TIME_UNTIL_HANDSHAKE_FINISHED.

This bug is to disable OCSP fetching for DV certificates. OCSP fetching should remain enabled for EV certificates.

OCSP stapling will remain fully functional. We encourage everyone to use OCSP stapling.

[DV is basic Domain Validation, EV is Extended Validation with more ownership checks]

So they are moving away from OCSP to OCSP stapling. From wikipedia, “OCSP stapling, formally known as the TLS Certificate Status Request extension, is an alternative approach to the Online Certificate Status Protocol(OCSP) for checking the revocation status of X.509 digital certificates.^[1] It allows the presenter of a certificate to bear the resource cost involved in providing OCSP responses by appending (“stapling”) a time-stamped OCSP response signed by the CA to the initial TLS handshake, eliminating the need for clients to contact the CA”.

From the OCSP RFC

The Online Certificate Status Protocol (OCSP) enables applications to determine the (revocation) state of identified certificates.  OCSP may be used to satisfy some of the operational requirements of providing more timely revocation information than is possible with CRLs and may also be used to obtain additional status information. An OCSP client issues a status request to an OCSP responder and suspends acceptance of the certificates in question until the responder provides a response.

How to setup OCSP stapling with letsencrypt:

The CSR request can request a OCSP_MUST_STAPLE option (PARAM_OCSP_MUST_STAPLE=”yes”). The issued cert will then have the parameter with OID 1.3.6.1.5.5.7.1.24 and an OCSP URI which are shown with

openssl x509 -in cert.pem -text  |grep 1.24

1.3.6.1.5.5.7.1.24:

openssl x509 -noout -ocsp_uri -in cert.pem

http://ocsp.int-x3.letsencrypt.org

This changes the cert itself that is issued, so that independent of a webserver/haproxy/nginx configuration that may disable OCSP, the browser can check this cert upon download and show the status of the OCSP check.  This reduces the reliance on the website operator, who may be rogue. Ok, but what happens if a cert gets revoked after initial issuance ? The check should be done periodically – but by whom ? Instead of disabling OCSP, the webserver should enable the periodic rechecking and update stapling.

Also this parameter is not shown in the safari/firefox on cert inspection, but shows up on command line as param 1.3.6.1.5.5.7.1.24 being present in the downloaded cert.

https://esham.io/2016/01/ocsp-stapling

1. Figure out which of the Let’s Encrypt certificates was used to sign your certificate.
2. Download that certificate in PEM format.
3. Point nginx to this file as the “trusted certificate”.
4. In your nginx.conf file, add these directives to the same block that contains your other ssl directives:

   ssl_stapling on;
   ssl_stapling_verify on;
   ssl_trusted_certificate ssl/chain.pem;