SSL Hygiene Beyond Renewal Day: Reviewing Hostnames, Chains, and Redirect Paths
Most small site owners think about SSL in one moment: the day a certificate is about to expire, or the day a browser shows a warning. That reactive pattern works until a site grows a second hostname, a subdomain for a form tool, or a redirect rule added during a migration. A quieter approach treats SSL as a set of connected parts. Each hostname needs coverage, each certificate needs a complete chain, and each redirect needs to land on a secure address without detours. This article walks through a review method you can run on any hosting account, along with the questions worth asking before renewal day arrives.
Start With an Inventory of Every Hostname
A certificate only protects the names it was issued for. Before you can judge whether your SSL setup is healthy, you need a complete list of every hostname that serves traffic for your site. This includes the obvious primary domain, the www variant, any subdomains for blogs, shops, or member areas, and any hostnames created for email, file uploads, or third-party embeds that you control.
Build the list from more than memory. Check your DNS records, your hosting control panel's domain list, and the configuration files of your web server or CMS. Old hostnames often survive because nobody removed their DNS entries after a redesign. Each stale record is a question: does this name still serve anything, and if not, should it be removed or redirected?
Record for each hostname what it serves, who set it up, and which certificate currently covers it. A simple table with four columns is enough: hostname, purpose, certificate name, and expiry date. This becomes the baseline for every later audit.
Verify the Certificate Chain, Not Just the Leaf
When a browser connects to your site, it receives your server certificate along with one or more intermediate certificates that link your certificate to a trusted root. If the intermediates are missing or misconfigured, some visitors see errors even though your certificate looks valid when you check its expiry date. This failure is easy to miss because many quick checks only read the leaf certificate.
To review the chain, use a command-line tool such as openssl s_client against each hostname and confirm that the chain presented by the server is complete and in the right order. Your hosting provider's documentation or control panel usually explains how to install the intermediate bundle. If you are not sure whether your setup is correct, compare the result against a second hostname on the same account that is known to work.
Pay attention to mismatched chains after renewal. Replacing a certificate without updating the bundle can leave some clients trusting the site and others rejecting it. Test from more than one device and network when you finish any change.
Trace Redirect Paths End to End
Redirects are where many SSL problems hide. A visitor who types an old http address may pass through two or three hops before reaching the final secure page. Each hop adds delay, and any hop that points to an insecure address can leak the visitor's requests over an unencrypted connection. Redirect chains also tend to multiply during migrations, when someone adds a rule for the new address without removing the old one.
Trace each entry point you expect visitors to use: the bare domain over http, the bare domain over https, the www variant, and any legacy paths from previous versions of the site. Follow each one with a tool that shows the full sequence of responses, and note the number of hops and the final address. The goal is a single hop to the canonical secure address wherever possible.
Check that internal links in your pages also use the secure canonical address. Hardcoded http links inside templates or old posts trigger mixed-content warnings and force browsers through extra redirects. A search across your site's content for insecure prefixes often reveals dozens of these.
Check Mixed Content and Third-Party Resources
A page served over https can still load scripts, images, or stylesheets over http. Browsers block or warn about some of these, and the result looks broken to visitors even though the certificate is perfectly valid. Mixed content often arrives through plugins, themes, or embedded widgets that were written before secure delivery became standard.
Load each important page in a browser with developer tools open and review the console for mixed-content messages. Then review the list of requested resources in the network panel and note any that use the insecure scheme. For each one, decide whether to update the reference to https, replace the resource, or remove it.
Third-party resources deserve their own review. Confirm that each external provider you rely on supports secure delivery, and remove embeds that you no longer use. Every external dependency is another place where a certificate problem on someone else's side can affect your pages.
A Practical Audit Checklist and Questions to Ask
Run this checklist on each hostname at least once per quarter, and again after any migration, theme change, or plan change. First, confirm the hostname appears in your inventory and that its purpose is still current. Second, verify that the server presents a complete chain and that the leaf certificate matches the hostname. Third, trace every redirect path and confirm it reaches the secure canonical address in a single hop. Fourth, scan pages for mixed-content warnings. Fifth, record the expiry date and the name of the person responsible for renewal.
Several questions are worth bringing to your hosting provider before renewal day. Ask whether certificate renewal is automatic or manual on your plan, and what notifications you receive before expiry. Ask how intermediate bundles are installed and whether the provider can confirm the chain for your specific account. Ask who has access to the certificate settings and whether that list matches your team. Ask what happens to your hostnames if you change plan types or move the site. Write the answers down, because the next person to manage the account will need them.
Finally, treat the audit as a routine rather than an emergency. A short review every few months, with a written record of what you checked and what changed, turns SSL from a source of surprise warnings into a dependable part of how your site runs.