How to keep SSL certificates current
Published . Updated .
This is a checklist for the certificates on client sites you already look after. It is about public TLS certificates on hostnames people type, including the ones nobody renewed last year.
Inventory every hostname, record who issues and renews each certificate, automate renewal with ACME where you can, and alert well before expiry, for example 60 days and again at 15. Public certificate lifetimes drop to 200 days in 2026, 100 in 2027, and 47 in 2029, so manual renewal stops scaling.
A certificate is a dated credential that a browser uses to decide whether the name in the address bar matches the server it reached. When it expires, or when the chain is wrong, the browser shows a warning and many clients will not click through. The site can still be "up" on a server you can SSH to. The visitor does not care.
Why do certificates still expire?
Someone installed them by hand. A firewall, a mail appliance, a camera portal, or a hosting panel holds a file that no automation can see. A subdomain was added for a staging site and never joined the renewal job. The person who knew the panel password left. The card on the certificate vendor expired. Any one of those is enough.
Shorter lifetimes make the same habits fail more often. The CA/Browser Forum Baseline Requirements, section 6.3.2, set the maximum validity of a subscriber certificate by the day it is issued. Issued before 15 March 2026, the maximum is 398 days. Issued on or after 15 March 2026 and before 15 March 2027, the maximum is 200 days. Issued on or after 15 March 2027 and before 15 March 2029, the maximum is 100 days. Issued on or after 15 March 2029, the maximum is 47 days. A day in that text is 86,400 seconds. Those are maximums. Your vendor can issue something shorter.
That schedule is why a spreadsheet you update once a year stops being a system. Forty-seven days is about six renewals a year per hostname if you ride the maximum, and you should renew earlier than the maximum so a failed job still has time.
What belongs on the inventory?
Write one row per hostname, not one row per client. A client with a website, a webmail name, and a remote-access portal has three certificates even when one vendor bills them as one "site."
For each hostname record the name people use, the name on the certificate, the issuer, the expiry date if you can read it, who renews it, where the files live, and whether renewal is automatic. Note the account that can buy or reissue it, and a second person who can get into that account. If the certificate is on a panel you do not control, say so in the row. An unknown owner is the row you will regret.
Then walk the names that are easy to forget. www and the apex. mail, remote, vpn, portal, autodiscover, and any name a phone or a scanner uses. A certificate can be valid for a name the website no longer links. It still expires, and something still presents it.
Use this list when you take a client on, and again when you add a hostname.
- List every public hostname, including the ones that only staff use.
- Record issuer, expiry, renewal owner, and where the certificate is installed.
- Mark which names renew with ACME and which ones a person still touches.
- Name a second person for the vendor account and the DNS account.
- Set two warnings, at about 60 days and again at about 15, to a mailbox someone reads.
- After each renewal, confirm the new certificate from outside the server.
Where does ACME help, and where does it stall?
ACME, described in RFC 8555, is the protocol a client uses to ask a certificate authority for a certificate and to prove control of the name. When it works, renewal is a job, not a calendar reminder. Let's Encrypt and other authorities that speak ACME are the usual path for a normal website on a server you administer.
It stalls in familiar places. The HTTP challenge cannot see a site that is only on an internal name. The DNS challenge needs an API token for the DNS host, and that token is a key to the whole zone, so store it like one. A panel that "includes SSL" may renew the certificate it shows and leave an old file on a load balancer. A device with a web upload form will not run a client. For those, the inventory row says "manual," and the 60-day warning is the system.
If a challenge fails, the old certificate keeps working until it expires. A green dashboard last month is not a renewal. Check the date on the certificate the public name presents, not the date in the vendor email you might have missed.
Who should hear about expiry, and when?
Sixty days is enough time to find a panel password and to reissue by hand. Fifteen days is enough time to treat it as this week's work if the first warning was ignored. Pick the mailbox your on-call already watches. A warning that lands in a shared inbox nobody owns is the same as no warning.
Match the warning to the person who can act. The tech who renews the appliance should get the 15-day note. The owner can get the 60-day note if you want a second pair of eyes. Do not page the whole company for a certificate that is two months out. Do not bury a 15-day warning in a weekly digest.
The warning has to say the hostname, the expiry date, and where to renew it. "Certificate expiring" with no name is how a tech renews the wrong site.
What is the difference between an outside check and a check on the server?
A check on the server reads the file you think is installed. A check from outside reads the certificate the hostname actually presents. Those differ when a proxy, a CDN, or a second server is in front. Renewing the file on the origin does not change what a visitor sees if the edge is serving its own certificate.
Check from a network that is not the server's. Note the issuer and the names on the certificate. If you expected your origin certificate and you see the CDN's, write that down. You then have two rows: the edge certificate, which the CDN may renew, and the origin certificate, which still expires and still matters the day someone turns the proxy off or connects directly.
An edge certificate can be valid while the origin certificate is expired. The site looks fine to the public and fails the moment the proxy is bypassed. An origin certificate can be valid while the edge certificate is the one about to expire. Watching only the server you SSH to misses that.
What should you do with the list?
Build the inventory, automate the names that can use ACME, and put the manual names on a 60-day and 15-day warning that names a person. Re-read the certificate from outside after every renewal. A domain that expires takes the certificate's name with it, which is why the domain expiration note sits next to this one. The glossary has the short definitions if you need them in a client email.
How The Watchbill helps
The Watchbill looks at the certificate a site actually presents to visitors, as part of every site check. It reports whether that certificate was trusted, so a broken chain shows up without anyone opening a browser. If the TLS connection fails outright, the site is marked down once two consecutive minutes agree, and you get an email.
It isn't a replacement for the inventory on this page. The checker often can't read a certificate's expiry date, and it doesn't send warnings at 60 or 15 days. When it can read a date, it marks a certificate inside 30 days as soon. Keep your 60-day and 15-day reminders in the inventory, aimed at the person who renews each name, and use The Watchbill as the outside check that confirms each public hostname is presenting a certificate browsers trust. You can add your clients' sites with a free account.
Sources
- CA/Browser Forum Baseline Requirements, section 6.3.2, certificate operational periods. Accessed October 10, 2026.
- RFC 8555, Automatic Certificate Management Environment (ACME). Accessed October 10, 2026.