How to Fix NET::ERR_CERT_SYMANTEC_LEGACY in Google Chrome

NET::ERR_CERT_SYMANTEC_LEGACY is one of Chrome’s most specific error codes because it has exactly one cause: the certificate presented by the server was issued by Symantec’s legacy certificate infrastructure, which Google permanently distrusted in 2018. This is a CA-level distrust decision baked into Chrome, not a configuration problem and not something that clearing cache, adjusting the clock, or disabling extensions can fix.

If you are a visitor seeing this error, the site has not replaced its certificate in over eight years. If you are a site owner seeing it on your own site, the fix is replacing the certificate from a currently trusted CA. This article explains why the error exists, which certificates trigger it, and the specific steps to resolve it for site owners.

Why Chrome Distrusts Symantec Certificates: The Background

Symantec was once the largest SSL certificate authority in the world, operating under brand names including VeriSign, GeoTrust, Thawte, RapidSSL, and Equifax Secure. In 2015 and 2016, security researchers discovered that Symantec had improperly issued test certificates for domains including google.com and other major sites without authorization from the domain owners. Further investigation revealed systematic failures in Symantec’s certificate issuance validation processes, with thousands of certificates issued without proper domain control verification.

Google’s trust in certificate authorities is conditional on those CAs following established validation procedures. Issuing certificates for domains without verified authorization is a fundamental violation of the CA/B Forum Baseline Requirements and of Google’s own CA policies. After an extended investigation and escalating disagreements with Symantec about the scope of the problems, Google announced in September 2017 that Chrome would progressively distrust all certificates issued by Symantec’s legacy PKI infrastructure.

The distrust happened in two phases. Chrome 66, released in April 2018, stopped trusting all Symantec certificates issued before June 1, 2016. Chrome 70, released in October 2018, completed the distrust by rejecting all remaining Symantec certificates regardless of issuance date. Any site still running a certificate from Symantec’s legacy infrastructure produces the ERR_CERT_SYMANTEC_LEGACY error on all Chrome versions released from late 2018 onward.

Symantec sold its CA business to DigiCert in late 2017 as part of the resolution process. DigiCert operates the infrastructure and issues new certificates under its own trusted root. Certificates issued by DigiCert after the acquisition are fully trusted and produce no errors. Only the legacy Symantec-era certificates from before the DigiCert transition are affected by this distrust.

Which Certificates Trigger This Error

The error fires for certificates issued by the following Symantec-operated CAs and their sub-brands that were part of the legacy PKI infrastructure at the time of distrust:

The test to determine whether a specific certificate is affected: click the padlock (or Not Secure) in Chrome’s address bar, view the certificate details, and check the Issuer chain. If the chain includes any of the Symantec-operated CAs above and the certificate was not reissued through DigiCert’s new infrastructure after the transition, it will produce this error.

What Cannot Fix This Error (And Why Other Guides Are Wrong)

Several published guides recommend fixing ERR_CERT_SYMANTEC_LEGACY by clearing the browser cache, adjusting the system clock, disabling antivirus, or removing Chrome extensions. None of these address the actual cause and none of them work.

The Symantec distrust is part of Chrome’s built-in trust policy, compiled into the browser binary. It is not stored in the browser cache and is not affected by cached data. It is not related to the system clock. Antivirus HTTPS scanning produces different error types when it interferes with certificate validation. Extensions do not affect the CA-level distrust logic. These generic SSL troubleshooting steps are relevant for other types of certificate errors but not for CA distrust decisions.

The only two paths to resolving this error are: the site owner replaces the certificate with one from a currently trusted CA, or the visitor uses a different browser that may have a different trust policy (though Firefox also distrusts these certificates, producing MOZILLA_PKIX_ERROR_ADDITIONAL_POLICY_CONSTRAINT_FAILED for the same cause).

Do not disable Chrome’s certificate verification to bypass this error. Doing so removes all certificate trust checking for every HTTPS connection, not just the one you are troubleshooting. The site triggering this error may be genuinely insecure due to using a certificate from an untrusted infrastructure. Proceed only if you have independent confirmation the site is legitimate and accept that the connection’s authenticity cannot be verified.

If You Are a Visitor Seeing This Error

The site you are trying to reach has not updated its SSL certificate in at least eight years. This is a strong indicator that the site is abandoned or very poorly maintained. Consider whether you need to access it at all.

If you know the site is legitimate and you need to access it despite the error, you can use the Advanced button on Chrome’s error page and click Proceed to the site (unsafe). This is appropriate only for internal tools, legacy enterprise applications, or sites where you have independent confirmation the operator is legitimate and simply has not replaced the certificate. Never enter credentials or payment information on a site with a Symantec legacy certificate error.

If the site is one you regularly need to access, contact the site owner or the webmaster. Tell them the specific error code ERR_CERT_SYMANTEC_LEGACY and that replacing the SSL certificate with one from a currently trusted CA (Let’s Encrypt, DigiCert, Sectigo, or any other current CA) resolves the issue immediately.

If the site belongs to your own organization and your IT team or hosting provider set it up years ago, it is very likely they are unaware the certificate is still from Symantec’s legacy infrastructure. Forwarding the error details to IT or the hosting provider is usually enough to prompt an immediate certificate replacement.

If You Are the Site Owner: Replacing the Symantec Certificate

The fix is straightforward: obtain a new SSL certificate from any currently trusted CA and install it on your server. The Symantec certificate itself cannot be renewed or updated to fix this issue. A fresh certificate from a trusted issuer is required.

Step 1: Confirm the certificate is the problem

