Shorter SSL Certificate Lifetimes: Check Your Renewal Works

New public certificates run 200 days or less, and the limit keeps dropping. The old maximum was 398 days, about 13 months, so renewing once a year used to be enough. That habit no longer fits. This article covers what changed, how to list every certificate your business relies on, how to find out who renews each one, and how to confirm that renewal actually ran. At the end is a short script that warns you before any certificate runs out.

What changed for public SSL certificates?

Certificate authorities and browsers agreed to shorten public certificate lifetimes in fixed steps. The schedule below comes from CA/Browser Forum Ballot SC-081v3.

Source: CA/Browser Forum Ballot SC-081v3. The 398-day row is the rule the ballot replaced, and the ballot’s own schedule lists it.

Each limit applies to certificates issued on or after its date. A certificate you already installed keeps its original end date. Proof that you control a domain also stays valid for less time, and that reuse period shrinks on its own schedule.

This changes what “annual” means. An annual product still buys a year of coverage, but that year is several certificates in a row. ZeroSSL explains that its annual products now include several certificate issuances.

Free certificates follow their own plan. Let’s Encrypt announced a cut from 90-day to 45-day certificates by 2028. Its plan sets February 10, 2027 for a 64-day default.

Why are SSL certificate lifetimes getting shorter?

Shorter lifetimes limit the damage from a compromised certificate, as World Wide Technology explains, and they push owners to automate renewal. The ballot keeps cutting the limit in steps through 2029. Each step adds more manual renewals per year, and every one of them is a chance to forget.

Which certificates does your business depend on?

Every hostname that serves HTTPS or encrypted mail needs a valid certificate, so list them all, one line per hostname:

1. Main site: example.com
2. www: www.example.com, even if it only redirects
3. Mail: the hostname your phone or mail app connects to, such as mail.example.com
4. Subdomains: shop, booking, staging and client sites
5. Admin panels: any control panel or dashboard on its own hostname

For each line, record the hostname, issuer, end date, who renews it and how you get warned. Keep the list where your team can find it.

Who renews each certificate?

Each certificate is renewed by your host, by a renewal tool on your server, or by you, depending on where the hostname runs.

On web hosting

Open your hosting panel and find the SSL section for each domain. Look for a status that says renewal is automatic. If you bought a certificate elsewhere and pasted it in, renewing it is your job. If the panel says nothing either way, ask your host in a ticket and keep the answer with your list.

On a Linux VPS

A self-managed server renews only what someone set up. Run these on the server to see what exists:

sudo certbot certificates
systemctl list-timers --all | grep -i -e certbot -e acme
sudo crontab -l
crontab -l
ls /etc/cron.d

A “command not found” line just means certbot is not installed. If certbot certificates lists your hostnames, certbot manages them, and a matching timer or cron line means renewal is scheduled. Test it without touching live certificates:

sudo certbot renew --dry-run

If nothing shows up, renewal on that server is manual. Set up scheduled renewal before the next end date, following your renewal tool’s own documentation.

How do you check that renewal actually ran?

Read the certificate’s start date. If it is recent and nobody renewed by hand, automatic renewal worked. This command runs on macOS and Linux:

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

The output has three lines: issuer names the certificate authority, notBefore is the issue date and notAfter is the end date. Repeat for every hostname on your list. For mail, use IMAP port 993 instead of 443.

A browser check works too. In Chrome, open site details from the icon left of the address, then open the certificate details to read the dates.

How do you get warned before a certificate expires?

Run a small check at least once a week, daily if you can, on a machine that stays on, and make sure its output reaches a person. Don’t put it on a laptop. Laptops sleep and skip runs, and cron output there lands in local mail nobody reads.

Pick one of three ways to get the warning to a person:

• Chat message: the script below posts to a chat channel you read.
• Email: only from a server whose mail really sends and reaches an inbox you check.
• Uptime monitor: an outside monitor that tracks certificate expiry and emails or messages you.

