NET::ERR_CERT_SYMANTEC_LEGACY: What It Meant and What to Do Now

NET::ERR_CERT_SYMANTEC_LEGACY is a Chrome certificate error from a very specific moment in web history. It marked a certificate that traced back to Symantec’s old certificate authority, the infrastructure behind the Symantec, Thawte, GeoTrust, RapidSSL, VeriSign and Equifax brands, which Google removed from Chrome’s trust in 2018.

That story is finished, and so is the error code. This guide explains what the message meant, what Chrome shows in its place today, the only fix that works if your own site is affected, and why the usual browser troubleshooting steps were never able to help here.

Quick answer:

NET::ERR_CERT_SYMANTEC_LEGACY no longer exists. Chrome deleted the error code in Chrome 136, released on April 29, 2025, so no current browser can display it. It meant the site’s SSL certificate chained to Symantec’s legacy certificate authority, which Chrome stopped trusting in Chrome 70 in October 2018.

If you own such a site, the certificate cannot be repaired or re-trusted: you have to replace it with one from a currently trusted CA. If you are only visiting, there is nothing to fix on your side, and you should not click through the warning. That infrastructure stopped issuing publicly trusted certificates by December 1, 2017, and the longest-lived certificate it could have produced expired in early 2021.

Does the NET::ERR_CERT_SYMANTEC_LEGACY error still exist?

No. The code was removed from Chromium, the open source project Chrome is built on. Chrome keeps its network error codes in a source file called net_error_list.h, where every error the browser can report is assigned a number. NET::ERR_CERT_SYMANTEC_LEGACY was number -215. That entry is now a tombstone comment:

// Error -215 was removed (CERT_SYMANTEC_LEGACY)

The supporting machinery went with it. The file that stored the fingerprints of the legacy Symantec roots, symantec_certs.cc, was deleted, and the certificate status flag that tagged an affected chain is now recorded only as a comment reading “Bit 25 was CERT_STATUS_SYMANTEC_LEGACY”. Nothing in a current browser build can produce this verdict.

That gives the error a precise lifespan. It arrived in Chrome 66, released on April 17, 2018, and it left in Chrome 136, released on April 29, 2025. Chrome 135, from April 1, 2025, was the last version capable of printing it. Because Microsoft Edge, Brave, Opera and Vivaldi are all built on Chromium, the same dates apply to them, give or take their own release schedules.

This matters for anyone searching the error today. If you are reading a guide that presents NET::ERR_CERT_SYMANTEC_LEGACY as a live problem with a list of browser settings to adjust, that guide is describing a browser that no longer exists.

What the error meant

In January 2017, a public investigation found that Symantec’s certificate authority had issued large numbers of certificates that did not meet the CA/Browser Forum Baseline Requirements. The investigation also established that Symantec had allowed several outside organizations to issue certificates without adequate oversight, and had known about problems at those organizations for some time. It was not an isolated incident but the latest in a series, and Google concluded that it could no longer rely on certificates coming out of that infrastructure.

Symantec did not operate under one name. The same certificate authority issued under the Thawte, VeriSign, Equifax, GeoTrust and RapidSSL brands, which is why the distrust reached so many sites that had never bought anything labelled Symantec.

Google announced the removal in September 2017 and carried it out in two stages, described in the Chrome Security team’s plan to distrust Symantec certificates:

• Chrome 66, stable on April 17, 2018, removed trust in Symantec-issued certificates with an issue date earlier than June 1, 2016.
• Chrome 70, stable on October 16, 2018, removed trust in the rest of the old infrastructure, whatever the issue date. Two narrow sets were carved out rather than distrusted: a small number of independently operated subordinate CAs that predated the incident, and the DigiCert-run Managed Partner CAs that issued certificates during the transition. Chromium carried both as explicit exception lists next to the Symantec root list, so “everything chaining to a Symantec root” was never quite the whole story.

Two other dates anchor the transition. Symantec’s old infrastructure stopped issuing publicly trusted certificates on December 1, 2017, after which new certificates came from DigiCert’s separately run infrastructure. And on October 31, 2017, DigiCert completed its acquisition of Symantec’s website security business, which is why the brand names survived while the certificate authority behind them did not.

Chrome was not alone. Mozilla ran its own distrust of Symantec TLS certificates on a parallel schedule: console warnings in Firefox 58 in January 2018, an untrusted-connection error for pre-June 2016 certificates in Firefox 60 in May 2018, and full distrust in Firefox 63 in October 2018. Firefox built this the way Chrome did, as a dedicated check rather than a plain root removal, so it had a message of its own. A distrusted chain returned MOZILLA_PKIX_ERROR_ADDITIONAL_POLICY_CONSTRAINT_FAILED, shown as “An additional policy constraint failed when validating this certificate”.

