You bought a certificate. You installed it. It worked. Then one day a customer writes: "Your site won't open in Chrome. It says Not secure." You check, and the certificate is fine. It works in Firefox. It works in Safari. It works in Edge. It works on your phone. Only Chrome complains. You didn't change anything.
You're right, you didn't. Something changed on the other side, in a part of the internet most of us never look at: the companies that issue certificates and the rules browsers use to trust them. That world is ambiguous to regular customers, and it's easy to miss a rare email notification from your certificate provider. This guide explains what happened in plain words, how to confirm it in one click, and how to fix it without becoming a certificate expert.
Why only Chrome?
Behind every padlock is a simple idea. Each browser keeps a list of companies it trusts to issue certificates. If your certificate comes from a company on the list, you get the padlock. If not, Chrome shows a warning to your customers instead of landing them on your website.
Here's the part nobody tells you: these lists are not the same from one browser to the next, and Chrome recently started keeping its own. So the company that issued your certificate can still be trusted by Safari, Firefox, and your phone while Chrome has quietly dropped it. Same certificate, different answer. Nothing on your side broke.
Why this keeps happening in 2026
The certificate industry is in the middle of a long cleanup, and the changes land on website owners with very little notice. A few examples from this year, so you can see the pattern:
- Old "do-everything" certificates are being retired. Chrome now wants a website certificate to do one job (secure a website) and nothing else. Providers are sunsetting the older type to comply; DigiCert, for example, published its notice about removing the extra capability from public certificates.
- SSL.com is retiring its 2016 roots. Because those older roots were used for the "do-everything" type, SSL.com is moving customers to its newer 2022 roots, which Chrome trusts. Their deadline is May 5, 2026. If your certificate still connects up to a 2016 root, it can lose Chrome's trust while still working elsewhere.
- DigiCert's older "G1" roots leave Chrome on April 15, 2026. Certificates that rely on them stop being trusted on that day. See DigiCert's G1 root removal advisory.
- Some providers were dropped completely. Chrome stopped trusting Chunghwa Telecom and NetLock certificates issued after July 31, 2025.
You don't need to remember any of this. The point is simpler, and a little unfair: a decision made far away can switch off your site in Chrome, and you're often the last to know. (If you ever want the official version, Google explains it in its Chrome root program announcement.)
How to tell if this is your problem
Two quick checks, no special tools needed:
- Open the same page in two browsers. If Firefox or Safari load fine but Chrome shows a warning, that's the giveaway. It's a trust problem, not a broken certificate.
-
Read the small print in Chrome's warning. Click "Advanced." If you see
NET::ERR_CERT_AUTHORITY_INVALID, Chrome doesn't trust the company that issued your certificate. That's this exact situation.
The fastest way to know for sure is to check your own domain. Type it below and we'll scan it for you. You'll see, in seconds, whether your certificate is trusted or not.
Check your certificate now
Enter your domain and our free scanner will check whether your certificate is trusted, the same check Chrome runs before it shows the padlock. Results open in a new tab.
How to fix it
The fix is the same no matter which provider caused it: get a certificate that connects up to a list Chrome trusts today, and install the whole chain.
- Reissue from a current, Chrome-trusted provider. If your provider has moved to newer roots (as SSL.com has with its 2022 roots), ask for a reissued certificate on the new ones. Any well-known provider works in Chrome today: Let's Encrypt, DigiCert, Sectigo, SSL.com's 2022 roots.
- Install the full chain, not just your certificate. Your server has to send your certificate and the in-between certificates that connect it up to the trusted root. A missing middle piece is its own common cause of "fine for me, broken for them." Swapping only your own certificate isn't enough.
- Check Chrome and one other browser after you deploy to confirm the warning is gone for everyone.
Need a working certificate right now?
Beacon issues free 90-day Let's Encrypt certificates with a guided DNS-validation flow. No account, no command-line tools, no ACME client to install - just a domain you control. Most people get a working certificate in under 10 minutes.
Get a free certificate from BeaconIn Chrome, "not trusted" means lost customers
If you only read one section, read this one. A browser trust change can take your site offline in Chrome with no warning, and the first you hear of it is customers walking away. TLS Radar watches your certificate around the clock and tells you the moment Chrome, or any major browser, stops trusting it. Create a free account and get the alert before your visitors ever see a warning.
Here's why this is worth taking seriously. Chrome is the browser most of your customers use. By a wide margin, it holds the largest share of personal browsers in the world. When Chrome decides your certificate isn't trusted, it doesn't show a small note. It puts a full-page red warning between your visitor and your website, and tells them it isn't safe to continue.
Think about what that costs. Every person who clicks your link, your ad, or your search result hits a scary security screen and leaves. They don't email you. They just go to a competitor. Your sales drop. Your sign-ups drop. And the visitors who do see the warning start to wonder whether your business can be trusted at all. The damage isn't only today's lost traffic; it's the reputation that's hard to win back.
The worst part is that your certificate didn't expire and you didn't misconfigure anything. A list inside one browser changed, and the first sign of trouble was a customer who couldn't reach you. By then, the lost traffic is already gone.
This is exactly the kind of failure that's invisible until it's expensive, and exactly the kind you can prevent. You shouldn't have to follow browser announcements and provider deadlines just to keep your site open. We watch your certificate against the trust lists browsers actually use, and we warn you the moment one of them stops trusting it, not just when it's about to expire. When the certificate world makes its next sudden change, you hear it from us first, with time to act, instead of from an angry customer.
Stop this from happening again
TLS Radar continuously monitors every certificate across your domains and alerts you weeks before anything expires, and also catches the silent failure modes (chain breaks, weak ciphers, hostname mismatches) that expiry-only monitoring misses. Built for solo developers monitoring a handful of sites and for enterprise teams managing thousands of certificates across multiple environments.
Related reading
Get the next post in your inbox
TLS monitoring tips and product updates. No spam, unsubscribe anytime.
Keep reading
The True Cost of a TLS Outage (And Why Calendars Won't Save You)
What Is SSL/TLS Certificate Monitoring and Why Does It Matter?
SSL Certificate Outages - 4 Real Incidents and What They Teach Us
Related guides
-
“This Website Cannot Be Trusted”: What It Means and How to Fix It
What the “this website cannot be trusted” error really means, and how to fix it fast.
-
Browser Warning About Site Security - What It Means
A friendly tour of browser security warnings and what causes each one.