#!/bin/sh
# cert-check.sh: warn when a TLS certificate is close to its end date.
# Usage: sh cert-check.sh example.com www.example.com mail.example.com:993
# Needs openssl (Linux and macOS). curl is used only for alerts.
DAYS=${DAYS:-21}
WEBHOOK_URL=${WEBHOOK_URL:-}
LIMIT=$((DAYS * 86400))
STATUS=0
for ARG in "$@"; do
  case "$ARG" in
    *:*) TARGET=$ARG; NAME=${ARG%%:*} ;;
    *)   TARGET=$ARG:443; NAME=$ARG ;;
  esac
  CERT=$(echo | openssl s_client -connect "$TARGET" -servername "$NAME" 2>/dev/null | openssl x509 2>/dev/null)
  if [ -z "$CERT" ]; then
    echo "FAIL $TARGET: no certificate received"
    STATUS=1
    continue
  fi
  END=$(printf '%s\n' "$CERT" | openssl x509 -noout -enddate | cut -d= -f2)
  if printf '%s\n' "$CERT" | openssl x509 -noout -checkend "$LIMIT" >/dev/null; then
    echo "OK   $TARGET expires $END"
  else
    echo "WARN $TARGET expires $END (less than $DAYS days left)"
    STATUS=1
  fi
done
if [ "$STATUS" -ne 0 ] && [ -n "$WEBHOOK_URL" ]; then
  curl -fsS -X POST -H 'Content-Type: application/json' \
    --data '{"text":"Certificate check failed. Run cert-check.sh to see which host."}' \
    "$WEBHOOK_URL" >/dev/null
fi
exit $STATUS

Save it as cert-check.sh on an always-on Linux server. In your chat app, create an incoming webhook for a channel. The script posts a JSON text field, which is the format Slack uses, so rename the field if your app expects another. Then run crontab -e and add these two lines with your own path and hostnames. This example runs every morning, which more than covers the weekly minimum:

WEBHOOK_URL=https://hooks.example.com/your-webhook
0 8 * * * /bin/sh /home/you/cert-check.sh example.com www.example.com mail.example.com:993 >/dev/null 2>&1

The cron line throws away the script’s own output on purpose, because the warning goes out through the webhook. Test the alert path once, with a window longer than any public certificate runs:

DAYS=400 WEBHOOK_URL=https://hooks.example.com/your-webhook sh cert-check.sh example.com

Every host should report WARN, and the chat message should arrive. No public certificate issued under the old or new rules runs 400 days. If no message shows up, fix the webhook before you rely on it.

The script can’t warn you when the server itself is down. For that, add an outside uptime monitor that checks your site from another network and emails you. With both in place, a dead server and an expired certificate each reach a person.

What do visitors see if renewal fails?

A full-page browser warning about the connection, instead of your site. To check what visitors see today, open each website hostname in a private window on your phone. A normal page load means the certificate is valid right now. The scheduled check covers the days after.

How does this work at PomeloHost?

PomeloHost web hosting includes free SSL. A KVM VPS is self-managed unless you add the managed option, and you get full root access. On a self-managed VPS, renewal is yours to set up. Outbound port 25 is closed by default and may be opened on request after review, so send VPS alerts through a chat webhook rather than local mail. The one-off openssl check above works against both services from any Mac or Linux machine.

What should you do this week?

Build the hostname list today, then read each start date and note who renews it. Run the dry run on any VPS. Schedule the check at least weekly on a server that never sleeps, and test the alert once. From then on, you hear about a certificate only when something is wrong.

Frequently asked questions

Do certificates already installed stop working when a new limit starts?

No. Each limit applies to certificates issued on or after its date. A certificate you installed earlier keeps the end date it was issued with. You see the change at your next renewal, when the replacement runs for a shorter time, so plan around that renewal rather than the schedule date.

Can I still buy a one-year SSL certificate?

You can buy a year of coverage, but not as one certificate. Annual products deliver several shorter certificates in a row. Each one has to be installed, by hand or by an automated tool. Installing by hand means repeating the job several times within the year, and automation takes that job off your list.

Do these limits apply to internal or private certificates?

The limits cover publicly trusted TLS certificates, the kind browsers accept without warnings. Certificates from a private certificate authority you run for internal tools follow your own policy. Anything your customers open in a browser, such as your website, shop or webmail, uses public certificates and falls under the schedule.

How often should a small business check its certificates?

Let a script check at least weekly, daily if you can, from an always-on server, and send failures to a chat channel you read. Once a quarter, review your hostname list for new subdomains or retired sites. New public certificates run 200 days or less, and the limit keeps dropping, so a yearly review comes too late.