How to fix the excessive certificate validity period advisory

The excessive_validity advisory fires when a certificate's lifetime (NotAfter − NotBefore) exceeds 398 days — the maximum that Apple, Google, and Mozilla enforce for publicly trusted server certificates since September 2020.

What triggers the advisory

CertTracker subtracts NotBefore from NotAfter on the leaf certificate. If the result is more than 398 days, the advisory fires. Examples that trip it:

• A 2-year cert issued by an internal CA with the old default template.
• A 5-year self-signed cert generated years ago and never rotated.
• A wildcard cert from a legacy procurement contract with a 3-year term.

Why it matters

For publicly trusted certs: browsers will refuse to trust certificates issued after 1 September 2020 that exceed 398 days. The cert simply won't work for end users on Chrome, Safari, Edge, or Firefox.

For privately issued certs: there's no enforcement mechanism — your internal CA's certs work as long as the CA's policy and your clients accept them. But the advisory still fires because long-lived certs are a security smell:

• Longer rotation windows mean larger blast radius if a key is compromised.
• Long validity periods generally point to a misconfigured CA template that's also issuing public-facing certs incorrectly.
• It indicates the rotation pipeline isn't being exercised regularly.

If you've intentionally chosen long internal cert lifetimes for a deliberate reason (offline air-gapped CA, etc.), you may choose to acknowledge this advisory permanently instead of fixing it.

Fix on a public-CA-issued certificate

You can't request a cert longer than 398 days from a public CA anymore — the limit is enforced at issuance. If you're seeing this advisory on a public-CA cert, the cert was issued before the rule took effect (i.e., before September 2020) and is now stale. Just reissue it; the new cert will automatically conform.

Fix on a private-CA / internal-PKI certificate

You have two choices: tighten the CA's issuance policy, or accept the longer validity and acknowledge the advisory.

Option A: Issue shorter-lived certs.

With openssl:

# 90-day cert (a common modern default — matches Let's Encrypt's lifetime)
openssl ca -config ca.cnf -in server.csr -out server.crt -days 90

With Active Directory Certificate Services, edit the certificate template's General tab to set the validity period to 1 year or less. Reissue under the updated template.

With HashiCorp Vault PKI:

vault write pki/roles/your-role   max_ttl="8760h"      # 365 days

Then reissue certs from that role.

Option B: Acknowledge the advisory.

If your internal policy genuinely calls for long-lived certs (rare but legitimate for some compliance contexts), click Acknowledge on the advisory in the CertTracker monitor detail modal. The advisory stays acknowledged until a new certificate is issued; if the next reissuance still has a >398-day lifetime, the advisory fires fresh and you can acknowledge it again.

Installing the new shorter-lived certificate

Same procedure as any other cert install — see the per-server sections under Fix weak signature algorithm for Apache, Nginx, IIS, and HAProxy steps.

Verify the fix

Check the validity span of the newly served leaf:

echo | openssl s_client -connect your-host.example.com:443 -servername your-host.example.com 2>/dev/null   | openssl x509 -noout -dates

Output:

notBefore=May 27 00:00:00 2026 GMT
notAfter=Aug 25 23:59:59 2026 GMT

Compute the span: notAfter - notBefore. 398 days or less = clean.

Trigger a re-scan from the CertTracker UI. The fastest path: open the monitor's detail modal (click the monitor row on the Monitors page), scroll to the Active Advisories section, and click the orange ⟳ Re-scan button on the right side of the section header. The status line below the header will confirm the cert re-poll and TLS audit are queued; the next 5-minute poller tick (within ~5 minutes) runs both, and the advisory clears if your fix took. See Where to find these buttons in the UI for visual landmarks. and confirm the advisory clears.

A note on automation

The right long-term answer for cert lifecycle hygiene is automation, not periodic manual reissuance. If your stack supports it:

• Let's Encrypt + certbot/acme.sh for public-facing services. 90-day certs, auto-renewed every 60 days.
• HashiCorp Vault PKI + cert-manager for Kubernetes internal certs.
• ADCS auto-enrollment for Windows-joined endpoints inside an AD forest.

A short validity period that never gets human attention is safer than a long one that gets forgotten.

Related advisories

• Weak signature algorithm — same reissuance flow.
• Hostname mismatch — also requires reissuance.

Back to the TLS hardening hub.