SSL Hygiene Starts With Asking Who Can Change Your Certificates
Most discussions of SSL hygiene focus on the certificate itself: its expiration date, its chain, its key length. Those details matter, but a surprising number of certificate incidents start somewhere else. The certificate was installed by someone who has since left the team. The renewal reminder went to an inbox nobody checks. The hosting account was set up under a personal login, and nobody else knows the password recovery path. For small sites and lean technical teams, the hardest part of SSL hygiene is often not the cryptography but the question of responsibility. This article walks through a question-driven audit you can run without any special tooling, so that renewal day becomes a routine task instead of a scramble.
Start With the Question of Ownership, Not the Expiry Date
Before you look at a single certificate, write down who is responsible for each site's HTTPS setup. Be specific. A name is more useful than a role, and a role is more useful than the word 'team.' If the answer is 'whoever handles hosting,' ask what happens when that person is on leave or changes jobs. The goal of this exercise is not to assign blame. It is to find out whether the knowledge needed to renew, replace, or troubleshoot a certificate exists in more than one place.
Ask three ownership questions for every domain and subdomain you operate. Who requested the original certificate? Who has access to the account where renewals happen? Who would be notified if a renewal failed? Many teams discover that the answers are three different people, and that one of them no longer works with the company. Write the answers in a shared document, even a simple table, and treat any blank cell as an open item to resolve before the next renewal window.
Map Certificates to the Places They Actually Live
A certificate is rarely just one file. It may be installed on a web server, referenced by a load balancer, bundled into a CDN configuration, or copied into a staging environment for testing. Each location is a place where a renewed certificate must be applied, and each one can drift out of sync. An audit should list not only the hostnames that need certificates but also every system that serves them. If you cannot say where a certificate is installed, you cannot confidently say when it will stop working.
A practical method is to walk the request path from the visitor's browser inward. Start with the public hostname, then ask what answers the connection, whether a proxy or CDN terminates TLS, and whether traffic is forwarded to an origin that presents its own certificate. Note the expiry date and the renewal owner for each hop. This exercise often reveals forgotten components, such as an old admin subdomain or a test hostname that still resolves publicly.
Audit Chains, Redirects, and Mixed Content Alongside Expiry
A certificate can be valid and still cause visible problems. An incomplete chain, where the server does not send necessary intermediate certificates, can cause errors on some clients while others work fine. This is especially confusing for small teams, because the problem may only appear on certain phones or older browsers. Check the chain with a standard command-line or browser inspection after every installation or renewal, and compare the results against what you expect.
Redirects deserve the same attention. If HTTP requests redirect to HTTPS, verify that the redirect goes to the correct hostname and does not create a chain of multiple hops. Mixed content is another common issue: a secure page that loads scripts, images, or forms over plain HTTP will trigger browser warnings even when the certificate is perfectly valid. Review the pages that handle logins and payments first, since visitors are most affected by warnings there.
Write a Renewal Checklist Someone Else Can Follow
Once you know who owns each certificate and where it lives, turn that knowledge into a checklist. The checklist should be short enough to finish in one sitting and specific enough that a colleague unfamiliar with the setup could complete it. Include the expected expiry date, the account or control panel where renewal happens, the command or interface used to install the new certificate, the verification steps, and the name of the person to contact if something unexpected appears.
Store the checklist alongside your other operational records, and review it each time a renewal is completed. Note what took longer than expected or what caused confusion. Over a few cycles, the checklist becomes an accurate description of how your site really works, rather than a memory held by one person.
A Short Pre-Renewal Checklist
Before each renewal window, answer these questions in writing. Which named person owns this certificate, and does a second person know how to access the renewal account? Which hostnames and subdomains does this certificate cover, and have any been added or retired since the last cycle? Which systems terminate TLS, including proxies and CDNs, and does each have a documented renewal step? Does the renewal notification go to a shared address that more than one person monitors? Has the certificate chain been verified from outside your network after the last installation? Are there redirects or embedded resources still using plain HTTP on pages that handle sensitive input?
If any answer is unclear, treat that as the first task. Hosting account records, payment and renewal histories, and access lists are all useful for confirming these details. The point is not to build an elaborate system but to ensure that renewal knowledge is shared, current, and written down before the day it is needed.