NET::ERR_CERT_SYMANTEC_LEGACY: Fix in Chrome

Problem

Chrome shows Your connection is not private with the code NET::ERR_CERT_SYMANTEC_LEGACY. There is no bypass button that makes it go away cleanly, and reloading changes nothing. This is not an expiry error, not a name mismatch, and not a chain problem in the usual sense. The certificate on this site was issued by the Symantec certificate authority hierarchy, and Chrome has deliberately stopped trusting that entire hierarchy. The browser isn’t confused about your certificate — it recognizes exactly who signed it and refuses on principle.

Symptoms

• The full-page interstitial reads NET::ERR_CERT_SYMANTEC_LEGACY (Chrome and Edge).
• The certificate’s dates are still valid — this is not ERR_CERT_DATE_INVALID.
• The issuer chain traces back to Symantec, Thawte, VeriSign, GeoTrust, or RapidSSL.
• Firefox or Safari may load the same site, or may show their own distrust wording.
• The error survives a cache clear and a reload, because it’s a property of who issued the certificate.

What This Error Actually Means

In 2017 Google concluded a long investigation into Symantec’s certificate authority operations, having found that Symantec and its partners had misissued certificates over a period of years. The response was blunt: Chrome would stop trusting the Symantec PKI entirely, in two waves. Certificates issued before 1 June 2016 lost trust with Chrome 66, which reached stable on 17 April 2018. Every remaining Symantec-issued certificate lost trust with Chrome 70, on 16 October 2018.

Symantec’s certificate business was sold to DigiCert in late 2017, and certificates issued through DigiCert’s modern infrastructure after that transition are fine. What NET::ERR_CERT_SYMANTEC_LEGACY flags is specifically a certificate still chaining to the old, distrusted Symantec roots. If you are seeing this in 2026, it means a certificate from that era is somehow still in service — a long-lived certificate that never got rotated, a device with a baked-in cert, or an internal appliance nobody touched.

The important thing to understand: you cannot fix this by renewing with the same authority or by adjusting your server. The distrust is aimed at the issuer, so the only real fix is a certificate from a CA Chrome still trusts.

Top 3 Causes

1. A long-lived Symantec-era certificate that was never rotated - The common case. A certificate issued before the 2018 cutoffs, with a multi-year validity window that has only now become a problem, or an automation gap that kept renewing against a legacy chain. The certificate is genuine Symantec lineage, and Chrome distrusts it on sight.
2. A reseller or brand you didn’t recognize as Symantec - You bought a “GeoTrust” or “RapidSSL” certificate without realizing those were Symantec brands. The issuer field, not the storefront, is what Chrome evaluates, and it sees Symantec.
3. An appliance, load balancer, or internal service with a baked-in legacy cert - Network gear, older management interfaces, and internal tools sometimes ship with or were configured to use a Symantec-lineage certificate that never made it onto anyone’s renewal calendar.

Diagnose with DechoNet

• SSL Check reads the certificate actually being served and shows the issuer and full chain. Look at who signed the certificate — if the chain names Symantec, Thawte, VeriSign, GeoTrust, or RapidSSL, that confirms the distrust is the cause and not something else.
• HTTP Check confirms the endpoint responds once you’re past the certificate question, useful for verifying the fix reached every layer that terminates TLS.

Resolution Checklist

• Confirm the issuer on the wire, not the file on disk: echo | openssl s_client -connect YOUR_DOMAIN:443 -servername YOUR_DOMAIN 2>/dev/null | openssl x509 -noout -issuer -dates. If the issuer names Symantec, Thawte, VeriSign, GeoTrust, or RapidSSL, this is the distrust.
• Reissue from a currently-trusted CA. This is the fix — renewing with the same lineage does nothing. Let’s Encrypt (free), DigiCert, or any modern public CA will issue a certificate that Chrome trusts. Generate a fresh key and CSR.
• Install the new certificate and its full intermediate chain. A missing intermediate turns your Symantec problem into an ERR_CERT_AUTHORITY_INVALID or chain error — fix one, don’t trade it for another.
• Reload every layer that terminates TLS: origin server, reverse proxy, load balancer, and CDN edge. A single stale layer keeps serving the old distrusted certificate to a slice of users.
• Re-run SSL Check and confirm the served issuer is now the modern CA, from more than one vantage point if you use anycast or a CDN.
• Set up automatic renewal so the replacement never becomes another forgotten long-lived certificate.

When to Escalate

• If the certificate lives on an appliance or vendor device you can’t reissue yourself, contact the vendor for a firmware or certificate update — a distrusted root baked into shipping hardware is their problem to fix.
• If SSL Check shows a modern issuer but Chrome still reports NET::ERR_CERT_SYMANTEC_LEGACY, suspect a stale intermediate in the served chain: the leaf was reissued but the bundle still ships an old Symantec intermediate. Rebuild the chain from the new CA’s current intermediates.
• If only machines behind a corporate network see the error, a TLS-inspection proxy may be re-signing with a legacy chain — that’s the network operator’s fix, not yours.