SSL Hygiene Questions: Auditing Your Own Certificate Estate
Most small site owners think about SSL once a year, usually when a browser warning appears or an email reminder arrives. By then the damage is already visible. A healthier approach treats certificate hygiene as a standing inventory task rather than an emergency. This article offers a method for building that inventory, the questions to ask about each entry, and a checklist you can run without specialized tooling. The goal is not to memorize protocol details. It is to know, at any moment, which names your site answers to, who can renew each certificate, and what a visitor's browser actually sees when it connects.
Start With a Hostname Inventory, Not a Certificate List
Certificate audits often begin with the certificates you already know about, which is the wrong starting point. Certificates are attached to hostnames, and hostnames accumulate quietly. A marketing subdomain created for a campaign, a staging name pointed at a test directory, a legacy address that still receives traffic from old links: each of these can serve a certificate that nobody on the current team remembers requesting.
Begin by listing every hostname that resolves to your site or to anything you operate. Include the apex domain, the www variant, subdomains used for mail, forms, documentation, or media, and any staging or preview addresses. Check your DNS records directly rather than trusting memory. For each hostname, note the purpose, the person or role responsible for it, and whether it is still in use. Hostnames that serve no current purpose are candidates for removal rather than renewal.
Once you have the list, record what each hostname presents to a visitor. Open each one in a private browser window and inspect the certificate details. Note the issuer, the subject names the certificate covers, and the expiry date. A certificate that covers only one name will fail on a sibling hostname, and a wildcard certificate may cover more than you expect. The inventory should reflect what is actually served, because configuration and documentation drift apart over time.
Ask Who Holds Renewal Responsibility for Each Certificate
A certificate that expires without anyone noticing is usually a question of ownership, not technical difficulty. For every entry in your inventory, answer three questions: who requested this certificate, where is renewal configured, and who receives the warning if renewal fails? If the answer to any of these is nobody, you have found your first real problem.
Renewal can be automated, manual, or a mix of both. Automated renewal depends on the account, domain validation method, and server configuration staying intact through staff changes and plan migrations. Manual renewal depends on a calendar entry and a person who still has access. Neither is wrong, but each needs a named owner and a documented fallback. Write down which method applies to each certificate and where the credentials or access for it live.
Pay attention to whether notifications go to a personal inbox. Warning emails sent to someone who has left the team are a common way certificates lapse. Route expiry notices to a shared address that more than one person monitors, and confirm that the address works by checking that it receives a test message.
Verify the Chain, Not Just the Leaf
A certificate's expiry date is only one part of its health. Browsers validate a chain of certificates from the server's leaf certificate up to a trusted root. If an intermediate certificate is missing from the server configuration, some clients will fail to connect even though the leaf certificate itself is valid and unexpired. These failures can be intermittent, appearing on some devices and networks but not others, which makes them difficult to diagnose from a single test.
When auditing, check that the server presents the complete chain it is supposed to present. Use an online or command-line chain inspection tool, or inspect the certificate details in a browser that shows the path. Confirm that the chain ends at a root that current browsers trust. If you recently changed hosting providers or certificate sources, the chain is the first thing to re-verify, because intermediates are the component most often left out during a migration.
Also confirm that the certificate's subject names match the hostnames you use. A mismatch between the name in the browser address bar and the names listed on the certificate triggers warnings that look like expiry problems but have a different cause.
Follow Redirects and Mixed Content Through the Whole Path
A visitor rarely loads one address cleanly from start to finish. An old link may redirect from an unencrypted address to an encrypted one, which may redirect again from a legacy hostname to the canonical domain. Each hop is a place where a certificate can fail or where traffic can be served unencrypted. Trace the full path for your most important entry points, including links from email campaigns, search results, and bookmarks you know about.
Mixed content is the other common gap. A page loaded over an encrypted connection may still request images, scripts, stylesheets, or embedded frames from unencrypted addresses. Browsers often block or warn about these resources, and the result looks broken to visitors even though the main certificate is valid. Review your templates, theme settings, and any third-party embeds for hardcoded unencrypted URLs.
Check whether the redirect from unencrypted to encrypted traffic is permanent and whether it exists for every hostname you listed in your inventory. A redirect that works for the main domain but not for a forgotten subdomain is a frequent source of complaints that take time to trace back.
A Practical Audit Checklist for Small Teams
Run this audit on a fixed schedule, such as the first week of each quarter, and again after any change to DNS, hosting, or site structure. Keep the results in a shared document so the history is visible.
First, confirm that your hostname inventory matches your DNS records, and mark any name without a current purpose for removal. Second, for each hostname, record the certificate issuer, covered names, and expiry date. Third, confirm the renewal method, the named owner, and the notification address, and test that the notification address receives mail. Fourth, verify that the full chain is served and terminates at a trusted root. Fifth, trace redirects from unencrypted and legacy addresses to the canonical encrypted address. Sixth, scan key pages for mixed-content requests and fix hardcoded unencrypted links. Seventh, update the owner list if anyone has joined or left the team since the last audit.
When you finish, write down the date, the people involved, and any items still open. The value of this routine is less in any single pass than in the record it builds, which lets a new team member answer the question of what protects this site and who keeps it working. Hosting arrangements, plan types, and provider policies differ, so when a question depends on your specific account or provider terms, check that provider's own documentation or support channel rather than assuming.