Invalid SSL Certificate: What It Means and How to Fix It

"Invalid SSL certificate" is one of those error messages that tells you something is wrong but doesn't tell you what. It's a catch-all. Your browser detected a problem with the site's certificate, decided the connection isn't trustworthy, and blocked the page.

The good news: there are only a handful of reasons a certificate gets flagged as invalid. Each one has a specific fix. Let's walk through every cause, how to identify which one you're dealing with, and how to resolve it.

What "Invalid SSL Certificate" Actually Means

When your browser connects to a website over HTTPS, it checks the site's SSL/TLS certificate against a set of rules. If the certificate fails any of these checks, the browser considers it invalid and shows a warning or error page.

The checks are straightforward:

• Is the certificate within its validity period (not expired, not yet valid)?
• Does the certificate cover the domain you're visiting?
• Was the certificate issued by a trusted certificate authority (CA)?
• Is the full certificate chain present and valid?
• Has the certificate been revoked?

Fail any one of these, and the certificate is invalid. Different failures produce different browser error codes, which is how you narrow down the cause.

Cause 1: Expired Certificate

The most common reason for an invalid certificate. Every SSL certificate has a Not Before and Not After date. Once the current date passes the Not After date, the certificate is expired and browsers reject it.

Browser error codes:

• Chrome: NET::ERR_CERT_DATE_INVALID
• Firefox: SEC_ERROR_EXPIRED_CERTIFICATE
• Safari: "This certificate has expired"

Why it happens:

• Auto-renewal failed (DNS validation broke, Certbot cron stopped running, hosting provider had an issue)
• The certificate was manually provisioned and nobody tracked the expiry date
• A certificate was installed as a temporary fix and never replaced

How to fix it:

Check the expiry date:

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

If notAfter is in the past, renew the certificate:

# Let's Encrypt
sudo certbot renew --force-renewal

# Then restart your web server
sudo systemctl restart nginx

For commercial certificates, log into your CA's portal and reissue or renew. Download the new certificate files and install them on your server.

After renewal, verify:

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

The notAfter date should now be in the future. You can check your certificate's expiration date with various tools to confirm.

Cause 2: Wrong Domain (Name Mismatch)

The certificate is valid and not expired, but it was issued for a different domain than the one you're visiting. The browser checks the Subject Alternative Names (SANs) field in the certificate. If your domain isn't listed there, the certificate is invalid for that domain.

Browser error codes:

• Chrome: NET::ERR_CERT_COMMON_NAME_INVALID
• Firefox: SSL_ERROR_BAD_CERT_DOMAIN
• Safari: "Safari can't verify the identity of the website"

Why it happens:

• Certificate issued for example.com but visitor goes to www.example.com (or vice versa)
• A subdomain wasn't included when the certificate was issued
• After a migration, the old certificate is still installed and doesn't cover the new domain
• Wildcard certificate (*.example.com) doesn't cover the bare domain example.com

How to fix it:

Check which domains the certificate covers:

openssl s_client -connect yourdomain.com:443 -servername yourdomain.com </dev/null 2>/dev/null | openssl x509 -noout -ext subjectAltName

Then reissue the certificate with the correct domains included. With Let's Encrypt:

sudo certbot --nginx -d example.com -d www.example.com -d api.example.com

Cause 3: Self-Signed Certificate

A self-signed certificate is one where the issuer and the subject are the same entity. The certificate wasn't issued by a trusted certificate authority -- the server operator created it themselves.

Browsers maintain a list of trusted CAs. Self-signed certificates aren't on that list, so they're treated as invalid for public websites.

Browser error codes:

• Chrome: NET::ERR_CERT_AUTHORITY_INVALID
• Firefox: SEC_ERROR_UNKNOWN_ISSUER or MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT
• Safari: "This certificate was signed by an unknown authority"

Why it happens:

• Development or staging certificate accidentally deployed to production
• Server was set up quickly with a self-signed cert and never updated
• Internal tool exposed to the public internet

How to fix it:

Replace the self-signed certificate with one from a trusted CA. Let's Encrypt is free:

sudo certbot --nginx -d yourdomain.com -d www.yourdomain.com

If the server is behind Cloudflare, you can use a Cloudflare Origin CA certificate instead. See the self-signed certificates guide for more detail on when self-signed certs are appropriate and when they're not.

Cause 4: Untrusted Certificate Authority

Similar to self-signed, but the certificate was issued by a CA that the browser doesn't trust. This is different from self-signed because the issuer is a separate entity -- just not one the browser recognizes.

Browser error codes:

• Chrome: NET::ERR_CERT_AUTHORITY_INVALID
• Firefox: SEC_ERROR_UNKNOWN_ISSUER

Why it happens:

• Certificate issued by a private or internal CA (common in enterprise environments)
• Certificate issued by a CA that has been distrusted by browser vendors (this has happened with some Symantec-affiliated CAs)
• Outdated CA bundle on the server or client

