SSL Hygiene Audits: Questions to Ask Before Your Certificate Expires

GhostHosts editorial ·

Showing blue LED screens giving MAC address and serial number. White cables are Ethernet cables. Each server features commodity PC outlets including a serial port, VGA port, PS/2 ports, and USB ports. CC0 waiver: To the extent possible unde
Illustrative image. Derrick Coetzee from Berkeley, CA, USA · CC0 · Cropped and resized. Image source

Most SSL problems are not dramatic. A certificate quietly expires on a Sunday night, a renewal email lands in a spam folder, or a site is migrated and the old certificate chain stops matching the new server configuration. Visitors then see a browser warning, search tools may flag the domain, and form submissions or logins start failing. For small site owners and technical teams who manage a handful of domains with limited time, the most useful response is not a heroic one-time fix but a repeatable hygiene routine. This article walks through what to inspect, how to organize the work, and which questions to put to any hosting provider before you rely on them for certificate management.

Start with an inventory of every hostname

You cannot maintain certificates you have not listed. Begin by writing down every hostname that serves traffic: the apex domain, the www variant, subdomains for staging or email, and any API or admin endpoints. Many teams discover at this stage that a forgotten subdomain still resolves to a server with an old certificate. Record for each hostname the server or platform that terminates TLS, the certificate issuer, the expiry date, and the person responsible for renewal.

Keep this inventory in a plain document or spreadsheet that lives alongside your other operational records. The goal is not sophistication. It is that when someone asks which domains will need attention next month, the answer takes two minutes rather than an afternoon of log digging.

Check expiry, chain, and name coverage separately

A certificate can be technically valid and still cause failures. Expiry is the most obvious problem, but three other checks matter just as much. First, confirm that the certificate's subject or subject alternative names cover every hostname that will present it; a certificate issued for example.com alone will fail on www.example.com. Second, verify the full chain. A server that sends only the leaf certificate without the intermediate can work in some browsers and fail in others, which makes the problem hard to reproduce. Third, confirm the protocol and cipher settings still meet current expectations, because old server defaults can linger after a platform change.

Command-line tools and online checkers can report all of these details. Run the same check from more than one network location if you can, since caching and regional routing occasionally hide problems from a single vantage point.

Build a renewal calendar with lead time

Renewal should never be the day a certificate expires. Set reminders at generous intervals, such as thirty, fourteen, and seven days before expiry, and assign each reminder to a named person rather than a shared inbox nobody watches. Where possible, automate renewal on the platform that issues the certificate, then verify that automation actually ran. Automation that silently fails is worse than a manual process, because the team stops looking.

After each renewal, confirm the new certificate is served on every hostname in your inventory, not only the one you tested. Update the inventory with the new expiry date. This closing step is the one most often skipped, and it is the reason inventories go stale.

Questions to ask your hosting provider

Before choosing or staying with a hosting provider, ask plain questions about certificates. Who issues the certificate on each plan, and can you install a certificate you obtained elsewhere? How is renewal handled, and what notice do you receive if it fails? Can you see the expiry date and the full chain from your control panel? What happens to certificates when you migrate between plan types, such as moving from shared hosting to a VPS? Who is responsible for configuring the server's TLS settings, and can you change them?

Write the answers down and compare them across providers. A provider's marketing copy may not address these operational details, so the answers you receive directly are more useful than general assurances. Where a provider cannot answer clearly, treat that as information for your decision.

A short hygiene checklist

Use this list as a recurring routine, perhaps monthly for each domain. Confirm every hostname in the inventory still resolves and presents a certificate. Check the expiry date against your calendar and note any certificate due within sixty days. Verify that the certificate covers all names it must serve. Confirm the full chain is sent. Review protocol and cipher settings after any server or platform change. Record the date of the check and the initials of the person who performed it.

A routine like this takes less time than a single outage investigation, and it turns certificate management from an emergency into an ordinary task. For small teams, that consistency matters more than any particular tool.