SSL Hygiene Questions for Small Sites: Checking Chains, Redirects, and Hostnames
Most small site owners think about SSL only when a browser warning appears or a renewal reminder lands in an inbox. That reactive pattern works until a certificate expires on a weekend, a subdomain nobody remembered starts throwing errors, or a redirect loop sends visitors in circles. SSL hygiene is the quieter discipline of checking the whole path a visitor's connection takes, not just the date printed on a certificate. This article lays out a method your team can run without specialist tooling, along with the questions worth putting to your hosting provider before you rely on any particular setup.
Start With an Inventory of Hostnames
A certificate only protects the names it was issued for. Before you judge whether your SSL setup is healthy, you need a complete list of every hostname that serves content to visitors. For a small site this usually includes the bare domain, the www variant, any subdomains for blogs, shops, or member areas, and sometimes older hostnames left over from previous redesigns or migrations. Write them all down in one place, even the ones you think are retired.
Next, note where each hostname points. Some names may resolve to your primary hosting account, others to a third-party service, a landing page builder, or a staging environment that was never taken offline. Each one needs to be accounted for, because a hostname that serves a browser warning undermines trust across the whole domain. Ask yourself who created each record and whether anyone currently checks it.
A practical habit is to keep the inventory in a shared document with four columns: hostname, purpose, where it resolves, and who owns it. Update the document whenever you add a subdomain or change a DNS record. This simple artifact turns a vague sense that 'our SSL is probably fine' into something you can verify line by line.
Read the Certificate Chain, Not Just the Expiry Date
Browsers do not trust a server certificate in isolation. They trust it because it chains back to a root certificate authority their operating system or browser already holds, usually through one or more intermediate certificates the server is expected to present. A certificate can be valid on its own date range and still produce errors if the intermediate is missing or misconfigured.
When you audit a certificate, check four things: the subject names it covers, the issuer, the validity window, and whether the presented chain is complete. Most browsers let you view the certificate details from the padlock menu, and many free command-line and web-based checkers display the full chain. Look for a chain that terminates at a trusted root and does not include expired intermediates. If you see the warning 'incomplete chain' in any tool output, that is a configuration problem to raise with whoever manages your server.
Keep in mind that chain problems often appear after a certificate is renewed or replaced. A new leaf certificate may be installed without the matching intermediate bundle, and the site looks fine in some browsers but fails in older devices. Testing from more than one device or client is a cheap way to catch this before visitors report it.
Audit Redirects and Mixed Content Together
A site can have a perfectly valid certificate and still leak trust through its redirects and embedded resources. Trace what happens when a visitor types the plain http address, the www variant, and the bare domain. Each should land on one canonical HTTPS address in a single hop where possible. Long redirect chains slow pages down, and loops can make the site unreachable for some visitors while others see nothing wrong.
Mixed content is the second half of this check. When an HTTPS page loads scripts, images, stylesheets, or frames over plain HTTP, browsers either block those resources or warn that the page is only partly secure. Load your key pages and open the browser console to look for mixed-content messages. Pay particular attention to older themes, plugins, and copy-pasted embed codes, which often hard-code http URLs that were correct years ago.
A useful exercise is to write down the three or four most important page types on your site, such as the homepage, a contact form, a product or service page, and a login screen. Run the redirect trace and console check on each. Results that differ between page types usually point to a template or plugin rather than the server configuration itself, which narrows down where to fix things.
Questions to Ask Your Hosting Provider
Your host shapes how SSL is installed, renewed, and troubleshot, so it is reasonable to ask direct questions before you depend on a plan. Start with how certificates are provisioned on the accounts you are considering: whether the host installs them for you, whether you supply your own, and what the process looks like for adding a new hostname. Ask how the chain is delivered and whether intermediate bundles are included automatically.
Next, ask about renewal responsibility in plain terms. Who receives expiry notices, which email address they go to, and what happens if the notice goes unanswered. Confirm whether renewal is handled by the host, by an automated client, or manually by you. Do not assume; get the answer in writing if it matters to your team. Equally important, ask what support channel you use when a certificate fails at an inconvenient hour, and what information the support team will need from you.
Finally, ask whether the hostnames you need can be covered under the plan you are considering, and how changes to DNS records interact with certificate issuance. Some setups require records to point at the server before a certificate can be validated, which affects migration planning. Writing these answers down alongside your hostname inventory gives you a reference the next time something needs attention.
A Quarterly Checklist You Can Actually Run
Turn the above into a routine rather than a one-time project. Once a quarter, work through a short checklist: confirm the hostname inventory matches what is live; check each hostname's certificate expiry date and chain completeness; trace redirects from http, www, and bare-domain entry points; load your key page types and clear mixed-content warnings; and verify that the renewal contact on file is still someone who reads email.
Record the date, the findings, and any changes in a simple log. Over time this log shows patterns, such as a particular subdomain that always needs attention or a plugin that keeps reintroducing http links. It also gives a new team member something concrete to follow when responsibility changes hands.
SSL hygiene is less about heroics than about consistency. A small team that inventories its hostnames, reads its chains, traces its redirects, and asks its host the right questions will rarely be surprised by a certificate problem. The goal is not perfection but knowing, at any given moment, what visitors are actually being served and who is responsible for keeping it correct.