How to Fix SSL Certificate Errors: A Troubleshooting Guide

SSL certificate errors are the internet's way of saying "I can't verify this connection is secure." But the error usually is not about encryption being broken. It is about identity. The certificate does not match the hostname. The chain is incomplete. The cert expired. The issuer is not in the trust store. Each of these failures triggers a different error code in the browser, and each has a specific cause and a specific fix.

The frustrating part is that browsers are deliberately vague in their user-facing warnings. "Your connection is not private" tells you almost nothing about what went wrong. The real information is buried in the error code at the bottom of the warning page, or in the certificate details accessible through browser dev tools. Once you know which error you are dealing with, the path to resolution is usually straightforward.

This guide walks through the five most common SSL certificate errors, explains exactly what triggers each one, provides a systematic diagnostic workflow using `openssl` and browser tools, and gives you the specific commands and configuration changes to fix each problem. If you want to check your certificate status right now, DomScan's SSL Certificate Checker shows chain details, expiry dates, and SAN entries in a single view.

The Most Common SSL Errors and What They Mean

Browsers display SSL errors using internal error codes that map directly to specific TLS validation failures. Understanding these codes is the fastest way to identify the root cause. Here are the five you will encounter most often, what each one actually means, and the scenarios that trigger them.

ERR_CERT_COMMON_NAME_INVALID

This error fires when the hostname in the browser's address bar does not match any name listed in the certificate. Despite the legacy name referencing Common Name (CN), modern browsers validate against Subject Alternative Name (SAN) entries exclusively. The CN field is ignored by Chrome and Firefox as of 2017.

The three most common triggers:

• Wrong certificate installed. A cert for `example.com` is serving traffic for `app.example.com`. The SAN list does not include the subdomain.
• www vs non-www mismatch. The cert covers `www.example.com` but not the bare domain `example.com`, or vice versa.
• Wildcard scope misunderstanding. A wildcard cert for `*.example.com` covers `app.example.com` but not `example.com` itself, and not multi-level subdomains like `api.v2.example.com`.

To confirm, inspect the certificate's SAN entries and compare them against the hostname that triggered the error. If you are managing multiple subdomains, a wildcard certificate or a multi-domain (SAN) certificate may be the correct solution, depending on your architecture.

ERR_CERT_DATE_INVALID

The certificate has either expired or is not yet valid. Every certificate has a `Not Before` and `Not After` timestamp. If the current time falls outside that window, the browser rejects the certificate. This is the single most common SSL error on the internet, and it is almost always preventable.

Common causes:

• Renewal failed silently. Certbot cron job stopped running, DNS challenge could not resolve, or HTTP-01 challenge was blocked by a firewall or WAF.
• Let's Encrypt 90-day cycle missed. Unlike traditional CAs that issue 1-year certs, Let's Encrypt certs expire every 90 days. One missed renewal is only weeks away from user-facing errors.
• Client clock is wrong. The server cert is fine, but the user's device clock is set to the past or future. Common on mobile devices with dead CMOS batteries or misconfigured NTP.
• New cert deployed early. A certificate with a `Not Before` date in the future was installed prematurely. Rare, but it happens with pre-issued certs from enterprise CAs.

If only a single user reports this error and the cert looks valid to everyone else, the client clock is almost certainly wrong. If multiple users report it, check the certificate dates immediately.

ERR_CERT_AUTHORITY_INVALID

The browser does not trust the entity that signed the certificate. TLS trust works through a chain: the server's certificate is signed by an intermediate CA, which is signed by a root CA that is embedded in the browser's or operating system's trust store. If any link in that chain is missing or unrecognized, the browser cannot verify the certificate and throws this error.

This error has three distinct causes that require different fixes:

• Missing intermediate certificate. The server sends only the leaf cert, not the intermediate(s). The browser cannot build the chain to a trusted root. This is the most common cause by far.
• Self-signed certificate. The cert was generated locally and is not signed by any recognized CA. Browsers will always reject these unless the user manually adds an exception.
• Corporate or private CA. An internal CA issued the cert. It is trusted on managed corporate devices where the CA root is installed, but not on personal devices or external visitors.

ERR_SSL_PROTOCOL_ERROR

The TLS handshake itself failed before certificate validation even began. This error means the client and server could not agree on a protocol version or cipher suite, or something interfered with the handshake at the protocol level.

Typical causes:

