Why Does My SSL Certificate Show as Not Trusted

Introduction

A “certificate not trusted” warning means the browser or client could not validate the SSL/TLS certificate presented by the server. This is different from a normal HTTP error because the secure connection fails during certificate validation, often before the page loads.

Common causes include expired certificates, self-signed certificates, missing intermediate chain files, hostname mismatch, wrong certificate installed on the active virtual host, CDN SSL misconfiguration, or CAA records blocking issuance. The fix depends on whether the problem is trust, expiry, chain completeness or hostname coverage.

Quick answer

Certificate not trusted

Browsers trust certificates that chain to a recognized public root CA and match the hostname being visited. A warning appears when one of those requirements fails.

Why this matters

Trust warnings also reduce confidence in login pages, checkout flows and admin areas. Fixing the certificate path and hostname coverage restores normal HTTPS behavior.

How to check

Use SSL Checker, Website Status Checker and openssl s_client to inspect the live certificate served on the public hostname.

1. Exact hostname — Test the URL shown in the browser address bar.
2. Expiry dates — Confirm notBefore and notAfter are valid.
3. Issuer — Check whether the certificate comes from a public CA or is self-signed.
4. Subject and SAN names — Verify hostname coverage for root, www and subdomains.
5. Certificate chain — Confirm intermediate certificates are sent by the server.
6. CDN vs origin — Test public hostname and origin separately if a CDN is used.
7. CAA records — Review whether DNS restricts which CA may issue certificates.

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates

Common problems

How to fix trust issues

1. Step 1: Test the public hostname

   Use SSL Checker and openssl s_client on the exact URL visitors use.

2. Step 2: Check expiry and issuer

   Confirm the certificate is current and issued by the expected CA.

3. Step 3: Verify hostname coverage

   Review Subject and SAN names for root, www and required subdomains.

4. Step 4: Install the full chain

   Upload leaf plus intermediate certificates as fullchain or CA bundle.

5. Step 5: Replace self-signed certificates

   Use a publicly trusted CA certificate for production websites.

6. Step 6: Reload web server or CDN

   Apply the new certificate to the active vhost or edge configuration.

7. Step 7: Check CDN/origin separately

   Fix edge and origin certificates independently if a CDN is involved.

8. Step 8: Re-test externally

   Confirm browsers and SSL Checker show a trusted chain with no warnings.

Examples

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -ext subjectAltName

Browser warning:
NET::ERR_CERT_AUTHORITY_INVALID

OpenSSL issuer on live site:
issuer=CN = R3

Problem:
Intermediate certificate not sent by server.

Fix:
Install fullchain.pem instead of cert.pem only.

Public hostname:
https://www.example.com → trusted edge certificate

Origin check:
https://origin.example.com → expired self-signed certificate

Problem:
Strict CDN-to-origin validation fails.

Fix:
Install valid origin certificate or adjust CDN SSL mode.

Frequently asked questions