Last updated: Oct 26, 2025
If you’re seeing the NET::ERR_CERT_SYMANTEC_LEGACY error in Google Chrome, it means the browser is blocking the website’s SSL certificate because it was issued by Symantec or one of its old certificate authorities (GeoTrust, Thawte, RapidSSL, etc.). This is not a browser glitch — it is a permanent distrust policy enforced by Chrome, because older Symantec certificates no longer meet modern security compliance requirements.
In 2018, Google and major browser vendors officially distrusted all legacy Symantec-issued SSL certificates, after a long security investigation into improper certificate issuance. As a result, Chrome now refuses to load any HTTPS site still using those legacy certificates, even if the certificate has not yet expired.
This error can affect:
-
Older websites still using pre-2018 Symantec SSL certificates
-
Corporate/intranet systems running on outdated cert chains
-
Staging environments with archived CA bundles
-
Sites migrated incorrectly (still serving old intermediate certs)
-
GeoTrust / Thawte / RapidSSL certs issued before DigiCert takeover
End users will see a connection-blocking error page and cannot proceed securely. Website owners must replace or reissue the certificate using a trusted modern CA (such as DigiCert, Sectigo, or Let’s Encrypt) to resolve the issue permanently.
In this guide, you’ll learn:
-
What the NET::ERR_CERT_SYMANTEC_LEGACY error really means
-
Why Chrome distrusts Symantec legacy certificates
-
Which SSL brands are affected
-
How to check if your certificate is impacted
-
Temporary vs permanent fixes
-
How to replace Symantec/GeoTrust/Thawte/RapidSSL certificates correctly
This is not something you can fix by clearing cache, reinstalling Chrome, or disabling HTTPS. The only real fix is replacing the legacy Symantec certificate with a modern CA-issued SSL.
What Does NET::ERR_CERT_SYMANTEC_LEGACY Actually Mean?
When Chrome shows NET::ERR_CERT_SYMANTEC_LEGACY, it means the browser is rejecting the SSL certificate because it was issued by Symantec’s legacy certificate infrastructure, which Chrome no longer trusts. Unlike normal SSL errors (such as expired certificates or hostname mismatch), this is a full CA distrust — meaning Chrome will block the connection even if the SSL certificate is technically valid and not expired.
This is not a local computer problem, not a browser issue, and not something that can be fixed by clearing cache, restarting Chrome, or changing settings. The certificate authority (Symantec or one of its sub-brands) itself has been permanently distrusted by Chrome and other Chromium-based browsers.
Plain English explanation:
The SSL certificate on the website comes from a company Chrome no longer trusts, so Chrome refuses to establish the HTTPS connection.
Why Chrome refuses these certificates
Chrome does not consider Symantec’s old root and intermediate authorities secure anymore. The browser treats all certificates issued by these older Symantec CA chains as “toxic,” and flags them as legacy SSL certificates — hence the error ERR_CERT_SYMANTEC_LEGACY.
This is fundamentally different from:
| Issue | Browser Behavior |
|---|---|
| Expired certificate | Can be renewed |
| Self-signed certificate | Can be trusted locally |
| Wrong hostname | Can be reissued |
| Symantec legacy certificate | Can never be trusted again |
The only real solution is replacing the SSL certificate with a new one issued by a modern CA.
Why Chrome Distrusts Symantec SSL Certificates (The Real Reason Behind ERR_CERT_SYMANTEC_LEGACY)
The NET::ERR_CERT_SYMANTEC_LEGACY error exists because Google Chrome (and later Firefox, Edge, Opera, Brave) permanently distrusted all legacy Symantec SSL certificates after discovering major security and compliance failures in Symantec’s certificate authority operations.
Between 2015 and 2017, security researchers and browser vendors found that Symantec improperly issued tens of thousands of certificates — including test certificates for real domains like google.com without authorization. This violated CA/B Forum rules and greatly weakened public trust in the entire Symantec PKI infrastructure.
As a result, Google announced a phased distrust:
| Timeline | What Happened |
|---|---|
| 2017 | Google publicly announces distrust plan |
| 2018 (Chrome 66–70) | Gradual distrust of Symantec root certificates begins |
| Oct 2018 | Full distrust of Symantec legacy SSL chains |
| 2019+ | GeoTrust, Thawte, RapidSSL (Symantec-owned) also distrusted |
| 2020–Now | ANY SSL using Symantec’s legacy chain triggers ERR_CERT_SYMANTEC_LEGACY |
Even though Symantec sold its SSL business to DigiCert, all certificates issued before the migration still use the old Symantec root/intermediate chains, which Chrome treats as insecure and untrustworthy.
This is why replacing the certificate — not “fixing” Chrome — is required.
This is not a browser bug — it’s enforced security
Chrome is not malfunctioning here; it’s enforcing a global industry-level security action. The distrust is baked into the Chrome certificate transparency rules and cannot be bypassed.
If a website still uses a Symantec legacy certificate, Chrome will always show NET::ERR_CERT_SYMANTEC_LEGACY until the certificate is replaced.
Other browsers also distrust Symantec
Although Chrome led the change, Firefox, Edge, Opera, Brave, and Chromium-based browsers all enforce the same policy. Safari eventually aligned as well, although Apple’s enforcement lagged briefly.
Which SSL Certificates Are Affected by NET::ERR_CERT_SYMANTEC_LEGACY?
Many website owners don’t realize they are still using a Symantec legacy SSL certificate because the certificate may not explicitly say “Symantec” in the UI. This is because Symantec owned several popular CA brands under its PKI infrastructure. When Chrome distrusted Symantec, it also distrusted all certificates issued by these associated brands before the DigiCert migration.
All affected certificate brands include:
| Legacy CA Brand | Status in Chrome | Still Trusted? |
|---|---|---|
| Symantec SSL | Distrusted | ❌ |
| GeoTrust | Distrusted (legacy chain) | ❌ |
| Thawte | Distrusted (legacy chain) | ❌ |
| RapidSSL | Distrusted (legacy chain) | ❌ |
| VeriSign (older roots) | Distrusted | ❌ |
These certificates cannot be repaired — they must be reissued or replaced using a modern CA chain.
This is why the Chrome error says CERT_SYMANTEC_LEGACY — it is literally telling you the certificate comes from a deprecated Symantec trust chain.
Important clarification
Not all GeoTrust/Thawte/RapidSSL certificates are distrusted — only those issued before the migration to DigiCert (pre-late 2018). After DigiCert took over the Symantec PKI infrastructure, newer certificates use DigiCert’s root chain and are fully trusted.
But if your site is still using an old intermediate or old CA chain bundle, Chrome will continue to block it even if the certificate is not expired.
Quick check:
If your certificate was issued before December 2018, it is almost certainly from a legacy Symantec chain and must be replaced.
How to Check If Your SSL Certificate Is a Symantec Legacy Certificate
Before replacing anything, you should confirm whether the certificate actually belongs to a legacy Symantec chain. The fastest way to verify is to inspect the issuer and intermediate CA. If the chain links back to Symantec, Thawte, GeoTrust, RapidSSL, or VeriSign (legacy), Chrome will classify it as CERT_SYMANTEC_LEGACY and block the connection.
There are two ways to check — inside Chrome itself and using an online SSL checker.
Method 1: Check in Chrome (Direct Browser Check)
-
Open the website in Chrome (you will see the error page)
-
Click Not Secure / Certificate (or click padlock → Certificate)
-
Look at Issued by
-
If you see any of these names:
-
Symantec
-
GeoTrust
-
Thawte
-
RapidSSL
-
VeriSign
then it is a legacy Symantec certificate
-
Additionally, if Chrome literally says:
then the browser has already confirmed it is a Symantec chain.
Method 2: Check using SSL Labs or other validation tools
You can also verify with an SSL testing tool such as:
-
SSL Labs (Qualys)
-
DigiCert SSL Checker
-
GeoCerts SSL Tester
-
Wormly SSL Checks
These tools show:
-
The full certificate chain
-
Which CA issued it
-
Whether the chain is outdated or distrusted
If the issuer chain includes any Symantec PKI roots, the certificate must be replaced.
Developer / Terminal Check (Advanced)
On macOS/Linux:
Look for:
If so → this is a Symantec legacy SSL and Chrome will never trust it again.
How to Fix NET::ERR_CERT_SYMANTEC_LEGACY (User vs Website Owner Fixes)
Because this error is triggered by Chrome distrusting the certificate authority (not the browser or the network), the correct solution depends on who you are:
| Scenario | Can you fix it locally? | Real fix |
|---|---|---|
| You are a visitor | Only temporary workarounds | No permanent fix possible |
| You own/manage the website | YES | Replace/reissue SSL cert |
If you are just visiting a site, you cannot repair the certificate — the only permanent fix must be done by the server owner. The Symantec PKI is dead, so Chrome will never trust those chains again.
Fix for Website Visitors (Temporary / Access Workarounds)
These do not fix the certificate — they simply allow you to continue if you trust the site.
-
Try opening the site in Firefox or Safari
(these browsers were slower to enforce distrust) -
Try viewing in Incognito → Proceed anyway (not recommended for sensitive data)
-
If it’s your corporate VPN/intranet, contact IT support
(they must reissue the certificate)
But note:
Chrome will always show NET::ERR_CERT_SYMANTEC_LEGACY until the site replaces its SSL certificate.
Fix for Website Owners (Permanent Solution)
If you manage the domain, the only real solution is to replace the old Symantec SSL certificate with a new certificate from a trusted modern Certificate Authority (CA). This means reissuing or migrating away from the legacy Symantec PKI chain.
There are two working approaches:
Option A — Reissue the Certificate Under DigiCert (Same brand, new chain)
DigiCert now manages the old Symantec brands. If you still have an active certificate (not expired yet), you can reissue it for free under the new DigiCert root.
This applies to:
-
GeoTrust
-
Thawte
-
RapidSSL
-
Symantec SSL (legacy)
Result: same brand name, but trusted under DigiCert PKI
→ Chrome accepts it again
Option B — Replace the Certificate With a New CA (Let’s Encrypt, Sectigo, DigiCert, etc.)
If the certificate is expired or you don’t want to maintain Symantec-branded SSL, replace it completely:
Examples of fully trusted CAs:
| Modern CA | Good For |
|---|---|
| Let’s Encrypt | Free + automatic renewal |
| Sectigo (Comodo) | Budget paid SSL |
| DigiCert | Enterprise / EV / OV |
| GlobalSign | Corporate / enterprise |
| Entrust | Banking/finance |
After installation, Chrome will no longer block the HTTPS connection.
Important:
No amount of browser tweaking, proxy bypassing, or “trust exceptions” will fix a Symantec legacy certificate. The CA itself is distrusted — the certificate must be reissued or replaced.
How to Migrate Away From a Symantec Legacy SSL Certificate (Step-by-Step)
Once you confirm that your website is using a legacy Symantec SSL chain, the only permanent fix for NET::ERR_CERT_SYMANTEC_LEGACY is to replace or reissue the certificate. There is no patch, browser flag, or trust exception that can “re-enable” Symantec PKI — Google pulled trust at the browser engine level (root CA distrust), meaning reinstallation or renewal of the same certificate will not work.
Here are the two supported migration paths depending on whether your certificate is still active or already expired:
Path 1 — Reissue Under DigiCert (If Your Symantec-family SSL Is Still Active)
DigiCert acquired the Symantec CA infrastructure and now manages reissues for:
-
GeoTrust
-
Thawte
-
RapidSSL
-
Old Symantec SSL certificates
Reissuing is free if the certificate is still within its validity period.
You keep the same brand, but DigiCert provides a new trusted chain.
High-Level Migration Steps:
-
Log into the SSL panel of your current provider
-
Find the existing Symantec/GeoTrust/Thawte/RapidSSL certificate
-
Choose Reissue / Re-Key
-
Generate a new CSR (same domain)
-
DigiCert issues a new certificate under their root
-
Install the new chain/fullchain on the server
-
Restart webserver / CDN
After reissue, the certificate will inherit DigiCert’s trusted chain → Chrome accepts it again.
Path 2 — Replace the SSL Certificate Completely (If expired or migrating away)
If the legacy certificate has expired — or if you want to stop using old Symantec-branded SSL entirely — you can install a brand-new certificate from a modern CA such as Let’s Encrypt, Sectigo, DigiCert, or GlobalSign.
High-Level Replacement Steps:
-
Purchase or issue a new SSL certificate from a trusted CA
(Let’s Encrypt, DigiCert, Sectigo, GlobalSign, etc.) -
Generate a CSR and complete validation (DV / OV / EV)
-
Download the new cert + intermediate bundle
-
Install on webserver / hosting panel
-
Remove old Symantec chain
-
Restart or reload your webserver (Apache, Nginx, etc.)
Once the old certificate chain is removed, Chrome will immediately stop showing ERR_CERT_SYMANTEC_LEGACY.
Why reissue is often better than replacement
Reissuing under DigiCert keeps:
✔ Same expiration window
✔ Same warranty
✔ Same OV/EV validation level
✔ No redirect/SEO changes
✔ Less downtime
Replacement is recommended:
✔ When migrating to Let’s Encrypt
✔ For automation (ACME)
✔ For cost reduction
✔ For staging/dev environments
How to Install the Reissued / New SSL Certificate (Apache, Nginx, Cloudflare) + Verification
Once you reissue or replace the legacy Symantec SSL certificate, you must install the new DigiCert/modern CA chain on your server or CDN. The error will persist until the new chain fully replaces the old Symantec intermediate.
Below are the correct installation steps for the most common environments:
Apache (Reissue/Replace Installation)
-
Upload the new certificate (
yourdomain.crt) -
Upload the new intermediate/chain (from DigiCert or new CA)
-
Update your VirtualHost:
-
Save and restart:
If the old Symantec chain is still referenced in ca-bundle.crt, Chrome will continue rejecting it → ensure the bundle file is updated too.
Nginx (Reissue/Replace Installation)
Nginx requires a fullchain instead of separate cert + intermediate.
Then reload:
If you don’t replace the fullchain, Nginx will continue serving the Symantec legacy intermediate, causing Chrome to show ERR_CERT_SYMANTEC_LEGACY even after “reissuing”.
Cloudflare
If using Cloudflare, you must update the origin certificate:
-
Go to Cloudflare Dashboard → SSL/TLS
-
Check “Origin Server”
-
If origin uses a legacy Symantec certificate → Replace it
-
Use Cloudflare origin cert OR DigiCert/LetsEncrypt
-
Purge cache → Full
However, even if Cloudflare’s edge cert is valid, the origin cert MUST NOT be Symantec legacy — Chrome still checks the backend during handshake.
cPanel / WHM
-
Go to SSL/TLS > Manage SSL sites
-
Install the new cert + CA bundle
-
Remove the old Symantec CA bundle
-
Save → Auto reloads Apache
How to Verify the Fix (after install)
Browser-level check (Chrome):
-
Visit the site
-
Click padlock → Certificate → “Issued by”
If it says DigiCert or another modern CA → ✅ FIXED
If it still says GeoTrust/Thawte/VeriSign/Symantec → still legacy
External validation:
Use SSL Labs:
Look for:
-
Chain issues: “Incorrect certificate chain” = Symantec still present
-
Trusted path: must chain to DigiCert / Let’s Encrypt / Sectigo
Troubleshooting: Why Chrome Still Shows NET::ERR_CERT_SYMANTEC_LEGACY After Replacing the SSL Certificate
If you already reissued or replaced your certificate but Chrome is still showing the NET::ERR_CERT_SYMANTEC_LEGACY error, then the problem is usually not the new certificate — it’s that the server is still serving the OLD intermediate chain. Chrome validates the entire chain, so if even one Symantec intermediate remains, the browser continues to block HTTPS.
This happens frequently when:
-
The hosting panel didn’t update the CA bundle
-
The sysadmin replaced only the leaf cert but not the chain
-
Cloudflare/CDN is serving a cached origin cert
-
Nginx fullchain.pem was not replaced fully
-
Apache is still referencing an outdated ca-bundle.crt
-
A load balancer terminates SSL using the legacy cert
Most common causes (post-migration failure)
| Cause | Why Chrome still blocks it |
|---|---|
| Old intermediate bundle still installed | Chain still points to Symantec |
| CA bundle path not updated | Server loads old chain |
| Cloudflare caching the origin | Edge OK, origin fails |
| Nginx fullchain not replaced | Old issuer remains |
| Apache using dual-cert config | Old one still loaded |
Fix Checklist (Server-side)
✅ Make sure new CA bundle is installed
✅ Confirm Symantec intermediate is fully removed
✅ Restart web server (reload is sometimes not enough)
✅ On Nginx, ensure fullchain.pem is new, not just cert.pem
✅ On Apache, confirm SSLCertificateChainFile path points to new bundle
✅ On Cloudflare or CDN, purge Origin SSL cache
✅ Check load balancer SSL termination if using HAProxy/NGINX-Ingress/ALB
Quick diagnostic test
Run:
Scroll up and check the Issuer:
❌ If you still see GeoTrust / RapidSSL / Thawte / Symantec / VeriSign → legacy chain still in use
✅ If you see DigiCert / Let’s Encrypt / Sectigo / GlobalSign → fixed
One more overlooked issue: Old certificate still installed on staging
Many website owners migrate production but forget staging or subdomains. Chrome will still block staging/dev/test URLs if they serve a Symantec legacy certificate — especially on wildcard certs or inherited chains.
Prevention & Best Practices (So the Symantec Legacy SSL Error Never Returns)
Once you’ve replaced the old Symantec certificate with a modern CA, the next step is preventing the NET::ERR_CERT_SYMANTEC_LEGACY error from reappearing in Chrome. This is especially important for businesses, agencies, ecommerce sites, SaaS applications, and enterprise infrastructure where SSL validation is tied to brand trust and uptime.
Because the problem originates from legacy CA infrastructure, not the browser, prevention is about ensuring your SSL chain always uses a modern, trusted root CA that Chrome recognizes — and never accidentally falls back to an outdated Symantec intermediate.
Best Practices for Website Owners / Developers
A temporary fix is not enough — proper SSL lifecycle management prevents this from happening again.
-
Always verify your SSL issuer chain after installation
(Chrome must show DigiCert, Sectigo, Let’s Encrypt, GlobalSign, etc.) -
Remove all old Symantec intermediates from the server
-
Reissue certs that were originally purchased pre-2018
-
Use CA bundles from your current provider, not archived backups
-
For Nginx, update fullchain.pem — not just the leaf
.crt -
For Apache, confirm
ca-bundle.crtpoints to the new intermediate -
If using Cloudflare/CDN, recheck origin certificate, not just edge SSL
-
Automate renewal (ACME) for zero chance of fallback to a legacy chain
Best Practices for Agencies / IT Teams
If you manage multiple client sites, subdomains, or corporate infrastructure:
-
Audit certificates yearly for legacy Symantec chains
-
Replace all older GeoTrust/Thawte/RapidSSL certs organization-wide
-
Standardize on a CA (Let’s Encrypt / DigiCert / Sectigo)
-
Store the latest CA bundles, never reuse old packages
-
Document reissue process for fast future maintenance
Why prevention matters
A site can be fully “valid” in terms of HTTPS expiration, hostname, and configuration — yet still blocked in Chrome if it uses a legacy Symantec issuer chain. This means uptime, conversions, and SEO visibility can all suffer from something that looks invisible until Chrome enforces the distrust.
By fully migrating to a modern CA and removing Symantec intermediates, you permanently eliminate the possibility of this browser error returning.
Frequently Asked Questions (FAQ)
1. What is NET::ERR_CERT_SYMANTEC_LEGACY in Chrome?
This Chrome error appears when a website is using a legacy Symantec SSL certificate or an old intermediate chain from Symantec-owned CAs (GeoTrust, Thawte, RapidSSL, or VeriSign). Chrome permanently distrusts these certificates, so it blocks the HTTPS connection.
2. Can I fix NET::ERR_CERT_SYMANTEC_LEGACY by changing browser settings?
No. This is not a browser setting issue — it is a CA distrust issue. Chrome will never trust legacy Symantec certificates again. The only permanent solution is reissuing or replacing the SSL certificate.
3. Why did Chrome distrust Symantec certificates?
Google and other browser vendors found large-scale mis-issuance problems in Symantec’s certificate infrastructure. As a result, Chrome removed Symantec’s root and intermediate CAs from the trust store. That’s why Chrome shows ERR_CERT_SYMANTEC_LEGACY.
4. Which certificates are affected?
The following legacy SSL brands are affected:
-
Symantec SSL
-
GeoTrust
-
RapidSSL (old chain)
-
Thawte
-
VeriSign
Any certificate issued before the DigiCert migration (pre-late 2018) is distrusted.
5. Why does the site work in Firefox but not Chrome?
Firefox uses its own trust store, while Chrome relies on the OS + CA trust rules defined by Chromium. Chrome enforces Symantec distrust more strictly than Firefox, so a website may still load in Firefox even when Chrome blocks it.
6. Can I bypass this error as a user?
You may temporarily view the site in:
-
Firefox
-
Safari
-
Edge (sometimes)
However, this is only a workaround. You cannot permanently fix it unless you control the website’s SSL certificate.
7. I replaced the certificate, but Chrome still shows the error — why?
This usually means the old Symantec intermediate chain is still being served. You must update the CA bundle/fullchain — not just the leaf certificate — and restart your web server or CDN.
8. Which CA should I migrate to?
Any modern CA is trusted by Chrome, including:
-
DigiCert (enterprise)
-
Let’s Encrypt (free, ACME automation)
-
Sectigo / Comodo (budget-friendly)
-
GlobalSign / Entrust (corporate)
Conclusion
The NET::ERR_CERT_SYMANTEC_LEGACY error is not a temporary glitch — it is Chrome enforcing a permanent security decision to distrust all legacy SSL certificates issued under the old Symantec PKI. That includes legacy GeoTrust, Thawte, RapidSSL, VeriSign, and Symantec-branded certificates. No browser setting, cache clear, or OS tweak can “fix” these certificates — the only true solution is replacing or reissuing the SSL certificate under a modern trusted CA chain, such as DigiCert, Sectigo, GlobalSign, or Let’s Encrypt.
If you are a visitor, you cannot repair the certificate, only work around it temporarily. If you own or manage the site, you must reissue or migrate the SSL certificate to a trusted CA. In most cases, reissuing through DigiCert (for old Symantec-family brands) is free and restores trust immediately. If you run Apache, Nginx, or Cloudflare, you must also update the CA bundle / fullchain to fully remove the legacy Symantec intermediate.
By replacing the certificate with a modern trusted root, Chrome will stop blocking access and your website will once again be recognized as secure.
