Why the padlock on your website keeps expiring sooner
Website certificates are shrinking from 398 days to 47 by 2029. Last weekend’s eMudhra key leak shows why browsers want them to expire fast.
The padlock in your browser’s address bar rests on a small file called a certificate. It proves the site really is the site it says it is, and it has an expiry date.
That date is coming closer. Until March this year, a certificate could last 398 days. From March 2029 the limit is 47.
The past few days gave a sharp lesson in why browsers want it that way.
Eight keys anyone could guess
On 17 October, a researcher reported a serious problem to the browser makers. Eight intermediate certificates run by eMudhra, an Indian certificate authority, had private keys that anyone could work out.
Intermediate certificates sit between a trusted root and a website’s own certificate. Whoever holds one of their keys can issue certificates that browsers trust. Six of these eight could sign website certificates, so a criminal with the keys could, in principle, mint a convincing padlock for almost any site.
Mozilla’s bug report says the keys were tiny numbers, below 256, which is why anyone could recover them. eMudhra’s preliminary explanation, not yet independently checked, blames a flawed key-generation script and “human errors in multiple steps”.
The browsers moved fast. Chrome’s root program says it pushed a block on the six website-signing intermediates less than two hours after the report arrived. Mozilla says its block reached Firefox users with standard settings in under three hours, and it released Firefox 158.0.1 on 20 October.
Chrome adds that no website certificates from those six intermediates had appeared in Certificate Transparency before its block. These are the public logs where trusted certificates are meant to be recorded. eMudhra revoked all eight on 18 October and estimates about 30,000 of its customers’ certificates need to move to a new chain.
Cancelling a certificate doesn’t really work
The eMudhra case worked out because browser makers could push an emergency block. For an ordinary certificate that goes bad, the system has always leant on revocation: the certificate authority publishes a list saying “don’t trust this one any more”.
The trouble is that revocation is patchy. The CA/Browser Forum ballot that set the new limits, proposed by Apple, says revocation checks “do not adequately protect relying parties”. Many parties have to act for it to work, and checks time out.
Let’s Encrypt, the free certificate authority, went further. It switched off its live revocation-checking service, called OCSP, on 6 August 2025, and now publishes revocation lists only. At its peak, that service handled about 340 billion requests a month.
If you can’t count on cancelling a bad certificate, the next best thing is for every certificate to die young. A stolen key or wrongly issued certificate is then only useful for weeks, not a year.
Three more reasons for a short life
The ballot gives other reasons too:
- Facts go stale. A certificate is a snapshot. If a domain lapses or someone else gets hold of the key, an old certificate can still vouch for the wrong party.
- Checks happen more often. Shorter certificates mean proving you control the domain more often. From 2029, a certificate authority can reuse that proof for only 10 days.
- Faster upgrades. When a cryptographic method turns out to be weak, the ballot says retiring it “is typically a complex process”. Short certificates let the whole web move on sooner.
The timetable
The ballot passed in April 2025 with no votes against. Apple, Google, Microsoft and Mozilla all voted yes. The Baseline Requirements, the rules certificate authorities must follow, now set these maximum lives:
| From | Longest certificate allowed |
|---|---|
| 15 March 2026 | 200 days |
| 15 March 2027 | 100 days |
| 15 March 2029 | 47 days |
Let’s Encrypt is going shorter than the rules require. Its plan, published in December 2025, moves its default to 64 days in February 2027 and 45 days in February 2028. Our story on Let’s Encrypt’s move to 64-day certificates covers what that means for renewal scripts.
Robots do the renewing
Nobody expects a person to renew a certificate every six weeks by hand. The answer is a protocol called ACME, standardised in 2019, which lets software prove it controls a domain and fetch a new certificate automatically.
In eMudhra’s case, the company told Mozilla about 97% of the 30,000 certificates it needs to move had been issued through ACME. So even at a commercial certificate authority, software was already doing nearly all the work.
The ballot’s authors admit automation is “not a panacea”. The sites at risk are the ones where a person still buys a certificate, downloads it and installs it by hand once a year. That routine already broke when the limit fell to 200 days in March, and it gets harder at 100 days in 2027 and 47 in 2029. Miss a renewal and browsers show visitors a security warning instead of your site.
Checklist
- Find out how your website’s certificate is renewed. Ask your host or developer whether it renews automatically or someone installs it by hand.
- Move hand-installed certificates to automatic renewal now. The longest allowed certificate is already 200 days, and it drops to 100 days on 15 March 2027.
- Set an expiry alert. Have someone notified well before any certificate runs out, so a failed renewal doesn’t take the site down.
- Update Firefox if it’s behind. Firefox 158.0.1 adds Mozilla’s eMudhra block for anyone whose settings stopped the automatic fix.
Tick items as you go. Your ticks stay in this browser.