• Deprecated TLS version. The server only supports TLS 1.0 or 1.1, which modern browsers have disabled. Chrome, Firefox, Safari, and Edge all dropped TLS 1.0/1.1 support in 2020.
• Cipher suite mismatch. The server's allowed cipher list has no overlap with what the client supports. Often caused by overly restrictive server configs or very old servers using RC4, DES, or export-grade ciphers.
• HTTP on HTTPS port. The server is responding with plaintext HTTP on port 443. The client sends a TLS ClientHello, the server responds with an HTTP error page, and the handshake fails.
• Middlebox interference. A firewall, proxy, or load balancer is mangling the TLS handshake. Common in corporate networks with SSL inspection appliances that are misconfigured.

NET_ERR_CERT_REVOKED

The certificate was explicitly revoked by the CA that issued it. Revocation is the CA's mechanism for declaring a certificate untrustworthy before its natural expiration date. When a browser checks the certificate's revocation status via OCSP or CRL and gets a "revoked" response, it refuses the connection.

Revocation happens for specific reasons:

• Private key compromise. The cert's private key was exposed through a server breach, accidental commit to a public repo, or backup leak.
• Domain ownership changed. The domain was transferred to a new owner, and the previous cert was revoked to prevent the old owner from impersonating the new one.
• CA misissuance. The CA issued the cert in violation of its own policies or the CA/Browser Forum baseline requirements, and was required to revoke it.
• Subscriber request. The certificate holder requested revocation because they no longer need the cert, replaced it, or suspect compromise.

Unlike expiry errors, a revoked certificate cannot be "renewed." You must request a completely new certificate from the CA, which will have a new serial number and a new key pair if the revocation was due to key compromise.

Diagnosing Certificate Errors Step by Step

When you encounter an SSL error, resist the urge to immediately regenerate certificates or change server configs. Diagnosis first, action second. A systematic approach saves time because most certificate errors have a single root cause that a few targeted checks will reveal.

1. Read the error code. The browser warning page shows the specific error code at the bottom. On Chrome, click "Advanced" to reveal it. This code narrows the cause to one of the five categories above.
2. Inspect the certificate in the browser. Click the lock icon (or the "Not Secure" label) in the address bar, then navigate to certificate details. Check the subject, SAN entries, issuer, and validity dates.
3. Verify hostname matches SAN entries. Compare the exact hostname in the address bar against every SAN entry in the certificate. Watch for www/non-www mismatches and subdomain omissions.
4. Check certificate dates. Confirm the current date falls within the Not Before and Not After range. If the cert expired recently, check when automated renewal last ran successfully.
5. Test the chain with openssl s_client. Run the command from a clean environment outside your browser to see the raw chain, protocol version, and any verification errors the server returns.
6. Check OCSP and CRL status. If the error suggests revocation, query the OCSP responder URL listed in the cert's Authority Information Access extension to confirm the revocation status.

The `openssl s_client` command is the workhorse of SSL troubleshooting. It shows you exactly what the server presents during the TLS handshake, without any browser-side caching or UI abstraction.

Using openssl s_client for Diagnosis

The following command connects to a server on port 443 and displays the full certificate chain, negotiated protocol, and cipher suite:

openssl s_client -connect example.com:443 -servername example.com

The `-servername` flag is critical. It sets the SNI (Server Name Indication) extension in the TLS ClientHello, which tells the server which certificate to present. Without it, servers hosting multiple domains may return the wrong certificate, and you will diagnose a problem that does not exist for real users.

Key sections in the output to examine:

• Certificate chain (depth 0, 1, 2). Depth 0 is the leaf cert (your domain). Depth 1 is the intermediate CA. Depth 2 is the root CA. If depth 1 is missing, you have an incomplete chain.
• Verify return code. A value of `0 (ok)` means the chain is valid. Common non-zero codes: `10` (certificate has expired), `18` (self-signed), `20` (unable to get local issuer certificate, meaning missing intermediate).
• Subject and issuer fields. The subject shows whose cert it is. The issuer shows who signed it. If the subject and issuer are the same entity, the cert is self-signed.
• Protocol and cipher. Shows the negotiated TLS version (e.g., TLSv1.3) and cipher suite. If the connection fails entirely, the server may not support the client's minimum TLS version.

To check specific certificate dates from the command line:

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

