Fix TLS Certificate Not Trusted Error (2026)

The TLS certificate chain is broken, and the client’s browser can’t verify the identity of the server it’s trying to connect to.

Common Causes and Fixes:

• Expired Intermediate Certificate: The most frequent culprit. A server relies on a chain of trust, usually Root CA -> Intermediate CA -> Server Certificate. If an intermediate certificate in that chain has expired, the chain is broken.

  • Diagnosis: Use openssl s_client -connect example.com:443 -servername example.com and inspect the verify return code and the s:/ lines to see which certificate is being presented and its expiry. Look for an intermediate certificate that shows as expired.
  • Fix: Obtain the current intermediate certificate bundle from your Certificate Authority (CA) and ensure it’s correctly installed on your web server. For Apache, this usually means updating the SSLCertificateChainFile directive or including it in the SSLCertificateFile. For Nginx, it’s typically concatenated into the ssl_certificate file.
  • Why it works: The server presents the full chain to the client. If an intermediate certificate is expired, the client can’t trace the path back to a trusted root, so providing the current intermediate certificate re-establishes the valid chain.

• Missing Intermediate Certificates: The server certificate is valid, but the intermediate certificates required to link it to a trusted root CA are not being served.

  • Diagnosis: Similar to the above, openssl s_client will show a valid server certificate but may report a verify return code like 20 (unable to get local issuer certificate).
  • Fix: Download the full certificate chain (server cert + intermediate certs) from your CA. Configure your web server to serve this complete chain. For Nginx, this means concatenating the intermediate certificates after your server certificate in the ssl_certificate file. For Apache, update SSLCertificateChainFile.
  • Why it works: The client needs the entire path. If the intermediate certificates are missing, the client can’t complete the validation path to a trusted root.

• Incorrect Server Certificate Configuration: The wrong certificate file is being pointed to by the web server configuration.

  • Diagnosis: Examine the SSLCertificateFile (Apache) or ssl_certificate (Nginx) directive in your web server configuration. Compare the certificate file path with the actual certificate file on disk. Use openssl x509 -in /path/to/your/cert.crt -noout -dates to check the expiry dates of the certificate specified in the config.
  • Fix: Correct the path in your web server configuration to point to the correct server certificate file.
  • Why it works: The web server must be configured to present the correct, valid server certificate for clients to even begin the trust validation process.

• Mixed Protocol/Cipher Suite Issues (Less Common for "Not Trusted"): While usually leading to connection failures or warnings about weak ciphers, very old or misconfigured clients might interpret certain cipher suite incompatibilities as a trust issue if the TLS handshake fails early.

  • Diagnosis: Use openssl s_client -connect example.com:443 -servername example.com -cipher 'ECDHE-RSA-AES256-GCM-SHA384' (and try a few other common, strong ciphers) to see if the connection succeeds with specific cipher suites. Check your web server’s SSL/TLS configuration for SSLProtocol and SSLCipherSuite (Apache) or ssl_protocols and ssl_ciphers (Nginx).
  • Fix: Ensure your web server is configured to support modern TLS protocols (TLSv1.2, TLSv1.3) and strong cipher suites. Remove outdated protocols like SSLv3 and TLSv1.0/1.1. For example, in Nginx: ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384';
  • Why it works: Clients and servers must agree on a secure protocol and cipher suite to establish a secure connection. If they can’t, the handshake fails, and some clients might misreport this as a trust issue.

• Server Certificate Issued to the Wrong Domain Name: The certificate is valid and trusted, but it’s not issued for the domain the user is trying to access.

  • Diagnosis: Compare the subject= and subjectAltName= fields in the output of openssl s_client -connect example.com:443 -servername example.com with the domain name in the browser’s address bar.
  • Fix: Obtain a new certificate that correctly lists all required domain names (including www. variants and subdomains) in its Subject Alternative Name (SAN) field. Reconfigure your web server with this new certificate.
  • Why it works: TLS requires the presented certificate’s domain name(s) to exactly match the domain name the client is attempting to connect to.

• Self-Signed Certificates (and Not Trusting Them): If you’re using a self-signed certificate for internal services, clients will naturally not trust it because it’s not signed by a recognized Certificate Authority.

  • Diagnosis: openssl s_client -connect internal.example.com:443 -servername internal.example.com will show a certificate where the s:/C=... (Issuer) is the same as i:/C=... (Subject), and the verify return code will be something like 18 (self signed certificate).
  • Fix: For internal systems, you have two main options:
    1. Import the self-signed certificate into the client’s trust store: This manually tells the client to trust this specific certificate or the CA that signed it. This is often done via group policy in enterprise environments.
    2. Obtain a certificate from a trusted internal or public CA: If the service needs to be widely accessible without manual client configuration, use a certificate from a CA that clients already trust.
  • Why it works: Browsers and operating systems have a pre-defined list of trusted root Certificate Authorities. A self-signed certificate bypasses this system, so clients reject it unless explicitly told to trust it.

After fixing these, the next error you’ll likely see is a "Too Many Redirects" error if your HTTP to HTTPS redirect isn’t configured correctly.