SSL Certificate Errors: Diagnose Expired, Mismatched and Incomplete

An SSL certificate error is the full-page warning that tells a visitor "your connection is not private" or that the site's certificate cannot be trusted. Most people leave at that point. A crawler that meets the same failure has the same problem: the secure connection cannot be established, so the page cannot be fetched over HTTPS.

Almost every certificate error comes down to one of three causes: the certificate has expired, its names do not match the address being visited, or the server is not sending the full chain of certificates that lets a browser trust it. This guide helps you work out which one you have, test it from the command line and from a browser, and fix it. It is for site owners, marketers and developers who manage a site's hosting or can talk to the people who do.

You will finish with a clear diagnosis, a fix that suits your hosting setup, and a renewal routine that stops the problem coming back.

Before you begin

You need to know where your certificate is managed. It may be issued automatically by your host or a CDN, issued by a certificate authority such as Let's Encrypt through a client on your server, or bought from a vendor and installed by hand. Ask whoever set it up, or look in the hosting control panel. You also need access to the server or panel to install a new certificate, and a terminal with OpenSSL for the command line tests (optional but useful).

Before changing anything, write down the current certificate details and keep a copy of any existing certificate and key files. Never share your private key in a ticket, chat or email. Only the public certificate and chain are safe to send to support staff.

Plan for downtime of seconds to minutes when you swap a certificate, depending on the server. If the error is live right now, fix it first and tidy up afterwards.

What the browser checks

A browser or crawler asks three questions about the certificate your server presents.

Is it within its validity dates? Every certificate has a start and end date. After the end date it is expired. Check the end date of your own certificate: validity periods differ between authorities, and short ones make automated renewal essential.
Does it cover the name being visited? RFC 9110, the HTTP standard, requires a client to verify the server's identity using the process in RFC 6125, and says that if the certificate is not valid for the target origin, the user agent must either get the user's confirmation or terminate the connection with a bad certificate error. Automated clients should terminate. That is why a name mismatch stops a crawler.
Can it be traced to a trusted root? Let's Encrypt describes a three-tier chain: a root certificate that browsers trust, intermediate certificates, and the end-entity certificate issued to your site. The server presents the chain so the browser can validate signatures up to a trusted root.

Step-by-step instructions

Step 1: See the error and the exact name

Open the site in a private window and click the warning for details. Note the host name in the address bar, including whether it begins with www, and the wording of the error: expired, name mismatch, untrusted issuer or chain problem.

Then test every name a visitor might type: example.com, www.example.com, and any subdomains such as shop.example.com or blog.example.com. A certificate may cover one and not another.

What success looks like: You have a list of which names show errors and what each error says.

Step 2: Check the expiry date

If the warning mentions an expired or "not yet valid" certificate, look at the dates. In a browser, view the certificate from the padlock or the warning page. From a terminal, OpenSSL can fetch and print them:

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

-servername sets the TLS Server Name Indication, which many servers need to choose the right certificate when they host several sites. The -dates option of openssl x509 prints the start and expiry dates. To test whether a certificate will expire soon, -checkend takes a number of seconds and exits with a non-zero code if the certificate expires within that time:

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

This checks for expiry within 30 days (2,592,000 seconds). A monitoring job can run it daily. Also check the server's clock if a brand-new certificate shows "not yet valid": a wrong system date makes a valid certificate look invalid.

If the certificate is expired, renew or reissue it (Step 5). If your automation should have renewed it, find out why it failed, because the same fault will recur.

What success looks like: You know the start and end dates of the certificate each name is serving.

Step 3: Check that the names match

If the dates are fine but the browser reports a name mismatch, print the names in the certificate:

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

The -ext option prints the named extension in text form. Look at the DNS names listed and compare them with the host name that failed. RFC 9110 points to RFC 6125 for the matching rules and says clients must not use a common name as the reference identity, so check the subject alternative names rather than the common name.

Common causes:

The certificate covers example.com but not www.example.com, or the reverse. Reissue it to include both.
A wildcard such as *.example.com covers only one label. web.dev explains that it covers foo.example.com but not foo.bar.example.com. Because it stands for exactly one label, list the bare example.com as its own name if you need it.
The request reaches the wrong server or site: a CDN, load balancer or shared host is serving a default certificate because the host name is not configured there. This is common after a DNS change or a migration.
You are testing by IP address. A certificate is issued for names, so connecting to a bare IP will not match.

What success looks like: Every host name that visitors use appears in the certificate, or you know which name to add.

Step 4: Check the chain

If the certificate is valid and the names match but some browsers, apps or tools still fail, the chain is the likely cause. Clients can differ in how they handle an incomplete chain, which is why the error can appear "only for some people".

The TLS 1.3 standard says the sender's certificate must come first in the certificate list, and each following certificate should directly certify the one before it. A root certificate may be left out when supported clients are known to have it. In practice, the server should send your certificate followed by the intermediate or intermediates, and the root can be left out.

See what the server sends:

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

-showcerts displays the certificate list in the order the server sent it. The OpenSSL manual points out it is not a verified chain, so also read the verification result printed at the end of the output, or use a hosted tester such as Qualys' SSL Server Test, which web.dev recommends running regularly; it advises treating any grade below A as a bug.