How to fix it:

If this is a private CA in an enterprise environment, distribute the root CA certificate to all client machines via group policy or MDM. For public-facing sites, the only fix is to get a certificate from a publicly trusted CA.

Cause 5: Incomplete Certificate Chain

Your server has a valid leaf certificate from a trusted CA, but it's not sending the intermediate certificate(s). The browser needs the full chain -- from your certificate through the intermediate(s) up to a trusted root -- to validate the certificate.

Some browsers (notably Chrome) cache intermediates and can fill in the gaps. Others (Firefox, curl, API clients, mobile apps) cannot. This creates a frustrating situation where the site works for some people but not others.

Browser error codes:

• Firefox: SEC_ERROR_UNKNOWN_ISSUER
• curl: SSL certificate problem: unable to get local issuer certificate

Why it happens:

• Only the leaf certificate was installed on the server
• The server was configured with the wrong intermediate
• Intermediates are installed in the wrong order

How to fix it:

Check the chain:

openssl s_client -connect yourdomain.com:443 -servername yourdomain.com </dev/null 2>/dev/null

Look at the Verify return code. A value of 21 (unable to verify the first certificate) confirms missing intermediates.

Download the correct intermediate from your CA's documentation and concatenate it with your leaf certificate:

cat yourdomain.crt intermediate.crt > fullchain.crt

Then update your server config to use the full chain file. The certificate chain explainer covers this in depth.

Cause 6: Revoked Certificate

Certificate authorities can revoke certificates before they expire. Browsers check revocation status via CRL (Certificate Revocation List) or OCSP (Online Certificate Status Protocol). If a certificate has been revoked, it's treated as invalid.

Browser error codes:

• Chrome: NET::ERR_CERT_REVOKED
• Firefox: SEC_ERROR_REVOKED_CERTIFICATE

Why it happens:

• The private key was compromised and you (or your CA) revoked the certificate
• The CA revoked the certificate due to a mis-issuance
• Domain validation expired and the CA revoked the certificate

How to fix it:

A revoked certificate cannot be un-revoked. You need to issue a new certificate entirely. If you're using Let's Encrypt:

sudo certbot certonly --nginx -d yourdomain.com -d www.yourdomain.com
sudo systemctl restart nginx

If the revocation was due to a key compromise, generate a new private key as well -- don't reuse the old one.

Browser Error Messages at a Glance

Different browsers show different error codes for the same underlying problem. This table maps them:

Notice that Chrome uses the same error code (ERR_CERT_AUTHORITY_INVALID) for both self-signed certificates and incomplete chains. That's why you need to inspect the certificate with openssl to tell them apart.

Quick Diagnosis Workflow

If you're not sure which cause applies to you, run through this sequence:

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

openssl s_client -connect yourdomain.com:443 -servername yourdomain.com </dev/null 2>/dev/null | openssl x509 -noout -ext subjectAltName

openssl s_client -connect yourdomain.com:443 -servername yourdomain.com </dev/null 2>/dev/null

openssl s_client -connect yourdomain.com:443 -servername yourdomain.com -status </dev/null 2>/dev/null | grep "OCSP Response Status"

You can also use a certificate validation tool to run these checks without touching the command line.

Fixing Invalid Certificates for Visitors (Not Site Owners)

If you're a visitor seeing this error and you don't control the website, your options are limited:

• Check your system clock. If your computer's date is wrong, valid certificates will appear expired. This is rare on modern systems but worth checking.
• Update your browser and OS. Outdated root certificate stores can cause trust failures for newer CAs.
• Don't bypass the warning unless you understand the risk. Clicking "Proceed anyway" means your connection to that site is not authenticated. Fine for a personal dev server. Dangerous for anything involving passwords or payment information.
• Contact the site owner. The problem is on their end.

Preventing Invalid Certificates

Every cause of an invalid certificate is preventable:

• Monitor expiry dates so you never get caught by an expired certificate. Automated alerts 30, 14, and 7 days out give you plenty of time to renew.
• Automate renewal with Certbot, your hosting provider's auto-renewal, or your CDN's managed certificates.
• Test the full chain after every certificate change. Don't just check that the site loads in Chrome -- test with openssl and Firefox too.
• Include all domains when issuing certificates. List every domain and subdomain in the SANs.
• Keep certificates from trusted CAs on any public-facing server. Save self-signed certs for development only.

For a broader overview of SSL/TLS and how certificates work, the SSL/TLS guide covers the fundamentals. If you're dealing with specific error codes, the SSL error troubleshooting guide walks through each one. And to understand what happens when a certificate expires, there's a dedicated guide for that too.

References

• Mozilla - SSL Error Codes
• RFC 8446 - The Transport Layer Security (TLS) Protocol Version 1.3
• Chromium - Certificate Errors

An invalid certificate is always fixable. The hard part is knowing which of the six causes you're dealing with.