Certificate Chains, Redirects, and the Hostnames Nobody Remembers
Most small site owners think about SSL in one way: is the padlock showing, and when does the certificate expire? Both questions matter, but they only cover a slice of what can go wrong. A certificate can be valid and still fail a visitor because the chain is incomplete, a redirect sends people through an insecure address, a forgotten subdomain serves an old certificate, or a single image loads over plain HTTP and triggers a browser warning. This article offers a quieter audit method for teams that run their own sites without a dedicated operations group. It does not depend on any particular provider's tooling. It depends on asking the right questions in a consistent order, and writing down the answers so the next person can repeat the check.
Start With a Hostname Inventory, Not the Homepage
The most common SSL gap is not an expired certificate on the main domain. It is a hostname that someone created years ago and nobody has touched since. Mail portals, staging copies, old campaign landing pages, API endpoints, and file-download subdomains all accept connections, and each one needs a valid certificate that matches its name.
Begin by listing every hostname that resolves to infrastructure you control. Pull names from your DNS zone, your web server virtual host configuration, any redirect rules, your email settings, and the links in your analytics and marketing materials. For each name, record what it is for, who requested it, and whether it still needs to exist. Hostnames that serve no current purpose are candidates for removal, and removing them is cheaper than renewing them forever.
Once you have the list, check each name from outside your network. Your internal view can hide problems, such as a split-horizon DNS setup that makes a name work from the office but fail for visitors. The test is simple: does each hostname present a certificate that names it, and does that certificate validate in a standard browser or command-line client?
Read the Full Chain, Not Just the Leaf
A certificate is usually delivered as a chain: the leaf certificate for your hostname, plus one or more intermediate certificates that connect it to a trusted root. Browsers generally trust the root store on the device, so the server must send the intermediates. When the chain is incomplete, some clients succeed because they cache or fetch intermediates on their own, while others fail with a trust error. That inconsistency is why a problem can appear on one phone and not another.
During your audit, examine what the server actually sends. Confirm that the chain ends at a recognized root, that intermediates are in the right order, and that no expired intermediate is still being served. Many renewals go wrong when someone installs a new leaf certificate but leaves an old chain file in the configuration, or when a bundle file is edited by hand and a line is lost.
Write down where the chain file lives, who installs it, and what command or step verifies it afterward. A chain that works today can break after a server migration if the new host expects the files in a different location.
Trace Redirect Paths End to End
Redirects are where SSL hygiene often breaks quietly. A visitor types the bare domain, is sent to a secure address, is then sent to a version with a trailing slash, and finally lands on a page. Each hop is a chance to reach an insecure address, a deprecated hostname, or a loop. A redirect that drops to plain HTTP even once can expose the session to interception and will show as insecure in the browser.
Test the paths that real visitors use. Start with the http version of your main domain, the bare domain without www, the www version, and any legacy addresses from older campaigns. Follow each chain step by step and note the status code and destination of every hop. A healthy setup sends every insecure request directly to the single canonical secure address in as few steps as possible, and no step ends on a plain HTTP URL.
Also check that redirects do not point to hostnames you have retired. An old redirect target that now resolves to a parked page or an unrelated server can send visitors to a site you no longer operate. Keep a short table of every redirect source and its intended destination so changes are visible.
Find Mixed Content Before Visitors Do
Mixed content means a secure page loads something over plain HTTP: an image, a script, a stylesheet, a font, or an embedded frame. Browsers may block the resource, display a warning, or quietly degrade the page depending on the resource type. For site owners, the practical risk is that a page looks secure at the top while a single insecure asset undermines the visitor's trust and breaks features such as forms or embedded players.
Mixed content usually comes from hard-coded absolute URLs in old templates, copied snippets from third-party pages, or media uploaded when the site was still on HTTP. A crawler or browser developer console can list these, but the review should also cover content that is not visible on the homepage: archived posts, footer widgets, email templates that link back to the site, and pages behind a login.
Decide how you will fix each instance. Often the answer is to update the URL to the secure version after confirming the remote host supports it. For resources you do not control, consider whether the element is worth keeping at all. Document each decision so a future editor does not reintroduce the same link.
A Short Checklist for Each Audit Cycle
Run through these questions on a fixed schedule, such as every quarter, and record the date and the person who ran the review:
Does every hostname in the inventory still have a current purpose, and has any unused name been removed?
Does each active hostname present a certificate that matches its name and validates from outside your network?
Does the server send a complete chain ending at a trusted root, and is the chain file location documented?
Does every insecure request reach the canonical secure address in one or two hops without loops?
Are there any absolute HTTP links in templates, posts, or widgets that should be updated?
Who is responsible for renewal, and where is the renewal reminder stored so it does not depend on one person's inbox?
Before you rely on any hosting provider's documentation for a specific step, confirm it against your own plan and account, since features and procedures differ across account types. The aim of this method is not to achieve a perfect score in one afternoon. It is to make the path from a visitor's request to a trusted page visible, so that when something breaks, your team can see the broken step instead of guessing.