What “SSL Certificate Not Trusted” Means
The how to fix SSL certificate not trusted problem appears when a browser, app, or operating system cannot verify that a site’s certificate was issued by a trusted certificate authority (CA).
The warning usually signals a break in the chain of trust, a hostname mismatch, an expired certificate, or a local device issue.
This error matters because TLS and SSL protect data in transit, and trust validation is what tells users they are connecting to the right server.
The challenge is that the cause can be local, server-side, or related to a middlebox such as a proxy or antivirus tool.
Common Reasons the Certificate Is Not Trusted
Before changing anything, identify the most likely source of the failure.
SSL trust errors often come from one of the following conditions:
- Expired certificate or expired intermediate certificate
- Hostname mismatch, such as using a domain different from the certificate’s common name or SAN entries
- Missing intermediate certificate, which breaks the certificate chain
- Self-signed certificate that is not installed in a trusted store
- Outdated root store on an operating system or browser
- Incorrect system time on the client device
- Proxy, firewall, or antivirus interception that re-signs traffic
- Incorrect server configuration, especially on Apache, Nginx, IIS, or load balancers
First Checks on the Client Device
Verify the system date and time
An incorrect clock can make a valid certificate appear expired or not yet valid.
Confirm the date, time, time zone, and automatic time synchronization on the client device, then reload the site.
Test in another browser or device
If the error appears in one browser but not another, the issue may be browser-specific cache, trust settings, or extensions.
Try a second browser, an incognito window, or another device on the same network to isolate the cause.
Clear cache and restart the browser
Browsers sometimes retain stale TLS state or cached certificate information.
Clear the browser cache, close all browser windows, and reopen the site to force a fresh handshake.
Check for antivirus or corporate proxy inspection
Some endpoint security tools and enterprise proxies install their own root certificate to inspect encrypted traffic.
If that root is missing, outdated, or blocked, browsers may show trust errors.
Review security software settings and test the connection on a different network if possible.
How to Fix SSL Certificate Not Trusted on the Server
Confirm the certificate is valid and not expired
Inspect the certificate in the browser or with a command-line tool such as OpenSSL.
Check the notBefore and notAfter dates, the issuer name, and the subject alternative names.
If the certificate is expired, renew it through your certificate authority or automation tool such as Let’s Encrypt certbot.
Install the full certificate chain
A very common cause of the trust warning is missing intermediates.
The server must send the leaf certificate plus any required intermediate certificates so the client can build a complete chain to a trusted root CA.
For example, on Nginx or Apache, you typically need to point the configuration to a full chain file rather than the leaf certificate alone.
If you use a hosting panel, verify that it includes the CA bundle or intermediate chain during installation.
Match the certificate to the exact hostname
The certificate must cover the domain the visitor actually uses, including www, subdomains, and any alternate hostnames.
For modern certificates, the Subject Alternative Name extension is the important field.
If the site is accessed as app.example.com, but the certificate only covers example.com, trust validation can fail.
Use a trusted certificate authority
Browsers trust certificates issued by recognized public CAs such as DigiCert, GlobalSign, Sectigo, Google Trust Services, and Let’s Encrypt.
A self-signed certificate is fine for internal testing, but production websites generally need a publicly trusted certificate unless every client explicitly trusts the internal CA.
Check server name indication and virtual host settings
On shared hosting or multi-site servers, incorrect SNI or virtual host configuration can cause the server to present the wrong certificate.
Verify that the default SSL vhost and each named vhost map to the correct certificate and private key pair.
Tools to Diagnose the Problem
Use diagnostic tools to see exactly what the server is sending.
These are especially useful when you need to fix SSL certificate not trusted errors on production systems.
- Browser certificate viewer: Shows issuer, subject, SANs, and expiration date
- OpenSSL: Useful for checking the certificate chain and handshake details
- SSL Labs Server Test: Detects chain issues, weak protocols, and configuration problems
- cURL: Helps test HTTPS responses from the command line
- Windows Certificate Manager or macOS Keychain Access: Useful for inspecting trusted roots and installed certificates
Platform-Specific Fixes
Apache
In Apache, make sure the SSL virtual host references the correct certificate files and that the chain is included where required.
Confirm that SSLCertificateFile and SSLCertificateKeyFile match, and use the CA bundle or full chain file if your distribution expects it separately.
Nginx
For Nginx, the most common correction is using the full chain certificate file in ssl_certificate.
If the leaf and intermediate certificates are split across files, combine them in the proper order so clients receive the complete chain.
IIS on Windows Server
In IIS, confirm that the certificate is imported into the correct certificate store and bound to the site under the right hostname and port.
If the certificate chain is incomplete, install the missing intermediate certificates into the Windows Intermediate Certification Authorities store.
WordPress and managed hosting
On WordPress sites, trust warnings often stem from a mix of server-side SSL problems and plugin-generated mixed content.
First confirm the certificate itself is trusted, then check whether the site loads images, scripts, or stylesheets over HTTP instead of HTTPS.
Mixed Content Can Look Like a Trust Problem
Not every browser security warning is caused by the certificate itself.
If the page loads some assets over plain HTTP, browsers may display a broken padlock or a warning that feels similar to a certificate trust issue.
Fix mixed content by updating internal links, replacing hard-coded HTTP URLs in templates and databases, and forcing HTTPS redirects.
Content delivery networks, embedded widgets, and legacy JavaScript libraries are common sources of these references.
How to Validate the Fix
After making changes, test from multiple locations and devices.
A valid fix should produce a clean HTTPS connection without warnings, certificate errors, or chain complaints.
- Reload the site in a private browsing window.
- Check the certificate details in the browser.
- Run an SSL Labs test or equivalent scanner.
- Confirm the hostname, expiration date, and issuer are correct.
- Test related subdomains, APIs, and admin panels separately.
Preventing Future SSL Trust Errors
Reliable SSL management reduces downtime and security warnings.
Use certificate automation where possible, monitor expiration dates, and keep server configurations consistent across environments.
- Automate renewals with Let’s Encrypt or a certificate management platform
- Set alerts for expiration and chain changes
- Use a configuration management tool to keep Nginx, Apache, or IIS settings consistent
- Document which domains and subdomains each certificate covers
- Regularly patch operating systems so root CA stores stay current
If your organization uses internal PKI, publish the root certificate to all managed devices and maintain an updated intermediate chain.
This is especially important in enterprises with MDM, VPNs, or remote workers connecting from multiple environments.