CPANEL could not connect to OCSP responder 'ocsp.comodoca.com'

 
les sites sont inaccessibles, et quand je redemarre le APACHE le site revient puis le apache est à 100%. ( RRRRRRRRRRRRRRRRRRRRRRR), j'ai ajouté l'option SSLUseStapling off, le probleme a été reglé ( mais avant cela j'avais bloquer quelque IP surement aussi de COMODO ) apres une journée j'ai supprimé SSLUseStapling off, mais le probleme persiste et quand je désactive le firewall le probleme est reglé.

Je pense qu'il y'a eu une NON COMMUNICTION entre notre serveur est COMODO OSCP pendant un moment

j'ai vérifeir dans fichier LOG apache et j'ai troouvé

 tail -f /var/log/apache2/error_log

une erreure ci dessous OCSP alors j'ai fait cela SSLUseStapling off en attendant que cela redevient bien

"L'option SSLUseStapling effectue des recherches de certificats SSL pour déterminer s'ils sont valides ou ont été révoqués. La désactivation de cette option peut permettre des connexions sécurisées aux serveurs dont les SSL ont été révoqués pour une raison ou une autre."

CPANEL could not connect to OCSP responder 'ocsp.comodoca.com'

I get a lof of error /var/log/apache2/error_log
I wonder what it's all about? How can solve this problem?

[Sat Apr 25 13:38:05.350828 2020] [ssl:error] [pid 20427:tid 47191871805184] AH01941: stapling_renew_response: responder error
[Sat Apr 25 13:38:08.354574 2020] [ssl:error] [pid 2597:tid 47191842387712] (70007)The timeout specified has expired: [client 37.26.52.163:43586] AH01974: could not connect to OCSP responder 'ocsp.comodoca.com'
[Sat Apr 25 13:38:08.354700 2020] [ssl:error] [pid 2597:tid 47191842387712] AH01941: stapling_renew_response: responder error
[Sat Apr 25 13:38:15.005719 2020] [ssl:error] [pid 2724:tid 47191854995200] (70007)The timeout specified has expired: [client 5.191.53.104:46847] AH01974: could not connect to OCSP responder 'ocsp.comodoca.com'

Many of you have likely landed here due to running across the following error or similar in your Apache error log when sites using AutoSSL or other SSL certificates take an excessively long time to load, or simply time out:

Code:

Network is unreachable: could not connect to OCSP responder 'ocsp.comodoca.com'

OCSP (Online Certificate Status Protocol) is used to ensure that the current status of a given SSL certificate is always communicated to the webserver, and the client's browser. This protocol provides updates on if a certificate has been revoked, so the browser knows to refuse the connection.

Traditionally the requesting browser makes these checks with the OCSP provider, which extends the time a full SSL/TLS handshake takes and as a result makes HTTPS connections longer.

cPanel's Apache installation by default implements a technology known as 'OCSP Stapling', which functions as a sort of caching for the OCSP status. Essentially after making the first OCSP connection, the status is "stapled" to the SSL/TLS handshake from the server end which reduces a significant load on the connecting browser and makes HTTPS connections faster.

The above error comes into play when OCSP Stapling fails because the host server couldn't connect to the certificate authority's OCSP server. This can happen for a variety of reasons, but we'll touch on the most common causes here:


DNS Caching causes your server to try connecting to the wrong IP address

Many certificate authorities tends to rotate and change the IP addresses where their OCSP server is hosted fairly frequently. This can result in servers trying to access an old IP address for the server, which may fail.

This can be verified by checking what your server resolves the OCSP server to, versus what a common public DNS resolver resolves. I use Google's '8.8.8.8' in the following example, but any "large" public resolver would let you check for a difference. The IP addresses in this example represent only the addresses at the time of my testing, and are very likely different when you're reading this post:

Code:

# dig A +short ocsp.comodoca.com
ocsp.comodoca.com.edgesuite.net.
a652.dscb.akamai.net.
58.27.86.11
58.27.86.48

# dig A +short ocsp.comodoca.com @8.8.8.8
ocsp.comodoca.com.edgesuite.net.
a652.dscb.akamai.net.
203.106.85.42
203.106.85.66

If you get a different response from the public DNS resolver versus your own server it's very likely your DNS resolves are using cached information and haven't updated the new IP addresses. This is often addressed by simply waiting until your server's DNS resolvers refresh their cached IP information.

If instead you receive the same IP addresses from your server and the public resolver, it's possible there may be network issues preventing your server from reaching your certificate authority's OCSP server.​

Network issues prevent your server from reaching OCSP server

This is by far the most common reason we see for sites reporting these errors. Often as a result of datacenter blocks, server firewalls or other network interferences the server is unable to connect to the necessary OCSP server. This can most reliably be verified by simply trying to ping the OCSP server in your error.

If you don't receive any information after the ping then there's likely a network block at play, in which case you should reach out to your datacenter or hosting provider, or server administrator to look into the network routing and try to determine why your server cannot reach the OCSP server.

We've seen a few isolated cases where incomplete IPv6 configurations can cause issues connecting to OCSP servers as well. This can be tested using 'ping6' instead of 'ping', which tests an IPv6 connection instead of IPv4. If you receive errors only when using ping6 then it's possible the IPv6 configuration on the server needs to be fixed, or disabled.

Otherwise, if you are able to successfully ping the OCSP provider it's possible they may be experiencing service issues.​

Certificate Authority may be experiencing service issues.

Infrequently, certificate authorities may have service downtime with their OCSP responder servers. If none of the above steps explain the errors being received, then you may want to check with your provider.

For AutoSSL certificates for example, Sectigo offers Sectigo Certificate Authority to check their service status and will announce if they're experiencing OCSP issues.

If there are systemic issues with the OCSP responder servers there will likely be a notice on their status page, and ideally a projected ETA for service to be restored.
​

If any of the above descriptions apply or if there's a less common issue causing these errors for you, it's possible to disable OCSP stapling to allow your sites to load again.

We firmly recommend that this only be a temporary workaround, as disabling Stapling places the OCSP burden back on your customer's browsers, slowing down site load speed and extending SSL/TLS handshake times.

To disable OCSP Stapling you can access WHM >> Service Configuration >> Apache Configuration >> Include Editor >> Pre VirtualHost Include >> All Versions and adding the following line:

Code:

SSLUseStapling off

Selecting 'Update' after this will rebuild the Apache configuration and restart the service, at which point the sites should begin loading as expected again.

Once the systemic issues in contacting OCSP have been addressed Stapling can be re-enabled by accessing the same interface and removing the additional line that was added. We at cPanel recommend keeping OCSP Stapling enabled whenever possible, as this improves the security in your HTTPS connections and improves site load speeds by optimizing the SSL/TLS Handshake