Monitoring SSL beyond expiry: chains, mismatches and weak settings

A site can have a perfectly valid certificate and still be broken. The browser shows a padlock, the expiry date is months away, and yet a payment gateway's callbacks fail, the mobile app cannot log in, and one customer insists they get a warning that nobody else can reproduce. Expiry dates are only the first line of SSL certificate monitoring; most of the awkward faults live in the configuration around the certificate.

This article covers the three that cause the majority of real incidents: incomplete chains, hostname mismatches and outdated protocol settings, along with a maintenance rhythm that catches them before customers do.

Incomplete certificate chains, the fault that hides from you

Your certificate is not trusted on its own. It is signed by an intermediate certificate, which in turn links to a root that devices already trust. Your server is supposed to send the intermediate along with your certificate so the client can build that path.

When the intermediate is missing, desktop browsers often paper over it. Several of them fetch the missing certificate automatically or rely on a cached copy from another site, so your testing looks fine. Other clients do not. Command-line tools, server-to-server integrations, Java applications, older Android devices and many payment or logistics APIs simply refuse the connection.

The symptoms are distinctive. The site works for you but a partner reports a verification failure; a webhook stops arriving with no error visible in your logs; an app works on one phone and not another. If you hear any of those while the browser looks healthy, check the chain first.

The fix is usually to install the full chain bundle your issuer provides rather than only the site certificate, then reload the web server. Automated clients generally handle this for you, which is another reason a hand-installed certificate deserves more scrutiny than an automated one.

Hostname mismatches and the names you forgot to include

A certificate is valid for the names listed in it. Anything else produces a warning, no matter how correct the certificate otherwise is. Common ways this goes wrong:

• The certificate covers the www hostname but not the bare domain, or the reverse, while both resolve and both are reachable.
• A wildcard covers one level of subdomain but not a deeper one, so a nested hostname fails.
• A new subdomain is launched and pointed at the same server, which then serves the default site's certificate to visitors.
• Server name indication is misconfigured on a host with several sites, so the wrong certificate is presented for some requests.
• A redirect sends visitors through an intermediate hostname that is not on the certificate, producing a warning in passing even though the destination is fine.

Test every hostname individually rather than assuming the certificate covers them all. Listing the subject alternative names on the served certificate takes seconds and settles the question definitively.

Also confirm the redirect chain. Visitors who type the domain without a prefix should land on your canonical hostname over https in as few hops as possible, and every hop in between must be covered.

Outdated protocol and cipher settings

Protocol configuration ages badly. Settings that were fine when the server was built quietly become liabilities as older versions are deprecated.

Protocol versions

TLS 1.0 and 1.1 are deprecated and have been disabled by major browsers. Modern configurations serve TLS 1.2 and TLS 1.3. Leaving the old versions enabled does not help the handful of ancient clients you imagine, and it will fail a security review or a payment compliance check.

Weak cipher suites

Old ciphers linger in configurations copied from tutorials years ago. Prefer your web server's current recommended cipher list rather than a hand-assembled string, and revisit it when you upgrade the server.

Supporting settings

A few related items belong in the same review. HSTS tells browsers to use https automatically, but commit to it carefully because the instruction is cached by browsers for the duration you set. OCSP stapling improves the speed of revocation checks. Mixed content, where a secure page loads an image or script over plain http, undermines the padlock and is worth hunting down in the browser console.

Changes here can lock out clients, so make them in a maintenance window, test your own integrations immediately afterwards, and keep the previous configuration to hand.

How to test, and what each tool tells you

You do not need to guess at any of this. A short routine gives you a clear picture:

1. Run an online SSL test such as Qualys SSL Labs against each public hostname. It reports the chain, the names covered, the protocol versions and the cipher list in one place.
2. Use the openssl client from a machine outside your network to see exactly what the server sends, including whether the intermediate is present.
3. Open the Security panel in Chrome DevTools on your key pages to confirm the connection details and spot mixed content.
4. Test an actual integration, such as a sandbox call from your payment gateway or a request from your mobile app, since those clients are stricter than browsers.
5. Check an older device if you support one, because trust stores differ and a chain problem shows there first.

Record the result somewhere. A dated note per hostname turns this from a vague memory into something you can compare after the next change.

Fold the checks into your maintenance rhythm

Configuration faults are introduced by changes, so tie the checks to changes as well as to the calendar.

Run the full test quarterly for every public hostname. Run it again, immediately, after any of these: a server migration, adding a subdomain, putting a CDN or proxy in front of the site, changing DNS or nameservers, a control panel or operating system upgrade, and any certificate installed by hand.

Add continuous checks where your monitoring supports them. Several uptime services can verify the served chain and the hostname match on every check, not just the expiry date, which turns a quarterly audit into a same-day alert.

Keep an inventory alongside it: hostname, issuer, covered names, protocol versions enabled, and who installed it. When something breaks at an inconvenient hour, that list is what shortens the diagnosis.

Start with one test on your busiest hostname

Pick the hostname that carries your revenue, run a full external SSL test on it today, and read the chain and protocol sections rather than only the overall grade. If anything is flagged, the same fault almost certainly exists on your other hosts, because they were configured the same way.

Server-level TLS configuration is fiddly to get right and easy to break, so if the report raises things you would rather not touch on a live site, our team handles it as routine work on managed servers; see Linux server hosting or raise it with our support team for an existing setup.

Frequently asked questions

My site works in Chrome but an API call fails with a certificate error. Why?

Most often an incomplete chain. Browsers can recover from a missing intermediate, while libraries and server-to-server clients usually cannot. Install the full chain from your issuer and test again with a command-line client rather than a browser.

Does a wildcard certificate cover every subdomain?

It covers one label at the level it was issued for. A wildcard for one level does not automatically cover a deeper nested hostname, and it never covers a different domain. Check the names listed on the certificate rather than relying on the wildcard as a general permission.

Is it safe to disable older TLS versions?

For most Indian business sites, yes, since current browsers and phones use TLS 1.2 or 1.3. The risk is with old internal systems or a partner integration on legacy software, so check your integrations before changing the setting and keep a rollback ready.

How is this different from just monitoring the expiry date?

Expiry monitoring answers one question: is the certificate still valid. These checks answer whether the certificate is presented correctly, for the right names, over acceptable protocols. A certificate can pass the first test and fail all three of the others.