SSL Hygiene Checks That Look Past the Expiry Date
Most small site teams treat SSL as a single date on a calendar. They note when the certificate expires, renew it when a reminder arrives, and assume the padlock in the browser means everything is in order. That assumption is understandable, but it leaves gaps. A certificate can be valid and still be installed incorrectly, served for the wrong hostname, bypassed by an old redirect, or paired with pages that load insecure resources. SSL hygiene means checking the whole path a visitor travels, not only the expiry field. This article walks through a practical audit method you can run without specialized tooling and without relying on any particular hosting feature.
Start With an Inventory of Hostnames
Before you look at any certificate, write down every hostname that serves your site. The obvious ones are the primary domain and the www variant. Less obvious entries include subdomains for a blog, a shop, a login portal, an image host, or a staging copy someone once shared with a client. Each hostname either has its own certificate, shares one that covers it, or fails to load over HTTPS at all. Any of these outcomes can surprise a visitor who types the address from an old email or a printed flyer.
Ask a few direct questions for each entry. Who requested it? Where is the DNS record managed? Which certificate covers it, and what does that certificate's name list include? A common failure is a wildcard certificate that covers one level of subdomain but not the deeper names someone added later. Another is a certificate that lists the domain but was issued for a different account or owner, which makes renewal harder when a staff member leaves. Recording these answers in a simple table turns a vague sense of coverage into a checkable record.
Read the Chain, Not Just the Leaf
A certificate your server presents is only one part of what a browser evaluates. The browser also needs the intermediate certificates that connect your certificate to a root the browser already trusts. When intermediates are missing or misordered on the server, some clients succeed because they fetch the missing piece on their own, while others, including many API clients and older devices, fail with a trust error. The site may look fine in your main browser and still break for a portion of your audience.
To check the chain, use a browser's certificate viewer to inspect the path from your leaf certificate up to its issuer, and confirm that every link is present and unexpired. Then test from a machine or tool that does not have cached intermediates, such as a command-line client with a clean trust store. If one environment passes and another fails, the chain configuration is the likely culprit. Fixing it usually means installing the full bundle your certificate authority provides, in the order it specifies, rather than only the leaf file.
Follow Every Redirect to the Final Destination
HTTPS hygiene depends on where requests end up. A site might serve a secure page while an old link still lands on the plain HTTP version, which then redirects. During that brief moment, traffic and cookies may travel without protection, and some browsers will flag the page as insecure. Redirect chains also add latency and can confuse crawlers that give up after a few hops.
Test your key entry points: the bare domain over HTTP, the www variant over HTTP, the bare domain over HTTPS, and any legacy paths from older site versions. Write down how many hops each one takes and whether the final URL uses HTTPS on the correct hostname. A healthy setup usually reaches the canonical HTTPS address in one redirect from any starting point. If you find loops, multiple hops, or redirects that bounce between hostnames, simplify them to a single permanent redirect to the canonical address.
Hunt for Mixed Content on Real Pages
A page can load over HTTPS and still reference images, scripts, or stylesheets through plain HTTP URLs. Browsers either block these resources or show warnings, and either outcome degrades the experience. Mixed content often hides in content added years ago: a pasted embed, a hard-coded image path in a theme, or a third-party widget that still points to an old address.
Audit a representative set of pages, not only the homepage. Include a long article, a contact form, a product or service page, and any page built from a different template. Open each in a browser's developer tools, check the console for mixed-content messages, and review the network list for any request that starts with an insecure scheme. Update references to HTTPS where the resource supports it, and remove resources you no longer use. Re-run the audit after any theme change or plugin update, because those are the moments when old references tend to reappear.
A Short Checklist and Renewal Questions
Use this checklist each quarter or after any significant change. Confirm that every hostname in your inventory resolves over HTTPS with a certificate that covers it. Confirm that the full intermediate chain is served and that a clean client validates it. Confirm that HTTP entry points reach the canonical HTTPS address in a single redirect. Confirm that key pages show no mixed-content warnings. Confirm that a named person on your team knows where renewal happens and can access it.
Before renewal day arrives, ask your team and your hosting provider several questions. Who receives expiry notices, and is that inbox monitored? Does renewal require a manual step, and has someone performed it before? Does the new certificate replace the old one on every hostname that depended on it? Where is the private key stored, and who can retrieve it? Clear answers to these questions reduce the chance that an expiry becomes an outage. Treat the answers as part of your site's records, updated whenever responsibilities change.