If only your own certificate is sent, install the full chain file your certificate authority provides. Many certificate tools output the certificate and the chain as separate files, so make sure you point the server at the file that includes the chain. Follow your certificate authority's instructions for the current intermediates rather than copying an old file from another server.

If an older device fails but modern browsers work, look at the chain. Let's Encrypt explains that chains ending at ISRG Root X1 are larger but more compatible with older clients, while chains ending at ISRG Root X2 (ECDSA only) are smaller but need a trust store updated around 2022 or later. Choose the chain that suits your audience.

What success looks like: The server sends your certificate and the intermediates, in order, and a tester reports no chain issues.

Step 5: Renew or reissue and install

How you fix it depends on who manages the certificate.

Managed by your host or CDN: Open its SSL or certificate section and look for a status such as pending validation or failed. Re-run issuance there, and make sure the DNS records the provider needs are in place.
Automatic client such as Certbot: Run the renewal in verbose mode and read the error. Common causes are a blocked validation path, a changed DNS record, a firewall rule or a stopped scheduled job. Whatever the cause, make the renewal job report its failures to a person.
Purchased certificate: Generate a new certificate signing request, submit it, and install the certificate with the chain file from the vendor. web.dev recommends a 2048-bit RSA key pair, and says to store certificates in a location that is not web-accessible, such as /etc/ssl on Linux.

After installing, reload the web server so it picks up the new files. Then repeat the Step 2 to Step 4 tests.

What success looks like: Each name serves a certificate with a future expiry date, the right names and a complete chain.

Step 6: Check redirects, HSTS and mixed content

Fixing the certificate is not the end. Check that http:// addresses redirect with a 301 to the HTTPS version; web.dev advises not redirecting until HTTPS works and using a 301 so browsers and search engines treat HTTPS as canonical. Load the HTTPS page and look for mixed content warnings (see fixing mixed content).

If you use HSTS, remember what it does: web.dev warns that it can make the site fail hard if a certificate expires, and says not to enable it until your site operation is robust. Read how to roll out HSTS safely before turning it on.

Finally, in Google Search Console, use the URL Inspection tool on a key page to check that Google can fetch and render the HTTPS version. If you changed redirects, check redirect chains.

What success looks like: All variants of your address lead to one valid HTTPS page, with no warnings in the browser.

Step 7: Prevent the next expiry

Set up two layers: automatic renewal, and monitoring that tells you if renewal fails. Run the -checkend test on a schedule and alert at 30 and 14 days. Put certificate expiry dates in a shared calendar if any certificate is bought and installed by hand. Name an owner. Our guide on uptime monitoring covers alerts that tell you before visitors do.

What success looks like: Someone is alerted well before expiry, and renewals are tested rather than assumed.

Final verification checklist

Every public host name (apex, www, subdomains) loads over HTTPS without a warning.
Each certificate's end date is in the future and is monitored.
The subject alternative names include every name you serve.
The server sends the end-entity certificate first, followed by intermediates.
A hosted SSL test or OpenSSL shows no chain errors.
HTTP addresses redirect with a 301 to HTTPS.
No mixed content appears on key pages.
Automatic renewal has been tested, and failures raise an alert.
The private key was not shared or stored in a public location.

Common mistakes to avoid

Installing only the leaf certificate. Some clients will fail. Install the full chain from your certificate authority.
Forgetting the bare domain or www. Request both names on the certificate, or redirect one to the other over a valid certificate.
Assuming a wildcard covers everything. It covers one label only, and not the bare domain.
Trusting a desktop browser test alone. Test with OpenSSL or a hosted tool too, because other clients can behave differently.
Enabling HSTS before renewal is reliable. An expired certificate then becomes a hard failure for returning visitors.
Redirecting before HTTPS works. You send visitors from a working page to an error. Fix the certificate first.
Ignoring renewal failure emails and logs. Automation can fail quietly. Add monitoring.
Sending the private key to support. Only the certificate and chain are safe to share.

Frequently asked questions

Does a certificate error affect SEO?

A page that cannot be fetched securely cannot be reliably crawled or used by visitors. web.dev also notes that Google uses HTTPS as a positive search quality indicator, though no guide can promise a ranking effect. The practical harm is lost visits and failed crawls.

Why does the site work on my computer but not on a phone or API client?

A common cause is a chain the server does not send in full, which different clients handle differently. Check the chain with -showcerts or a hosted tester.

How long should a certificate last?

That depends on the authority that issued it. Read the end date from your own certificate (Step 2), and treat short lifetimes as a reason to automate renewal and monitor it.

My certificate looks fine but I still see an error.

Test each host name separately and check that your CDN, load balancer or host has the certificate attached to that exact name. A default certificate served for an unconfigured name is a common cause.

Is a free certificate as good as a paid one?

What matters is that the issuing authority is trusted by the browsers and devices your visitors use, that the names match and that it is renewed on time. Check the compatibility details your authority publishes.

Official references

Next step: See how Crawvix checks a website and capture a baseline once scanning opens. This guide provides technical information, not a guarantee of rankings, traffic or index inclusion.