TLS certificate expiry has a new rhythm, and October 1 is the first date on which it shows. Since March 15, 2026, publicly trusted certificates may last at most 200 days, down from 398. Do the calendar arithmetic and a certificate issued on March 15 at the maximum length runs out on October 1.

Not every certificate was issued that day, of course. Still, renewals can cluster around a changeover whenever a team reissues in batches, and that makes this week a sensible time for an audit.

Sectigo’s chief compliance officer, Tim Callan, went further in a March 30 opinion piece for TechRadar, predicting major internet instability around October 1 from certificates that were issued under the new limit and then forgotten. That is a vendor executive’s forecast, not an enforced deadline, and nothing in browsers or servers changes on the date itself. The useful part is the checklist underneath it, which this guide turns into commands.

What follows covers why the limit exists, how to inventory every certificate you own, how to test renewal, how to alert on expiry, and what the next two cuts will demand.

What Changed and What Comes Next

The schedule comes from CA/Browser Forum ballot SC-081v3, which steps maximum certificate validity down from 398 days to 47 between March 2026 and March 2029. DigiCert documents the milestones and notes that it issues certificates one day shorter than each limit, which is why its cap under the 200-day rule is 199 days.

Forum limit takes effectMaximum validityDigiCert issues up toDomain-validation reuse
March 15, 2026200 days199 days200 days
March 15, 2027100 days99 days100 days
March 15, 202947 days46 days10 days

Validity and DigiCert figures come from DigiCert’s notice. The validation-reuse column comes from the TechRadar piece. Two consequences follow. A once-a-year renewal habit no longer works at all, and a quarterly calendar reminder will stop working in March 2027. Anything renewed by hand needs a process that survives the next two cuts.

Step 1: Build the Inventory From the Outside

Start with what the public internet can see. Certificate Transparency logs record every publicly trusted certificate issued for your domains, including ones nobody on your team remembers requesting. The community search site crt.sh queries those logs, and a wildcard search on your domain lists every name with its expiry date.

Terminal listing certificate expiry dates
curl -s "https://crt.sh/?q=%25.example.com&output=json" \
  | jq -r '.[] | [.name_value, .not_after, .issuer_name] | @tsv' | sort -u

Replace example.com with your own domain. Expect noise, since the output includes expired entries and a single name_value field can hold several names separated by newlines. Because crt.sh is community-run, it is also prone to rate limits and slow responses, so retry before concluding something is missing.

Step 2: Probe Every Live Endpoint

Transparency logs say what was issued. They do not say what a server is presenting right now. For that, ask the server.

echo | openssl s_client -connect www.example.com:443 -servername www.example.com 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates

Pass -servername every time. A server hosting many sites returns its default certificate without it, and you end up auditing the wrong one. The -checkend option turns the same check into an exit code, which is what scripts want: it takes a number of seconds and returns a non-zero status if the certificate expires within that window.

#!/usr/bin/env bash
# hosts.txt holds one host:port per line
while read -r target; do
  host="${target%%:*}"
  if echo | openssl s_client -connect "$target" -servername "$host" 2>/dev/null \
      | openssl x509 -noout -checkend $((30*86400)) >/dev/null; then
    echo "ok     $target"
  else
    echo "CHECK  $target"
  fi
done < hosts.txt

Read a CHECK line as either expiring within 30 days or unreachable, then look at the host. Not everything speaks HTTPS, either. The -starttls option covers SMTP, IMAP and other protocols, so mail servers get the same treatment.

openssl s_client -starttls smtp -connect mail.example.com:587 -servername mail.example.com
openssl s_client -starttls imap -connect mail.example.com:143 -servername mail.example.com

Step 3: Look Inside the Machines

Some certificates never face the internet: internal APIs, message brokers, database listeners, VPN gateways. Look where they live. On Windows servers, the machine certificate store is the first stop.

Get-ChildItem Cert:\LocalMachine\My |
  Where-Object { $_.NotAfter -lt (Get-Date).AddDays(30) } |
  Sort-Object NotAfter |
  Format-Table Subject, NotAfter, Thumbprint

On Linux, a crude sweep of the usual directories finds files worth opening. Adjust the paths to wherever your services keep their keys and chains.

find /etc -type f \( -name "*.pem" -o -name "*.crt" \) 2>/dev/null | while read -r f; do
  openssl x509 -noout -enddate -in "$f" 2>/dev/null | sed "s|^|$f |"
