Why Apple Enforced a 398-Day Limit for TLS Certificates

In September 2020, Apple began enforcing a strict policy across its operating systems and the Safari web browser, capping the maximum validity period of newly issued, publicly trusted TLS server certificates at 398 days. This article provides a direct breakdown of why Apple made this unilateral decision, focusing on the need to improve web security, mitigate the risks of unreliable certificate revocation, increase cryptographic agility, and force the adoption of automated certificate management.

The Shift from 825 to 398 Days

Prior to Apple's announcement at the beginning of 2020, the maximum validity period for TLS certificates was 825 days (roughly two years and three months). Certificate Authorities (CAs) and browser vendors usually agree on these standards through the CA/Browser Forum. However, when a ballot to reduce certificate lifespans failed to pass in 2019 due to pushback from CAs, Apple decided to enforce the rule independently using its root store policy. Google and Mozilla quickly followed suit, making the 398-day limit the de facto industry standard.

The specific number of 398 days was chosen to represent a single year (365 days), plus one day for a leap year, and an additional 32-day grace period to allow administrators time to renew and deploy the next certificate without losing the value of their remaining time.

1. Reducing the Window of Vulnerability

The primary driver behind shorter certificate lifespans is security. If a server's private key is compromised, an attacker can impersonate the website and intercept encrypted traffic.

Theoretically, compromised certificates are added to revocation lists so browsers know not to trust them. In practice, certificate revocation mechanisms—specifically Certificate Revocation Lists (CRLs) and the Online Certificate Status Protocol (OCSP)—are notoriously unreliable, slow, and raise privacy concerns. Because browsers cannot always depend on revocation checks, a compromised certificate often remains trusted until it naturally expires. Reducing the lifespan from two years to one year cuts the potential window of vulnerability in half.

2. Increasing Cryptographic Agility

Technology and cybersecurity threats evolve rapidly. When a flaw is discovered in a cryptographic algorithm or a TLS protocol version, the entire internet must transition to a new standard.

Long-lived certificates slow down this transition. If a Certificate Authority changes its issuance standards to fix a vulnerability today, older, vulnerable certificates will remain active in the wild until they expire. With an 825-day limit, it took over two years to fully phase out outdated cryptography. By enforcing a 398-day maximum, Apple ensured that future security upgrades and cryptographic changes can be rolled out across the web in just one year.

3. Maintaining Accurate Domain Validation

A TLS certificate binds an identity and a domain name to a cryptographic key. Over two years, companies get acquired, go out of business, or let domain registrations lapse.

Under the old rules, an entity could buy a domain, generate a two-year certificate, and then sell the domain a month later. The original owner would still possess a valid certificate for a domain they no longer owned for the next 23 months. Requiring annual re-validation ensures that the entity holding the certificate is still the legitimate owner of the domain.

4. Forcing Automation

Manually tracking, buying, validating, and installing TLS certificates is tedious and prone to human error. Forgotten renewals frequently lead to expired certificates and major service outages.

By making certificate renewal a yearly requirement, Apple aimed to make manual management painful enough that organizations would finally abandon it. The 398-day limit was a deliberate nudge to force system administrators to adopt automated certificate management protocols, such as ACME, which can renew and deploy certificates seamlessly in the background without human intervention.