The TLS article ended its revocation section by calling it "the part that isn't finished" — a certificate whose key has been stolen keeps working, because the mechanism that should say "this one is no longer valid" does not reach the browser in time, or reaches it and gets ignored.
This article is what the industry did about that, and the answer was not to fix revocation.
The answer was to make certificates expire so fast that revoking them stops mattering.
The story usually gets told wrong in two ways. The first is "CAs want to sell more often", which the vote tallies below contradict — the CAs were the side resisting, for years. The second is treating this as a 2029 problem, which is false. The first step took effect on 15 March 2026 and you can measure it on the sites you open every day.
If you have never looked, start here
One command shows how many days a site's certificate is good for.
$ echo | openssl s_client -servername example.com \
-connect example.com:443 2>/dev/null \
| openssl x509 -noout -datesTwo lines come back.
notBefore=Aug 29 01:40:33 2026 GMT
notAfter=Nov 27 02:40:27 2026 GMTThe span between them is what the standard calls the validity period, and the Baseline Requirements define it by quoting RFC 5280 directly: "The period of time from notBefore through notAfter, inclusive."
That example is this site's own certificate. Ninety days apart.
The line you can measure today
The rule in force right now lives in Baseline Requirements section 6.3.2, and it is written as date ranges.
issued before issued on/after ceiling
2026-03-15 398 days
2026-03-15 2027-03-15 200 days
2027-03-15 2029-03-15 100 days
2029-03-15 47 daysNote that the rule binds to the date of issuance, not the date of use. A certificate issued before a boundary keeps its full original lifetime.
Which is why today you can measure two eras coexisting on the same internet.
Measured 31 August 2026 with the command above.
host issued days issuer
www.thaigov.go.th 2026-03-06 396 GlobalSign
chula.ac.th 2026-01-05 396 Sectigo
krungsri.com 2025-08-21 393 DigiCert
netflix.com 2026-02-18 365 DigiCert
www.microsoft.com 2026-01-23 360 Microsoft
---------------------- boundary 2026-03-15 -------------
scb.co.th 2026-04-23 199 GlobalSign
www.kasikornbank.com 2026-04-20 198 DigiCert
www.bot.or.th 2026-04-21 198 DigiCert
amazon.com 2026-05-05 197 DigiCert
www.apple.com 2026-07-03 166 Apple
github.com 2026-07-03 89 Sectigo
wikipedia.org 2026-08-06 89 Let's Encrypt
netkubelab.com 2026-08-29 90 Google TrustThe top half was issued before the boundary and still runs close to 398. The bottom half was issued after it, and not one of them touches 200 — three banks stop at 198 and 199, which is the signature of a system asking for the longest certificate the rule allows.
www.thaigov.go.th is the clearest illustration of binding the rule to the issuance date. It was issued on 6 March 2026 — nine days before the boundary — so it got 396 days and will live until April 2027, skipping the entire 200-day era.
Eight years of negotiation
This ceiling did not fall because anyone discovered something new. It fell because of politics in a room called the CA/Browser Forum, which has two kinds of member: Certificate Issuers, the CAs that sign certificates, and Certificate Consumers, the browser and operating-system vendors who decide whose signatures to believe.
The bylaws require two thirds of the Certificate Issuer votes and more than half of the Certificate Consumer votes to adopt a ballot.
2017-03-17 Ballot 193 ceiling of 825 days
CAs 24 yes 0 no 3 abstain
browsers 5 yes 0 no 1 abstain
passed, effective 2018-03-01
2019-09-10 Ballot SC22v2 ceiling of roughly one year
CAs 11 yes 20 no 2 abstain
browsers 7 yes 0 no 0 abstain
failedTwo years apart, and the vote flipped from unanimous to two-to-one against. The Forum's own results page records "35% of voting Certificate Issuers voted in favor" against "100% of voting Certificate Consumers voted in favor".
The day the forum could not decide, so someone decided for it
After SC22 failed the matter should have ended. Instead, in February 2020, Apple posted on its own support site:
"TLS server certificates issued on or after September 1, 2020 00:00 GMT/UTC must not have a validity period greater than 398 days."
And the next line asked nobody for anything.
"Connections to TLS servers violating these new requirements will fail."
No vote, no resolution — just an edit to one company's own root program requirements. Because no CA wants to sell a certificate Safari refuses, the whole industry moved to 398 days within a year: the very number the CAs had voted down five months earlier.
One detail says a great deal. Here is the definition Apple published that day:
"398 days is measured with a day being equal to 86,400 seconds. Any time greater than this indicates an additional day of validity."
That sentence is barely distinguishable from the text sitting in the Baseline Requirements today. One company's root program requirement became the whole industry's standard.
That is the lesson that made the 2025 vote look different. When Ballot SC-081v3 reached the room in April 2025 carrying a schedule all the way down to 47 days, the result was:
2025-04-11 Ballot SC-081v3 schedule down to 47 days
CAs 25 yes 0 no 5 abstain
browsers 4 yes 0 no 0 abstain
passed, BR version 2.1.5, effective 2025-05-16The same population of CAs that had killed a one-year ceiling six years earlier raised not a single vote against a 47-day one. Five chose to abstain.
Reading that as "the CAs changed their minds" probably misses the point. What changed is that everybody had now seen what the alternative looks like: being told rather than being asked.
The reasons, in the ballot's own words
Ballot SC-081v3 states its own reasoning, and the passage that lands closest to the TLS article is this one:
"Certificate status services, such as CRLs and OCSP, are technologies which do not adequately protect relying parties at the current scale of the internet, whether due to privacy concerns, performance impacts, timeliness of relevant statuses, the accuracy (and usability) of data, or other inadequacies."
In plain language: revocation does not work, and we have stopped trying to make it work.
The next argument is the one I think is the best-written thing in the whole document.
"Certificates are representations of a point in time state of reality. ... The more time passes from that moment of issuance, the more likely it becomes that data represented in the certificate diverge from reality."
A certificate does not describe the present. It describes the second it was issued. Every day that passes is another chance for the truth inside it and the truth outside it to come apart — the domain lapsed and someone else registered it, the key got copied, the company was sold, the person holding the key left. The ballot cites research calling these "security-relevant events that enable a third-party to impersonate a domain outside their control".
And the sharpest argument is the one pointing out that none of this is a new demand at all.
"The TBRs maintain a requirement for CAs to revoke certificates they have issued within 24 hours under certain circumstances. It can reasonably be inferred from this that certificates issued in compliance with the TBRs are understood to be managed in such as a way as to allow for certificate replacement within any given 24 hour period."
The Baseline Requirements have demanded 24-hour revocation since their first version, which means the standard has always assumed a site operator can swap a certificate inside a day. In reality almost nobody could. The ballot goes on: "the reality of certificate management practices ... has not necessarily reflected such an expectation. Nonetheless, this is and has been the requirement presented by the TBRs."
So 47 days does not add a requirement — it makes an existing one enforceable. If you cannot replace a certificate within 47 days, you could never have replaced one within 24 hours, which means you have been out of compliance the whole time and nobody was in a position to notice.
Why 47
The number looks arbitrary enough that people keep asking, and the answer circulating in the industry is:
31 the longest month
15 half of a 30-day month
1 slack
--
47The practical reasoning: renew once a month, and if one attempt fails you still have half a month to fix it before the certificate dies.
One thing to be straight about — I could not find this arithmetic anywhere in SC-081v3 itself. The document gives the schedule table and never explains the number. The 31+15+1 breakdown comes from blog posts by CAs that took part in the process, such as DigiCert and Sectigo, which makes it a secondary source. Cite it that way if it matters.
The number everybody skipped
Every headline says 47 days. But the ballot's full title is "Introduce Schedule of Reducing Validity and Data Reuse Periods", and it is the second half that will change day-to-day work more.
Baseline Requirements section 4.2.1 governs how long a CA may reuse its proof that you control a domain. That table falls faster than the lifetime table.
issued before issued on/after domain proof may be reused for
2026-03-15 398 days
2026-03-15 2027-03-15 200 days
2027-03-15 2029-03-15 100 days
2029-03-15 10 daysThe last line is not 47. It is 10.
From March 2029 a certificate lives 47 days, but the evidence that you own the domain is only good for 10. You will therefore be re-proving domain control more often than you replace the certificate itself.
If your organisation still validates by dropping a file on a web server or editing a DNS record by hand, this is the line that kills that practice. Not the 47.
A second table dropped quietly at the same time: organisation identity data for OV and EV certificates, previously reusable for 825 days, fell to 398 days on 15 March 2026.
Short-lived certificates, and what they get excused from
The standard has a special category called a Short-lived Subscriber Certificate, and its definition tightened on the same day the ceiling fell to 200.
issued 2024-03-15 through 2026-03-15 at most 10 days (864,000 s)
issued on or after 2026-03-15 at most 7 days (604,800 s)What you get for it is an exemption written plainly into section 4.9.1.1:
"The CA MAY support revocation of Short-lived Subscriber Certificates."
MAY, not SHALL — a short-lived certificate need not even be revocable, and need not appear in a CRL. Ordinary certificates live under a sentence that begins "With the exception of Short-lived Subscriber Certificates, the CA SHALL revoke a Certificate within 24 hours".
The logic is direct. If the certificate dies in seven days anyway, announcing that it is invalid arrives too late to help. The lifetime is the revocation mechanism.
And this is not theoretical. Measured the same day as the table above:
$ echo | openssl s_client -servername www.dga.or.th \
-connect www.dga.or.th:443 2>/dev/null \
| openssl x509 -noout -issuer -dates
issuer= /C=US/O=Google Trust Services/CN=WE1
notBefore=Aug 21 15:02:39 2026 GMT
notAfter=Sep 4 16:02:35 2026 GMTA Thai government agency is running 14-day certificates right now. Same issuer as this site, same policy OID (2.23.140.1.2.1, domain validated). The only difference is what the site operator asked for.
The CAs have opened the door already. Let's Encrypt publishes three profiles:
classic 90 days the default
tlsserver 45 days
shortlived 160 hours "6ish days" in their own words160 hours is 576,000 seconds, under the 604,800-second ceiling, so it lands inside the new short-lived definition exactly. And tlsserver at 45 days is rehearsing life under the 47-day ceiling three years early.
A day is 86,400 seconds
The detail that explains why nobody issues a certificate for exactly 200 days sits at the end of section 6.3.2:
"For the purpose of calculations, a day is measured as 86,400 seconds. Any amount of time greater than this, including fractional seconds and/or leap seconds, shall represent an additional day. For this reason, Subscriber Certificates SHOULD NOT be issued for the maximum permissible time by default, in order to account for such adjustments."
One second over is a whole extra day. So the standard writes every ceiling as a pair:
period SHOULD NOT MUST NOT
before 2026-03-15 397 398
2026-03-15 to 2027-03-15 199 200
2027-03-15 to 2029-03-15 99 100
from 2029-03-15 46 47The left column is the target; the right is the line you must not cross. A CA that issues exactly 200 days and then has a clock drift by one second has mis-issued, which leads to mass revocation and an incident report to the root programs.
Look back at the measured table and the 197, 198 and 199 stop being coincidence. They are each CA's chosen safety margin, and nobody dares touch 200.
What has to change in practice
If you are still renewing by hand, the number to look at is how often per year.
lifetime renewals/yr renew at 1/3 left real window
398 ~1 133 days very wide
200 ~2 67 days manageable
100 ~4 33 days getting tight
47 ~8 16 days must be automatedAt 47 days the window in which you can notice a failed renewal and still fix it is about two weeks, and it comes around eight times a year per certificate. An organisation with 300 domains faces 2,400 renewals a year. No team does that by hand.
The protocol for this is ACME, RFC 8555, published in March 2019 with authors from Let's Encrypt, the EFF and Cisco. It turns requesting and renewing a certificate into an API call rather than a form.
The problem that follows from everyone automating is that everyone renews at once. RFC 9773 of June 2025 adds an extension called ACME Renewal Information (ARI) so the server can tell clients when to come back. Its abstract gives the reason: to "mitigate load spikes and ensures that clients do not make false assumptions about appropriate certificate renewal periods".
ARI does something more important too. When a CA has to revoke certificates in bulk because of a mis-issuance, it can tell clients to renew early rather than emailing tens of thousands of people.
When it lies
"The certificate has not expired, so it is safe." Different subject entirely. The expiry date says when browsers stop accepting it, not whether the key is still a secret. Shorter lifetimes do not make certificates safer — they shorten how long an already-unsafe certificate stays usable.
"Shortening lifetimes made things safer immediately." No. Certificates issued before 15 March 2026 are still running their original clocks. The measured table above contains 396-day certificates that live on into April of 2027, and the rule only takes full effect once the old era has drained out.
"This is a 2029 problem." No. The 200-day step is enforced today, and the 100-day step lands on 15 March 2027, which is under seven months from the day this was written.
"Automate it and you are done." Not quite. A successful renewal does not mean the service loaded the new file. Plenty of software reads its certificate once at startup. The most common version of this failure is ACME renewing perfectly every time, a brand-new file on disk, and a web server still serving the old certificate out of memory until it genuinely expires.
"Short-lived certificates need less watching." The opposite. The shorter they are, the less time a mistake has to be caught before it becomes an outage.
Real cases from real work
Case 1 — work out which era your organisation is in
Situation You need to know which of your domains hits the wall first.
Command
$ for h in a.example.com b.example.com; do
echo | openssl s_client -servername $h -connect $h:443 \
2>/dev/null | openssl x509 -noout -subject -dates
doneReal output, two rows taken from the table measured above.
www.thaigov.go.th issued 2026-03-06 396 d ends 2027-04-07
scb.co.th issued 2026-04-23 199 d ends 2026-11-08How to read it The first was issued before the boundary and kept the old era's length — and when it renews in April 2027 it drops straight under the 100-day ceiling, because that date is past 15 March 2027. From 396 to 100 in a single renewal. The second has already made half the journey; its next renewal stays under 200.
What this does not prove We know when each certificate was issued and how long it runs. We do not know whether that organisation renews by hand or automatically. A long certificate does not imply manual, and a short one does not imply automated. Only the operator can answer that.
Case 2 — renewal succeeds but the site serves the old certificate
Situation Monitoring says a certificate is about to expire, even though ACME reported a successful renewal last week.
Command Compare the file on disk against what is actually served.
$ openssl x509 -in /etc/ssl/live/example.com/cert.pem \
-noout -enddate
notAfter=Nov 27 02:40:27 2026 GMT
$ echo | openssl s_client -servername example.com \
-connect example.com:443 2>/dev/null \
| openssl x509 -noout -enddate
notAfter=Sep 4 01:15:11 2026 GMTHow to read it The two values disagreeing is the whole answer. The file was renewed; the process listening on 443 is still holding the certificate it read at startup. The fault is not in ACME but in the post-renewal hook, which never told the service to reload.
What this does not prove We do not yet know which process is holding it. With several layers — a reverse proxy in front of an application — the stale copy could be at any one of them, and you have to walk the layers by connecting to each port directly.
Case 3 — read renewal history from the public record
Situation You want to know how often a site really renews without logging into anything. Every certificate a CA issues must be logged to Certificate Transparency.
Command
$ curl -s "https://crt.sh/?q=netkubelab.com&output=json" \
| python3 -m json.tool | head -40Real output, reduced to essentials and sorted by issue date.
issued expires days gap from previous
2026-04-20 2026-07-19 90 -
2026-06-18 2026-09-16 89 58 days
2026-08-16 2026-11-14 89 58 days
2026-08-23 2026-11-21 90 7 daysHow to read it The first two intervals are both 58 days on certificates lasting 89 to 90, which is renewal at about one third of life remaining — the convention among ACME clients, and the thing ARI formalises. The one seven days later is an out-of-band issuance, not a scheduled renewal.
What this does not prove CT logs the precertificate and the certificate as separate entries, so counting rows overstates how many issuances happened. And a managed platform may reissue for reasons unrelated to expiry, such as adding a hostname or moving machines. This evidence shows the rhythm; it cannot show the reason.
Case 4 — work out where it will hurt first
Situation Planning ahead of the 15 March 2027 boundary.
Command Walk every host and sort by how long its certificate runs.
$ for h in $(cat hosts.txt); do
d=$(echo | openssl s_client -servername $h -connect $h:443 \
2>/dev/null | openssl x509 -noout -enddate)
printf "%-30s %s\n" "$h" "$d"
done | sort -k2How to read it The hosts with the longest certificates are the ones that will hurt most — not because those certificates are bad, but because they are the systems that have never been forced to renew often, and are therefore the likeliest to have no automation at all. A 396-day certificate whose next renewal yields 100 days is a near fourfold increase in frequency, all at once.
What this does not prove This list only sees hosts you already know about that expose port 443 to the internet. Certificates on internal appliances, test machines, and services that only talk to each other inside the organisation never appear here — and they are usually the ones most forgotten.
Where this goes next
The schedule stops at 47 days in 2029, but nothing in the documents says that is the destination. The domain-validation reuse table already reaches 10 days, and Let's Encrypt will sell you a 160-hour certificate today.
The direction is clear enough: certificates are turning from a document you hold into something a system fetches and discards — the same shape DHCP imposed on IP addresses thirty years ago, when it stopped asking who owns an address and started asking who is borrowing it right now.
References
Standards
- CA/Browser Forum Baseline Requirements version 2.2.9, dated 6 August 2026 — section 6.3.2 for the lifetime table, 4.2.1 for the reuse tables, 4.9.1.1 for the short-lived exemption
- RFC 5280 the source of the validity-period definition that both Apple and the Baseline Requirements quote
- RFC 8555 ACME, March 2019
- RFC 9773 ACME Renewal Information, June 2025
Votes and announcements
- Ballot 193 the 825-day ceiling, passed unanimously in 2017
- Ballot SC022v2 failed in 2019, with every vote listed by name
- Ballot SC-081v3 the source of the current schedule and of the reasoning quoted here
- Apple's announcement of the 398-day ceiling, which no one ever voted on
Manuals
- Let's Encrypt certificate profiles the source of the 90-day, 45-day and 160-hour figures