After recent upgrades, my sites (hork.com, virtualcrash.com) got stellar reports from SSL labs, except for:
Revocation status Validation error
OCSP ERROR: Exception: connect timed out [http://r3.o.lencr.org]
Perhaps the OCSP server is just having an off (site) day or maybe it is more chronic. Who can say? Cheers.
Please see:
It probably has some answers for you. It also contains stuff about OCSP.
Hi @crashulater
before writing, use the search. It's old - 2021-01-23
Not only letsencrypt, same with a GoDaddy -> it's a known Ssllabs - bug.
Yes, same issue. Glad to see it is SEP.
I'd be wary of referring people to the IdenTrust CRL issue thread, because there the SSL Labs issue was just a red herring confusing people about a real problem that existed for a few hours.
But there does seem to be some connectivity issue between SSL Labs and Let's Encrypt's OCSP server.
The way I like to easily test OCSP through a web site is to look up the certificate on crt.sh and click the "Check" link for OCSP there. I find that one works pretty well.
Just following up on this weird issue....
Just checked on the issue on the qualys forum and there is actually an ongoing discussion about this.
OSCP Revocation status for letsencrypt certificates
Rip
A (relatively heavyweight but in my opinion worthwhile) thing you could do to mitigate this would be to enable OCSP Stapling for your (web) server if applicable. A Good OCSP stapling implementation completely insulates you from any problems clients have connecting to the OCSP servers, because you're giving them the same (signed) information they'd have retrieved anyway. And if there is a bigger issue (e.g. Let's Encrypt OCSP servers go offline for 24 hours), your own monitoring can detect that, because you're the one fetching the OCSP response, not the clients.
As I understand it, SSL Labs understands OCSP stapling, so it will accept the stapled response and not risk this issue.
They do dozens of TLS handshakes upon testing, some of them with stapling, others without. I use stapling on my certs and I occasionally see the timeout issue on the cert page (even when ocsp stapling is green), so I guess that the cert display on Qualys doesn't care about OCSP stapling.
From that discussion it looks like Qualys is denying that the problem exists.
I wonder if it might be something like the CDN that Let's Encrypt puts in front of the OCSP systems (is it Cloudflare?) is seeing a lot of traffic to it from Qualys's IPs and ends up blocking them intermittently as a DoS-prevention measure. That is, it may be something that neither Let's Encrypt nor Qualys have much visibility into, or at least neither have much incentive to spend a lot of resources digging into.
We have an OCSP rate limit that's very high, but well below where we expect our CDN's DDoS protection to kick in. This limit does get hit sometimes but not by SSL Labs, as far as I can tell. Our troubleshooting ability here is a little limited, because we minimize OCSP traffic logging for privacy reasons.
Having read up on the issue of cert revocation and OCSP a bit more, it seemed to me that OCSP stapling indeed is the (only sensible) way to go. So, when it was time to renew my Let's Encrypt certs this weekend, I added one additional option to the usual certbot command:
With that cert in place, you'll get a difference response when you poll the status of your server:
OCSP response: no response sent
That indicates the cert has OCSP stapling capability, but the server is not (yet) set up to provide it. (No OCSP response at all means OCSP stapling is not provided in the cert).
I use Apache httpd on Fedora-30 Linux. The configuration is surprisingly easy. Just a few directives that, for me, go in conf.d/ssl.conf
SSLUseStapling on
SSLStaplingCache shmcb:/run/httpd/ssl_stapling(32768)
SSLStaplingResponderTimeout 5
Make sure to put these in the global context (ie. NOT inside VirtualHost:443 anything.) and to match the SSLStaplingCache value to the SSLSessionCache value of your distro. Mine is the RedHat convention, other distributions may use "shmcb:logs/ssl_stapling(32768)" or "shmcb:/tmp/stapling_cache(32768)"
Because I have a local-only VirtualHost that uses a self-signed cert, for that VirtualHost I used the directive:
SSLUseStapling off
because OCSP stapling isn't valid for self-signed certs (obviously).
Like me, you may have this burning question of who, how, when the OCSP-staple gets refreshed. 1./ Apache httpd takes care of the refresh; 2./ The cached OCSP-staple is valid for 7-days; 3./ There have been years of discussions on how best to do the refresh. I assumed something reasonable came out of that and went with the defaults. If that doesn't satisfy you then there are the
ssl-stapling and ssl-stapling-refresh Mutex directives to explore.
Make sure to run your equivalent of:
to verify the configuration, before reloading/restarting
You should now see a different response when you poll the server:
OCSP response:
OCSP Response Data:
OCSP Response Status: successful (0x0)
Response Type: Basic OCSP Response
Final SSL Labs verdict:
OCSP stapling : Yes
Problem solved!
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.