Certificate Lifespan (CT)

The TLS industry has been moving toward shorter cert lifespans for years. Apple capped public certs at 398 days in 2020; Google followed; Let's Encrypt has used 90 days since launch and recently announced 6-day certs. Short-lived certs reduce the exposure window if a private key is compromised, force automation as a precondition (no one renews 90-day certs by hand), and align with current browser policy. This check measures the share of your CT-logged certificates over the last 12 months that fall into three lifespan bands.

How the check works

Per scan, RedScore queries Certificate Transparency for every cert issued for the domain over the last 12 months and reads each one's notBefore/notAfter dates (falling back to crt.sh PEM fetch if dates are not in the index, then to live TLS leaf reads if CT does not yield dates). For each dated cert:

• Lifespan up to 90 days: 1.0 (short-lived, modern automated issuance).
• Lifespan 91-398 days: 0.85 (commercial standard; the upper bound matches Apple/Google browser policy).
• Lifespan over 398 days: 0.0 (excessive; should not exist for new public certs since 2020).

Score = mean of per-cert scores, multiplied by a sample-confidence factor. Special case: when every dated cert is at or under 90 days, confidence is set to 1.0 (a uniformly-modern issuance posture is not penalized for sparse data). When CT does not yield dated certs, the check falls back to live TLS leaf reads on primary HTTPS hosts.

How the verdict maps to evidence

• Pass: all certs short-lived (<=90 days), or mostly short-lived with confidence supporting it.
• Warn: standard commercial mix (91-398 days) without any over-398 certs. Reason: commercial_cert_lifespans (low severity).
• Fail: at least one cert over 398 days. Reason: excessive_cert_lifespan. The 0.0 weight on long-lived certs drags the mean down hard.
• Deferred: no dated certs could be obtained even via fallback. The check returns no score.

Evidence shows certificates_in_window, certificates_with_valid_dates, lifespan_measurement_source (ct_log or tls_leaf_live), short_lived_pct, medium_lived_pct, long_lived_pct, and the confidence multiplier.

Special states

• Deferred: no dated certs in window. Fall back to TLS leaf reads on primary hosts; if those also yield nothing, defers entirely.

Fix: migrate to short-lived ACME-issued certs

The fix for this check is the same as the fix for half the Certificate category: automate issuance via ACME and let renewal cycles drop your average cert lifespan. Most operators reach pass on this check the moment they migrate everything to Let's Encrypt or another ACME-based CA.

If you have certs over 398 days (fail)

These are almost always commercial 1-year-or-longer certs issued before 2020 that are still in their validity window. Two paths:

• Re-issue immediately from an ACME source (Let's Encrypt, Buypass Go, ZeroSSL, or your CA's ACME endpoint). Replace the binding on every host serving the long-lived cert. The old cert remains in CT history for 12 months but at least your active fleet is short-lived.
• If the long-lived cert is from a commercial CA you have to keep using, ask the CA to issue with a shorter validity period. Most commercial CAs now offer 90/180/365-day issuance; just ask for it explicitly.

If you have a commercial 91-398 day mix (warn)

Operationally fine and very common. The check intentionally does not score commercial lifespans as a fail; the warn is informational. Migration to short-lived improves the score and reduces the operational risk window:

• Pick an ACME provider (Let's Encrypt is the default; ZeroSSL, Buypass, and Google Trust Services also work).
• Stand up an ACME pipeline: certbot for traditional servers, cert-manager on Kubernetes, Caddy or Traefik for built-in. Automatic 90-day renewal at the 60-day mark is standard.
• Migrate one cert at a time as commercial certs approach renewal. No need to force-rollover; let natural expiry drive the migration.

If you are already short-lived (pass)

Stay short-lived. The check passes; do not regress to longer lifespans for cost or operational reasons; the operational cost of automation is low and the security benefit is real. Watch out for one-off long-lived certs being issued during emergencies ("just give me a 1-year cert so I can get past this incident"); they show up in CT and tank the score.

Verify the fix

• crt.sh search (https://crt.sh/?q=yourdomain.tld). For each entry, the validity dates show the lifespan. Sort by issued-date and check the most recent N for the lifespan distribution.
• openssl s_client -connect yourdomain.tld:443 -servername yourdomain.tld < /dev/null 2>/dev/null | openssl x509 -noout -dates shows the live cert's window. Calculate notAfter - notBefore.
• Re-run the RedScore lookup. New certs hit CT logs typically within minutes; the percentage updates on the next scan after issuance.

Common pitfalls

• 12-month CT window includes old long-lived certs. A 2-year cert issued 13 months ago has dropped out of the window; one issued 11 months ago is still in. The check rolls forward over time as old certs age out.
• Mixed CA sources producing mixed lifespans. Let's Encrypt for web (90 days) plus AWS ACM for ALB (13 months by default) gives a mixed lifespan distribution. ACM-issued public certs default to ~13 months but renew automatically.
• Long-lived cert imported into ACM. ACM also lets you import your own certs; if those are 2-year commercial certs, they show up in CT for your domain with the long lifespan. Re-issue from ACM (which renews automatically) instead of importing long-lived certs.
• EV cert from a commercial CA. EV certs typically have shorter lifespans now, but legacy EV setups may still be on multi-year cycles. Audit.
• Internal CA-issued cert accidentally exposed publicly. An internal CA may have issued a 5-year cert for an internal hostname that ended up in CT. Re-issue with a public-CA-appropriate lifespan, or remove from public DNS.
• Sample size confidence pulling a real failure out of scoring. With very few certs in the window, the confidence multiplier scales the score down. The check still flags excessive_cert_lifespan in evidence; investigate even if the score did not fully materialize.