empty response from OCSP server

[ruiz]

Today morning I had a issue on one server that sites were not loading at all. I checked that Apache processes maxed out and just restarted apache to fix the problem. This worked for a couple minutes, but then the same thing happened, I checked apache and the processes were not maxed out, but were piling up fast. Another restart and the problem seems to stop.

This is not normal. I have more than enough "Max Request Workers". Usually i'm using only 20% of the available slots.

Later I started investigating the issue and found out multiple OCSP errors at /var/log/apache2/error_log like the following:
-----------------------------------------------------------------
[Tue Aug 13 11:00:40.153186 2019] [ssl:error] [pid 12151] [client 189.x.x.x:49123] AH02321: empty response from OCSP server
[Tue Aug 13 11:00:40.153212 2019] [ssl:error] [pid 12151] [client 189.x.x.x:49123] AH01980: bad response from OCSP server: (none)
[Tue Aug 13 11:00:40.153212 2019] [ssl:error] [pid 12151] AH01941: stapling_renew_response: responder error
-----------------------------------------------------------------
Dozens, maybe hundreds of responses like this happen everyday. Any idea of what could be the problem?

Heres some things i use:
Centos 7
Apache 2.4.39 + mpm_prefork
Jail Apache Virtual Hosts enabled

Thanks!

 

[LucasRolff]

The problem is that sometimes OCSP responders go down, and Apache doesn't handle that very well in general Can be "fixed" by temporarily disabling OCSP stapling in the httpd.conf.

 

[ruiz]

@LucasRolff yes if this happens sometimes that would be ok, however in my case it happens everyday, all day.
Do you know if there is a "rate limit" that responder might apply? I have over 1000 accounts sharing the same ip. so this might be it.

 

[LucasRolff]

@LucasRolff yes if this happens sometimes that would be ok, however in my case it happens everyday, all day.
Do you know if there is a "rate limit" that responder might apply? I have over 1000 accounts sharing the same ip. so this might be it.

Responders do rate limit, rather heavily even - but even with 1000 accounts it shouldn't be a problem since there should be a local OCSP cache that takes care of this. The only time you actually might be rate-limited is if the OCSP cache expires and your server keeps retrying - then what you can do is to simply turn off OCSP Stapling for a day or two, that should allow you to then turn it on afterward and then no rate-limiting should happen.

In my own case, I simply switched to LiteSpeed so I don't have to deal with OCSP issues anymore.

 

[cPanelLauren]

I've seen a few of these issues over the last few days as well, it would seem there have been OCSP responder issues with certain providers. The advice provided by @LucasRolff is correct though, we can advise you to disable SSLUseStapling but the responder uptime or connectivity isn't' something we're able to control or maintain.

 

[johanlimm]

Responders do rate limit, rather heavily even - but even with 1000 accounts it shouldn't be a problem since there should be a local OCSP cache that takes care of this. The only time you actually might be rate-limited is if the OCSP cache expires and your server keeps retrying - then what you can do is to simply turn off OCSP Stapling for a day or two, that should allow you to then turn it on afterward and then no rate-limiting should happen.

In my own case, I simply switched to LiteSpeed so I don't have to deal with OCSP issues anymore.

Hello Lucas,

Is there any specific configuration for swtiching from Apache to LiteSpeed? Cause I've tried to switch it but the OCSP problem still here.

 

[LucasRolff]

Hello Lucas,

Is there any specific configuration for swtiching from Apache to LiteSpeed? Cause I've tried to switch it but the OCSP problem still here.

When using litespeed, OCSP errors isn't "fatal" as they are in Apache where it completely blocks the request from happening, so it might still cause OCSP issues (because the OCSP server blocks you or isn't reachable), but LiteSpeed handles this gracefully.