Certificate Validity Periods: The 398-Day Rule and Why It Matters

ScanMalware Team
6 min read

Introduction

If you've ever wondered why TLS certificates now expire after just over a year instead of multiple years like they used to, you're not alone. The industry has undergone significant changes in certificate validity periods, with browsers now enforcing strict limits that many certificate holders may not be aware of.

In this post, we'll explore the history of certificate validity limits, explain the current 398-day rule, and show how ScanMalware detects certificates that violate these standards.

The Evolution of Certificate Validity Limits

The Old Days: 5+ Years

Before 2015, it wasn't uncommon to see certificates valid for 5 years or more. This seemed convenient—issue once, forget for years.

The problems:

  • Long-lived certificates increased the window for exploitation if compromised
  • Revocation mechanisms (CRL, OCSP) proved unreliable
  • Cryptographic standards evolved faster than certificate lifetimes

2015: The 39-Month Limit

In March 2015, the CA/Browser Forum voted to limit certificate validity to 39 months (1,185 days).

Example: A certificate issued on January 1, 2015, could be valid until March 31, 2018.

2018: The 825-Day Rule

On March 1, 2018, the limit was reduced to 27 months (825 days).

Why?

  • Faster crypto agility (easier to migrate to new algorithms)
  • Reduced impact window for compromised private keys
  • Better alignment with automated certificate management (ACME)

2020: The 398-Day Rule (Current)

On September 1, 2020, Apple announced that Safari would reject certificates with validity periods exceeding 398 days. Other browsers quickly followed:

  • Apple Safari: September 1, 2020
  • Google Chrome: September 1, 2020
  • Mozilla Firefox: Later adopted the same limit

Critical detail: This applies to certificates issued on or after September 1, 2020. Pre-existing longer certificates were grandfathered.

Why 398 Days Specifically?

You might wonder: "Why not exactly 1 year (365 days)?"

The answer: Certificate renewal overlap.

The reasoning:

  • 365 days = 1 year
  • +30 days = renewal grace period
  • +3 days = buffer for timezone/processing differences
  • Total: 398 days

This allows organizations to renew certificates a month before expiration while maintaining continuous coverage.

Industry Standards and Requirements

CA/Browser Forum Baseline Requirements

Section 6.3.2 (Valid Period for Certificates):

Subscriber certificates issued after 1 September 2020 MUST have a validity period of 398 days or less.

Browser Enforcement

What happens if you use a certificate valid for > 398 days?

Modern browsers will:

  1. Show a security error (NET::ERR_CERT_VALIDITY_TOO_LONG)
  2. Display a "Your connection is not private" warning
  3. Block access to the site (user must bypass manually)

Example error in Chrome:

This site can't provide a secure connection
scanmalware.com sent an invalid response.
ERR_CERT_VALIDITY_TOO_LONG

Our Implementation

We added automated detection for excessive validity periods in ScanMalware's TLS analyzer.

Calculation

We calculate the total validity period by determining the number of days between the certificate's "Not Before" and "Not After" dates. This gives us the total lifetime of the certificate in days, which we then compare against the industry standards.

Two-Tier Severity Model

Medium Severity (398-825 days):

  • Violates current browser requirements
  • Certificate will be rejected by modern browsers
  • Risk Score: +15 points

High Severity (> 825 days):

  • Violates even the older 2018 standard
  • Indicates outdated certificate practices
  • Risk Score: +25 points

Security Finding Example

{
  "severity": "medium",
  "finding": "Long validity period",
  "description": "Certificate validity period is 739 days (> 398 days / 13 months). Modern browsers (Chrome, Safari, Firefox) reject certificates with validity > 398 days issued after September 1, 2020. This may cause connection failures for users. Consider reissuing with a shorter validity period.",
  "remediation": "Reissue the certificate with a validity period of 398 days or less",
  "impact": "Users will see 'Invalid certificate' or 'Connection not secure' warnings in modern browsers"
}

Real-World Testing Results

GitHub.com (Compliant)

Not Before: 2024-02-01 00:00:00
Not After:  2025-02-01 23:59:59
Validity Period: 365 days
Status: ✅ Compliant (< 398 days)
Risk Score Impact: 0

Analysis: GitHub's certificate is compliant with modern standards. No browser warnings.

badssl.com Test Certificate (Non-Compliant)

Not Before: 2023-01-01 00:00:00
Not After:  2025-01-31 23:59:59
Validity Period: 739 days
Status: ⚠️ Non-compliant (> 398 days)
Risk Score Impact: +15
Severity: Medium

Analysis: This certificate would trigger browser warnings if issued after September 1, 2020.

Impact on Certificate Management

The Rise of Automation

The 398-day limit has accelerated adoption of automated certificate management:

Popular Solutions:

  • Let's Encrypt (90-day certificates, free)
  • Certbot (automated renewal)
  • ACME protocol (industry standard)
  • cert-manager (Kubernetes)

Best Practices

  1. Use automated renewal - Don't rely on manual processes
  2. Monitor expiration dates - Get alerts 30+ days before expiry
  3. Test renewals - Ensure your automation works before you need it
  4. Keep buffers - Renew at 60-70% of lifetime, not 90%

The 90-Day Trend

Many CAs now issue 90-day certificates by default:

Advantages:

  • Forces automation (manual renewal every 90 days is impractical)
  • Reduces blast radius of key compromise
  • Enables faster crypto agility
  • Free for most use cases (Let's Encrypt)

Disadvantages:

  • Requires robust automation
  • More frequent certificate changes
  • Dependency on CA availability

Future Directions

Shorter Periods Ahead?

There's industry discussion about further reducing maximum validity:

Proposed: 90-day maximum (matching Let's Encrypt's default)

Arguments for:

  • Better security posture
  • Widespread automation already exists
  • Reduced compromise window

Arguments against:

  • Not all environments support automation
  • Internal CAs and air-gapped networks face challenges
  • Increased operational overhead without automation

Timeline: Likely 2025-2026 if adopted

Conclusion

The 398-day certificate validity limit represents the industry's shift toward shorter-lived, automatically-managed certificates. While this requires more robust automation, it significantly improves the security posture of the web ecosystem.

ScanMalware's TLS analyzer now automatically detects certificates that violate these standards, helping site owners identify potential browser compatibility issues before their users encounter them.

Recommendations

If your scan shows a validity period violation:

  1. Check the issue date - Pre-September 2020 certificates were grandfathered
  2. Test in modern browsers - Verify if users are actually seeing errors
  3. Plan for reissuance - Get a compliant certificate before the old one expires
  4. Implement automation - Use ACME/Let's Encrypt for future renewals
  5. Monitor continuously - Set up alerts for upcoming expirations

Check your certificate validity at ScanMalware.com - we'll tell you if your certificates meet modern browser requirements!