Fix TLS OCSP Response Not Trusted Error (2026)

The TLS handshake is failing because the server’s certificate’s OCSP responder is not being trusted by the client.

This usually means the client (your browser or the server you’re connecting to) cannot verify the revocation status of the server’s certificate. Certificates can be revoked for various reasons, like the private key being compromised. OCSP (Online Certificate Status Protocol) is the mechanism used to check this in real-time. If the OCSP response itself can’t be validated, the connection is dropped as a security precaution.

Here are the common reasons and how to fix them:

Client-side Clock Skew: The most frequent culprit. If your system’s clock is significantly off, the timestamps on the OCSP response, the certificate, and the current time won’t align, leading to trust issues.
- Diagnosis: Check your system’s date and time. On Linux/macOS, date command. On Windows, check the clock in the taskbar.
- Fix: Synchronize your system clock with a reliable NTP server.
  - Linux: sudo timedatectl set-ntp true (if using systemd) or configure /etc/ntp.conf and restart ntpd.
  - Windows: Go to "Date & Time settings" -> "Sync now".
- Why it works: OCSP responses and certificates have validity periods. If your clock is far off, these periods appear expired or not yet valid, breaking the trust chain.
Firewall/Proxy Blocking OCSP Requests: Network devices between your client and the OCSP responder can interfere. Firewalls might block the outbound UDP/TCP port 80 or 443 requests to OCSP servers, or a misconfigured proxy might fail to forward them.
- Diagnosis: Use openssl s_client -connect example.com:443 -status and observe the output for "OCSP response:." If it hangs or times out, it might be a network issue. You can also try querying OCSP directly using openssl ocsp -issuer issuer.crt -cert cert.crt -url http://ocsp.example.com.
- Fix: Ensure your firewall allows outbound connections to common OCSP servers (often found in the certificate’s Authority Information Access extension) on ports 80 and 443. If using a proxy, configure it to allow these requests or to cache OCSP responses.
- Why it works: The client needs to reach the OCSP responder to get a valid, signed status for the certificate. Blocking this prevents the client from verifying the certificate’s validity.
Invalid or Expired OCSP Signing Certificate: The OCSP response is digitally signed by the Certificate Authority (CA) that issued the server’s certificate. If the CA’s own certificate (used to sign the OCSP response) is expired or invalid on the client’s trust store, the response won’t be trusted.
- Diagnosis: Examine the OCSP response (if you can capture it) or the CA’s certificate chain. You can often see details in your browser’s certificate viewer (under "Details" -> "Authority Information Access" and then checking the CA’s certificate itself).
- Fix: Update your system’s root CA certificates. This is usually handled by operating system updates. For specific applications (like Java or specific web servers), you might need to update their trust stores manually.
  - Linux (Debian/Ubuntu): sudo apt update && sudo apt upgrade ca-certificates
  - Linux (RHEL/CentOS): sudo yum update ca-certificates
  - Windows: Ensure Windows Update is running and up-to-date.
- Why it works: The client trusts the OCSP response because it trusts the CA that signed it. If the CA’s signing certificate is untrusted, the signature on the OCSP response is also untrusted.
Server Misconfiguration (OCSP Stapling Not Working): The server is supposed to "staple" the OCSP response directly into its TLS handshake. If this feature is misconfigured or disabled on the server, the client might have to fetch it independently, increasing the chance of network or timing issues.
- Diagnosis: Check your web server’s configuration for OCSP stapling directives. For Nginx, look for ssl_stapling on; and ssl_stapling_verify on; in your nginx.conf or site-specific configuration. For Apache, check SSLStapling on and SSLStaplingForceURL.
- Fix: Enable and correctly configure OCSP stapling on your web server. Ensure the server can reach the OCSP responder to fetch responses and staple them.
  - Nginx example:
```
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /path/to/your/fullchain.pem; # Needs to include CA chain
resolver 8.8.8.8 8.8.4.4 valid=300s; # DNS resolver to fetch OCSP
resolver_timeout 5s;
```
- Why it works: OCSP stapling makes the client’s job easier and more reliable by providing the OCSP status directly from the server, reducing external dependencies during the handshake.
Intermediate CA Not Included in Server Certificate Chain: When stapling, the server needs to provide not just its certificate but also the intermediate certificates that link it back to a trusted root CA. If these are missing, the client cannot build the full trust chain to validate the OCSP response.
- Diagnosis: Use openssl s_client -connect example.com:443 and examine the "Certificate chain" section. Ensure all necessary intermediate certificates are present.
- Fix: Configure your web server to send the full certificate chain, including intermediate certificates, to the client. This is typically done by concatenating your server certificate and its intermediate certificates into a single file (e.g., fullchain.pem) and pointing your server’s ssl_certificate (Nginx) or SSLCertificateChainFile (Apache) directive to it.
- Why it works: The client needs the entire chain to verify that the server certificate was issued by a CA that is itself trusted, and that the OCSP response from that CA is valid.
OCSP Responder Server Issues: In rare cases, the OCSP responder server itself might be down, slow, or misconfigured, returning invalid responses or no response at all.
- Diagnosis: Use online SSL/TLS checkers (like SSL Labs’ SSL Test) which often report OCSP issues. You can also try manually querying the OCSP responder URL found in the certificate’s Authority Information Access extension using openssl ocsp.
- Fix: There’s often little an end-user can do here. If you control the CA, fix the responder. If you don’t, you might need to contact the CA or switch to a certificate from a different provider. As a workaround, some clients can be configured to ignore stapling failures or fall back to CRLs (Certificate Revocation Lists), but this reduces security.
- Why it works: The client is attempting to get a valid status from the OCSP server, and if that server is broken, the verification fails.

The next error you’ll likely encounter if you fix all OCSP issues is a certificate expiration warning, or perhaps a different certificate validation error if there are deeper chain issues.

More Deep Dives in Tls Ssl