Cert Lifetime Lint - 200/100/47-Day TLS Audit

Four lines in one cert-manager manifest are all it takes to make a production certificate un-issuable, and the platform engineer who owns that file usually does not learn it until a renewal quietly fails.

Here is the manifest. Every line in it was correct in 2025.

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: api-prod-tls
spec:
  secretName: api-prod-tls
  duration: 8760h        # 365 days
  renewBefore: 2400h     # 100 days
  dnsNames:
    - api.example.com

Two of those lines are now wrong, and the reason is a date rather than a bug.

On 11 April 2025 the CA/Browser Forum passed Ballot SC-081v3 by 29 votes to zero, with Apple, Google, Mozilla and Microsoft all in favour. It puts the maximum lifetime of a publicly trusted TLS certificate on a ratchet:

The first step is already behind us. duration: 8760h is 365 days, which no public CA has been able to issue since 15 March 2026. renewBefore: 2400h is 100 days, which will be longer than the entire certificate from 15 March 2027 - and a renewBefore longer than the certificate makes cert-manager renew in a loop.

The second half of the problem is the renewal cadence, and it moves on a different calendar. Let's Encrypt switched its tlsserver profile to 45-day certificates on 13 May 2026, made a 160-hour shortlived profile generally available on 15 January 2026, and will switch the default classic profile to 64 days on 10 February 2027 and to 45 days on 16 February 2028. Anything renewing monthly gets exactly one attempt per certificate; anything renewing yearly is expired for 165 days out of every 365.

That arithmetic is the whole point. A renewal job on a yearly schedule against a 200-day maximum is not "slightly stale" - it is a service serving an expired certificate for 165 days a year.

The awkward part is that none of this is visible in a code review, because none of it is a syntax error. 8760h is a valid Go duration. validity_period_hours = 8760 is valid HCL. -days 365 is a valid openssl flag. They are all simply describing a certificate that cannot exist any more. And if you ask an AI assistant, most will still tell you the maximum is 398 days, or that Let's Encrypt is fixed at 90 days, because SC-081v3 landed after their training data.

So it is worth grepping for the assumption rather than the syntax. The places it hides:

• cert-manager: duration and renewBefore on every Certificate
• Terraform: validity_period_hours, early_renewal_hours
• openssl / cfssl / step / keytool: -days, "expiry", --not-after, -validity
• ACME: cron and systemd timers that fire @monthly, @yearly or OnCalendar=monthly
• monitoring: a fixed days-remaining threshold - a 60 or 90 day alert is breached the instant a 47-day certificate is issued
• pinning: pin-sha256 and hardcoded leaf fingerprints, which break on every rotation
• runbooks: the numbers 398 and 825, and the phrase "valid for one year"

Cert Lifetime Lint is 24 rules over exactly that list. You can paste a file into the free web version and see every finding with its line number, its severity and the date the limit changes - nothing withheld. The licensed version adds the parts that are about scale rather than answers: the whole repository in one pass, a CI gate so a pull request cannot reintroduce 8760h, an exported CSV/JSON/HTML audit for the change ticket, and in-place rewriting of the durations.

The next date is 15 March 2027, when the maximum halves to 100 days. Every duration above 2400h in your repository fails on that day. It is worth knowing how many there are before then.