An SSL certificate is a small digital file installed on a web server that lets a browser check it has reached the genuine website and set up an encrypted connection to it. It is what makes the address start with https:// instead of http://. If the certificate is missing, wrong or expired, browsers show a security warning, and many visitors will leave rather than click through.
The name is a little out of date. SSL was the original protocol; today's connections use its successor, TLS. Most providers still say "SSL certificate", so this article uses both terms.
What a certificate actually does
When someone opens your site, their browser and your server agree how to encrypt the traffic between them. The certificate plays two parts in that exchange:
- Identity: it is issued for specific domain names and signed by a certificate authority (CA) that browsers trust. The browser checks that the name on the certificate matches the address being visited.
- Encryption setup: it carries the public key that is used to establish a private, encrypted session, so form entries, logins and payment details cannot easily be read or altered in transit.
A certificate does not make the website itself secure. It protects the connection; the application, server and accounts behind it still need their own care.
Every certificate has an expiry date
Certificates are only valid for a fixed period. When that period ends, browsers stop trusting the certificate and visitors see a warning page, even if nothing else on the site has changed. Expiry can also break connections visitors never see, such as an app calling your API.
That period is getting much shorter. The CA/Browser Forum, the body of certificate authorities and browser makers that sets the rules for publicly trusted certificates, approved ballot SC-081 in 2025. It reduces the maximum lifetime in steps:
- 398 days for certificates issued before 15 March 2026
- 200 days from 15 March 2026
- 100 days from 15 March 2027
- 47 days from 15 March 2029
Let's Encrypt, the free CA used by many websites, already issues shorter certificates. In an announcement on 7 October 2026 it said that from 10 February 2027 its certificates will last 64 days by default instead of 90, ahead of a planned move to 45 days in 2028. Existing certificates will not be revoked; the last 90-day ones should expire around 11 May 2027. It is also cutting how long a domain authorisation can be reused, from 30 days to 10 days, and to seven hours in 2028.
The stated reason for the change is to limit the damage if a certificate's private key is exposed or a certificate is issued by mistake: a shorter life means a shorter window for misuse.
What this means in practice
Renewing by hand once a year was manageable. With lifetimes measured in weeks, one missed date takes the site down, so renewal needs to be automated.
Most automated renewal uses ACME, a standard protocol that tools such as Certbot and acme.sh, and many hosting platforms, use to request and install certificates without a person involved. Let's Encrypt recommends:
- Use a client that supports ARI (ACME Renewal Information). ARI lets the CA tell your client when to renew, so a change in lifetime is handled automatically.
- Remove fixed renewal timings. Scripts set to renew after a fixed number of days were often written for 90-day certificates. Let's Encrypt suggests renewing at about two-thirds of the lifetime instead.
- Test before the switch. Let's Encrypt planned to start issuing 64-day certificates in its staging environment on 14 October 2026 so teams can test first.
- Automate the whole chain. A renewed certificate is no use if the web server, load balancer or CDN keeps serving the old one. Reloading and deployment should be part of the automated process.
- Alert on failure. Renewal can fail quietly after a DNS or firewall change, so someone should be notified well before expiry.
Illustrative example: A company's main website renews automatically through its hosting platform, but a booking subdomain set up years ago on a separate server still relies on a script with a fixed renewal date. The main site keeps working; the booking page starts showing a browser warning. A list of every domain using a certificate would have caught it.
Where to start
- List every domain and subdomain that serves HTTPS, including APIs, admin panels and staging sites.
- For each one, note who issues the certificate, how it is renewed and where it is installed.
- Check whether renewal is automated end to end, and whether the tool supports ARI.
- Add certificate expiry to your website monitoring so an approaching date raises an alert.
- Agree who responds when renewal fails, for example as part of a software support SLA.
If you use a commercial CA or your hosting provider manages certificates for you, ask how they are handling the new limits. For help keeping launched systems monitored and maintained, see technine.io's Managed Support & SLA service.
Frequently asked questions
Are SSL and TLS certificates different things?
No. "SSL certificate" is the common name; the certificate is used with the TLS protocol, which replaced SSL. Providers use the two terms interchangeably.
Does a paid certificate last longer than a free one?
Not beyond the industry limit. The CA/Browser Forum maximums apply to all publicly trusted certificates, so paid certificates will also move to shorter lifetimes on the same schedule.
Do I need to do anything if renewal is already automatic?
Possibly not, but check. Confirm that your tool does not rely on fixed renewal timings, that the renewed certificate is actually deployed, and that someone is alerted if renewal fails.