Comodo / Sectigo OCSP Responders

[Wallu]

Hi all!

Writing this to be sure this issue really is addressed, and that there might be light at the end of the tunnel.

First of, using latest everything, whm/cpanel, kernel, all.

Also, I have read all the posts here on the forum about people having the same issue, and all the workaround solutions, which are bad.

So, base of the problem:

[Thu Jan 30 11:07:00.925036 2020] [ssl:error] [pid 1336702:tid 47358379804416] (70007)The timeout specified has expired: [client 109.xxx.xx.xx:3838] AH01985: error reading response from OCSP server
[Thu Jan 30 11:07:00.925099 2020] [ssl:error] [pid 1336702:tid 47358379804416] AH01941: stapling_renew_response: responder error

Now, many of you see this every day. Some of you have done: "SSLUseStapling off" and some of you might have increased the: "SSLStaplingResponderTimeout" and some of you have this issue, but don't even know about it.

I have done them too. I currently just have Stapling turned off, because increasing the timeout, makes the darn handshake take like 6-11 seconds, and what's up with that?!?

What I need to know, a) is this issue actually addressed with Comodo / Sectigo, and are they actually doing something? OR b) would it be just better to go with Let's Encrypt?

The fact is, and I have several servers with Let's Encrypt, there is no OCSP Responder problem with any of those.

I do NOT want to keep Stapling off and just forget about it. Working Stapling makes the handshake so much faster. So, where are we on this?

p.s. this is from my server where Comodo / Sectigo SSL is used:

openssl s_client -connect xxxxxxxxx.com:443 -status -servername xxxxxxxxx.com
*snip*
OCSP response:
======================================
OCSP Response Data:
    OCSP Response Status: successful (0x0)
*snip*
    Cert Status: good

So, as far as I see this, it's just matter of slow responses from OCSP server(s). If I'm wrong, educate me please.

Thanks,

- Wallu

 

[Wallu]

Just wanted to add this:

[[email protected] ~]# dig A +short ocsp.comodoca.com
151.139.128.14
[[email protected] ~]# dig A +short ocsp.comodoca.com @8.8.8.8
151.139.128.14
[[email protected] ~]# dig A +short ocsp.comodoca.com @208.67.222.222
151.139.128.14

[[email protected] ~]# ping 151.139.128.14
PING 151.139.128.14 (151.139.128.14) 56(84) bytes of data.
64 bytes from 151.139.128.14: icmp_seq=1 ttl=58 time=27.9 ms
64 bytes from 151.139.128.14: icmp_seq=2 ttl=58 time=27.1 ms
64 bytes from 151.139.128.14: icmp_seq=3 ttl=58 time=27.3 ms
64 bytes from 151.139.128.14: icmp_seq=4 ttl=58 time=27.2 ms

So not a local resolve or speed issue as far as I can tell.

- Wallu

 

[cPanelLauren]

Hello,

I think the difference is in the method used. Most CA's base their OCSP checking on the CRL, where Comodo doesn't. This is discussed in a press release they did some time here: It is All About Flexibility for Comodo Online Status Protocol

Comodo, the second-largest issuer of high assurance digital certificates, offers OCSP as a standard feature. Its OCSP responder has been developed in-house, designed to be stable, fast and scalable.

Unlike other Certificate Authorities and OCSP Responders, Comodo's response is not based on the CRL. Unlike most other Certificate Authorities, Comodo is able to sign each OCSP Response using the same Certificate Authority that signed each certificate. This reduces by 75% the amount of data that the OCSP Responder needs to return to the customer.

Specifically, since Comodo's OCSP Response does not depend on the CRL, it can accurately identify a questioned certificate as "good," "revoked," or "unknown." OCSP responders checking only the CRL can only respond "revoked," for certificates already on the CRL, or "unknown" for all other certificates.

Most importantly, whenever a new certificate is issued, or an old one is revoked, Comodo's OCSP Responder receives and acts upon the information within a few minutes. CRL-based OCSP Responders only find out about the certificate status changes as many as 24 hours later when the next CRL is published.

OCSP Stapling being enabled, in theory should be the faster method - For those that are unaware of what this is: OCSP stapling allows the web server to send the browser an OCSP response signed by the CA so the browser doesn't need to make a secondary request to the CA . With OCSP stapling off you offload the request to the browser. For the end-user though, this will take more time to complete the request.

Now, Comodo isn't the only one with OCSP issues, though theirs have been at the forefront lately, all providers using OCSP, unfortunately, have been subject to OCSP responder issues. In fact, their responders were just down recently. You can view the full history here:

Let's Encrypt Status

Support for Let's Encrypt services is community-based and information on current status and outages can be found at: https://community.letsencrypt.org

letsencrypt.status.io

So, I can't tell you that Comodo won't have any issues nor can I tell you the same for Let's Encrypt or other providers. What you can do to combat this is allow for outages regardless of the CA you're using by modifying the size limit of the cache mod_ssl - Apache HTTP Server Version 2.5

 

[Wallu]

Thanks Lauren for the answer. Going to test some with Comodo and if I find anything interesting , will let you know.

- Wallu

 

[roliboli]

Hi Wallu

Did you find something? I have the same issue. There are a lot of timeouts in the error_log:

[ssl:error] [pid 18876:tid 47866007529216] (70007)The timeout specified has expired: [client <IPADDRESS>:29633] AH01985: error reading response from OCSP server

But the ocsp.comodoca.com is available despite this message. So I think there is another cause.

Thanks for your update.

Regards Roland

 

[cPanelLauren]

Just to confirm, were the errors in the log happening at the same time you checked ocsp.comodoca.com? It is possible they had maintenance or couldn't be reached for some period of time but were back before you checked. They did have some scheduled maintenance occurring over the weekend on the 15th and the 16th where downtime was expected for the issuing platforms. You can keep apprised of current status as well as planned maintenance windows here: Sectigo

 

[Wallu]

@roliboli Nope, still have OCSP disabled, been kinda busy.

@cPanelLauren I had errors for weeks, so doubt it was maintenance. ocsp.comodoca.com was reachable all the time, but those responses were just too slow.

- Wallu