1321273 - OCSP error prevent to access the website - SEC_ERROR_OCSP_TRY_SERVER_LATER

Status: RESOLVED DUPLICATE of bug 1028534

(Core :: Security: PSM, defect)

Description

[Rémy Hubscher (:natim)]

When trying to access https://café-vie-privée.fr/ I get a SEC_ERROR_OCSP_TRY_SERVER_LATER which prevent me for accessing the website.

If I try with wget, curl or chromium I don't have any error.

I guess we should not block on OCSP error but rather fallback to the CRL file and then to a degraded SSL access but we should not prevent the user to access the website in that specific case.

Comment 1

[:Gijs (he/him)]

I'm pretty sure that we don't default to strict OCSP enforcement. I can access the website in question fine on my default profile - but maybe the problem was intermittent? Did you check whether this was a result of strict settings you enabled?

(In reply to Rémy Hubscher (:natim) from comment #0)
> I guess we should not block on OCSP error but rather fallback to the CRL
> file and then to a degraded SSL access but we should not prevent the user to
> access the website in that specific case.

What is "degraded SSL access" ?

Comment 2

[:Gijs (he/him)]

(See also e.g. bug 1028534 - Chrome doesn't do any OCSP checking which explains the different behaviour.)

Comment 3

[Rémy Hubscher (:natim)]

> I can access the website in question fine

Yes it is back as well on my side.

> What is "degraded SSL access" ?

Something that uses the SSL certificate to encrypt the connection but display a warning and a red or orange lock instead of the green one telling that the certificate revocation server couldn't be reached for instance.

Comment 4

[Dana Keeler (she/her) (use needinfo) [:keeler]]

This can happen if the site staples an OCSP response that contains the "try later" code. We could definitely improve the UI of the error page, but we're probably not going to make this an overridable error.

Comment 5

[Rémy Hubscher (:natim)]

> but we're probably not going to make this an overridable error.

I don't understand why?

Comment 6

[Dana Keeler (she/her) (use needinfo) [:keeler]]

One reason is the specification requires it ( https://tools.ietf.org/html/rfc6066 bottom of section 8). My understanding is part of the aim of that requirement was to transition from soft-fail OCSP fetching (which is fairly useless from a security standpoint) to hard-fail opt-in to OCSP checks (via stapling, which still has some problems), that could then be augmented with some sort of expect-stapling mechanism, which would actually enable sites to opt-in to meaningful revocation checking.