Apple moved more slowly. Safari and the rest of Apple’s platforms began a partial distrust of the Symantec certificate authorities on August 1, 2018, rejecting certificates issued before June 1, 2016 or after December 1, 2017 while still accepting the middle band provided it had been logged to Certificate Transparency. Full distrust did not arrive until February 25, 2020, well over a year after Chrome and Firefox had finished.

One point is worth stating plainly, because it causes unnecessary worry: GeoTrust, Thawte and RapidSSL certificates sold today are not affected. Those are DigiCert brands now, and their certificates chain to DigiCert’s own roots, which Chrome trusts. Only the pre-December 2017 certificates from the original Symantec certificate authority were distrusted.

What Chrome shows instead today

Chrome removed the special case because it had become redundant. Chrome now ships its own curated root store, and the legacy Symantec roots are simply not in it. We checked the current list: not one of the roots Chrome ships is a VeriSign, Symantec, GeoTrust, Thawte, RapidSSL or Equifax root. The seven DigiCert roots it does include are all from DigiCert’s own modern hierarchy.

With no root to chain to, such a certificate fails the ordinary trust check rather than a Symantec-specific one, and the browser reports NET::ERR_CERT_AUTHORITY_INVALID. A dedicated error code is no longer needed to explain why the chain does not build.

Firefox reached the same position by the same route. Its Symantec-specific check is gone from the source, and the legacy roots are absent from the trust store Firefox ships, so the certificate now fails as an ordinary unknown issuer and reports SEC_ERROR_UNKNOWN_ISSUER rather than the policy-constraint message it used during the distrust.

In practice the certificate is also long expired, so depending on which check the browser reports first you may instead see NET::ERR_CERT_DATE_INVALID. Either way the interstitial is the familiar “Your connection is not private” page, and either way the remedy is the same.

Where the old message can still turn up

Seeing this exact string in 2026 requires two unlikely things at once: a browser engine older than Chrome 136, and a certificate from a certificate authority that stopped issuing in 2017. That combination is rare but not impossible.

• A browser that stopped updating. A kiosk, a digital signage player, a lab machine on a frozen corporate image, or an Android device past its support window may still run Chromium 135 or earlier.
• An application with its own bundled engine. Electron apps, software built on the Chromium Embedded Framework, and Android WebView carry their own Chromium version. An application pinned to an older engine keeps the old error table regardless of which browsers are installed on the machine.
• An internal system with a frozen trust store. Old appliances, management consoles and internal tools sometimes still present certificates from the legacy hierarchy, kept alive on the network by an administrator who re-added the root to the operating system’s trust store.
• Old material rather than a live browser. A screenshot in a support ticket, an internal runbook, or a monitoring alert whose rule was written years ago will repeat the string without any browser producing it.

It is worth being clear about the age of the certificate involved. The last possible issue date from that infrastructure was December 1, 2017. The maximum certificate lifetime at the time was 39 months, dropping to 825 days for anything issued from March 1, 2018. So the longest-lived certificate the legacy Symantec authority could ever have produced expired in early 2021. Anything still presenting one is running a certificate that has been distrusted for nearly eight years and expired for more than five, which usually means the rest of the software on that machine is equally old.

How to fix it if you own the site

There is one fix, and it is not a repair. A distrusted certificate cannot be revalidated, re-signed, or brought back into Chrome’s good graces by any server-side configuration change. You replace it with a certificate from a currently trusted certificate authority.

1. Confirm what your server is actually sending

Before replacing anything, check which certificate authority issued the certificate your server presents. The quickest route without a terminal is our free SSL Checker, which reports the issuer, the expiry date and the chain your server sends.

From a terminal, this one-liner prints the issuer, the subject and the validity dates of the certificate a live site is serving:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -issuer -subject -dates

Read the issuer line first. An organization of Symantec Corporation, VeriSign, GeoTrust, thawte or Equifax on a certificate issued before December 2017 is the legacy hierarchy. An issuer belonging to DigiCert Inc, even one whose name contains GeoTrust or Thawte, is the modern hierarchy and is fine.

The notAfter date settles it on its own. Because that infrastructure stopped issuing in December 2017, any certificate still valid today cannot possibly have come from it. If your certificate has not expired, the legacy Symantec distrust is not your problem and you should look at the actual error your browser reports.

To inspect a certificate file sitting on the server rather than a live connection:

openssl x509 -in certificate.crt -noout -issuer -subject -dates

To see the full chain your server sends, including the intermediates, which is where the old brand names usually show up:

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null

