SSL Hygiene Beyond the Expiry Date: Chains, Redirects, and Mixed Content
Most site owners think about SSL in one dimension: is the padlock showing, and when does the certificate expire? Those questions matter, but they miss a range of problems that quietly erode trust and sometimes break features. A certificate can be valid and still be served incorrectly. A site can load over HTTPS and still pull in assets over plain HTTP. A redirect can send visitors through three hops before they arrive. This article offers a method for auditing SSL hygiene that goes past the expiry date, written for site owners and small technical teams who manage their own sites and need a repeatable routine.
Start with a complete inventory of hostnames
Before you inspect anything, list every hostname that serves your content. That includes the apex domain, the www variant, subdomains for blogs, shops, or help centers, and any staging or preview hosts that are reachable from the public internet. Small teams often discover forgotten hostnames during this step, and each one needs its own certificate coverage or a deliberate decision to retire it.
Record for each hostname who requested its certificate, where it is installed, and what process renews it. If the answer to the last question is "someone remembers to do it," treat that as a risk to document rather than a process to trust. An inventory turns an abstract concern into a short list you can check against.
Verify the full certificate chain
A certificate is only half of what a browser needs. The server should also present intermediate certificates that connect your certificate to a trusted root. When the chain is incomplete, some browsers and clients fail to validate the connection even though the leaf certificate looks correct in a quick check. This failure can appear only on certain devices, which makes it hard to diagnose from a single desktop browser.
Use an online chain checker or a command-line tool that displays the presented chain, and confirm that the intermediates are in the order the server sends them. Also check that the leaf certificate's subject or subject alternative names cover every hostname from your inventory. A certificate that covers the apex domain but not www will look fine to someone who only types the apex address.
Audit redirects as part of the security path
Redirects are where HTTP and HTTPS interact, and they are often configured in several places: the web server, a CMS plugin, a content delivery layer if you use one, and sometimes application code. Each layer can add a hop. A visitor who types the plain domain may go from HTTP to HTTPS, then to the www variant, then to a trailing-slash version, before reaching the page. Each hop adds latency and a chance for misconfiguration.
Test a few representative entry points: the bare domain over HTTP, the bare domain over HTTPS, the www variant, and a deep link to an old article or product page. Count the hops and confirm each one ends at a single canonical HTTPS address. Loops, redirects to hostnames without valid certificates, and redirects that drop the path are the failures to look for first.
Find mixed content before your visitors do
Mixed content appears when an HTTPS page loads scripts, stylesheets, images, fonts, or embeds from an HTTP address. Browsers may block active mixed content such as scripts and stylesheets, which can break layouts or features, and they may warn about passive content such as images. Either outcome damages the impression of a secure site.
Audit by loading key pages with the browser developer tools open and filtering for requests that use the http scheme. Pay attention to content injected by themes, old plugins, hard-coded links in templates, and third-party widgets. Replace hard-coded HTTP references with HTTPS or with protocol-relative paths where appropriate, and remove embeds that no longer serve a purpose. Re-test after each change, because a fix on one page template often leaves the same problem on others.
A short checklist and the questions to ask your host
Run this routine on a schedule that matches how often your site changes, and record the results so the next audit has a baseline. The checklist: confirm every hostname in your inventory is covered by a valid certificate; verify the full chain is served in the correct order; confirm the apex, www, and HTTP entry points each reach one canonical HTTPS address within a small number of hops; scan key templates and pages for HTTP resources; and confirm the expiry date and renewal owner for each certificate.
When you evaluate or review a hosting provider, ask specific questions rather than assuming. Which certificate types are available and how are they installed? Who is responsible for renewal, and how will you be notified before expiry? Can you see the certificate and chain details from your account? How are redirects configured, and can you change them without a support ticket? Does the plan you are considering allow the configuration your audit requires? Write down the answers, because the right provider is the one whose answers match your actual needs, and only you can verify that against your site.
SSL hygiene is less about a single renewal date and more about a set of small, checkable facts. Inventory the hostnames, verify the chain, trace the redirects, and remove mixed content. Doing this on a routine basis turns security from a surprise into a maintenance habit.