done

Kubernetes clusters running cert-manager can list every managed certificate with kubectl get certificates -A. The cert-manager documentation is explicit about timing. The default spec.duration is 90 days. The spec.renewBefore field has no default, and when neither it nor renewBeforePercentage is set, renewal happens at two thirds of the certificate’s lifetime. Durations use Go-style units of seconds, minutes and hours only, so 90 days is written as 2160h. The documentation also recommends renewBeforePercentage over an absolute window, because it prevents renewal loops when the issuer returns a shorter lifetime than you requested.

Step 4: Check That Renewal Actually Works

An inventory shows what exists. A renewal test shows whether it will keep existing. With Certbot, a dry run requests test certificates from the Let’s Encrypt staging environment and saves nothing, which makes it safe on a live server.

Calendar with certificate renewal dates marked
sudo certbot certificates
sudo certbot renew --dry-run

The first command lists each certificate with its names, expiry date and days remaining. The second exercises the whole renewal path. According to the Certbot documentation, pre and post hooks run during a dry run, but deploy hooks run only when you add --run-deploy-hooks.

Check which timing rule your version applies. Certbot 4.0.0 and later renews when less than one third of the lifetime remains, and older releases used a fixed 30 days. Both are fine at 200 days. They diverge as lifetimes shrink: a fixed 30-day window renews a 47-day certificate after 17 days, while the one-third rule renews it after about 31.

Then confirm that something is running the renewal at all. The documented manual setup calls certbot renew -q at midnight and noon with a random delay of up to an hour, and your package may have installed a systemd timer instead. systemctl list-timers shows which.

sudo certbot renew --deploy-hook "systemctl reload nginx"

One detail deserves attention. The documentation says a failing hook does not directly change the exit code, and renew exits non-zero only when a renewal attempt itself fails. A certificate that renewed on disk but never reached the running server can therefore look healthy to the scheduler. That gap is the reason for the next step.

Step 5: Alert on What the Server Presents

Monitoring from the outside looks at the certificate clients actually receive. The Prometheus blackbox exporter publishes the expiry of the earliest-expiring certificate it sees as probe_ssl_earliest_cert_expiry, and a Grafana write-up shows the alert expression in one line.

groups:
  - name: tls
    rules:
      - alert: TLSCertificateExpiringSoon
        expr: probe_ssl_earliest_cert_expiry - time() < 86400 * 30
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Certificate on {{ $labels.instance }} expires in under 30 days"

Thirty days is a comfortable warning at today’s lifetimes. Choose the threshold relative to the lifetime you expect, though. If certificates renew when a third of their life remains, a 47-day certificate sits at about 16 days left right after a healthy renewal, and a flat 30-day alarm would fire through half of every cycle.

Step 6: Plan for 100 Days and 47 Days

The audit is only the first pass. The harder question is which systems still depend on a person, and the answer usually includes the following.

Padlock icon on a browser address bar
  • Systems that take certificates by hand, such as load balancers, VPN gateways, printers and mail appliances. Each needs a route to ACME or an API call, or a replacement plan.
  • Third-party services that hold a certificate for your domain. Ask each vendor how they renew and whether you must re-validate the domain.
  • Domain validation itself. The reuse window for validation data shrinks with certificate lifetimes and falls to 10 days by 2029, so DNS or HTTP challenges must be repeatable on demand.
  • Runbooks that mention a yearly renewal. Rewrite them around automation and failure alerts.

The vendor checklist in the TechRadar piece boils down to discovering certificates, inventorying vendor dependencies, mapping automation with ACME as the preferred protocol, planning for frequent renewals, and building crypto agility. The steps above cover the first three.

Common Questions

Will certificates break on October 1?

Nothing changes in browsers or servers on that date. A certificate stops working at its own expiry time, and for one issued at the maximum length on March 15, that moment arrives on October 1. Anything renewed on schedule is fine. The risk sits with certificates nobody is renewing.

Does the limit apply to my private CA?

The Forum’s rules are mandatory for public certificate authorities. A private CA follows whatever policy you set, although matching lifetimes makes internal and public certificates easier to renew in one process.

Why does DigiCert say 199 days?

DigiCert caps its certificates one day below each Forum limit so that it never exceeds the allowed maximum.

How often should I run these checks?

Daily for the external probe, since it is cheap and catches the server-side gap described above. A weekly look at transparency logs is enough for most teams.

Sources