Beyond Expiry Dates: Auditing Certificate Chains and Mixed Content
Most small teams think about SSL in one way: is the certificate still valid? That question matters, but it only covers one part of a secure site. A certificate can be unexpired and still cause browser warnings, broken API calls, or confusing redirect loops. A clean HTTPS setup depends on the whole chain of pieces that a visitor's browser touches, from the certificate installed on your server to the individual images and scripts loaded on each page. This article walks through a practical audit that goes past the expiry date and focuses on what visitors actually experience.
Start With the Certificate Chain, Not the Leaf
When a browser connects to your site, it receives your server certificate, often called the leaf certificate, along with one or more intermediate certificates that link it back to a trusted root. If the server does not send the complete set of intermediates, some browsers will fail to validate the connection while others succeed by fetching missing pieces on their own. That inconsistency is a common source of confusing reports from visitors who say the site works on one device and not another.
To audit the chain, ask your team these questions. Does the server send the full intermediate bundle, or only the leaf certificate? Were the intermediates installed in the correct order? Does the chain end at a root that current browsers trust? If you cannot answer these from memory, use a command-line tool such as openssl s_client against your hostname to print the chain the server presents. Record the output in your ops notes so the next person does not have to reconstruct it under pressure.
Pay attention to how the certificate was issued and where the private key lives. The chain check tells you whether visitors can validate the connection, but it does not tell you who can replace the certificate when it needs renewal. Keep that ownership question on your checklist separately.
Audit Every Redirect Hop
A typical small site has several redirects that accumulate over the years: an old HTTP-to-HTTPS rule, a www-to-apex rule, a trailing-slash rule, and perhaps a legacy path that moved during a redesign. Each one is reasonable on its own. Together they can form chains where a single URL takes three or four hops before reaching the final page. Each hop adds latency, and some hops can loop if two rules disagree about the preferred hostname.
Audit redirects by listing your entry points: the root domain with and without www, the HTTP version of each, and the most important deep links from search results or email campaigns. Trace each one and count the hops. The goal is a single hop to the canonical HTTPS URL wherever possible. If a redirect points to a URL that itself redirects, update the rule to point directly at the final destination.
Check that the redirect status codes match intent. A permanent redirect tells search engines and browsers that the move is final, which is correct for HTTP-to-HTTPS and for hostname consolidation. A temporary redirect is appropriate for maintenance pages or experiments. Mixing these up can leave old URLs stuck in caches or confuse crawlers.
Find Mixed Content Before Visitors Do
Mixed content occurs when an HTTPS page loads resources over plain HTTP. Browsers respond in one of two ways. Passive mixed content, such as an image, may load with a warning. Active mixed content, such as a script or stylesheet, is often blocked entirely, which can break forms, menus, or payment widgets on the page. Either outcome makes the site look untrustworthy even though the certificate itself is valid.
The usual sources are hardcoded absolute URLs in templates, old embedded videos or maps, third-party widgets that were configured with HTTP, and content imported from a previous site. Crawl your site with a tool that reports the protocol of every resource, or inspect pages in browser developer tools and filter the console for mixed content warnings. Check templates and content databases, not only the pages you happen to browse.
Fix mixed content at the source rather than relying on the browser to upgrade requests. Update the URLs in your templates and content, replace or remove outdated embeds, and confirm that third-party services offer HTTPS endpoints before you adopt them. Once fixed, retest the pages that carry forms and checkout steps, since those are where a blocked script does the most damage.
A Short Checklist for Your Next Audit
Use this list as a recurring routine, not a one-time project. First, confirm the server sends the complete intermediate chain and that a command-line check shows no missing certificates. Second, trace the redirect path for the root domain with and without www, plus the HTTP version, and confirm each reaches the canonical HTTPS URL in one hop. Third, review the console on your highest-traffic pages, including login, contact, and any checkout flow, and record every mixed content warning. Fourth, confirm the expiry date and note who would perform the renewal if it failed.
Record the results with dates in a shared document. Comparing this quarter's findings against last quarter's will show whether redirect chains are growing or whether a recent plugin change introduced new HTTP resources. Small, regular checks catch problems that a single expiry-date glance will never reveal, and they give your team a clear picture of what visitors actually experience when they arrive over HTTPS.