SSL Hygiene Without the Expiry Panic: A Monthly Audit Method
Most small site owners think about SSL in one moment: the day a browser warns that a certificate has expired. By then the work is already reactive. A better habit is a short recurring audit that looks at more than the expiry date. A certificate can be valid on paper and still fail visitors because a subdomain was never covered, an intermediate certificate is missing from the served chain, or an old redirect sends users through an insecure address on the way in. This article describes a method you can run once a month with a notes file and a few browser tools, without needing a dedicated security team. It also lists the questions to ask about your hosting account, since some answers depend on how your provider handles certificates rather than on the certificate alone.
Start With an Inventory of Names, Not Certificates
Auditing from the certificate outward tends to miss things. Start instead from the list of hostnames that people actually use: the apex domain, the www variant, any blog or shop subdomain, staging environments that someone may have shared with a client, and old hostnames still referenced in email signatures or printed materials. Write each one in a single table with columns for purpose, who requested it, and where it is linked from.
This inventory matters because a certificate only protects the names listed on it. A certificate that covers example.com may not cover www.example.com unless it was issued that way, and a wildcard certificate covers one level of subdomain but not every depth. When you compare your inventory against the names each certificate claims, mismatches become visible. A hostname with no matching certificate is a visitor warning waiting to happen, and a certificate covering names nobody uses is clutter that complicates future renewals.
Check the Chain as Visitors Receive It
A server presents its own certificate plus any intermediate certificates needed to connect it to a trusted root. When the intermediates are missing or ordered incorrectly, some browsers and devices fail to validate the connection while others succeed, which makes the problem hard to reproduce from a single desktop browser. Use an online certificate inspection tool or the command-line openssl client to view the chain the server actually sends, and confirm it ends at a trusted root and that every link is present.
Record the result each month along with the certificate's issuer and expiry date. A change in issuer that you did not initiate is worth investigating, because it can indicate that a configuration was altered during a maintenance window or that a different service is now handling connections for that name.
Follow Redirects From the Outside
Many security problems on small sites are not in the certificate at all. They live in the path visitors take to reach it. A bookmark or an old external link may point to a plain HTTP address that redirects to HTTPS, and that first request travels unencrypted. Test your most-linked addresses in a private browser window and watch the sequence of redirects. Ideally each hop moves directly to the final HTTPS destination without bouncing through a second or third URL.
Also check for mixed content. A page loaded over HTTPS that pulls scripts, stylesheets, or images from HTTP addresses will trigger warnings or blocked resources. Browser developer tools list these requests in the console. Fix them by updating the references to HTTPS or removing the outdated resource.
A Monthly Checklist You Can Run in Under An Hour
Work through these items in order and record the date and results. First, confirm the hostname inventory is current and note any new subdomains added since last month. Second, for each hostname, verify the certificate covers it, the expiry date is at least several weeks away, and the chain is complete. Third, load the apex and www addresses over HTTP and HTTPS, counting redirect hops and confirming the final destination uses HTTPS. Fourth, open the homepage, one interior page, and any login or form page, then check the browser console for mixed-content warnings. Fifth, note any certificate whose issuer or validity dates changed without your involvement.
Keep the results in a plain document or spreadsheet so that comparisons are easy. A single missing item in one month is much easier to trace when the previous month's record shows everything was correct.
Questions to Ask Your Hosting Provider
Some parts of SSL hygiene depend on the hosting arrangement rather than on your own configuration. Before your next renewal or plan change, ask the provider how certificates are issued and renewed on your account, whether that process is automatic or manual, and who receives notifications when it fails. Ask whether certificates are installed per domain or shared across an account, and what happens to those certificates if you move a site to another server or change plan types.
Also ask which hostnames are covered by default and how you add a new subdomain to certificate coverage. Clarify who holds the account credentials needed to change certificate settings, since a certificate problem is much slower to resolve when nobody on your team can log in. Write the answers down next to your inventory so that the next audit starts from documented facts rather than memory.