Quite often I get OCSP errors directly after issuing a new certiticate.
The last time this happened was on Tue, 12 Nov 2019 07:06:45 +0100 (CET) for the certificate https://crt.sh/?id=2101378294.
The OCSP-client of the OpenSSL-tool returned: Responder Error: unauthorized (6)
after being invoked with: openssl ocsp -issuer intermediate.crt -cert cert.crt -url http://ocsp.int-x3.letsencrypt.org -header Host=ocsp.int-x3.letsencrypt.org -CApath /etc/ssl/certs/ -no_nonce
I run the OCSP-client three times in a row on a failure with a delay of 60 and 90 seconds and usually all three requests fail if the first already failed.
Can you define what you mean by âafter a longer timeâ? I see that your certificate does not have the OCSP must-staple extension which means that you shouldnât need to immediately check OCSP.
It doesnât matter whether the certificate has must-staple or not. As soon as I use the certificate in production my server will ask the OCSP server for an OSCP response for OCSP stapling (or browsers will ask the OCSP server). Therefore, it should work.
Sure, but can you define what you mean by âafter a longer time, the requests workâ? Is this 12+ hours later? Iâm trying to rule out if the OCSP caching layer could be at fault.
Iâm sorry I canât provide a better explanation for âafter a longer time, the requests workâ, because I renew certificates automatically (and cache OCSP responsed locally) and this always happened when I was not sitting at the computer.
At 13:06:28 local time I still got error 6 from the OCSP servers. I see similar errors in my logs until 13:15:13. So, at that time the issue might got solved or not new OCSP-cache requests were performed.
I just experienced this issue again (around Fri, 6 Dec 2019 22:04:21 +0100 (CET)) for the certificate 03:58:9b:69:46:82:8f:ea:90:ed:d3:83:34:35:f9:c7:ae:f6 and now I had the chance to dig deeper. At Sat Dec 7 00:11:40 +0100 CET I still get the Response Error: unauthorized (6). Using strace I found out that the connected host seems to be (a771.dscq.akamai.net.). The servers 2001:2030:0:6::50ef:c820 and 2001:2030:0:6::50ef:c820 report the error. The servers on 72.247.178.19 or 72.247.178.16 works as expected (really rarely I also get the two working servers 2a01:4a0:1338:28::c38a:ff10, 2a01:4a0:1338:28::c38a:ff18 as round robin). Now at 02:31:43 CET also the âfaultyâ IPv6 servers work.
Whereas at the very same time I renewed the certificate 04:d6:6f:42:6a:82:ae:86:2a:20:4a:a5:77:b6:87:22:0f:48 for which the first OCSP response was fine immediately (I check all listed IP addresses above, all do work as expected).
Yeah, this seems like a cache infrastructure problem. Does Letâs Encrypt have automated testing in place for the CDN wrapped OCSP service so that they donât have to rely on users to report problems? Itâs already hard enough to get any momentum behind OCSP stapling without also having a major CA that gives bogus errors for OCSP requests.
Hi folks, sorry for lack of responses here recently.
We aim to have OCSP responses ready essentially immediately, and typically that is the case. The additional time stamps and IP addresses youâve posted will be helpful in troubleshooting this issue, so thank you!
Even with a caching CDN, Iâd estimate that we continually field approx 1600 requests per second for OCSP at our origins. Additionally, according to our privacy policy, we do not record individually identifying details for OCSP requests.
So teasing the needle out of this haystack may take a while, especially with end-of-year holidays around the corner, but we will keep reviewing the details youâve provided and work with Akamai if the issue is beyond our origins, and see if we can get to a root cause.
Also, this link is to a very old thread (before my time on this forum), but is there any chance that your initial requests are happening within the first second after issuance? In the linked thread, it seems those requests were too soon and the unauthorized response was cached. If you wait one or even two seconds before the first OCSP request, do you have better luck as they did in the old thread?
I took a look, and we are indeed experiencing brief periods of higher replication lag than usual - on the order of 10 seconds at times, which could present opportunities for an âunauthorizedâ response to be cached at the CDN.