This outputs the `notBefore` and `notAfter` dates in a readable format. To see the full SAN list:

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

These two commands alone resolve the majority of hostname mismatch and expiry errors. For a browser-friendly alternative, DomScan's SSL Checker extracts the same information and presents it in a structured view.

Fixing Each Error Type

Once you have identified the error, apply the targeted fix. Each error type has a different resolution path.

Fixing ERR_CERT_COMMON_NAME_INVALID

The fix depends on why the hostname is missing from the SAN list:

• Wrong cert installed: Identify the correct cert for the hostname and install it. On Nginx, check the `ssl_certificate` directive in the relevant server block. On Apache, check `SSLCertificateFile`.
• Missing subdomain in SAN: Reissue the cert with the missing hostname. With Let's Encrypt: `certbot certonly -d example.com -d www.example.com -d app.example.com`.
• Wildcard scope issue: If you need coverage for the apex domain plus subdomains, issue a cert with both `*.example.com` and `example.com` as SANs. Wildcards do not cover the bare domain.

Fixing ERR_CERT_DATE_INVALID

• Expired cert (Let's Encrypt): Run `sudo certbot renew --force-renewal` and reload the web server. Check that the certbot timer or cron job is active: `systemctl status certbot.timer`.
• Expired cert (traditional CA): Purchase and install a new certificate. If using PFX/P12 format, ensure you import the full chain including intermediates.
• Client clock wrong: The user needs to sync their system clock. On Linux: `sudo timedatectl set-ntp true`. On macOS: System Settings, Date & Time, enable automatic date/time. On Windows: Settings, Time & Language, toggle Set Time Automatically.

Fixing ERR_CERT_AUTHORITY_INVALID

Missing intermediates are the most common cause, and the fix is straightforward but server-specific:

• Nginx: The `ssl_certificate` file must contain the leaf cert followed by the intermediate(s) in order, concatenated into a single PEM file. The root CA is not needed (browsers have it in their trust store).
• Apache: Set `SSLCertificateChainFile` to point to the intermediate bundle, or concatenate intermediates into the `SSLCertificateFile` if using Apache 2.4.8+.
• Self-signed cert in production: Replace it with a certificate from a public CA. Let's Encrypt is free and automated. There is no good reason to serve self-signed certs to public users.
• Corporate CA: Distribute the root CA certificate to all devices via MDM, Group Policy, or manual installation into the system trust store.

Fixing ERR_SSL_PROTOCOL_ERROR

• Deprecated TLS version: Update the server TLS configuration to support TLS 1.2 and 1.3. In Nginx: `ssl_protocols TLSv1.2 TLSv1.3;`. In Apache: `SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1`.
• Cipher suite mismatch: Use Mozilla's SSL Configuration Generator to produce a modern cipher list for your server software and version. Avoid hand-tuning cipher strings.
• HTTP on port 443: Verify the virtual host or server block on port 443 has SSL enabled. In Nginx, the `listen 443 ssl;` directive must include the `ssl` keyword.
• Middlebox interference: Test from outside the corporate network. If the error disappears, the issue is the SSL inspection appliance. Work with the network team to whitelist the domain or fix the appliance's certificate injection.

Fixing NET_ERR_CERT_REVOKED

• Key compromise: Generate a new private key, create a new CSR, and request a new certificate. Do not reuse the compromised key. Rotate any other credentials that may have been exposed in the same breach.
• Domain transfer: The new domain owner should request a fresh certificate from their preferred CA. The old owner's cert should have been revoked by the previous CA as part of the transfer process.
• CA misissuance: Contact the CA to understand the revocation reason. Request a correctly issued replacement cert. If the CA cannot resolve the issue, switch to a different CA.
• Accidental revocation: If you or a team member revoked the cert by mistake, you cannot un-revoke it. Request a new cert with a new key pair.

ACME and Automated Certificate Renewal

The ACME (Automatic Certificate Management Environment) protocol, implemented by Let's Encrypt and other CAs, was designed to eliminate manual certificate management. When it works correctly, you never see an expiry error because certificates are renewed automatically weeks before they expire. Let's Encrypt certs have a 90-day lifetime, and certbot attempts renewal at 60 days by default, giving a 30-day buffer for failures.

The major ACME implementations and their approaches:

• Certbot is the reference ACME client. It supports HTTP-01, DNS-01, and TLS-ALPN-01 challenges. Runs as a systemd timer or cron job. Requires explicit web server reload after renewal (Nginx: `--deploy-hook 'systemctl reload nginx'`).
• Caddy has ACME built into the web server. Certificates are obtained and renewed automatically with zero configuration. Caddy handles challenges, renewal, and OCSP stapling internally. This is the lowest-friction option.
• Traefik manages certificates automatically when configured with ACME resolvers. Supports Let's Encrypt out of the box with HTTP and DNS challenges. Stores certs in a JSON file or KV store.
• acme.sh is a pure shell ACME client with broad DNS provider support. Useful in environments where certbot cannot be installed or where you need DNS-01 challenges across many providers.

Automated renewal is not infallible. The common failure modes that lead to expired certificates despite automation being "set up":

1. DNS-01 challenge fails. Required for wildcard certs. If the DNS API credentials expire, the provider changes their API, or the DNS zone is moved, renewal silently fails.
2. HTTP-01 challenge blocked. Port 80 must be accessible from the internet. Firewalls, WAFs, CDN configurations, or load balancer rules that block `/.well-known/acme-challenge/` paths break the challenge.
3. Certbot timer not running. The systemd timer was disabled during a server migration, or the cron entry was lost during an OS upgrade. Check with `systemctl list-timers` or `crontab -l`.
4. Web server not reloaded. Certbot renewed the cert on disk, but the web server is still serving the old cert from memory. Add a deploy hook or post-renewal hook to reload the server process.
5. Rate limits hit. Let's Encrypt enforces rate limits: 50 certificates per registered domain per week. Hitting this limit during testing or misconfiguration prevents renewal until the window resets.

The safest approach is to combine automated renewal with certificate monitoring. Even if you trust your automation, an external monitor that checks your live certificate's expiry date catches failures that internal logs miss.

Mixed Content and HSTS Issues

Sometimes the SSL certificate is perfectly valid, the chain is complete, nothing is expired, and users still see security warnings or broken behavior. These situations usually trace to application-layer issues rather than certificate problems.

Mixed Content

A page served over HTTPS that loads sub-resources (images, scripts, stylesheets, fonts, iframes) over plain HTTP triggers mixed content warnings. Browsers handle this in two tiers:

• Mixed passive content (images, video, audio) is loaded but flagged with a warning. The page shows a degraded security indicator instead of a full lock icon.
• Mixed active content (scripts, stylesheets, iframes, fetch requests) is blocked entirely. Modern browsers refuse to load active content over HTTP on an HTTPS page. This breaks functionality silently.

The fix is straightforward: update all resource URLs to use HTTPS or protocol-relative paths. Search your codebase, database content, and CMS templates for `http://` URLs pointing to your own domain or external resources. Most CDNs and external services support HTTPS, so changing the protocol is usually sufficient.

HSTS Complications

HTTP Strict Transport Security (HSTS) tells browsers to always use HTTPS for a domain, even if the user types `http://`. Once a browser receives an HSTS header, it will refuse to connect over HTTP for the duration specified in `max-age`. This is a powerful security mechanism, but it creates specific problems when things go wrong:

• Cert error becomes total blockage. Without HSTS, users can click through SSL warnings. With HSTS active, browsers refuse to show the "proceed anyway" option. A certificate error becomes a complete denial of access.
• HSTS preloading is permanent. If you submit your domain to the HSTS preload list (built into browser source code), removing it takes months. Do not preload until you are certain HTTPS works perfectly across all subdomains.
• includeSubDomains catches everything. The `includeSubDomains` directive forces HTTPS on every subdomain. If you have internal tools on subdomains without valid certificates, they become inaccessible.

If you are locked out by HSTS, the immediate fix depends on the context. In Chrome, navigate to `chrome://net-internals/#hsts` and delete the domain entry. This only fixes the problem on that specific browser instance. The real fix is to resolve the certificate error that HSTS is now enforcing strictly.

Redirect Loops

A misconfigured HTTP-to-HTTPS redirect can create infinite loops. The classic scenario: a load balancer terminates SSL and forwards traffic to the backend over HTTP. The backend sees an HTTP request and issues a 301 redirect to HTTPS. The load balancer receives the HTTPS request, terminates SSL again, forwards over HTTP, and the cycle repeats. Fix this by checking the `X-Forwarded-Proto` header instead of the request scheme, or configure the redirect at the load balancer level rather than the application level.

Preventing Certificate Errors

Every certificate error described in this guide is preventable with the right monitoring and automation. The goal is to catch problems before users encounter them, not after.

Certificate Monitoring

External monitoring services connect to your server on a schedule, check the certificate's expiry date, validate the chain, and alert you when something changes or when expiry is approaching. This is your safety net when automated renewal fails.

• Set alerts at 30, 14, and 7 days before expiry. The 30-day alert catches renewal failures early. The 7-day alert is your last chance before users start seeing errors.
• Monitor all hostnames, not just the primary domain. Subdomains with separate certificates are easy to forget. A wildcard cert renewal failure affects every subdomain.
• Check from multiple locations. A certificate that works from your office may fail from other regions due to CDN edge caching or geo-specific load balancer configs.

DomScan's Domain Monitor tracks SSL expiry across all your domains and sends alerts before certificates expire. Combined with SSL Grade checks, you get continuous visibility into both certificate validity and TLS configuration quality.

Certificate Transparency Log Watching

Certificate Transparency (CT) is a public log system where CAs must record every certificate they issue. Watching CT logs for your domain names gives you visibility into certificates issued for your domains, including certificates you did not request. This catches:

• Unauthorized certificate issuance. If someone obtains a cert for your domain through a compromised CA or a domain validation bypass, it appears in CT logs before it can be used in attacks.
• Shadow IT certificates. Teams spinning up services on subdomains and obtaining their own certs. You see every cert issued, maintaining an inventory without manual tracking.
• CA misissuance. Certificates issued in error or in violation of baseline requirements. CT logs make these visible to domain owners and the security community.

You can search CT logs for any domain using DomScan's Certificate Transparency API. Set up alerts for new certificates matching your domain names to stay informed about every certificate issued.

Pre-Deployment Validation

Catch certificate errors before they reach production by adding SSL validation to your deployment pipeline:

1. Validate the cert file before deployment. Run `openssl x509 -in cert.pem -noout -text` to confirm the SAN entries match your hostnames and the dates are valid.
2. Verify the chain is complete. Run `openssl verify -CAfile chain.pem cert.pem` to confirm the leaf cert chains to a trusted root through the provided intermediates.
3. Test after deployment, before DNS cutover. Use `openssl s_client -connect new-server-ip:443 -servername yourdomain.com` to test the new server's certificate before routing real traffic to it.
4. Automate the check in CI/CD. Add a post-deploy step that curls your HTTPS endpoint and fails the pipeline if the connection returns a certificate error.

Automated Renewal Testing

Do not wait for your certificates to approach expiry to discover that renewal is broken. Test renewal proactively:

• Dry run renewals. Run `certbot renew --dry-run` monthly to verify that the ACME challenge mechanism still works. This simulates renewal without actually replacing the certificate.
• Monitor renewal logs. Check `/var/log/letsencrypt/letsencrypt.log` for errors after each renewal attempt. Pipe failures to your alerting system.
• Test deploy hooks. Renewal succeeds but the web server does not reload? Test the full chain: renewal, deploy hook execution, and web server process restart.

When to Escalate Beyond Self-Diagnosis

Most SSL certificate errors are diagnosable and fixable with the tools and techniques in this guide. But some situations require external help:

• CA-side revocation you did not request. Contact the CA directly to understand why your certificate was revoked. CAs are required to explain revocation reasons under the CA/Browser Forum baseline requirements.
• Certificates appearing in CT logs that you did not issue. This may indicate a domain validation bypass or compromised CA account. Investigate immediately and consider setting up CAA records to restrict which CAs can issue for your domain.
• Intermittent errors that vary by client. If some users see errors and others do not, and it is not a clock issue, you may have a CDN edge serving a stale or incorrect certificate. Purge the CDN certificate cache and redeploy.
• Errors only on specific devices or OS versions. Older trust stores may not include newer root CAs (e.g., the Let's Encrypt ISRG Root X1 transition). Cross-signing or alternative chain configurations may be needed.

For ongoing visibility into your domain's SSL posture, run a Domain Health check to get a consolidated view of DNS, SSL, and email security in one report. Combined with SSL Grade analysis for TLS configuration details, you have the information needed to both fix current errors and prevent future ones.

Independent references: Review the SSL Labs rating guide for grading methodology and Mozilla's Server Side TLS guidelines for current TLS configuration best practices.