SSL certificates now expire faster: what changes for you
New SSL certificates last at most 200 days, and only 47 from 2029. What that means for your site, three questions for your host, and a checklist.
A customer sends you a screenshot. Your website is hidden behind a full-page warning that says the connection is not private. Nobody attacked the site. Its SSL certificate reached its expiry date and nobody replaced it.
Until this year that could happen once a year. Under rules that began to apply in March 2026 it can happen several times a year, unless software does the replacing. If your certificate already renews automatically, nothing breaks, and your only job is to confirm that it does. If a person renews it by hand, this post gives you the dates and the questions to ask.
The new limits and their dates
An SSL certificate is the file on your server that lets a browser show the padlock and encrypt what visitors send. The modern name of the technology is TLS, but most people still say SSL, so this post does too. Every certificate carries an expiry date. Once that date passes, browsers show a full-page warning in place of your site.
In April 2025 the CA/Browser Forum, the body where certificate authorities and browser makers agree the rules, approved a schedule that shortens the maximum life of public certificates. The maximum had been 398 days. The schedule cuts it in three steps:
- certificates issued from 15 March 2026 live at most 200 days;
- from 15 March 2027, at most 100 days;
- from 15 March 2029, at most 47 days.
The first step is already in force. Apple, Google, Microsoft and Mozilla supported the schedule, for two reasons. A stolen or wrongly issued certificate stays dangerous for less time. And a short life forces renewal to be automated.
Renewing by hand once a year is over
The old routine was manageable. Someone bought a one-year certificate, installed it on the server and put a reminder in a calendar. Under the new limits the same job comes round twice a year now, four times a year from 2027, and about every six weeks from 2029. Nobody keeps that up by hand without missing a date.
Paying for a year does not change this. A certificate bought "for one year" is now reissued several times within that year, and every reissue has to be installed on the server. If a person does the installing, every reissue is a chance to forget.
In practice, software has to request the certificate, install it and switch it on, with no person involved. A person should hear about it only when a renewal fails.
Where certificates get missed
Automatic renewal is already common on current hosting, and a site set up that way will pass all three dates without anyone noticing. The outages come from the corners nobody is watching:
- A certificate installed by hand by someone who has left. A freelance developer bought it from an account of their own, uploaded it and moved on. Nobody in the company knows where it came from or when it ends.
- Certificates on things other than the website. The mail server, the hosting control panel, the address your mobile app or accounting system connects to (an API), a device you reach through a web address. When one of these expires there is often no warning page. Phones stop fetching mail, or the app shows an error, and the cause can take hours to find.
- Expiry notices sent to an address nobody reads. The warning emails go to whoever ordered the certificate: a former employee, the agency that built the site, a personal mailbox. It is the same administrative gap through which companies lose their own domain name.
- A move to a new host. The certificate does not follow the site. It has to be issued on the new server before visitors are sent there, which is one of the steps in moving a website without downtime.
Mail hides the problem longest. When Outlook or a phone shows a certificate warning, people tap "continue anyway", and nobody hears of it until a new device refuses to connect.
Three questions for your host or developer
- Is issuing and renewing automatic? Ask about every certificate, including the ones outside the main site. If the answer mentions a reminder, or "we do it every year", it is manual.
- Who is alerted if a renewal fails? Automation breaks too, for example after a DNS record is changed or the domain is moved. The alert has to reach a named person while the old certificate is still valid.
- Which certificates do we have beyond the main site? Ask for a written list: the name each one covers, where it is installed, its expiry date and whether it renews by itself.
If nobody can answer the third question, build the list yourself with the checklist further down.
Free or paid: which certificate you need
Free certificates that are issued and renewed automatically are widely available, and many hosting plans include one. Not every host does, so read what your plan says. To a visitor, a free certificate and a paid one look the same: the same padlock, the same encryption.
The difference lies in what was checked before the certificate was issued. A basic certificate confirms that you control the domain. An organisation-validated certificate, often shortened to OV, goes further. The issuer checks that the company exists, and the company's name is written inside the certificate for anyone who opens its details.
Some banks, some tender documents and some corporate IT policies still require an organisation-validated certificate from the companies they deal with. If one of them asks, buy what they specify. If nobody asks, the free automatic certificate does the job.
A paid certificate follows the same shrinking limits. Before you buy one, ask the seller how each reissue will reach your server without someone uploading it by hand.
A five-line checklist to hand over
Give this to whoever runs your website and ask for it back filled in:
- List every certificate the company uses: website, mail, control panels, API addresses, devices. For each one, note where it is installed and when it expires.
- Mark each one automatic or manual. Give every manual one a named owner and a date by which it will be automated.
- Send expiry and failure notices to a shared company address that more than one person reads.
- Add an outside check that looks at the expiry dates and warns while there is still time to act.
- Write down who to call when the warning page appears, and where the logins for the hosting and certificate accounts are kept.
SSL on PearlFibers hosting
Every PearlFibers hosting plan includes a free SSL certificate, so each site hosted with us is served over HTTPS. The certificates are issued and renewed automatically, and SSL for each site sits in the Loop portal beside its files and databases. If your site is hosted elsewhere and nobody can answer the three questions above, write to us with the address and what you know about how it was set up.