OCSP timeout is considered "Good (not revoked)"

[folkol]

I got "Revocation status: Good (Not revoked)", but it also showed an error "OCSP ERROR: Exception: Read timed out".

(I performed this scan on 2020-03-12 07:19:57 UTC.)

[tamthing]

We will look at it. Could you share the domain to https://discussions.qualys.com/people/tamthing ? Thanks.

[folkol]

Sure. I'll PM you there.

[tamthing]

Hi @folkol , this issue is not reproducible anymore both on www.ssllabs.com & dev.ssllabs.com. However, if an error has occurred like in your case, the revocation status is not correctly represented and we have created a ticket to fix that.

Please note that this kind of issue is seldom expected to happen.

[folkol]

For what it's worth, it happened again (just now):

[logopk]

Here too, today (just now)

[noloader]

@folkol,,

I'm seeing this too with a Let's Encrypt chain. It looks liek an intermittent problem. I'm guessing there's a race somewhere in the server code (either SSL Labs or the OCSP).

I got "Revocation status: Good (Not revoked)", but it also showed an error "OCSP ERROR: Exception: Read timed out".

This is expected... The lawyers from the CA's got involved. They decided they did not want the legal liability of associated with a "certificate is good" when in fact certificate (or the private key was bad). Instead they return a response of "certificate is not bad"/"certificate is bad". Since the predicate is based on "not bad", getting a "not bad" response is considered good/success. That is, there's a difference legal distinction between "certificate is good" and "certificate is not bad". A timeout is effectively a the same as not getting a "certificate is bad" response. (You can't make this shit up...).

[folkol]

I am not surprised that the check fails intermittently—it is a distributed system after all—the only thing that I find confusing is the presentation on the report page. I would have preferred "indeterminate" or something similar if the check (and retries?) failed.