When an automatic renewal does not show up

Why a shorter lifetime changes the habit

A long-lived certificate can be tracked on a calendar. A certificate that lasts about 90 days is replaced several times a year, often by an automated client. A certificate that lasts about 64 days, or about 47 days, turns over faster still. The dangerous moment is not the issuance. It is the gap between a successful issuance and a server that is still offering the previous certificate, or a load balancer that was not reloaded, or a second host that the client does not know about. It is also the quiet case: the client failed, no new certificate was logged, and the expiry email you used to receive never arrived.

Certificate Transparency records the issuance. If the certificate is publicly trusted, it should appear in the logs the sources CertLantern reads. The not-after date on that row is when that issuance expires. The next renewal is a different row, with its own dates, even when the names match. CertLantern stores both once it has seen them. It does not collapse them into a single health bit.

What the logs will and will not show

You will see names, issuer, and expiry for issuances the log source returns. Subdomains of a domain you watch are included when the query asks for them, which the public checker and the demo both do. You will not see a private certificate that never went to a public log. You may miss a certificate that expired before the first successful read, because the primary source lists unexpired issuances. After CertLantern has stored a row, the row stays past expiry.

A renewal that was logged and never installed still looks healthy in a pure log view: there is a certificate with a later not-after. That is why the inventory alone is not a deployment check. The public checker is explicit about this. It shows the page of logs and a call to action to monitor the domain. It never opens a socket to the host to see which certificate answers.

Automated clients can also fail quietly. The previous certificate remains served until it expires, and the logs simply do not gain a new row. Waiting for an email from the certificate authority does not help when that mail is filtered, sent to someone who left, or no longer sent at all. CertLantern measures about two-thirds of the certificate's own lifetime. At that point, if the logs still have no newer certificate with the same set of names, Pro and Team are alerted once. That is day 60 of a 90-day certificate, about day 43 of a 64-day certificate, and about day 31 of a 47-day certificate. A fixed 30-day reminder is a different event and stays available. Pre-certificates that were never finalized do not count as the newer certificate. The alert uses the same daily sending caps as every other alert.

How to tell a logged renewal from a deployed one

Add the hostname and port under the domain on an account. The hostname has to belong to that domain. Implicit TLS is allowed on a short list of ports, and STARTTLS on another short list. A container completes the handshake and stores the leaf and chain. DNS is resolved inside that container. Private, loopback, link-local, and shared addresses are refused, so this is not a way to scan an internal network.

The endpoint page compares the name set, and when it can, fingerprint, serial, or public key, with the stored log rows. A newer row for that same set of names counts as not deployed only after about 48 hours from its not-before. A row that shares one name and not the rest does not count. If the served certificate matches and no newer row is past that grace period, the page says they match. Free includes a few manual live checks and does not schedule them. Pro and Team check each endpoint once a day. CertLantern still does not install the newer certificate.

Use the public checker first if you only want the logged dates for a name. Use the account when those dates should be kept, and add the endpoint when you need the deployment fact. The live demo shows a logs-only inventory for an example domain from public Certificate Transparency logs. It is not a statement about how that organization renews certificates.

A renewal checklist that stays small

Look the apex up and note the soonest not-after and the issuer. If several names expire on different days, the automation is not covering every name evenly. Add the domain to an account so the next renewal has a place to land even if you are not on the checker that afternoon. The checker cache lasts about a day and then only refreshes when someone asks again, inside the lookup cap.

Leave the renewal-overdue alert on. It is the one that scales with a 90-day, 64-day, or 47-day certificate. Email at 30, 14, 7, and 1 days is still there for the final approach. Add Slack on Team if the reminder should hit a channel instead of, or as well as, a mailbox. Then probe the host that clients actually reach, which may be a CDN name or a load balancer rather than the origin you renewed.

Questions

Look up a domain or start monitoring

The public checker reads one page of Certificate Transparency and does not connect to the domain. An account keeps the inventory. Alerts, when you want them, start on a paid plan.

Check a certificate Create an account

See pricing for what Free, Pro, and Team include. The live demo is an example domain from public Certificate Transparency logs. Related: Renewed but not deployed · SSL certificate expiry monitoring · How expiry rows stay after the date.