View the certificate details in Chrome by clicking the padlock or Not Secure indicator and selecting Certificate is not valid. Confirm the Issued By chain shows Symantec, GeoTrust, Thawte, VeriSign, or RapidSSL as an issuer. Run your domain through the SSL Labs test at ssllabs.com/ssltest to get a full certificate chain analysis, which will confirm the Symantec legacy CA in the chain.

Step 2: Choose a replacement certificate

Any currently trusted CA works. The options depend on your validation level needs:

• Let’s Encrypt: Free DV certificates with 90-day validity and automated renewal. Available on virtually all Linux hosting environments through Certbot. Takes minutes to issue. No cost.
• DigiCert: DV, OV, and EV certificates from the current DigiCert infrastructure, which is fully trusted. These are different from the legacy Symantec certificates. Contacting DigiCert and requesting a new certificate (not a renewal of the old Symantec-era one) issues a new trusted certificate.
• Sectigo, GlobalSign, Entrust, or any other current CA: All provide DV, OV, and EV options. Any of these work as replacements.

Step 3: Generate a new private key and CSR

Since the old certificate is untrusted and from a compromised CA infrastructure, generate a completely new private key when requesting the replacement. Use a 2048-bit RSA key or a P-256 ECC key. Submit the new CSR to your chosen CA, complete domain validation, and download the issued certificate.

Step 4: Install and verify

Install the new certificate on your server. Ensure the certificate bundle includes the intermediate certificate from the new CA. Reload the web server after installation. Verify using the SSL Labs test that the new certificate chain shows a trusted issuer and receives a passing grade. The ERR_CERT_SYMANTEC_LEGACY error disappears immediately for all visitors once the new certificate is deployed.

Enterprise and Internal Systems: The Lingering Symantec Problem

The most common context where ERR_CERT_SYMANTEC_LEGACY still appears in 2026 is enterprise internal systems: intranet portals, internal web applications, management interfaces, monitoring dashboards, and legacy software systems that were set up before 2018 and never received certificate updates.

In enterprise environments, these systems often have no clear owner, were set up by staff who have since left, or are considered too low-risk to prioritize for maintenance. The certificate error appears when someone opens Chrome on a managed device and tries to access one of these internal tools. Because the system is internal, the erroneous assumption is sometimes made that the certificate does not matter. The consequence is that internal users are either bypassing certificate errors habitually or unable to access internal systems at all from current Chrome versions.

The correct resolution for enterprise environments is the same as for public sites: replace the certificate from a trusted CA. For internal-only systems not accessible from the public internet, a private CA certificate (using an internal CA whose root is distributed to managed devices via group policy) is acceptable. A free certificate from Let’s Encrypt or any public CA is the simplest option if the internal system is reachable via a public domain name. Certificate management for these legacy internal systems is a straightforward operation that is often delayed for organizational reasons rather than technical ones.

Frequently Asked Questions

What is the NET::ERR_CERT_SYMANTEC_LEGACY error?

It means Chrome is blocking a website because the site’s SSL certificate was issued by Symantec’s legacy certificate authority infrastructure, which Google permanently distrusted in 2018 following documented failures in Symantec’s certificate issuance processes. The error applies to certificates from Symantec and its sub-brands including VeriSign, GeoTrust, Thawte, and RapidSSL that were issued before Symantec’s CA business was sold to DigiCert. Chrome version 70 and later block all these certificates. The only fix is replacing the certificate with one from a currently trusted CA.

Why did Google distrust Symantec certificates?

Google’s certificate team discovered in 2015 and 2016 that Symantec had issued certificates for major domains including google.com without authorization from those domain owners, in violation of the CA/B Forum Baseline Requirements that all CAs must follow. Further investigation found that these were not isolated incidents but reflected systemic failures in Symantec’s certificate validation processes. After extended engagement with Symantec that did not resolve the underlying problems, Google announced a phased distrust that completed with Chrome 70 in October 2018.

Does DigiCert have the same problem?

No. DigiCert acquired Symantec’s CA business in 2017 and operates it under new PKI infrastructure with DigiCert’s own trusted roots. Certificates issued by DigiCert under its current infrastructure are fully trusted. The distrust applies specifically to the legacy Symantec PKI that existed before and during the problematic period. A new certificate obtained from DigiCert today is completely unaffected by the Symantec distrust.

Can I fix this error without replacing the certificate?

No, and you should not try to. This is a permanent CA-level distrust decision in Chrome, not a configuration error. There is no browser setting, cached value, or local file that controls this behavior. Disabling Chrome’s certificate verification globally to bypass it removes all HTTPS security for every connection, which is not an acceptable trade-off. The correct action is replacing the certificate. Let’s Encrypt provides free certificates in minutes. There is no technical or cost barrier to replacing a Symantec legacy certificate.

I have a DigiCert account from when it was Symantec. Does my renewal go through the old infrastructure?

This depends on when your account was migrated and which products you are using. DigiCert migrated legacy Symantec customer accounts to its CertCentral platform. If you log into your old Symantec portal and it redirects to DigiCert CertCentral, new certificate issuances from that account go through DigiCert’s trusted infrastructure. If you receive a certificate whose chain shows Symantec rather than DigiCert as the issuer, contact DigiCert support directly to confirm you are being issued from the current infrastructure rather than legacy systems.

Is this error still common in 2026?

It is rare for public-facing websites. The distrust has been in effect since 2018, and any site that was maintained during that period would have replaced its certificate long ago. The error still appears occasionally for abandoned or unmaintained public sites and more regularly for enterprise internal systems, legacy applications, and embedded device management interfaces that were deployed before 2018 and have not received certificate updates. The error is always fixable by replacing the certificate; the operational question is finding who is responsible for the system and getting the replacement prioritized.