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.

Checked 4 addresses · kirkdiamond.com from Google Trust Services JSON · text

Verdict Ready for 47-day certificates: renewal looks automated ready

Renewal probably automated Google Trust Services offers ACME

Lifetime 90 days 56 days left

CA renewal window 2026-11-13 to 2026-11-14 ahead

Your certificate against the schedule maximum lifetime, days

This certificate 90
15 March 2026 (in force) 200
Automated renewal absorbs it: about 3 renewals a year, none of them by hand.
15 March 2027 100
Automated renewal absorbs it: about 6 renewals a year, none of them by hand.
15 March 2029 47
Automated renewal absorbs it: about 12 renewals a year, none of them by hand.

Findings

pass

Certificate lifetime 90 days

Already within the 100-day limit that applies from 15 March 2027.
pass

Renewal automation probably automated

A 90-day certificate from Google Trust Services. Nobody renews certificates this short by hand for long, so a client is almost certainly doing it.
pass

Renewal timing 56 of 90 days left

No renewal is due yet.
pass

ARI renewal window 2026-11-13 to 2026-11-14

Google Trust Services publishes when it wants this certificate renewed, and an ARI-aware ACME client follows it. That is how a CA gets millions of certificates replaced in hours when it has to revoke them.
pass

Edges 2 addresses, one certificate

Every address the name resolves to serves the same certificate, so the last renewal reached all of them.

The CA's explanation for this window: https://status.pki.goog/

Every address for kirkdiamond.com 4 in DNS · 1 certificate

Address	Issued	Expires	CA	SHA-256
172.67.128.220:443	2026-09-16	2026-12-15 this report	Google Trust Services	0E0160977BDACACB
104.21.2.69:443	2026-09-16	2026-12-15 this report	Google Trust Services	0E0160977BDACACB
[2606:4700:3030::6815:245]:443	not checked: this server has no IPv6 route
[2606:4700:3030::ac43:80dc]:443	not checked: this server has no IPv6 route

When the addresses disagree, the report is about the certificate that runs out first, because that is the one that breaks first.

Reproduce it from any machine with dig and OpenSSL:

for ip in $(dig +short kirkdiamond.com A kirkdiamond.com AAAA); do echo "$ip $(echo | openssl s_client -connect "[$ip]:443" -servername kirkdiamond.com 2>/dev/null | openssl x509 -noout -enddate)"; done

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 --reloadcmd for 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.