Let’sEncrypt OSCP Server Response Error In cPanel

This issue normally occurs when STAPLING is enabled and you are not able to connect to the SSL CA provider. Normally it’s because of network error in the datacenter.

You can verify that by pinging from your server (where you are facing this issue) to SSL CA provider. In our case ocsp.int-x3.letsencrypt.org.
If you not getting ping request from the server and you are getting ping request from another server that means its Network issue from the datacenter.

Symptoms

• all the https sites went down
  
• server load is normal
• apache service is running
• /etc/apache2/logs/error_log shows the following errors

[Thu May 02 03:06:38.713291 2019] [ssl:error] [pid 16491] AH01941: stapling_renew_response: responder error

[Thu May 02 03:06:38.713219 2019] [ssl:error] [pid 16491] (70007)The timeout specified has expired: [client 104.131.103.14:38624] AH01985: error reading response from OCSP server

You can use the OpenSSL command-line program to verify that an OCSP response is sent by your server:

$ openssl s_client -connect www.example.com:443 -status -servername www.example.com
...
OCSP response:
======================================
OCSP Response Data:
OCSP Response Status: successful (0x0)
Response Type: Basic OCSP Response
...
Cert Status: Good
...

• Check for any Let’Encrypt outages on https://letsencrypt.status.io/
• Verify that OCSP stapling is now enabled by running an SSL Install check. Enabled OCSP stapling will display beside the field OCSP Must Staple as “Yes”.

The above screenshot shows a server with OSCP Stapling disabled

OSCP STAPLING

OCSP stapling, formally known as the TLS Certificate Status Request extension, is an alternative approach to the Online Certificate Status Protocol (OCSP) for checking the revocation status of X.509 digital certificates. It allows the presenter of a certificate to bear the resource cost involved in providing OCSP responses by appending (“stapling”) a time-stamped OCSP response signed by the CA to the initial TLS handshake, eliminating the need for clients to contact the CA.

In Other Words, If this OSCP protocol is enabled then, web-server brings all the information of requested domain SSL from CA Certificate and gives to the web-browser.

IF STAPLING is disabled then our Web-browser will go to CA certificate provider and check the SSL certificate, whether it’s valid or not and rest of the stuff.

If it’s disabled then web-browser needs to send multiple connections and if STAPLING is enabled it gets done in a single request. Because our web server will do all the things and keep that information in the cache.

As the client can obtain the certificate revocation status from the server, without requiring an extra connection from the client to the Certificate Authority, OCSP Stapling is the preferred way for the revocation status to be obtained. Other benefits of eliminating the communication between clients and the Certificate Authority are that the client browsing history is not exposed to the Certificate Authority and obtaining status is more reliable by not depending on potentially heavily loaded Certificate Authority servers.

Reasons for the Error

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 data center or hosting provider, or server administrator to look into the network routing and try to determine why your server cannot reach the OCSP server.

Also, 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.

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.

This is only 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.

Resolution

To resolve this issue we have to disable the OSCP Stapling on the web server.

Manually disabling OSCP Stapling requires us to make changes to 3 configuration files

/usr/local/apache/conf/httpd.conf /usr/local/apache/conf/includes/pre_virtualhost_global.conf (global apache virtualhost conf)/usr/local/apache/conf/includes/pre_virtualhost_2.conf -(virtual host conf For apache version 2.x.xx)

Add the following directives to end of the 3 configuration files as required.

TO DISABLE SSLUseStapling off TO ENABLE SSLUseStapling on SSLStaplingCache “shmcb:logs/ssl_stapling(32768)“

The path on the SSLStaplingCache directive (e.g., logs/) should match the one on the SSLSessionCache directive. This path is relative to ServerRoot.

This particular SSLStaplingCache directive requires mod_socache_shmcb (from the shmcb prefix on the directive’s argument). This module is usually enabled already for SSLSessionCache or on behalf of some module other than mod_ssl.

If you enabled an SSL session cache using a mechanism other than mod_socache_shmcb, use that alternative mechanism for SSLStaplingCache as well. For example:

SSLSessionCache “dbm:logs/ssl_scache“
SSLStaplingCache “dbm:logs/ssl_stapling“

After making the changes restart httpd service.

/scripts/restartsrv_httpd

From the WHM Interface,

• Login to your WHM with root access.
• Go to ‘Service configuration’ > Apache Configuration > Include Editor
• Go to Pre VirtualHost Include > select Apache version x.x.xx > insert ‘SSLUseStapling off’ in the column > click Update
• Click ‘Restart Apache’

Conclusion

The above article gives us an idea about OSCP, its application and how to resolve common issues faced while implementing the feature. Hope this helps in quicker resolution of similar errors in the future.

Also, this is only a temporary workaround to the issue, once the network issues have been resolved It is suggested to re-enable OSCP Stapling for better website loading speeds.