SSL certificate renewal checker.
Public SSL certificates are getting shorter: 200 days now, 100 days from 15 March 2027, 47 days from 15 March 2029. A certificate renewed by hand once a year will need renewing every month. This tool checks the certificate on every address your name resolves to, and asks your CA when it wants that certificate renewed, then tells you whether renewal is automated and what will break first.
About this tool
This server looks up every public address the name resolves to and opens a TLS connection to each, so a renewal that reached some servers and not others shows up as two different certificates. If the issuing CA speaks ACME, it then asks the CA's own renewal information endpoint (ARI) when the CA wants that certificate replaced. That is the only call to anything other than your servers, and it goes to the CA that issued the certificate, the same way the chain checker fetches a missing intermediate from the CA. No lookup service sits in between.
Whether renewal is automated cannot be seen from outside, only inferred, and every inference is stated in the findings with its evidence. A certificate of 100 days or less is almost always renewed by a client, because nobody keeps doing that by hand. A long-lived certificate from a commercial CA is reported as probably manual, because it usually is, and the finding says that ACME with an account key is possible. A newer certificate already being served by another address is direct evidence that a renewal ran.
The certificate lifetime schedule
The CA/Browser Forum, the body of CAs and browser makers that sets the rules for public certificates, passed ballot SC-081 in April 2025. It cuts the maximum lifetime of a publicly trusted TLS certificate in three steps, and shortens how long a CA may reuse a domain validation alongside it. A certificate issued before a step stays valid until it expires; the limit applies at issuance.
| Issued on or after | Maximum lifetime | Domain validation reuse | Renewals a year |
|---|---|---|---|
| Before 15 March 2026 | 398 days | 398 days | 1 or 2 |
| 15 March 2026 | 200 days | 200 days | about 3 |
| 15 March 2027 | 100 days | 100 days | about 6 |
| 15 March 2029 | 47 days | 10 days | about 12 |
"Renewals a year" assumes the normal habit of renewing with a third of the lifetime left. The validation column matters as much as the lifetime: from 2029, proving you control the domain has to be redone every ten days, so a process that relies on doing it once and reusing it all year stops working. The full explanation, including what changes for private CAs (nothing) and for load balancers and appliances (a lot), is in 47-day SSL certificates: the timeline and how to get ready.
What the renewal checker reports
| Check | What it tells you |
|---|---|
| Certificate lifetime | How long the certificate being served was issued for, and which step of the schedule that already breaks. |
| Renewal automation | Managed, probably automated, probably manual or unknown, with the evidence: the issuing CA, the lifetime, and anything the other addresses show. |
| Renewal timing | Days left against the lifetime. Under a third left with no address serving a replacement means an ACME client that should have run has not. |
| Deployment | One address serves a newer certificate for the same names while another still serves the old one, which is due for replacement. The renewal worked and did not reach every server. This is the failure shorter lifetimes make frequent. |
| ARI renewal window | When the CA wants this certificate replaced. A window moved early means the CA intends to revoke it. |
| Edges | Whether every address answers and serves the same certificate. Different certificates are flagged, and explained when it is a large site staggering renewals on purpose. |
| Client authentication | Whether the certificate carries the clientAuth usage that public CAs dropped in 2026, which breaks mutual TLS that leaned on it. |
ACME Renewal Information (ARI)
ARI, standardised as RFC 9773 in 2025, lets an ACME CA tell clients when to renew each certificate. A client asks the CA's renewalInfo endpoint about a certificate it holds, using an identifier built from the issuer's key ID and the serial number, and gets back a suggested window. Normally the window sits about two thirds of the way through the certificate's life, and the CA spreads it out so that millions of clients do not all renew at the same moment.
The reason it exists is revocation. When a CA finds a problem with certificates it has issued, the rules give it as little as 24 hours to revoke them. Before ARI that meant emailing subscribers and hoping. With ARI the CA moves the window to now, every ARI-aware client renews on its next check, and the revocation happens to certificates nobody is using any more. Let's Encrypt, Google Trust Services, ZeroSSL, Sectigo and SSL.com all publish it; certbot 4.1 and later, Caddy and lego follow it. More in ACME Renewal Information (ARI) explained.
Common renewal problems
- Renewed, not reloaded: certbot wrote a new file and nginx still has the old one in memory. Add
--deploy-hook "systemctl reload nginx", or--reloadcmdfor acme.sh. - Renewed on one box: the ACME client runs on one server and the certificate is copied to the others by hand, or not at all. Shows up here as two certificates across the addresses. Behind a load balancer with one public address, check each backend from inside.
- The appliance cannot do ACME: older load balancers, firewalls and NAS boxes take a certificate uploaded through a web form. These are the ones 47-day certificates break. Terminate TLS in front of them, use the vendor's ACME support if it has one, or script the upload against its API.
- Pinned in a client: a mobile app or partner integration pins the leaf certificate or its key. Every renewal breaks it. Pin the intermediate or the CA's key, or stop pinning.
- One CA, no fallback: the CAA record allows a single CA and the ACME client has no second one configured. A few days' outage at 47-day lifetimes is a real risk.
Examples
- letsencrypt.org: a 90-day ACME certificate with an ARI window
- www.google.com: Google Trust Services, automated, with an explanation URL
- kirkdiamond.com: Cloudflare, with certificates from two CAs
- example.com: a commercial certificate
From the command line
curl "kirkdiamond.com/tools/cert-renewal?host=example.com" gives the verdict, the schedule, the findings and every address as plain text; add &format=json for structured output with ready, automation ari and edges, and &port= for a port other than 443. Only public hosts can be checked. The certificate's identifier (its issuer key ID and serial number, both public) is sent to the issuing CA's ARI endpoint; nothing else leaves this server, and nothing about the lookup is stored here.
Every parameter, the JSON field names and rate limits are in the API and curl reference.