NET::ERR_CERT_SYMANTEC_LEGACY (distrusted CA)

What’s actually happening

A full-page browser interstitial blocks the site, and unlike a normal name or expiry mismatch the cert itself can still be inside its validity dates. The dates are fine, the chain is the problem. This is a deliberate browser policy decision: the cert traces back to a root operated under Symantec's old PKI. It hits every visitor on Chrome 66+ and recent Firefox regardless of OS or network, and clicking through is often not even offered.

Common causes

• The server certificate was issued by Symantec, GeoTrust, Thawte, RapidSSL, or Equifax under the legacy Symantec PKI that browsers stopped trusting
• Chrome distrusted certs issued before June 1, 2016 starting in Chrome 66, then distrusted the entire legacy Symantec PKI in Chrome 70 (October 2018); Firefox rolled out the same distrust in parallel
• An old long-lived (e.g. 3-year) cert bought years ago that is technically unexpired but chains to a now-untrusted root
• An intermediate certificate in the chain that itself was issued off the distrusted Symantec hierarchy
• A server never reissued after the 2018 distrust deadline, often a forgotten internal tool or a legacy subdomain

How to fix it

1. Confirm it's the CA, not expiryOpen the cert (click the warning > certificate details, or run openssl s_client -connect example.com:443 -showcerts) and read the issuer chain. If you see Symantec, GeoTrust, Thawte, RapidSSL, or Equifax up the chain, it's the distrust, and no clock change or date fix will help.
2. Reissue from a currently trusted CAGet a fresh certificate from Let's Encrypt (free, automated), DigiCert, Sectigo, or Google Trust Services. Generate a new CSR, validate the domain, and you'll get a cert that chains to a modern trusted root. This is the actual fix; everything else is a workaround.
3. Install the full new chainDeploy the new leaf plus the correct intermediate bundle your CA provides. A leaf that's fine but an intermediate still pointing at the old hierarchy keeps the error alive. Verify with the SSL Labs server test (ssllabs.com/ssltest) or openssl that the served chain is clean end to end.
4. Automate renewal so it never recursPut certbot or your ACME client on a cron/systemd timer, or let your host/CDN (Cloudflare, your load balancer) manage TLS. Short-lived auto-renewed certs mean you're never again holding a multi-year cert when a CA gets distrusted.