How to Fix SSL Certificate Not Trusted Issues on Your Website

If you've landed here because your browser is throwing an "SSL certificate not trusted" error — or your visitors are seeing scary warning screens when they try to reach your site — you're in the right place. An SSL certificate not trusted fix isn't always complicated, but it does require understanding why the trust chain broke down in the first place. This guide walks through every common cause and gives you concrete steps to resolve each one, whether you're a site owner, developer, or server administrator.

Why SSL Certificates Become Untrusted

Before jumping into fixes, it helps to understand what "trusted" actually means in the context of SSL/TLS certificates.

When a browser visits your site, it checks your SSL certificate against a list of trusted Certificate Authorities (CAs) — organizations like Let's Encrypt, DigiCert, Comodo, and GlobalSign. These CAs have their root certificates pre-installed in operating systems and browsers. Your certificate is trusted if it chains back to one of those root certificates through a valid, unbroken path.

Trust breaks down for several reasons:

Expired certificate — the most common cause
Incomplete certificate chain — intermediate certificates are missing
Self-signed certificate — not issued by a recognized CA
Domain mismatch — the certificate is for a different domain
Revoked certificate — the CA has invalidated it
System clock issues — the client's date/time is wrong
Outdated root store — old OS or browser doesn't recognize newer CAs

Each of these has a distinct fix. Let's go through them one by one.

How to Diagnose the SSL Certificate Not Trusted Problem

You can't fix what you haven't properly diagnosed. Here are the best ways to identify the exact issue.

Check with a Browser

Open your site in Chrome or Firefox. The browser's error message is usually specific:

NET::ERR_CERT_DATE_INVALID → expired or future-dated certificate
NET::ERR_CERT_COMMON_NAME_INVALID → domain mismatch
NET::ERR_CERT_AUTHORITY_INVALID → untrusted CA or missing chain
NET::ERR_CERT_REVOKED → certificate has been revoked

Click the "Not Secure" warning and then "Certificate" to view the full details — issuer, validity dates, and the Subject Alternative Names (SANs).

Use the OpDeck SSL Checker

The fastest way to get a complete picture is to use the SSL Certificate Checker. It inspects your certificate chain, expiration date, issuer information, and whether the certificate is properly trusted — all in seconds. You'll see exactly which part of the chain is broken without needing to interpret raw OpenSSL output.

Use OpenSSL from the Command Line

For developers and sysadmins who want raw output:

openssl s_client -connect yourdomain.com:443 -servername yourdomain.com

Look for this section in the output:

Verify return code: 0 (ok)

If you see anything other than 0 (ok), the number and message tell you what's wrong:

10 → certificate has expired
19 → self-signed certificate in chain
20 → unable to get local issuer certificate (missing intermediate)
23 → certificate has been revoked

You can also check the full chain:

openssl s_client -connect yourdomain.com:443 -showcerts

This prints every certificate in the chain, which is critical for diagnosing missing intermediates.

Use curl to Test Quickly

curl -vI https://yourdomain.com 2>&1 | grep -E "SSL|certificate|expire|verify"

A successful handshake shows SSL connection using TLS... and no verify errors.

Fix 1: Renew an Expired SSL Certificate

An expired certificate is the most common cause of SSL trust errors. Certificates have a validity period — currently capped at 398 days for publicly trusted certs.

For Let's Encrypt (Certbot)

sudo certbot renew

If auto-renewal isn't working, check the systemd timer:

sudo systemctl status certbot.timer

Force a renewal for a specific domain:

sudo certbot renew --cert-name yourdomain.com --force-renewal

After renewal, restart your web server:

# For Nginx
sudo systemctl restart nginx

# For Apache
sudo systemctl restart apache2

For Paid Certificates

Log into your CA's dashboard, generate a new Certificate Signing Request (CSR), complete the validation process, and download the new certificate files. Then replace the old files on your server and restart the web server.

Prevention: Set Up Auto-Renewal and Monitoring

Don't wait for expiry to catch you off guard. Set a calendar reminder 30 days before expiry, or use a monitoring tool. The SSL Certificate Checker on OpDeck shows you the exact expiration date so you can plan ahead.

Fix 2: Install the Complete Certificate Chain

Missing intermediate certificates are the second most common cause of SSL certificate not trusted errors. Your server might be sending only the end-entity certificate without the intermediates that connect it to the root CA.

