SSL certificate validity drops to 100 days in March 2027

From 15 March 2027 no newly issued public TLS certificate, still usually called an SSL certificate, may be valid for more than 100 days. The limit is set by the CA/B Forum Baseline Requirements, the rules every certificate authority has to follow. Let’s Encrypt moves first: from 10 February 2027 its certificates will last 64 days by default.

If your certificate renews itself, all you need to check is that someone hears when a renewal fails. A certificate installed by hand will have to be replaced at least three times a year from March, and in practice four.

The limit falls from 200 to 100 days

A certificate issued before 15 March 2026 could be valid for 398 days, just over a year, which is where the habit of a yearly swap comes from. The limit has been 200 days since 15 March 2026, so a certificate issued today won’t last even seven months. From 15 March 2027 it falls to 100 days, and from 15 March 2029 to 47.

Check the issuer and the expiry date

Your browser shows the issuer and the expiry date in the certificate details when you click the icon next to the address. For several hostnames this command is quicker; it runs on Linux with OpenSSL 1.1.1 or 3.x, with your own hostname in both places:

echo | openssl s_client -connect shop.example.com:443 \
  -servername shop.example.com 2>/dev/null \
  | openssl x509 -noout -issuer -enddate -checkend 1209600

The first line of output is the issuer and the second is notAfter, the expiry date. The number 1209600 is 14 days in seconds. With less time left, OpenSSL adds “Certificate will expire” and exits with an error, so the same command can go into a script that raises an alert.

The issuer is a good clue to who renews the certificate: Let’s Encrypt and Amazon usually mean automation, while with Sectigo or DigiCert someone most often bought a file and installed it by hand. Check every hostname separately, because a customer portal or a VPN gateway often has a different certificate from the website. Behind a proxied Cloudflare record or CloudFront the command shows the CDN’s certificate, so run it once more on the server itself, with 127.0.0.1:443 after -connect.

Where Let’s Encrypt renewal breaks

Let’s Encrypt stopped sending expiry reminder emails on 4 June 2025. According to the certbot documentation, versions before 4.0 renew a certificate 30 days before expiry and 4.0 onwards once less than a third of its lifetime remains, so certbot renew run from a timer or cron is in time either way.

A certificate issued with --manual, often a wildcard with a DNS record added by hand, won’t renew on its own unless certbot gets a script that adds the record. Let’s Encrypt suggests checking home-made scripts and cron jobs with a fixed interval, because they may now run too late. A web server that is never reloaded keeps serving the old certificate, so pass the reload command to certbot’s --deploy-hook and certbot will run it after every successful renewal.

ACM with email validation waits for a click

Since 18 February 2026 AWS Certificate Manager has issued public certificates valid for at most 198 days, and AWS says customers need to do nothing. With DNS validation, ACM renews the certificate on its own as long as it is in use by an AWS service, a load balancer for example, and ACM’s CNAME records are still in DNS.

With email validation, ACM sends an email 45 days before expiry to addresses such as admin@ and webmaster@ at your domain. The certificate renews only after someone clicks the link in it, so with 198-day certificates someone has to click roughly every five months. You can’t switch the validation method to DNS, so you have to request a new certificate with DNS validation and swap it in on your services. It is worth doing now, because from 15 March 2028 the CA/B Forum rules forbid certificate authorities from validating by email to those addresses.

Hand-installed certificates are slow to replace

In October 2026 the main browsers stopped trusting eight intermediate certificates of the certificate authority eMudhra, all within three days. Where certificates are installed by hand, the site then has to wait for a new certificate and for someone to install it.

What it means for a small team

This week, check every hostname you use, in the browser or with the command, and note who issued each certificate.

With Let’s Encrypt there is nothing to replace, but nobody will warn you when renewal breaks. Add monitoring that alerts you 14 days before expiry. I can also run it alongside uptime and disk alerts as part of server maintenance.

In ACM, only the certificates with email validation need replacing: the ones someone approved by clicking a link in an email from Amazon. Request new ones with DNS validation before the next email arrives.

Replace a commercial certificate you install by hand wherever you can: on an ordinary server with one from Let’s Encrypt, and on a load balancer or CloudFront with one from ACM. Where you can’t, put the expiry dates in a calendar and in your monitoring. Do it before 15 March 2027 or, failing that, get your next commercial certificate issued before that day, because it can still be valid for up to 200 days instead of 100.