Certificate Validity and 90-Day Proposals

Certificate validity is the time window during which a TLS certificate is considered trustworthy by clients. Once the notAfter date passes, browsers and TLS libraries reject the certificate immediately — no grace period, no warning, just a hard failure. The industry has been steadily reducing maximum validity periods, and the current trajectory points to 90 days becoming the standard for all publicly-trusted certificates.

Why it matters

• Compromise window — a stolen private key is useful only until the certificate expires. A 398-day certificate gives an attacker over a year of impersonation. A 90-day certificate limits that to three months maximum.
• Revocation is unreliable — CRL and OCSP are the mechanisms for invalidating compromised certificates before expiry, but both have serious gaps. Soft-fail OCSP (the default in most browsers) means a network attacker can simply block the revocation check and the client proceeds anyway. Short validity is the only reliable backstop.
• Forces automation — organizations that manually manage certificates can survive with 398-day validity. At 90 days, manual processes collapse. This forces adoption of ACME, CLM platforms, and proper certificate lifecycle tooling — which eliminates the expired-certificate outages that plague manual workflows.
• Aligns with key rotation best practices — NIST SP 800-57 recommends periodic key rotation. Shorter certificate validity naturally enforces key rotation since most implementations generate a new key pair at each renewal.
• Domain validation freshness — a certificate proves domain ownership at issuance time. If the domain changes hands, the old certificate remains valid until expiry. Shorter validity means stale domain validation is caught sooner.

How it works

1. CA issues certificate with notBefore and notAfter fields in the X.509 structure
2. Client checks validity during TLS handshake — compares current time against both fields
3. If expired — client aborts the connection with a certificate error. No negotiation.
4. Renewal window — operators must renew before notAfter. Best practice: renew at 2/3 of the validity period (e.g., at 60 days for a 90-day cert), leaving buffer for failures.
5. Key generation — most ACME clients generate a fresh key pair at each renewal, providing automatic key rotation
6. Deployment — new certificate and key must be installed and the TLS-terminating service reloaded

In real systems

Let’s Encrypt (already 90-day):

# Certificates valid for 90 days
# Certbot renews at 60 days remaining (30-day buffer)
certbot renew --deploy-hook "systemctl reload nginx"
# Runs via systemd timer twice daily — catches renewal window reliably

AWS Certificate Manager — ACM certificates auto-renew 60 days before expiry. No operator action needed for certificates attached to ALB/CloudFront. But certificates exported for use on EC2 instances do NOT auto-renew — you must re-export manually or build automation.

Enterprise environments (398-day certs today):

# Typical enterprise renewal workflow:
# 1. Certificate monitoring alerts at 30 days before expiry
# 2. Team generates CSR, submits to CA portal
# 3. CA validates organization (can take days for OV/EV)
# 4. Certificate downloaded, deployed to servers
# 5. Services reloaded
# At 90-day validity, this manual workflow runs 4x per year per certificate.
# With 500 certificates, that's 2000 renewal cycles annually — impossible without automation.

Kubernetes cert-manager — already designed for short-lived certificates. Default renewal is at 2/3 of validity. For 90-day certs, it renews at day 60 automatically:

apiVersion: cert-manager.io/v1
kind: Certificate
spec:
  duration: 2160h    # 90 days
  renewBefore: 720h  # 30 days before expiry

Where it breaks

No automation in place when validity drops — the organization has 500 certificates managed manually via spreadsheets. When the CA/Browser Forum enforces 90-day maximum, every certificate must be renewed 4x per year instead of once. Without ACME or a CLM platform, the team is overwhelmed and certificates start expiring in production. The fix isn’t “renew faster” — it’s “automate everything before the deadline.”

Renewal succeeds but deployment fails — ACME renews the certificate on disk, but the application server isn’t reloaded. The old certificate (now expired) is still served from memory. Monitoring shows the file is valid, but clients see an expired cert. This failure mode multiplies with shorter validity because renewals happen more frequently.

Clock skew — a server with an incorrect system clock may reject a valid certificate as “not yet valid” or serve a certificate that clients see as expired. With 398-day certificates, minor clock drift is absorbed. With 90-day certificates, even a few hours of skew near the boundaries can cause failures. NTP synchronization becomes critical infrastructure.

Operational insight

The real impact of 90-day certificates isn’t technical — it’s organizational. Companies that have never invested in certificate automation will be forced to in a compressed timeline. The organizations that struggle most are those with certificates embedded in legacy systems (hardware load balancers with manual cert upload, mainframes, IoT devices with no remote update capability). These systems can’t run ACME clients and have no API for certificate deployment. The 90-day proposal will create a hard divide between automated infrastructure (which handles it trivially) and legacy infrastructure (which faces recurring outages until modernized or exempted).

Related topics

• What is ACME Protocol
• What is a TLS Certificate
• Certificate Renewal and Revocation
• Certificate Automation at Scale
• CA/Browser Forum Baseline Requirements