Why Website Certificates Now Expire Every 200 Days

Website certificates now last 200 days at most, down from 398, and the limit falls to 47 days by 2029. A certificate is the digital file that lets your browser show the padlock and encrypt your connection. Shorter lifetimes shrink the damage when a certificate is stolen or a domain changes hands.

If you run a site, this is a calendar problem. If you only browse, it is a story about a quiet piece of internet plumbing getting a stricter schedule. Oddworldz covers how everyday internet machinery works, and this explainer is for anyone who has seen a certificate warning and wondered who decides when the padlock expires.

What Does a Website Certificate Actually Do?

A website certificate proves that a server controls a domain name and carries the public key used to encrypt your traffic. A trusted company called a certificate authority signs it. Your browser checks that signature before it shows the padlock.

Think of it as a passport for a web address. It names the holder, shows who vouched for them and carries an expiry date. When the date passes, browsers stop trusting it and show a full-page warning.

That expiry date is the part that is changing. For years the longest allowed lifetime crept down, from several years to 398 days. Now it is dropping on a fixed schedule, and the schedule is public.

The New Schedule: 200 Days, Then 100, Then 47

The change comes from a proposal called Ballot SC-081v3 at the CA/Browser Forum, the group where certificate authorities and browser makers agree on shared rules. The ballot passed in April 2025. According to the forum's own record of the ballot, the maximum validity falls from 398 days to 47 days, and the reuse of domain validation data falls from 398 days to 10 days.

The steps run on a calendar. Here is the schedule as reported by certificate authorities.

DigiCert, a large certificate authority, summarizes the same timeline in its explainer on the move to 47 days. It also records the vote. Twenty-five certificate authorities voted yes, none voted no, and all four browser vendors with a vote backed it.

Why Is the Limit Getting Shorter?

The limit is getting shorter because a certificate is a promise made on one day and trusted for months. During that time the domain can change owners, the encryption can age and the private key can leak. A shorter lifetime caps how long a bad certificate can keep working.

This is the same idea as an expiring card on a keycard door. Nobody assumes the cardholder turned dishonest. The expiry just forces a regular check that the right person still holds it.

The odd number 47 has a reason too. DigiCert reports that Apple's proposal built it from one 31-day month, half of a 30-day month and a single day of slack. It is a renewal window, not a cryptographic constant. Not everyone loved the pace. Some certificate authorities asked for a slower rollout, and the final vote kept the original timetable.

Who Is Affected by the Change?

Anyone who runs a site with a publicly trusted certificate is affected, from a one-page blog to a bank. Visitors notice nothing unless a renewal fails. The cost lands on whoever manages the server, the hosting plan or the content delivery network.

Many people never touch a certificate. Their host or website builder handles it. A host that already renews automatically will simply do it more often. Sites that depend on a person copying a file into a control panel once a year are the ones at risk.

Small organizations feel it differently from large ones. A big company has a security team and a tracking sheet. A volunteer-run club site may have a certificate that one person set up years ago and nobody has touched since. That is the case worth checking first.

Some systems cannot renew on their own. Older appliances, internal tools and devices with fixed software may need a vendor update or a different design. That is where most of the real pain sits, and it is why the schedule was spread over three years.

How Did We Get Here? A Short History of Shrinking Lifetimes

Certificate lifetimes have been shrinking for more than a decade, so the 2026 change is a continuation, not a surprise. Certificates once ran for several years. The cap fell to 39 months, then 825 days, and then 398 days after Apple announced in 2020 that Safari would stop trusting longer ones.

Each step met the same objection, that renewal would be a burden. Each step also pushed more people toward automation, and the web adapted. That track record is why browser makers felt confident asking for another big cut.

The pattern matters because it shows who holds the leverage. A certificate is only useful if browsers trust it, so a rule that browsers enforce becomes the rule for everyone. The forum vote made it official, but the browsers were always going to set the pace.

How Does Automatic Renewal Work?

Automatic renewal works through a protocol called ACME, which lets software prove control of a domain and fetch a fresh certificate without a person involved. A small program on the server runs on a timer, asks for a new certificate before the old one expires and installs it.

Let's Encrypt, a free certificate authority, shows what this looks like in practice. Its FAQ says its default certificates last 90 days and recommends renewing every 60. It also offers optional six-day certificates, renewed every three days.

The FAQ adds a detail that sounds trivial and is not. It asks software to renew at random times instead of exactly at midnight. If millions of servers all asked at the same second, the service would buckle. Randomness spreads the load, a small piece of internet etiquette hidden in a config file.

Oddworldz editors checked the schedule against both primary sources. The dates line up, and the main uncertainty is how quickly each hosting company moves.

What Goes Wrong When a Certificate Expires?

When a certificate expires, browsers block the page with a security warning, and apps that call the server may fail without any message at all. The server itself is fine. The proof of identity has simply gone out of date.

This looks a lot like other quiet expiry problems. A broken security signature once knocked many sites offline, as we explained in our look at the DNSSEC bug that hit .de domains. Expired certificates produce a similar effect, healthy machines that nobody can trust. Failures are also often deliberate on the server side, as in how internet shutdowns work, though a lapsed certificate is almost always an accident.

The common causes are mundane. A renewal job failed. A reminder email went to someone who left. A certificate was installed on one server and forgotten on another. More frequent renewals make each mistake smaller but also make forgetting more likely, which is the argument for automation.

How Can You Tell If Your Own Site Is Ready?

A site is ready if its certificate renews on its own and someone gets an alert when it does not. Check three things: who issues the certificate, how it renews and who is told on failure. If the answer to the second question is "a person remembers," that is the gap.

Use this short checklist to review a site.

Phones and other gadgets have their own version of this. They stop receiving security updates on a schedule, as our guide to how long phones get software updates shows. Digital trust nearly always has an end date, and it is better to know it than to be surprised.

Conclusion

The 200-day certificate limit is the first step in a three-year march toward 47-day certificates. The reasons are sensible, the schedule is public and the fix for site owners is automation. Visitors will mostly never notice, which is exactly the point.

If you manage a site, check today how its certificate renews. If you only browse, the next time a padlock appears, you will know it was signed recently and will be replaced soon. Oddworldz will keep tracking how the web's trust machinery changes as the dates arrive.