One-Year Certificates Are Coming — Apple Just Changed the Rules

At last month's CA/Browser Forum face-to-face meeting, Apple stood up and made an announcement that ends a years-long industry argument in a single stroke: starting September 1, 2020, Safari will not trust any newly issued publicly-trusted TLS certificate with a validity period longer than 398 days. Not "we propose." Not "we'd like a vote." Safari — on every iPhone, iPad and Mac — will simply treat longer-lived new certificates as invalid.

Since no site can afford to be broken for Safari users, this is a de facto rule for the entire web. Two-year certificates — today's maximum — are effectively finished for anything issued from September onward. If your organization buys certificates in bulk, renews them by calendar reminder, or has that one load balancer nobody wants to touch, the clock on your current process just started ticking.

How we got here — the ballot that failed

Certificate lifetimes have been on a downward march for years: five-year certificates were eliminated mid-decade, then three-year, and in 2018 the maximum dropped to 825 days (~27 months). Browser makers — Google most vocally — have pushed to keep going.

In the summer of 2019 that push became Ballot SC22 at the CA/Browser Forum: a formal proposal to cap validity at roughly one year. Browsers voted for it unanimously. The certificate authorities — whose business models lean on multi-year deals — voted it down decisively, and the ballot failed in September 2019. For a few months, that looked like the end of the argument.

Apple's February announcement is the sequel, and the lesson in power dynamics is hard to miss: the forum's rules require industry consensus, but any browser vendor can simply change what its own root store accepts. A certificate Safari rejects is a certificate you can't use, whatever the ballots say. Google and Mozilla publicly favored the same cap in SC22, so expect alignment rather than resistance — but even if no other browser moved, Apple alone is enough to make 398 days the working maximum for everyone.

What exactly changes — and what doesn't

The details matter for planning, so let's be precise:

• The cutoff is issuance date, not renewal date. Certificates issued on or after September 1, 2020 must have a validity period of 398 days or less to be trusted by Safari.
• Existing certificates are grandfathered. A two-year certificate issued on August 31 remains valid until it expires in 2022. (Expect a mini-rush of "last long certificates" this summer — resist it; it just defers the process change while adding certificates you'll be tracking manually the longest.)
• 398, not 365 — one year plus a grace margin so a certificate renewed slightly late can still be issued for a clean year.
• Public TLS only. Private/internal CAs your own devices trust are unaffected — though the operational logic below applies to them just as much.

The real message: renewal is now an engineering problem

Halving certificate lifetimes doubles renewal frequency, and the security rationale — shorter exposure for stolen keys, faster turnover of weak crypto, less reliance on revocation checking that famously doesn't work — points one direction: lifetimes will likely keep shrinking. The industry is being told, unambiguously, that certificate renewal should be automated infrastructure, not an annual human ritual. Practically, that means three moves.

1. Inventory what you have — all of it

You can't plan around certificates you don't know exist. Most organizations who run this exercise find strays: the marketing microsite, the API subdomain, the staging box that somehow serves production traffic, the appliance with a certificate uploaded through a web UI in 2018. For each host you know about, capture expiry and lifetime:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -subject -dates
# subject=CN = example.com
# notBefore=Mar  1 00:00:00 2019 GMT
# notAfter=Feb 28 23:59:59 2021 GMT

Anything long-lived deserves a flag: those are the hosts where renewal is probably a manual process — and manual processes that ran every two years are about to run twice a year, on more hosts, forever.

2. Automate with ACME wherever possible

The ACME protocol — the automation standard behind Let's Encrypt, now published as RFC 8555 — has made "certificates renew themselves" a solved problem for most stacks. Clients like Certbot or acme.sh renew well before expiry and reload the web server, unattended:

# Typical setup: renewal runs twice daily, renews ~30 days before expiry
certbot --nginx -d example.com -d www.example.com
systemctl list-timers | grep certbot

Commercial CAs are moving to support ACME issuance too, so automation doesn't have to mean changing vendors. For hosts that can't run an ACME client — appliances, managed platforms, that one Windows box — a DNS-01 challenge issued centrally and deployed by script usually gets you there. The goal state is simple: no certificate anywhere whose renewal depends on a human remembering.

3. Monitor expiry independently — because automation fails silently

Here's the trap in the brave new automated world: automation converts a predictable annual task into a silent recurring dependency. Renewal jobs fail quietly — an expired API credential, a changed DNS setup breaking the challenge, a renewed certificate that never got deployed to the load balancer — and nothing tells you until browsers start throwing full-page warnings. More renewals per year mechanically means more opportunities for exactly this.

The answer is a watcher that doesn't share fate with the automation: an external monitor that connects to each host like a browser would, reads the certificate actually being served, and alerts when expiry approaches — 30 days out, 14, 7. If the renewal automation works, the alert never fires. If anything in the chain breaks, you find out weeks before your visitors do. It also verifies the thing that matters and that renewal logs can't: what's deployed, not what was issued.

The deadline behind the deadline

September 1 isn't really when certificates change — it's when the era of treating certificates as a set-and-forget annual purchase officially ends. Teams that use the next six months to inventory, automate and monitor will barely notice the transition; teams that don't will meet it one expired certificate at a time.

CompleteStatus monitors SSL certificate expiry and validity from the outside on every host you point it at — independent of your CA, your ACME client and your deploy pipeline — with alerts well before expiry, alongside your uptime and DNS checks in one dashboard. Create a free account and put your certificate inventory under watch this week; when September arrives, you'll be one of the teams for whom nothing happens.