Responder Error: unauthorized (6)

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

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 -header -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.

After a longer time, the requests work.

1 Like

Hi @mrtux,

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.

1 Like


I mistyped, the certificate does not have must-staple.

1 Like

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.

1 Like

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.

1 Like

We’re investigating this and will get back to you with our findings.


No reponse since 21 days :frowning:

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 ( The servers 2001:2030:0:6::50ef:c820 and 2001:2030:0:6::50ef:c820 report the error. The servers on or 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).

1 Like

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?

1 Like

The thread you linked ([Solved] OCSP server sometimes has malformed response of 5 bytes or "unauthorized") is actually out of date. We switched over to immediate OCSP generation in 2017. However, since we serve OCSP off of our replicas, there is some possibility of getting an unauthorized result immediately post-issuance due to replication lag (and then that result being cached).


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.

We’re working on making it lower.


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.