SSL certificate error: how to identify the cause and fix it

An SSL error means the browser could not verify a secure connection to the intended site or load its resources over HTTPS. First, note the exact error code, URL, and time. The phrase “connection is not secure” alone does not tell you whether the certificate expired, the name did not match, or a network proxy interfered.

If you are a visitor, do not enter a password or payment details after a browser warning. Check the URL and your device’s date and time, try again in an up-to-date browser and on another network. If the error persists, send the site owner the URL and error code. Adding an unknown certificate to your trusted certificates is not a routine way to fix a website.

For a site owner, an initial SSL certificate check shows the available information: issuer, names, validity period, and parameters of one TLS connection. The reChecker assessment does not replace checks of the full trust chain, all protocols, and browser compatibility. If a field is unavailable because of a timeout, that means there is no result, not that the site is confirmed to be working correctly.

Quick diagnosis by error code

Error codes vary by browser. Compare the actual URL and circumstances, not just similar warning text. An error on www.example.com and a successful visit to example.com concern different names.

Certificate validity period: ERR_CERT_DATE_INVALID

Check Not Before and Not After, then check the client and server clocks. The certificate may not yet be valid, may have expired, or may be valid while the device time is incorrect. Do not attribute the cause solely to how long ago the certificate was issued.

If the certificate is managed by Certbot, check the configured renewal task and run a renewal dry run:

sudo certbot renew --dry-run

After a successful renewal, make sure the web server has loaded the new certificate and the public address is serving that certificate. The renewal command may succeed while the server continues to use an old file or a certificate on another load balancer. The renewal process and hooks are described in the Certbot guide.

For regular validity-period checks, use SSL Monitor. Monitoring alerts you to the observed status; it does not issue a certificate or automatically fix server settings.

Domain name: ERR_CERT_COMMON_NAME_INVALID

Compare the hostname in the address bar with the SANs in the certificate actually received. Check the primary domain, www, the required subdomains, and the address after a redirect. A wildcard for one subdomain level does not cover every address at any depth.

If the server hosts several sites, check SNI and virtual host selection. The error may be caused by another site’s certificate being served on the same IP. When connecting to an IP without a hostname, you may receive the default virtual host’s certificate.

A redirect from an HTTPS URL does not fix that URL’s certificate error: the browser checks TLS before receiving the HTTP response containing the redirect. First ensure that the connection works correctly for the original name, then configure the redirect. Redirect check helps inspect the HTTP redirect chain after the connection is established.

Trust chain: ERR_CERT_AUTHORITY_INVALID

Check the server certificate and intermediate certificates. In Nginx, the ssl_certificate file should contain the site certificate, followed by the required intermediate certificates. Do not add a root certificate at random or fix the problem by disabling trust verification. An example and the required order are provided in the Nginx documentation.

Example of connecting to your server with SNI and hostname verification:

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

Replace example.com with your domain. The command uses the trusted CAs in the current environment. -showcerts shows the certificates sent by the server and does not, by itself, confirm a trusted chain. Verification options are described in the OpenSSL documentation.

If the connection works on one device but not another, compare the OS versions, browsers, trusted CAs, and networks. A corporate proxy may substitute its own certificate. Check its issuer and give the details to your network administrator; do not install a random CA to bypass the warning.

TLS and ciphers: ERR_SSL_VERSION_OR_CIPHER_MISMATCH

A successful connection from one testing client shows the protocol and cipher selected for that attempt. It does not describe all the options supported by the server. For an in-depth check, use a specialist TLS scanner and inspect the actual configuration of the server, CDN, and load balancer.

First determine where the connection fails: browser → CDN or CDN → origin. Check that the target server is actually listening for HTTPS on the expected port and is using the required certificate. Do not blindly enable outdated protocols to eliminate one error: this changes the security conditions for other visitors.

Record the client version, command, time, and result. After making a change, repeat the same check and try opening the site in the affected browser. If a check is unavailable, leave that scenario unverified.

Revoked certificate: ERR_CERT_REVOKED

Find out from the certificate authority why the certificate was revoked. If the private key was compromised, you need a new key and certificate; simply reissuing the certificate with the old key does not resolve the problem. Then replace the files, update the configuration, and check the certificate served by all nodes.

Checking the validity period is not the same as checking revocation. A certificate that is still within its validity dates may have been revoked. Record which tool and source were used to check this status.

Mixed content: the certificate is valid, but resources are blocked

Open DevTools → Console and Network. Find the specific HTTP request from the HTTPS page: a script, image, stylesheet, iframe, or API. Check whether the resource is available over HTTPS and change its URL in the template, CMS settings, or data source.

For a resource on the same site, a relative path such as /image.jpg often works. An external resource needs a working HTTPS URL. Replacing all instances of http:// in the database may damage external links and serialized values. Make a backup and use a migration tool that understands your CMS’s data format.

After making the change, reload the page and check the key action: a form, payment, image, or embedded widget. The disappearance of one Console message does not confirm that the entire scenario works. A certificate check alone does not detect every mixed resource on a page.

CDN: check the public certificate and origin separately

For Cloudflare Full (strict), the origin must serve a certificate with a suitable name and validity period, issued by a public CA or Cloudflare Origin CA. A regular self-signed certificate is not the same as Origin CA. The requirements are listed in the Cloudflare documentation.

Record which connection path each tool checks. A successful connection to the public domain through a CDN does not confirm the status of the direct origin. Conversely, an Origin CA certificate is intended for the relevant connection to the CDN and does not mean that a regular browser will trust a direct connection to the server address.

How to confirm the fix

1. Save the original URL, error code, time, and testing client.
2. Record the specific change: certificate name, renewal, chain, server setting, or resource URL.
3. Repeat the original test with the same address and parameters.
4. Open the site in a browser and check an important user action.
5. If there are multiple nodes or a CDN, check the required configurations and note any that remain untested.
6. Enable validity-period monitoring and save the result of the repeated check.

SSL Checker, SSL Monitor, and security headers check provide different evidence. Use them for their respective purposes, and verify the trust chain, revocation status, page resources, and compatibility with separate checks. In your log, write “data not obtained” if the request did not complete, and “fixed” only when the original symptom no longer occurs.