SSL Hygiene Beyond Expiry: Certificate Chains, Redirects, and Mixed Content
Most site owners learn about SSL certificates the same way: a browser warning appears, a visitor complains, or a renewal notice arrives. Treating the certificate as a calendar item is a reasonable start, but it misses a large share of the problems that make a secure connection look broken or behave unpredictably. A certificate can be valid today and still be served incorrectly, paired with an incomplete chain, or undermined by pages that load insecure resources. This article takes a different angle from simple expiry tracking. It focuses on the three layers where small sites most often go wrong: the certificate chain the server presents, the redirect path visitors follow to reach the secure version, and the mixed content that loads inside each page. The goal is a repeatable audit you can run without specialized tooling, along with the questions to put to any hosting provider before you rely on their setup.
Start With the Chain, Not the Expiry Date
A certificate is rarely trusted on its own. Browsers check the leaf certificate for your hostname, then verify that it was issued by an intermediate authority, which in turn traces back to a root that the browser already trusts. If the server fails to send the intermediate certificate, some browsers and devices will still connect, while others will show an error. This is why a site can look fine on one laptop and broken on a phone.
Check the chain by opening your site in a browser and inspecting the certificate details. Confirm that the hostname on the certificate matches every name visitors use, including the version with and without the www prefix. Then confirm that the issuing chain is complete. Online checkers and command-line tools can display the chain the server presents, and comparing that output with what you expect is a useful habit.
Ask your provider how certificates are installed and whether they handle the intermediate bundle for you. The answer determines whether a renewal could leave your chain incomplete, so get the answer in writing and test once after every renewal.
Audit the Redirect Path
Visitors reach your site through several doors: typed addresses without a scheme, bookmarks saved years ago, links from older posts, and search results that still point to HTTP. Each of these should land on one canonical HTTPS address in a single hop. Long chains, where HTTP redirects to a non-canonical HTTPS URL that then redirects again, add latency and occasionally break for crawlers and older clients.
Test the path by requesting the plain HTTP address and counting the responses. You want one permanent redirect to the preferred HTTPS URL, and that URL should return a success status without bouncing elsewhere. Check both the bare domain and the www variant. If one of them loops or lands on an error page, fix the rule at the server or in your application's configuration before anything else.
When you review your host's control panel, ask how HTTP-to-HTTPS redirects are configured and whether they are applied at the server level or inside your application. Redirects defined in two places are a common source of loops that only appear after a plan change or migration.
Find Mixed Content Before Visitors Do
Mixed content appears when a page served over HTTPS loads scripts, images, stylesheets, or frames from an HTTP address. Browsers may block active content such as scripts outright, which can break forms, carts, and interactive menus, while passive content like images may load with a warning or fail silently. The page looks secure from the address bar, yet a component inside it is not.
Small sites accumulate mixed content over time. A theme might hard-code an old asset path, a plugin might embed a video from an insecure source, or a migration might leave absolute URLs in the database. Crawl a representative set of pages, including the checkout and contact pages, and check the browser console for mixed-content messages. Replacing references with protocol-relative or HTTPS URLs and updating stored content usually resolves the problem.
Pay special attention to pages you rarely visit. Archived posts and landing pages built years ago are the most likely places for stale references to survive.
A Practical Hygiene Checklist
Run this audit quarterly, and again after any hosting change, migration, or renewal. First, confirm that the certificate covers every hostname visitors use and that the chain is complete when tested from a fresh browser session. Second, request the HTTP address and verify a single redirect to the canonical HTTPS URL for both the bare and www domains. Third, load your highest-traffic and most interactive pages with the developer console open and clear every mixed-content warning. Fourth, record the certificate's expiry date and the name of the person responsible for renewal, so that a lapse is not discovered only when a browser shows a warning.
Before you choose or renew a hosting plan, ask the provider a short set of questions. Who installs and renews certificates, and is renewal automatic? Does the installed chain include the intermediate certificates? Where are HTTP-to-HTTPS redirects configured? Can you test the final configuration on a staging copy before it goes live? Clear answers make the difference between a renewal that quietly succeeds and one that surprises you during a busy week.
SSL hygiene is not a single setting. It is a set of small checks across the certificate, the redirect path, and the content on each page. Treating all three as part of one routine keeps a secure site secure in practice, not just on the day the certificate was issued.