Browsers can sometimes fetch missing intermediates on their own (called AIA fetching), but many clients — especially mobile apps, API clients, and older browsers — cannot. This causes intermittent or client-specific trust failures.

Understanding the Chain

A complete chain looks like this:

Root CA Certificate (trusted by OS/browser)
  └── Intermediate CA Certificate
        └── Your Domain Certificate

Your server needs to serve the domain certificate plus all intermediate certificates. The root certificate is NOT included in what you serve — it's already in the client's trust store.

How to Bundle the Chain Correctly

Most CAs provide a "bundle" or "chain" file when you download your certificate. If not, you can create it manually.

For Apache (in httpd.conf or your virtual host config):

SSLCertificateFile /etc/ssl/certs/yourdomain.crt
SSLCertificateKeyFile /etc/ssl/private/yourdomain.key
SSLCertificateChainFile /etc/ssl/certs/intermediate.crt

For Nginx, you concatenate the certificates into a single file:

cat yourdomain.crt intermediate.crt > yourdomain_bundle.crt

Then reference it in your Nginx config:

ssl_certificate /etc/ssl/certs/yourdomain_bundle.crt;
ssl_certificate_key /etc/ssl/private/yourdomain.key;

Important: The order matters. Your domain certificate must come first, followed by the intermediate(s), from least to most authoritative.

Verify the Chain After Installing

openssl verify -CAfile /etc/ssl/certs/ca-certificates.crt yourdomain_bundle.crt

Or check it online with the SSL Certificate Checker, which validates the complete chain automatically.

Fix 3: Replace a Self-Signed Certificate

Self-signed certificates are fine for internal development environments, but they will always trigger "SSL certificate not trusted" warnings in browsers for public-facing sites because no recognized CA has vouched for them.

Get a Free Certificate from Let's Encrypt

Let's Encrypt provides free, publicly trusted certificates. Install Certbot:

# Ubuntu/Debian
sudo apt install certbot python3-certbot-nginx

# Then obtain and install the certificate
sudo certbot --nginx -d yourdomain.com -d www.yourdomain.com

For Apache:

sudo apt install certbot python3-certbot-apache
sudo certbot --apache -d yourdomain.com -d www.yourdomain.com

Certbot handles configuration changes and sets up auto-renewal automatically.

Alternatives to Let's Encrypt

ZeroSSL — free certificates with a web-based UI
Cloudflare — free SSL when you proxy through Cloudflare
Your hosting provider — many hosts (cPanel, Plesk, SiteGround, etc.) offer one-click SSL

Fix 4: Resolve a Domain Mismatch

A domain mismatch occurs when the certificate is issued for www.yourdomain.com but you're accessing yourdomain.com (or vice versa), or when the certificate was issued for a completely different domain.

Check the Certificate's SANs

openssl s_client -connect yourdomain.com:443 -servername yourdomain.com 2>/dev/null | openssl x509 -noout -text | grep -A1 "Subject Alternative Name"

This shows all domains the certificate is valid for.

Solutions

If you have a single-domain certificate and need both www and non-www:

Reissue the certificate with both names. With Certbot:

sudo certbot --nginx -d yourdomain.com -d www.yourdomain.com

If you've moved to a new domain:

You need a new certificate for the new domain. The old certificate cannot be transferred.

If the wrong certificate is being served:

Check your server's virtual host configuration. In Nginx, make sure the correct ssl_certificate path is in the right server block. In Apache, verify the VirtualHost *:443 block for your domain has the correct SSLCertificateFile directive.

Fix 5: Handle Revoked Certificates

If a certificate has been revoked (because the private key was compromised, for example), you need to obtain a completely new certificate. There's no way to "un-revoke" a certificate.

Steps After Revocation

Generate a new private key — never reuse a compromised key
Create a new CSR from the new key
Request a new certificate from your CA
Install the new certificate on your server
Revoke the old certificate if you haven't already (your CA's dashboard handles this)

# Generate a new private key
openssl genrsa -out new_private.key 2048

# Create a new CSR
openssl req -new -key new_private.key -out new_request.csr

Fix 6: Correct System Clock Issues on the Client Side

Sometimes the "SSL certificate not trusted" error isn't a server problem at all — it's the visitor's clock. If a client's system time is significantly off, valid certificates can appear expired or not-yet-valid.

This is more common than you'd think, especially on:

