SSL TRUST & CERTIFICATE CHAINS
SSL Certificate Not Trusted: Causes and How to Fix It
An SSL/TLS certificate warning can stop browsers and applications from establishing a trusted HTTPS connection. Causes include a self-signed certificate, an unknown issuer, missing or incorrect intermediates, expired dates, hostname mismatches, or the wrong certificate installed on the server. Device trust stores and clocks can also affect the result.
“Not trusted” is often used broadly, but an expired or mismatched certificate is a validation problem without necessarily being a certificate-authority trust failure. Identifying the exact error helps you correct the right part of the connection.
Start with the certificate actually served
Record the hostname and error code. Compare issuer, dates, Subject Alternative Names, and chain verification; then test another updated device or trusted network. Website owners should check certificate assignment and intermediate-chain installation. Do not bypass warnings, disable verification, or install an unknown root certificate to remove the message.
What Does SSL Certificate Not Trusted Mean?
HTTPS uses TLS to encrypt traffic and a certificate to help authenticate the server’s identity for the requested hostname. Encryption can be technically possible while identity validation fails. A browser warning means the client cannot accept the connection under its certificate-validation rules.
A certificate authority signs certificates after applying its issuance and validation requirements. Public trust comes from a chain to an accepted trust anchor, not simply from a recognizable issuer name. Private authorities can serve controlled environments with a deliberately managed trust policy.
From the server certificate to a trusted root
The website presents a server or leaf certificate, usually signed by an intermediate authority. One or more intermediates connect it to a root authority that the client trusts. Clients use a trust store supplied or managed by the browser, operating system, application, or organization; implementation and policies vary.
Many root certificates are self-signed, but their trust comes from their accepted distribution and policy. A website creating its own self-signed leaf certificate does not automatically gain that trust. The client still needs valid signatures and an acceptable chain, plus hostname, date, and other required checks.
Trust is one part of website safety
A successful certificate validation helps authenticate the hostname and protect the connection. It does not prove that the site’s content is trustworthy or that its applications are free from malware or vulnerabilities.
Common SSL Certificate Trust Errors
Google Chrome and Microsoft Edge
NET::ERR_CERT_AUTHORITY_INVALIDNET::ERR_CERT_DATE_INVALID
NET::ERR_CERT_COMMON_NAME_INVALID
NET::ERR_CERT_AUTHORITY_INVALID points to a certificate authority or chain-validation problem. Possible causes include a private/self-signed issuer, missing intermediates, or HTTPS interception. Review the actual certificate and chain rather than assuming the issuer alone is at fault.
NET::ERR_CERT_DATE_INVALID indicates a date-validation problem, such as an expired or not-yet-valid certificate or an incorrect device clock. NET::ERR_CERT_COMMON_NAME_INVALID indicates hostname coverage problems; modern hostname validation relies on Subject Alternative Names despite the historical error name.
Mozilla Firefox
SEC_ERROR_UNKNOWN_ISSUERMOZILLA_PKIX_ERROR_SELF_SIGNED_CERT
SEC_ERROR_UNKNOWN_ISSUER means Firefox cannot establish an acceptable issuer chain. MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT specifically identifies a self-signed certificate problem. Local trust configuration, missing intermediates, and managed-network interception can influence these results.
Safari
Safari may report that it cannot verify the website’s identity or that the certificate is not trusted. Inspect the available warning details and certificate information. Wording and viewer controls vary by macOS, iOS/iPadOS, and Safari version.
Keep the exact hostname, error code, and test context. A general privacy warning can cover several failures, and clients may display only one problem even when more than one is present.
How to Check Whether an SSL Certificate Is Trusted
Hostingcone’s free SSL Certificate Checker can inspect the certificate publicly presented for your hostname. Enter the exact domain or subdomain used by visitors and review the results together:
1. Certificate issuer.
2. Start and expiration dates.
3. Hostname coverage.
4. Certificate chain verification.
5. Reported validation failures.
A chain can verify while the requested hostname does not match. An unexpired certificate can still fail trust validation. Untrusted metadata collected after a failed validation is labelled; it is useful for investigation but is not a successful trust result.
The tool checks one public address on port 443 using the Hostingcone server’s trust store. Other endpoints and client trust stores may differ. For a proxied Cloudflare domain it normally sees the edge certificate, not the private origin. Network failure does not establish whether a certificate is expired or trusted.
Self-Signed SSL Certificates
A self-signed certificate is signed with its own corresponding private key instead of being issued through a separately trusted authority. It can support encryption, but an ordinary public browser has no automatic reason to accept that site’s identity.
Self-signed certificates and private PKI can be appropriate in labs, controlled internal systems, or applications with an intentionally configured trust model. Administrators must distribute and maintain trust securely, control access, and manage certificate lifecycles. Private use is a design choice, not a shortcut around validation.
Public websites generally need certificates trusted by their visitors’ browsers. Replace a self-signed public-facing leaf certificate with an appropriate publicly trusted certificate and the required intermediate chain. Do not ask visitors to ignore warnings or broadly install unknown roots.
Self-signing alone does not determine encryption strength. The important difference for a visitor is whether identity and trust are established through an acceptable policy. Root trust should be managed through legitimate platform or organizational channels.
Missing or Incorrect Intermediate Certificates
A common chain is root authority → intermediate authority → server certificate. The server generally presents its leaf certificate followed by the required intermediate certificates. Root trust normally comes from the client’s trust store; sending a root from the server does not make it trusted.
Use the correct intermediate chain supplied for your certificate and the installation format expected by your hosting platform. A similarly named issuer, unrelated intermediate, or bundle in the wrong place may not connect the leaf to an accepted root. Follow the issuer’s chain and ordering guidance instead of guessing from names.
A certificate can work on one device and fail on another because a client may have a cached intermediate, fetch one automatically, or use a different root store or chain-building policy. Do not rely on those differences to compensate for incomplete server configuration.
Compare the certificates the server presents with the issuer’s required chain. Correct the configured bundle, activate the change through the platform’s supported process, and retest from independent clients. Check all relevant nodes and IPv4/IPv6 destinations if the website is load-balanced.
Expired or Not-Yet-Valid Certificates
Each certificate has a Not Before and Not After value. The client’s correct current time must fall within the applicable validity period. Expiration or a start date in the future can cause rejection even if the issuer chain is otherwise trusted.
If one device reports a date error, confirm its actual time, date, time zone, and synchronization. Do not deliberately alter the clock to make an expired certificate appear valid. Compare another up-to-date device and an external result.
Website owners should verify the certificate currently served, not just the replacement shown in an order or control panel. A wrong virtual host, incomplete deployment, or old load-balancer node can keep presenting an expired certificate. Renew or replace when appropriate and verify activation.
SSL Hostname Mismatch
The certificate’s Subject Alternative Names must cover the hostname the client requests. example.com, www.example.com, and shop.example.com are distinct names; a certificate covering only one does not necessarily cover the others.
A wildcard such as *.example.com normally covers a single matching level, including www.example.com or shop.example.com. It does not cover the bare example.com name or deeper names such as a.shop.example.com. Check the actual SAN list rather than assuming a product label covers every subdomain.
A mismatch may mean the certificate needs different names, or the server is presenting another site’s certificate. Review certificate assignment, virtual hosts, SNI, and DNS destinations before ordering a replacement.
An HTTPS redirect is not a fix for an invalid certificate on the original hostname: TLS validation happens before the redirect can be followed. Maintain valid certificate coverage for HTTPS names that redirect visitors.
How to Fix SSL Certificate Trust Errors
For Website Visitors
1. Check the URL, including spelling and the subdomain. Stop if a link sends you to an unexpected hostname.
2. Verify the device’s real date, time, and time zone; use supported automatic synchronization where appropriate.
3. Update the browser and operating system through their normal update process. An old or unsupported trust store can differ from current clients.
4. Test a separate trusted device or network. One-device failures suggest a local issue; failures on independent networks can point toward the site. These comparisons are clues rather than proof of security.
5. Check for a public Wi-Fi sign-in portal or managed-network TLS inspection. Use the operating system’s legitimate network sign-in prompt; ask IT about corporate certificates or policies. Do not bypass a website warning to reach a portal.
6. Contact the website owner when the certificate itself is invalid. Do not submit sensitive information while the warning remains unresolved, remove managed protections, or import an unfamiliar certificate.
For Website Owners
1. Record the exact browser or TLS validation error and affected hostname. Separate authority/chain problems from date and hostname failures.
2. Inspect the certificate the endpoint actually presents. Compare the issuer, serial number or fingerprint, and dates with the intended installation; a control-panel status alone is insufficient.
3. Check issuer chain, validity dates, and SAN coverage together. Compare independent client results and identify any proxy or HTTPS inspection in the path.
4. Confirm that the correct certificate and matching key are assigned to the intended virtual host or TLS listener. Keep private keys secure and follow the platform’s supported deployment process.
5. Correct missing or inappropriate intermediates using the issuer’s chain instructions. Do not solve a public trust problem by asking visitors to trust a private root.
6. Renew, reissue, or replace only when that addresses the diagnosed cause. A missing intermediate or wrong certificate assignment may need configuration changes rather than renewal.
7. Retest externally after activation, including affected subdomains and different server/address paths. Keep verification enabled and review any remaining errors before declaring the issue resolved.
Follow browser-specific “Your Connection Is Not Private” troubleshooting
SSL Trust Problems With Cloudflare
A proxied website has separate visitor-to-Cloudflare and Cloudflare-to-origin TLS connections. A browser normally evaluates Cloudflare’s edge certificate; Cloudflare evaluates the origin connection according to the configured encryption mode.
Cloudflare Origin CA certificates are intended for the Cloudflare-to-origin link and are not generally trusted by ordinary browsers connecting directly to the origin. A direct-browser trust warning about an Origin CA certificate does not mean it is unsuitable for its intended private origin connection.
Full (strict) requires appropriate origin certificate trust, valid dates, and hostname coverage. A suitable publicly trusted or Cloudflare Origin CA certificate can satisfy that configuration. A valid edge certificate or Universal SSL status does not prove that the origin certificate is valid.
Inspect edge activation and hostname coverage separately from origin chain, dates, and assignment. An external checker of the proxied hostname normally samples the edge. Cloudflare 525 indicates an origin handshake failure; 526 indicates invalid origin certificate validation in Full (strict), which is different from a browser warning about the edge certificate.
Do not switch to Flexible SSL or weaken validation as a general fix for origin trust errors. Correct the affected certificate or configuration through the responsible hosting or Cloudflare administrator.
How to Diagnose SSL Chain Problems With OpenSSL
OpenSSL must be installed and available in your terminal. Replace both occurrences of example.com with the exact hostname in this first command:
openssl s_client -connect example.com:443 -servername example.com -showcerts -verify_return_error-connect selects the host and HTTPS port; -servername supplies SNI so the server can select the intended certificate. -showcerts displays the certificates supplied by that server. -verify_return_error makes certificate verification errors fail the connection instead of merely reporting them and continuing.
Review the verification output and server-presented leaf/intermediates. The list from -showcerts is not itself a verified chain: OpenSSL builds a chain using the presented certificates and its local trust configuration. “Unable to get local issuer certificate” can reflect a missing intermediate or a local CA-store issue; compare the issuer requirements and another appropriate client.
Add hostname verification when testing identity
The first command does not explicitly request hostname matching. A handshake or chain-verification success alone is not proof of complete certificate validation. To test the hostname too, use -verify_hostname and review the final verification result. OpenSSL does not automatically reproduce every browser policy or perform every revocation check.
For a POSIX-compatible shell on macOS or Linux, this version also closes input after the diagnostic connection:
openssl s_client -connect example.com:443 -servername example.com -showcerts -verify_return_error -verify_hostname example.com </dev/nullThe first command is interactive and may remain open; end it with Ctrl+C after collecting the result. The /dev/null redirection in the second example is POSIX shell syntax, not a command to paste unchanged into Windows PowerShell or Command Prompt.
Verification depends on the CA store and OpenSSL configuration on the test machine. Use an organization-approved trust configuration when testing private services. Do not add the certificate being investigated as a trusted root just to produce a successful result.
When to Contact Your Hosting Provider
Ask for assistance with certificate installation, failed renewals, missing intermediates, an unexpected served certificate, shared-host configuration, or TLS changes after migration. Cloudflare origin problems may require the hosting provider and the proxy administrator to coordinate.
Share the exact hostname, error code, timestamps, public certificate details, and recent hosting/DNS changes. Mention whether the issue affects different devices or networks. Do not send private keys, passwords, API credentials, or sensitive customer information in an ordinary support message.
Explore Hostingcone SSL Certificates
Explore Hostingcone Website Care
Get help with website repairs and configuration issues
Review Hostingcone’s Website Migration service
Service scope depends on the purchased plan or work agreed. Third-party hosting, DNS, proxies, software, and access requirements can affect investigation and results. No certificate or troubleshooting service guarantees that every website security risk is eliminated.
Frequently Asked Questions
Why is my SSL certificate not trusted?
The client may be unable to build an acceptable chain to its trusted authorities, for example because the issuer is private/self-signed or an intermediate is missing. Date and hostname failures are separate validation problems that can also produce a general warning.
Is a self-signed certificate secure?
It can support encryption in a controlled environment with a deliberately managed trust policy. Public browsers do not automatically trust a website’s self-signed leaf certificate, so it is generally unsuitable for ordinary public access without an appropriate trust model.
What is an intermediate certificate?
It belongs to a CA between the server certificate and a trusted root. Servers normally supply the required intermediates so clients can build a valid chain; root trust normally comes from the client’s trust store.
Why does my SSL work on one browser but not another?
Clients can use different roots, chain-building behavior, cached intermediates, policies, clocks, or network paths. Compare updated clients and trusted networks, then check that the server supplies its required intermediate chain.
Can an expired certificate cause trust errors?
Yes, it can cause certificate rejection and a general security warning. More precisely, expiry is a date-validation failure, not necessarily evidence that the issuing authority is untrusted.
How do I fix NET::ERR_CERT_AUTHORITY_INVALID?
Identify the certificate and chain actually presented, check the issuer and intermediate installation, and compare another trusted client/network. Review private issuers or HTTPS interception with the responsible administrator. Keep certificate verification enabled.
Can Cloudflare cause certificate trust problems?
Edge certificate coverage or activation can affect visitors, while origin certificate validation is a separate connection. Origin CA certificates are not normally browser-trusted for direct access; Full (strict) needs suitable valid origin configuration.
Does an SSL certificate guarantee website security?
No. A correctly validated certificate helps authenticate the hostname and protect traffic in transit. It does not guarantee safe content, secure applications, malware prevention, or uninterrupted service.
How do I test my SSL certificate chain?
Inspect the exact hostname using a verified public checker or OpenSSL’s verification output and server-presented chain. Add explicit hostname verification where needed and interpret results against the client’s CA store. A successful handshake alone is insufficient.
Resolve SSL Certificate Problems With Confidence
Check your certificate's trust status, issuer, and validity information, or explore Hostingcone's SSL solutions and website troubleshooting services.