Fetch OCSP responses on startup, and store across restarts

[jsha@…]

Once TLS Feature (​https://datatracker.ietf.org/doc/draft-hallambaker-tlsfeature/?include_text=1, formerly known as OCSP Must Staple) lands, CAs will be able to sign certs with a bit that says "Do not trust this certificate unless it is accompanied by a stapled OCSP response." For Nginx users to be able to use such certificates, they need to be able to serve stapled OCSP with high reliability and speed. That means two things:

• Nginx should prefetch OCSP responses for all configured certificates on startup, and when the responses are nearing their NextUpdate time.
• Nginx should store OCSP responses in long-term storage, to minimize the cost of startup fetching, and to ensure that if an OCSP responder is temporarily unreachable at startup time, it doesn't prevent correctly serving the relevant site.

[robstradling@…]

TLS Feature landed a few weeks ago.

​https://tools.ietf.org/html/rfc7633

[Jonathan Leroy]

Also, you can look at Ryan Sleevi's (from Chrome Security Team) "requirements" for OCSP stapling support : ​https://gist.github.com/sleevi/5efe9ef98961ecfb4da8

[TerraX-net@…]

As Let's Encrypt supports OCSP must-staple, we are reading everywhere that nginx would fetch OCSP only after the first connection, which would result in a browser's certificate error for that user.

People are recommending to fetch OCSP manually before nginx gets started ​https://unmitigatedrisk.com/?p=241 , but this is not possible with dual certificate deployments (RSA+ECDSA).
As you closed https://trac.nginx.org/nginx/ticket/990 denying to give ssl_stapling_file some logic (which was the right decision in my opinion), this ticket here has a high importance to use OCSP Must-Staple at all.

As SSLLabs.com (and maybe Hardenize.com) are checking and promoting this as a wise security feature, please fetch fresh OCSP before a first connection to make OCSP Must-Stapling possible.

Thank you.

[antoinep92@…]

Hi, could someone provide some status on this ?

As OCSP is being pushed forward, its deployment rate increases and control is being enforced, e.g. firefox displays a scary error message on first connection to nginx if OCSP is enabled. Thus it would seem to me that the priority of this issue has increased compared to 3 years ago.

I just need to know if someone is working or planning to work on this (and I can wait a bit for enabling OCSP) or if it's stalled and I need to consider other options.

Thanks a lot.

[https://stackoverflow.com/users/6250649/johannesb]

This problem gets worse with short lived OCSP responses like in the case of one of our customers.
Somehow (do we have influence on this?) we get very short-lived OCSP responses (2 minutes).

# openssl s_client -host www.some-kpn-pkioverheid-ev-domain.nl -port 443 -status
CONNECTED(00000003)
OCSP response:
======================================
OCSP Response Data:

OCSP Response Status: successful (0x0)
Response Type: Basic OCSP Response
Version: 1 (0x0)
Responder Id: ...
Produced At: Nov 6 17:07:17 2018 GMT
Responses:
Certificate ID:

Hash Algorithm: sha1
Issuer Name Hash: ...
Issuer Key Hash: ...
Serial Number: ...

Cert Status: good
This Update: Nov 6 17:07:17 2018 GMT
Next Update: Nov 6 17:09:17 2018 GMT

[Maxim Dounin]

Replying to https://stackoverflow.com/users/6250649/johannesb:

This problem gets worse with short lived OCSP responses like in the case of one of our customers.
Somehow (do we have influence on this?) we get very short-lived OCSP responses (2 minutes).

[...]

Cert Status: good
This Update: Nov 6 17:07:17 2018 GMT
Next Update: Nov 6 17:09:17 2018 GMT

Such a short-lived OCSP response won't work well, since nginx imposes a hard limit on refreshing OCSP responses (to prevent things getting wild due to invalid dates in the OCSP responses), and won't try to refresh it for at least 5 minutes after the response is received. As a result, with such short-lived OCSP responses nginx won't return anything stapled for 3 out of 5 minutes.

To fix this, you'll have to contact CA which issued the cert, as only CA can control what is returned in OCSP responses.

This doesn't seem to be relevant to this ticket though.

[https://stackoverflow.com/users/6250649/johannesb]

Replying to mdounin:

Replying to https://stackoverflow.com/users/6250649/johannesb:

This problem gets worse with short lived OCSP responses like in the case of one of our customers.
Somehow (do we have influence on this?) we get very short-lived OCSP responses (2 minutes).

[...]

Cert Status: good
This Update: Nov 6 17:07:17 2018 GMT
Next Update: Nov 6 17:09:17 2018 GMT

Such a short-lived OCSP response won't work well, since nginx imposes a hard limit on refreshing OCSP responses (to prevent things getting wild due to invalid dates in the OCSP responses), and won't try to refresh it for at least 5 minutes after the response is received. As a result, with such short-lived OCSP responses nginx won't return anything stapled for 3 out of 5 minutes.

To fix this, you'll have to contact CA which issued the cert, as only CA can control what is returned in OCSP responses.

This doesn't seem to be relevant to this ticket though.

Well if my reading of the code is correct it would seem that the 'only' valid OCSP response is exactly 300 seconds?

​https://github.com/nginx/nginx/blob/master/src/event/ngx_event_openssl_stapling.c#L692

I contacted the OCSP maintainers but surely you cannot expect everyone to use exactly 5 minutes? And if it is not exactly 5 minutes you only get the message: "OCSP_check_validity() failed". Which isn't verify helpful.

See also:

​https://community.letsencrypt.org/t/ocsp-server-sending-expired-responses-stapling-breaks-chrome/23964/31

[Maxim Dounin]

Replying to https://stackoverflow.com/users/6250649/johannesb:

Well if my reading of the code is correct it would seem that the 'only' valid OCSP response is exactly 300 seconds?

No, your reading of the code is not correct. The 300 seconds used in the OCSP_check_validity() call indicate leeway allowed when checking that the response is valid - that is, that the current time is between thisupdate and nextupdate.

If you have further questions, please use ​support options available.

[Sam Bull]

Also see #1830 for a more serious blocker, if using multi-domain certificates.

[Maxim Dounin]

See also #1998.