Virtual machines that haven't synced time
IoT devices
Older computers with dead CMOS batteries

For Your Own Machine

Windows: Right-click the clock → Adjust date/time → Sync now

macOS: System Preferences → Date & Time → Set automatically

Linux:

sudo timedatectl set-ntp true
sudo timedatectl status

If this is affecting your visitors, there's not much you can do server-side. However, you can add a note on your error page if you're running an internal application.

Fix 7: Update Root Certificates on Old Systems

Older operating systems and browsers may not have the root certificates for newer CAs like Let's Encrypt's ISRG Root X1. This became a real issue in September 2021 when Let's Encrypt's cross-signature from IdenTrust expired, breaking access on Android 7.1 and earlier.

For Servers Running Old OS Versions

Update the CA certificate bundle:

# Ubuntu/Debian
sudo apt update && sudo apt install ca-certificates
sudo update-ca-certificates

# CentOS/RHEL
sudo yum update ca-certificates

For End Users on Old Devices

If you're running a public site and need to support older Android devices, consider using a certificate from a CA with broader legacy compatibility (like DigiCert or Comodo/Sectigo), or use Cloudflare as a proxy, which handles the TLS handshake on behalf of old clients.

Fix 8: Check for Mixed Content and Redirect Loops

Sometimes what looks like an SSL trust issue is actually a configuration problem causing the browser to distrust the connection for different reasons.

Mixed Content

If your HTTPS page loads HTTP resources (images, scripts, stylesheets), browsers may block them or downgrade security. Fix this by updating all resource URLs to HTTPS, or use a protocol-relative URL (//example.com/script.js).

HTTP to HTTPS Redirect Configuration

Make sure your server is correctly redirecting HTTP to HTTPS. In Nginx:

server {
    listen 80;
    server_name yourdomain.com www.yourdomain.com;
    return 301 https://$host$request_uri;
}

In Apache:

<VirtualHost *:80>
    ServerName yourdomain.com
    Redirect permanent / https://yourdomain.com/
</VirtualHost>

Verifying Your SSL Fix Is Complete

After applying any fix, verify everything is working correctly before calling it done.

Full Verification Checklist

Certificate is valid and not expired
Certificate chain is complete (no missing intermediates)
Certificate covers the correct domain(s)
HTTP redirects to HTTPS cleanly
No mixed content warnings
HSTS header is present (optional but recommended)
Certificate grade is A or A+ on SSL Labs

Test with SSL Labs

Visit https://www.ssllabs.com/ssltest/ and enter your domain. An A+ rating means everything is configured correctly.

Test with OpenSSL One More Time

openssl s_client -connect yourdomain.com:443 -servername yourdomain.com < /dev/null 2>&1 | grep -E "Verify|subject|issuer|notBefore|notAfter"

You should see Verify return code: 0 (ok) and dates that confirm the certificate is currently valid.

Preventing Future SSL Certificate Not Trusted Issues

The best SSL certificate not trusted fix is the one you never need to apply because you caught the problem before it happened.

Monitoring Best Practices

Set expiry alerts — most CAs send email reminders, but don't rely solely on them
Use automated renewal — Let's Encrypt with Certbot's systemd timer is the gold standard
Monitor your certificate regularly — run weekly checks with a tool like the SSL Certificate Checker to catch chain issues, upcoming expirations, and configuration drift
Test after every deployment — any server configuration change can accidentally break SSL

Use HSTS to Prevent Downgrade Attacks

Once your SSL is solid, add an HTTP Strict Transport Security header to tell browsers to always use HTTPS:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

This won't prevent trust errors, but it prevents attackers from stripping HTTPS in the first place.

Conclusion

Resolving an SSL certificate not trusted fix comes down to identifying the root cause — whether that's an expired cert, a broken chain, a self-signed certificate, or a domain mismatch — and applying the right solution for each. The steps above cover every major scenario you're likely to encounter, from a quick certbot renew to rebuilding your certificate chain from scratch.

The key takeaway: don't guess. Diagnose first, then fix. Use the SSL Certificate Checker on OpDeck to get an immediate, detailed breakdown of your certificate's status, chain integrity, and expiration timeline. It takes seconds and gives you the exact information you need to act confidently. Once you've resolved the issue, set up monitoring so you're never caught off guard again — your visitors' trust (and your search rankings) depend on it.