47 days: what actually changes

The schedule

The CA/Browser Forum is the body where certificate authorities and browser makers agree the rules for publicly trusted certificates. In April 2025 it passed ballot SC-081v3, proposed by Clint Wilson of Apple and endorsed by Sectigo, Google Chrome and Mozilla. Twenty-five certificate authorities voted yes and none voted no, and the four browser makers that voted, Apple, Google, Microsoft and Mozilla, all voted yes.¹ The ballot writes a schedule into the Baseline Requirements that cuts the maximum lifetime of a certificate in three steps, and at each step also cuts how long a domain-control check may be reused.²

The first cut has already happened: a certificate issued today can live 200 days at most. The next step is less than six months away, and the last one arrives in March 2029. A quieter line in the same ballot cuts how long an authority may reuse the checks behind an organization-validated certificate, from 825 days to 398.²

Who it binds

The rules bind publicly trusted certificates: the ones a browser or an operating system trusts out of the box. A private certificate authority, the kind you run for the machines inside your own walls, is not bound by them and can keep issuing long-lived certificates. So why does this reach beyond the public website? Because public certificates are everywhere inside an estate: on load balancers, on internal services that carry public names, on the API gateway, on the thing a vendor set up three years ago. Every one of them is on the schedule.

The second cut: proving you own the name

Before an authority signs a certificate for api.example.com, it has to check that you control that name. That check is domain-control validation, and you pass it by publishing a token in DNS or serving one over HTTP.³ Until this year an authority could reuse a passed check for over a year. By 2029 the check is good for ten days.²

That is the part of the ballot that ends manual certificate management, more than the 47 days itself. Ten-day reuse means re-proving control several times a month, for every name, forever. Nobody does that by hand. The reasoning behind short lifetimes is the one Let's Encrypt gave when it announced six-day certificates: revocation "doesn't work very well", and a short lifetime shrinks the window in which a stolen key is useful.⁴

What breaks

• Renewal becomes continuous. A 398-day certificate was renewed once a year. Let's Encrypt's guidance is to renew when a third of the lifetime is left,⁵ which for a 47-day certificate means every 31 days: eleven or twelve renewals a year, for every certificate you own.
• Expiry is a hard failure. An expired certificate does not degrade. Browsers refuse the page, API clients refuse the connection, health checks go red. Twelve renewal windows a year is twelve chances to miss one.
• The long tail is the problem, not the certificate you know about. The one on the marketing site has an owner. The one on the internal load balancer that a contractor set up, the wildcard that six teams quietly reuse, the SaaS integration that expects a client certificate: those are the ones that fail at 3 a.m.
• Tickets stop working. A renewal that goes through a change ticket has a lead time measured in days. At ten-day validation reuse, the process is longer than the proof.

The four moves

1. Inventory first. You cannot rotate what you cannot see. Find every certificate, tie it to an owner and an expiry, and keep that list current. Discovery is the unglamorous half of the job and the half most teams skip.
2. Automate issuance with ACME. ACME is the protocol that lets a machine request, prove and fetch a certificate with no human in the loop; it is how Let's Encrypt works.³ Your internal authority should speak it too, so the same clients (certbot, acme.sh, Caddy, cert-manager) work everywhere. trstctl implements the authority side of ACME with all three standard challenges, so those clients can enroll against it.⁶
3. Renew ahead of expiry, safely. Renew on policy, well before the deadline, and let the authority tell you when: ACME Renewal Information exists for exactly that.⁷ Make every operation idempotent, so a retried renewal returns the same result instead of a second certificate. trstctl requires an Idempotency-Key on every mutating request for this reason.⁸
4. Keep custody while you automate. The temptation is to hand the automation the CA private keys. Don't. Put the keys in a separate signer process and let the automation orchestrate. That is a post of its own.

The schedule with a live countdown is on trstctl.com/47days, and the console demo shows what an inventory with owners and expiries looks like, on sample data.