‘Invalid SSL certificate’ is not an error code. It is how people describe the experience of seeing a browser security warning on an HTTPS site. The actual error code behind that warning — which your browser shows in smaller text or in the Advanced section — identifies the specific reason the certificate failed validation. That code is the most important information on the page, and it changes everything about which fix to apply.
This guide is structured as a triage tool. The first step is reading the error code you actually have. From there, each condition has its own section with the specific cause and the targeted fix, split by whether you are a visitor trying to reach someone else’s site or a site owner who has received reports about your own certificate.
Applying fixes in a random order wastes time. A site owner whose intermediate certificate is missing does not need to clear their browser cache. A visitor whose device clock is wrong does not need to contact the server administrator. The error code routes you to the right section.
Step Zero: Read the Error Code in Your Browser
Every major browser shows a specific error code alongside the general security warning. Finding it takes seconds and determines everything that follows.
In Chrome
Below the Your connection is not private heading, Chrome shows a code in gray text such as NET::ERR_CERT_DATE_INVALID or NET::ERR_CERT_AUTHORITY_INVALID. If you do not see it immediately, click the Details triangle or the Advanced button.
In Firefox
Firefox shows Warning: Potential Security Risk Ahead. Click Advanced and the specific error code appears, such as SEC_ERROR_EXPIRED_CERTIFICATE or MOZILLA_PKIX_ERROR_SELF_SIGNED_CERTIFICATE.
In Safari
Safari shows This Connection Is Not Private. Click Show Details for the certificate information including the specific issue (expired, untrusted issuer, domain mismatch).
If there is no specific error code
Look in the certificate itself. Click the padlock (or Not Secure / the shield icon), then View Certificate or Certificate is not valid. The certificate details reveal the specific problem: check the Not After date (expiry), the Subject Alternative Names (domain coverage), and the Issuer (who signed it and whether they are trusted).
| Error Code (Chrome) | Error Code (Firefox) | Plain Description | Who Usually Fixes It |
| NET::ERR_CERT_DATE_INVALID | SEC_ERROR_EXPIRED_CERTIFICATE | Certificate expired or device clock is wrong | Server owner (renew cert) or visitor (fix clock) |
| NET::ERR_CERT_AUTHORITY_INVALID | SEC_ERROR_UNKNOWN_ISSUER | Certificate not signed by a trusted CA, or chain incomplete | Server owner (fix chain or replace cert) |
| NET::ERR_CERT_COMMON_NAME_INVALID | SSL_ERROR_BAD_CERT_DOMAIN | Hostname does not match certificate’s covered domains | Server owner (reissue cert with correct domain) |
| NET::ERR_CERT_REVOKED | SEC_ERROR_REVOKED_CERTIFICATE | Certificate was deliberately revoked by the issuing CA | Server owner (replace with new certificate immediately) |
| NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED | N/A (Firefox handles differently) | Certificate not logged in public CT logs | Server owner (reissue from a CA that submits CT logs) |
| ERR_SSL_VERSION_OR_CIPHER_MISMATCH | SSL_ERROR_NO_CYPHER_OVERLAP | Server TLS configuration incompatible with browser | Server owner (update TLS configuration) |
| MOZILLA_PKIX_ERROR_MITM_DETECTED | MOZILLA_PKIX_ERROR_MITM_DETECTED | Firefox detected a MITM interceptor (often antivirus or corporate proxy) | Visitor (check antivirus HTTPS scanning) or IT team |
Condition 1: Certificate Expired or Device Clock Is Wrong
NET::ERR_CERT_DATE_INVALID in Chrome and SEC_ERROR_EXPIRED_CERTIFICATE in Firefox both mean the certificate’s validity period does not include the current date. This has two completely distinct causes: the certificate itself has passed its Not After date, or your device clock is set to a date outside the certificate’s valid range.
Distinguishing the two causes in 30 seconds
Open the browser error page and find the expiry date it shows for the certificate (in Chrome: Advanced > Certificate information; in Firefox: Advanced > error details). Note the date the certificate expired. Now check your own device clock’s current date. If your clock is set correctly to today’s actual date and the certificate’s expiry is in the past, the server’s certificate has genuinely expired. If the certificate’s expiry is still in the future but your clock shows a date before the certificate’s Not Before date, or far in the future past its Not After date, your clock is wrong.
If your clock is wrong (visitor fix)
On Windows: right-click the clock in the taskbar, select Adjust date and time, and ensure Set time automatically is on. On Mac: open System Settings, General, Date and Time, and enable Set time and date automatically. On Linux: run timedatectl set-ntp true or sudo ntpdate -u pool.ntp.org. After correcting the clock, reload the page.
If the server’s certificate is genuinely expired (server owner fix)
The certificate must be renewed immediately. There is no client-side fix for a genuinely expired server certificate. For Let’s Encrypt certificates, run certbot renew –force-renewal followed by systemctl reload nginx or systemctl reload apache2. For commercial certificates, log into your CA’s portal, initiate renewal, complete validation, download the new certificate files, and install them. After any renewal, verify externally using openssl s_client -connect yourdomain.com:443 2>/dev/null | openssl x509 -noout -dates to confirm the new certificate is being served.
Condition 2: Untrusted Certificate Authority or Incomplete Chain
NET::ERR_CERT_AUTHORITY_INVALID and SEC_ERROR_UNKNOWN_ISSUER both mean the browser cannot trace the certificate’s chain of trust to a root CA in its trust store. Three distinct situations produce this error.
Situation A: Missing intermediate certificate (most common)
Most SSL certificates are not signed directly by a root CA. They are signed by an intermediate CA, which itself chains to the root. Your server must send both the site certificate and the intermediate certificate. If the intermediate is missing from the server’s bundle, browsers cannot build the chain and report the authority invalid error.
Test: run openssl s_client -connect yourdomain.com:443 -showcerts and count the certificates in the output. A properly configured server sends at least two certificates. If only one appears, the intermediate is missing. Download the intermediate certificate from your CA’s website and add it to your certificate bundle. In Nginx, the ssl_certificate file should contain the site certificate followed by the intermediate, concatenated in order. In Apache 2.4.8+, SSLCertificateFile should reference the full chain file.
Situation B: Self-signed certificate
A self-signed certificate was signed by the entity itself rather than by any CA. Browsers reject self-signed certificates on public-facing sites because there is no independent party who verified the certificate holder’s identity. For production public sites, replace the self-signed certificate with one from a publicly trusted CA. Let’s Encrypt is free and takes minutes. For development environments, use mkcert to create a local CA, install it in the browser trust store, and issue a properly trusted development certificate.
Situation C: Outdated device trust store (visitor-side)
If the certificate uses a newer root CA added after the device’s last OS update, the device may not have that root in its trust store. The fix is running all available OS updates to refresh the root certificate store. This situation is uncommon on regularly updated devices.
If this error appears on a major, well-known site (a bank, a large retailer, a major social platform) and only for you while others can reach the site fine, the cause is almost certainly on your device or network: an outdated trust store, antivirus HTTPS scanning presenting its own certificate, or a corporate network proxy. Major sites do not have persistently broken certificate chains for some visitors.
Condition 3: Certificate Does Not Cover This Hostname
NET::ERR_CERT_COMMON_NAME_INVALID and SSL_ERROR_BAD_CERT_DOMAIN mean the hostname in the browser’s address bar does not appear in the certificate’s Subject Alternative Names (SAN) list.
Common scenarios
The www and non-www versions of a domain are treated as separate hostnames. A certificate covering yourdomain.com does not automatically cover www.yourdomain.com. The fix is reissuing the certificate with both variants listed as SANs, or using a wildcard (*.yourdomain.com which covers www and all other single-level subdomains).
A subdomain that was not listed when the certificate was issued. If shop.yourdomain.com was added after the certificate was issued for yourdomain.com and www.yourdomain.com, visiting shop will trigger this error. Add shop as a SAN when reissuing, or use a wildcard.
A CDN serving the wrong certificate. If the CDN does not have a certificate configured for your specific hostname and falls back to a default certificate for another domain, the browser sees a hostname mismatch. Configure the CDN with a certificate that covers your hostname.
Verifying the certificate coverage
| # See exactly which hostnames the certificate covers:
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com 2>/dev/null | openssl x509 -noout -text | grep -A5 ‘Subject Alternative Name’
# If your hostname does not appear in the output, # the certificate must be reissued with it included. |
Condition 4: Certificate Has Been Revoked
NET::ERR_CERT_REVOKED and SEC_ERROR_REVOKED_CERTIFICATE mean the certificate was deliberately invalidated by the issuing CA before its natural expiry. This happens when a private key is compromised, when a certificate was mis-issued, or when the owner requests revocation.
If this error appears on your own site and you did not request revocation, treat it as a security incident. Your private key may have been compromised. Generate a completely new private key immediately, obtain a new certificate, redeploy, and investigate how the old key may have been exposed. Do not reuse the compromised private key. If this appears as a visitor on a site you normally trust, do not proceed and do not submit any credentials or personal data.
There is no technical bypass for a revoked certificate. The only resolution is replacing it with a new one. Contact your CA, request a new certificate with a new private key, and deploy it.
Condition 5: Antivirus or Corporate Proxy Intercepting HTTPS
MOZILLA_PKIX_ERROR_MITM_DETECTED in Firefox specifically flags situations where Firefox believes a MITM proxy is intercepting the connection. This usually means antivirus HTTPS scanning software or a corporate network inspection appliance is presenting its own certificate rather than the destination server’s. Chrome may show this as ERR_CERT_AUTHORITY_INVALID.
The indicator: open the certificate details in the browser and look at the Issuer field. If the Issuer shows your antivirus product name (Kaspersky Anti-Virus Personal Root, AVAST Web/Mail Shield Root, Bitdefender Personal CA) or your company’s internal CA name, the connection is being intercepted.
Antivirus HTTPS scanning fix
Disable HTTPS scanning in the antivirus settings. In Avast and AVG: Settings, Protection, Core Shields, Web Shield, disable Enable HTTPS scanning. In Kaspersky: Settings, Additional, Network, Encrypted connections scanning, select Do not scan encrypted connections. In ESET: Setup, Internet Protection, disable HTTPS filtering. In Bitdefender: Protection, Online Threat Prevention, turn off Encrypted Web Scan. After disabling, reload the page. If the error clears, add the affected site to the antivirus URL exclusions list rather than leaving scanning fully disabled.
Corporate proxy fix
If the Issuer shows a corporate or network vendor name and you are on a work network or VPN, the corporate network’s SSL inspection appliance is intercepting the connection. The fix is an IT department issue, not a personal one. Contact your IT support and report the specific error code and the site. The network appliance may have an expired intermediate certificate or a misconfiguration. As a temporary test, disconnect from the corporate VPN and try on a different network to confirm the network is the source.
Condition 6: TLS Version or Cipher Suite Incompatibility
ERR_SSL_VERSION_OR_CIPHER_MISMATCH and SSL_ERROR_NO_CYPHER_OVERLAP mean the server’s TLS configuration has no overlap with what the browser accepts. Chrome removed TLS 1.0 and TLS 1.1 support in version 84 (2020). A server that only supports these deprecated versions is now unreachable from any modern browser.
The fix is on the server side: enable TLS 1.2 and TLS 1.3. In Nginx, set ssl_protocols TLSv1.2 TLSv1.3. In Apache, set SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1. Run the SSL Labs test (ssllabs.com/ssltest) to identify exactly which TLS versions and cipher suites your server currently offers and to confirm the fix after making changes. As a visitor, there is nothing you can do: the fix must be on the server.
Site Owner: Certificate Configuration Checklist
When you receive a report that visitors are seeing an SSL error on your site, verify these in order. The SSL Labs test at ssllabs.com/ssltest runs all of them automatically and returns a grade.
| Check | How to Verify | Fix if Failing |
| Certificate not expired | Check Not After date in browser cert viewer or via openssl s_client | Renew certificate immediately; enable automated renewal |
| Certificate chain complete | openssl s_client shows 2-3 certificates, not 1 | Concatenate intermediate cert to domain cert bundle; reload web server |
| Certificate covers the visited hostname | Check SAN list in cert viewer — every hostname must be listed | Reissue cert with correct SANs including www and non-www |
| Certificate from trusted CA | Issuer shows a recognized public CA, not self-signed | Replace self-signed with publicly trusted CA cert; Let’s Encrypt for DV |
| TLS 1.2 or 1.3 active | SSL Labs shows Protocol Support 100% for TLS 1.2 and 1.3 | Update ssl_protocols in Nginx or SSLProtocol in Apache |
| AEAD cipher suites only | SSL Labs shows no weak cipher warnings | Update ssl_ciphers to remove RC4, 3DES, and CBC mode suites |
| New certificate actually being served | openssl s_client returns new Not After date from live endpoint | Reload web server; purge CDN cache; check server config points to new file |
Visitor: When the Problem Is on Your Device
If you see an SSL error on a site that other people (on different devices or networks) can reach without a warning, the cause is on your device or your network. Run through these checks in order.
- Check your device clock. An incorrect date is the single most common client-side cause of SSL errors. Right-click the taskbar clock (Windows) or open System Settings, Date and Time (Mac) and enable automatic time synchronization.
- Check whether the error is on multiple sites or just one. If multiple HTTPS sites are showing errors simultaneously, the problem is almost certainly your clock or a network interception issue, not each individual site’s certificate.
- Try incognito mode. Incognito disables extensions. If the error disappears in incognito, a browser extension is causing it. Re-enable extensions one at a time to identify the offending one.
- Try a different browser. If the error appears in Chrome but not Firefox, the issue is in Chrome’s configuration or its cached data.
- Check the certificate issuer. If the Issuer field shows your antivirus product or a corporate CA name, HTTPS inspection is intercepting the connection. See Condition 5 above.
- Try a different network. If the error disappears when you switch from your work network or VPN to a home network or mobile data, the corporate network’s SSL inspection appliance is the source.
- Clear the browser cache and SSL state. Press Ctrl+Shift+Delete in Chrome, select All time, check Cached images and files and Cookies, click Clear Data. On Windows, also clear the SSL state in Internet Properties (Win+R, inetcpl.cpl, Content tab, Clear SSL state).
- Update the browser. An outdated browser may not recognize newer CA root certificates. Check for browser updates via the Help menu.
After working through these steps, if you still see the error and confirm others can reach the site, the remaining option is to report the specific error code to the site owner. Include the exact error code from the Advanced section of the browser warning, the URL you were trying to reach, and the result of checking from a different device or network. This gives the site owner the information needed to investigate.
Frequently Asked Questions
What does ‘invalid SSL certificate’ mean?
It means the browser’s certificate validation process found a problem with the SSL certificate presented by the server. The term covers several distinct conditions: the certificate has expired, the certificate was not issued by a trusted Certificate Authority, the certificate does not cover the hostname you are visiting, the certificate has been revoked, the certificate chain is incomplete, or the server’s TLS configuration is incompatible with the browser. The specific error code shown in the browser (NET::ERR_CERT_DATE_INVALID, NET::ERR_CERT_AUTHORITY_INVALID, etc.) identifies which of these conditions applies and determines the correct fix.
Is it safe to bypass an invalid SSL certificate warning?
It depends entirely on which condition caused the warning and which site you are visiting. For NET::ERR_CERT_REVOKED, never bypass: a revoked certificate indicates the CA determined it should not be trusted, often due to a key compromise. For an expired certificate on a site you personally manage, bypassing temporarily while you renew is acceptable. For any site where you are entering credentials, payment information, or personal data, do not bypass a certificate warning. An invalid certificate means the browser cannot verify the server’s identity, and you cannot be certain you are communicating with the intended party rather than an impersonator.
My site has a valid SSL certificate but visitors are still seeing warnings. Why?
Several scenarios produce this. The certificate file was renewed but the web server was not reloaded, so the old expired certificate is still being served from memory. The certificate bundle does not include the intermediate certificate, causing chain validation failure even though the certificate itself is valid. A CDN in front of your server is serving a different certificate than the one on your origin server. The certificate covers yourdomain.com but not www.yourdomain.com, and visitors are reaching the www version. Verify using openssl s_client -connect yourdomain.com:443 -showcerts from an external perspective to see exactly what certificate and chain the server is presenting to real clients.
How do I fix an SSL error on a website I do not own?
In most cases, you cannot fix it from your side. The exception is if the error is caused by something on your device: an incorrect system clock, antivirus HTTPS scanning, or an outdated browser trust store. For these, the fixes are on your device and the site owner does not need to take any action. If the error persists after verifying your clock is correct, antivirus is not intercepting, and your browser is current, the error is on the server side. The only action available to you is reporting the specific error code to the site owner. Most sites have a contact form or support email where you can report the issue.
Why do I see the error on one site but not others?
A site-specific SSL error almost always means the error is in that site’s server configuration rather than on your device. Common site-specific causes: the certificate expired only for that domain, the certificate does not cover the specific subdomain you are visiting, the intermediate certificate is missing from that server’s configuration, or that particular server is still running an old TLS configuration. If you can confirm the error appears on a different device and a different network, the server is the issue and the site owner needs to act.
Can antivirus software cause SSL certificate errors?
Yes, and it is a common cause of confusing SSL errors. Products including Kaspersky, Avast, AVG, ESET, and Bitdefender include HTTPS scanning features that intercept TLS connections by presenting their own certificate to the browser. If the antivirus certificate has expired, is misconfigured, or handles specific TLS features incorrectly, the browser shows an SSL error that appears to be from the destination site but is actually from the antivirus interception. The sign is that the Issuer field in the certificate viewer shows the antivirus product name rather than a public CA like DigiCert, Let’s Encrypt, or Sectigo.