One caution when you read the verification summary at the end of that output. On its own, s_client checks that the chain builds to a trusted root, but it does not check that the certificate matches the hostname, so it can print Verify return code: 0 (ok) for a certificate issued to a completely different site. Add -verify_hostname when you want the answer to include the name check:

openssl s_client -connect example.com:443 -servername example.com -verify_hostname example.com </dev/null

On macOS, the bundled openssl is LibreSSL, which rejects this flag with unknown option -verify_hostname. Install OpenSSL through Homebrew and run that binary instead, then check openssl version again: /usr/bin comes first on the default PATH, so you may still be calling LibreSSL and need the full path /opt/homebrew/bin/openssl.

2. Get and install a replacement certificate

Replacing the certificate follows the normal process. You generate a CSR (Certificate Signing Request) on the server, submit it to a certificate authority, complete validation, then install the issued certificate together with its intermediate chain. Our installation guides cover the specific steps for individual server platforms.

Any SSL certificate from a certificate authority in Chrome’s current root store resolves the error. There is no requirement to stay with the same brand, and no advantage to doing so.

Since you are rebuilding this part of the server anyway, it is worth setting up ACME certificate automation at the same time, which is the practical way to stop another certificate quietly going stale.

3. Check the rest of the server while you are there

A server still presenting a legacy Symantec certificate has not had its TLS configuration touched since 2017 or earlier, so the certificate is rarely the only thing out of date. Once the new certificate is installed, confirm the server offers TLS 1.2 and TLS 1.3, that TLS 1.0 and 1.1 are switched off, that the full intermediate chain is being sent, and that HTTP requests redirect to HTTPS. Running the site through the SSL Checker after installation confirms the chain is complete, which a padlock icon in the browser will not tell you.

If you are looking for an old Symantec, Thawte, GeoTrust or RapidSSL account to renew from, those portals no longer exist. They were consolidated into DigiCert CertCentral after the acquisition, and DigiCert support is the right contact for recovering access to a legacy account.

What to do if you are just visiting the site

Nothing on your device caused this and nothing on your device can fix it. The certificate is served by the website, and the trust decision is made against a list built into your browser. No setting you can reach changes either one.

Do not click through the warning. The advice to proceed anyway is common and wrong here. This is not a cosmetic mismatch: the certificate authority that vouched for the site was removed from browsers because it issued certificates it should not have, so the certificate tells you nothing reliable about who is on the other end. Continuing means sending your traffic to a server whose identity is unverified, over a connection you cannot confirm is private.

What you can reasonably do instead:

• Close the tab and reach the organization another way, by phone or through a different official address, particularly before entering credentials or payment details.
• Tell the site owner. Many operators genuinely do not know, because the site may still load without warnings in an old internal browser.
• If it is an internal system your employer runs, report it to whoever administers it rather than working around it on your own machine.
• If your browser is genuinely years out of date, update it. That will not make the site load, but it will replace the obsolete message with an accurate one and close the other security holes an unpatched browser leaves open.

What does not fix this error

Most troubleshooting articles about this error, including an earlier version of this one, recommend a standard set of browser cleanup steps. None of them can affect the outcome, and the reason is worth understanding, because it applies to every certificate error of this type.

The Symantec verdict was reached by comparing the SHA-256 fingerprints of the public keys in the certificate chain against a fixed list of known Symantec roots compiled into the browser. That comparison takes exactly two inputs: the certificate the server sends, and the list inside the browser. Your clock, your stored files and your installed add-ons are not part of the calculation.

• Correcting the date and time. A wrong clock does cause certificate errors, but a different one. It makes a valid certificate look expired or not yet valid, which produces NET::ERR_CERT_DATE_INVALID. The Symantec check never looked at a date, so no clock setting could trigger or clear it.
• Clearing the cache and cookies. Certificate validation runs during the TLS handshake, on the certificate the server sends at that moment. The verdict is never read from the HTTP cache, so emptying it changes nothing about which root the chain builds to.
• Disabling extensions. Extensions cannot take part in certificate verification. The decision is made in the browser’s network layer before any extension is given the response, and no extension API exists to alter chain building or trust.
• Reinstalling or updating Chrome. Updating changes which message you see, not whether the site works. Before Chrome 66 there was no Symantec check at all, from Chrome 66 to 135 you got this error, and from Chrome 136 onward you get NET::ERR_CERT_AUTHORITY_INVALID instead. In every case the certificate remains untrusted.
• Switching browsers. Firefox and Safari removed the same roots on their own schedules, and Edge, being built on Chromium, follows Chrome. A different browser gives you a different error message for the same certificate, not a different verdict.

These steps are not harmful, and they are reasonable first moves for many other browsing problems. They simply have no mechanism to act on this one.

Frequently Asked Questions

For more SSL error troubleshooting, check our detailed tutorials about fixing different SSL errors.