I have an application which communicates with a web server over an HTTPS connection, secured with a Lets Encrypt Certificate from Dreamhost.
One user on Windows 10 is reporting that they’re getting a message stating that “Revocation information for the securty certificate for this site is not available”.
The certificate appears to be working fine for all other users - can anyone shed any light on what can cause this?
The “revocation information” it refers to is presumably the OCSP status for the certificate.
As a public CA, Let’s Encrypt implements the Online Certificate Status Protocol, which is a web server operated on behalf of Let’s Encrypt that for every certificate serial number can provide a signed, time-stamped message saying the certificate is still good. This is what the “revoke” feature for Let’s Encrypt does - if you know your server was broken into and bad guys might have your private keys, you can revoke them, Let’s Encrypt will then reply “bad” not “good” to OCSP for that certificate (and you can get yourself a new certificate once you’ve secured everything properly).
Alas Windows users get these messages for a variety of inscrutable reasons, I can see reports of this problem dating back long before Let’s Encrypt existed, at least to 2013, so it may be hard to debug. But as I understand it, the most likely include:
The user has the date and time set wrong on their PC. Even just an hour wrong (e.g. from forgetting they moved to a state with no Daylight Savings and left the clock settings the same) can cause trouble. If this is the issue, usually the user will find it works some days but not others, and see the same issue intermittently for other sites too, perhaps at other times.
The user has a firewall or other security device / software that prevents their computer contacting Let’s Encrypt’s servers for OCSP. In this case they would probably see the error also in Internet Explorer browsing https://helloworld.letsencrypt.org/ and they should adjust their system not to prohibit this normal activity.
Thanks for getting back to me. In the meantime I’ve set up a Windows 10 test environment and I get the same error.
Strangely, it’s ok in Microsoft Edge etc, but only an issue in the Adobe Air application I’m running. Could there be some incompatibility in the Air code do you think which might prevent it reading the revocation information correctly?
Was scouring the internet for why this was happening in my Adobe AIR app on Windows 7 as well, and as it turns out the error went away on its own. It may have been because the certificate was just created in the same day I was trying to use it, since the next day it was gone. I did see this pop-up happen at least once on an older certificate I had, but that also seemed intermittent and stopped. Maybe it was something on LetsEncrypts end, I don’t know. But I don’t think Adobe AIR/Windows were necessarily at fault
@ahaw021 Unfortunately I don’t have a domain available at the moment I can reproduce the issue on. Like I said, it’s as if the problem fixed itself. But as for a screenshot, it was basically just the same pop-up described by the OP:
If you want you could inspect https://www.mcleodgaming.com Though keep in mind I didn’t ever get this pop-up before in my AIR app when it read from that domain, although about 2 or 3 times it occurred when I was seeing the issue occur consistently for one of my other newly created sub-domains. I gave up after trying to debug for 8 hours straight and when I tried again the next day the pop-up stopped.
–EDIT–
I should also add that unchecking “Check for server certificate revocation” in Internet Explorer’s Advanced internet options as described in some other threads fixed the problem when it was occurring, but that is obviously not an desirable solution
This was probably a result of the OCSP service outage last week (Friday). It may also have had some continuing effects through Saturday or so.
OCSP stapling on the web server is probably a better solution than relying on OCSP server availability, even though the operations team is trying to keep the OCSP service up and reachable at all times.
I had no idea about the outage, and none of my searches turned up anything about OCSP stapling. I’ve enabled that on my servers so hopefully moving forward this issue doesn’t come up again
We did learn as a result of the outage that some OCSP stapling implementations are pretty bad. They should keep the last valid OCSP response that they have seen—I believe the responses are valid for a week!—but some of them discard a previous valid response when they see an error (!). There is very little value in that. So it might be worth checking into whether or not your server’s implementation keeps serving old stapling data while the CA’s OCSP responder is temporarily unavailable.