Google Wants 90-Day Certificates: Get Ready Before It Becomes a Rule

Earlier this month the Chrome Root Program published a roadmap document called "Moving Forward, Together," laying out where Google wants the web PKI to go over the next few years. Most of it is inside baseball for certificate authorities. One line is not: Google says it intends to propose reducing the maximum validity of publicly trusted TLS server certificates from 398 days to 90 days, either through a future Chrome policy update or a CA/Browser Forum ballot.

There's no effective date yet. It's a stated intention, not a rule, and the details could change. But if you've followed this blog for a while, the direction won't surprise you. We wrote about the cut to 825 days in 2018 and the move to one-year certificates in 2020, and both times the conclusion was the same: the trend only goes one way. A 90-day ceiling would be the step where manual renewal stops being merely annoying and becomes impractical.

What Google actually said

The roadmap covers several themes. The ones most relevant to people who run websites:

• Shorter certificate lifetimes, with 90 days as the proposed maximum for server certificates.
• Shorter reuse of domain validation, meaning CAs would need to re-verify that you control a domain more often.
• Automation as a baseline expectation, including a push for CAs to support ACME, the protocol Let's Encrypt made standard.

The stated reasoning is that shorter lifetimes reduce the damage from mis-issued or compromised certificates, lessen the dependence on revocation (which has never worked as well as anyone hoped), and make it easier for the ecosystem to change algorithms or policies quickly, because the whole population of certificates turns over in a few months.

You can agree or disagree with the timing, but the logic has been consistent for years, and Chrome's root program has enough weight that its proposals tend to happen in some form.

Who this hurts, and who won't notice

If your certificates come from Let's Encrypt or another ACME-based CA and renew automatically, you're already on 90-day certificates. Let's Encrypt has issued 90-day certs since launch. A policy change would mean nothing to you, apart from a reason to double-check that the automation really works.

The people who will feel it:

• Teams buying one-year certificates and installing them by hand on load balancers, CDNs, appliances or Windows servers. Four times as many renewals means four times as many chances to forget.
• Anything with a certificate in an unusual place: VPN concentrators, mail servers, IoT dashboards, printers, admin panels on odd ports, embedded devices whose only update path is a web form.
• Organisations where a renewal needs a purchase order, a ticket and three approvals. A process that takes two weeks is fine once a year and painful every couple of months.
• Anyone pinning certificates in mobile apps or API clients. Frequent rotation and pinning to a leaf certificate don't mix.

Getting ready: a practical checklist

1. Build an inventory. You can't automate what you can't find. Start with Certificate Transparency logs, which list every publicly trusted certificate issued for your domains:

# All certificates issued for a domain and its subdomains, via crt.sh
curl -s 'https://crt.sh/?q=%25.example.com&output=json' | \
  jq -r '.[] | [.not_before, .not_after, .issuer_name, .name_value] | @tsv' | sort -u

Then check what each endpoint actually serves, which isn't always what you think:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | \
  openssl x509 -noout -issuer -enddate

2. Sort each certificate into "automated" or "manual." Be honest. "Someone gets a calendar reminder" is manual.

3. Automate the easy majority now. For ordinary web servers, an ACME client does the job: certbot or acme.sh on traditional hosts, Caddy's built-in ACME support, cert-manager on Kubernetes, and the managed certificate features most cloud load balancers and CDNs already offer. If your current CA supports ACME, you can often keep the same CA and just change how you request certificates.

4. Find a plan for the awkward minority. Appliances without ACME support may have an API you can script against. Some can sit behind a reverse proxy that handles TLS for them. A few may need replacing, and it's better to find that out now than when the rule has a date.

5. Remove leaf pinning. If you must pin, pin to a CA's public key or intermediate, and keep a backup pin. Better still, rely on Certificate Transparency and CAA records instead.

6. Monitor the result. Automation fails quietly. We covered the common ways Let's Encrypt renewals stop in 2021: expired DNS API credentials, a firewall change that blocks HTTP-01 challenges, a renewal that succeeds but a web server that never reloads. With 90-day certificates, the gap between "renewal broke" and "certificate expired" is weeks, not months.

Picking alert thresholds for short-lived certificates

With one-year certificates, many teams alert at 30 days before expiry and consider that generous. With 90-day certificates renewed by automation, the math changes. Most ACME clients try to renew at around 30 days remaining. So:

• If a certificate has fewer than about 20 days left, a renewal has probably failed at least once. That's a warning, worth a ticket.
• Fewer than 7 days means repeated failures and someone needs to look today.
• Also alert on the served certificate not changing after a renewal should have happened. That catches the "renewed on disk, never reloaded" case, which expiry alerts only catch late.

Check from outside your network, against the hostname your users actually hit. A certificate renewed on the origin doesn't help if the CDN in front is still serving the old one.

Start before the deadline exists

The comfortable time to do this work is while 90 days is still a proposal. Once there's a date, CAs, vendors and every other team in your industry will be doing the same migration at once. Inventory this quarter, automate what you can, and put expiry monitoring on everything, including the certificates you're sure are automated. CompleteStatus watches certificate expiry from the outside if you'd rather not build that part yourself.