---
title: 47-day SSL certificates: what breaks and how to stay ahead
description: Public TLS certificates already max out at 200 days, drop to 100 in March 2027 and to 47 in March 2029, and proof of domain control will be reusable for only 10 days. Here is the exact CA/Browser Forum schedule, the setups that will break first, and a checklist for automating renewal and checking what your servers actually serve.
canonical: https://watchfor.io/blog/47-day-ssl-certificates
---

# 47-day SSL certificates: what breaks and how to stay ahead

2026-10-03 · WatchFor Team · Networking · ssl, certificates, security, automation

Public TLS certificates already max out at 200 days, drop to 100 in March 2027 and to 47 in March 2029, and proof of domain control will be reusable for only 10 days. Here is the exact CA/Browser Forum schedule, the setups that will break first, and a checklist for automating renewal and checking what your servers actually serve.

On 15 March 2026 the longest a publicly trusted TLS certificate can live
dropped from 398 days to 200. Most teams didn't notice, because a
certificate issued the day before was still good for thirteen months. The
next steps are harder to miss: 100 days from March 2027, and 47 days from
March 2029.

Forty-seven days means renewing roughly every month. If you renew at two
thirds of the lifetime, as Let's Encrypt recommends, that's every 31 days, or
about twelve renewals a year for each certificate you run. Anything that
still depends on a person, a calendar reminder or a file copied to a box by
hand will fail on that schedule. Not dramatically, just one Saturday at a
time.

This post covers the exact schedule from the source, the setups that tend to
break first, and a checklist for automation and monitoring that works whether
or not you use WatchFor.

## The CA/Browser Forum schedule, with exact dates

The change comes from ballot
[SC-081v3](https://cabforum.org/2025/04/11/ballot-sc081v3-introduce-schedule-of-reducing-validity-and-data-reuse-periods/),
"Introduce Schedule of Reducing Validity and Data Reuse Periods". It was
proposed by Apple and endorsed by Sectigo, Google Chrome and Mozilla. Voting
closed on 11 April 2025: 25 certificate issuers voted yes, none voted no and
five abstained, and all four browser makers (Apple, Google, Microsoft,
Mozilla) voted yes. It entered the
[TLS Baseline Requirements](https://github.com/cabforum/servercert/blob/main/docs/BR.md)
as version 2.1.5, effective 16 May 2025.

Two tables in the Baseline Requirements matter. Section 6.3.2 sets the
maximum validity of a certificate. Section 4.2.1 sets how long a CA may
reuse an earlier check that you control a domain (and, separately, how long
it may reuse checks of your organization's identity).

| Certificate issued | Max validity | Domain validation reuse | Identity data reuse (OV/EV) |
| --- | --- | --- | --- |
| Before 15 Mar 2026 | 398 days | 398 days | 825 days |
| 15 Mar 2026 to 14 Mar 2027 | **200 days** | 200 days | 398 days |
| 15 Mar 2027 to 14 Mar 2029 | **100 days** | 100 days | 398 days |
| From 15 Mar 2029 | **47 days** | **10 days** | 398 days |

A few details in the text are worth knowing:

- The limits are hard maximums (MUST NOT exceed), with a softer target one
  day shorter: certificates SHOULD NOT exceed 199, 99 and 46 days. A day is
  counted as exactly 86,400 seconds, and any extra second counts as another
  day, so CAs are told not to issue for the full maximum by default.
- It only covers **publicly trusted TLS server certificates**. Certificates
  from your own internal CA, S/MIME and code signing aren't affected by this
  ballot.
- The ballot gives the reasons itself: a certificate is a snapshot of facts
  that drift over time, revocation (CRLs, OCSP) doesn't protect people
  reliably at internet scale, and short lifetimes make it possible to move
  off a broken algorithm quickly.

### The 10-day reuse period is the part people miss

Shorter certificates get the headlines. The domain validation column changes
more. Today a CA can issue a certificate based on a domain check you passed
months ago. From March 2029 that check is only good for 10 days, so in
practice **every renewal includes a fresh proof of control**: the HTTP-01
token has to be reachable, or the DNS-01 TXT record has to be written, every
single time.

Let's Encrypt is moving faster than the minimum. Its
[December 2025 announcement](https://letsencrypt.org/2025/12/02/from-90-to-45/)
sets out its own timeline:

- **13 May 2026:** the opt-in `tlsserver` ACME profile issues 45-day
  certificates.
- **10 February 2027:** the default `classic` profile moves to 64-day
  certificates with a 10-day authorization reuse period.
- **16 February 2028:** `classic` moves to 45-day certificates, and
  authorization reuse drops to 7 hours.

The same post warns that "renewing certificates at a hardcoded interval of 60
days will no longer be sufficient" and recommends renewing at about two
thirds of the lifetime. Let's Encrypt also
[stopped sending expiry reminder emails](https://letsencrypt.org/2025/01/22/ending-expiration-emails/)
on 4 June 2025. If that email was your safety net, it has been gone for over
a year.

There is some relief on the validation side. A newer method,
[DNS TXT Record with Persistent Value](https://github.com/cabforum/servercert/blob/main/docs/BR.md#322422-dns-txt-record-with-persistent-value)
(ballot SC-088), lets you publish one `_validation-persist` TXT record that
names your CA and your ACME account, so the record doesn't change on every
renewal:

```text
_validation-persist.example.com. IN TXT "authority.example; accounturi=https://authority.example/acct/123"
```

It's in the Baseline Requirements now. Let's Encrypt calls it DNS-PERSIST-01
and said in December 2025 that it expected to offer it during 2026, so check
whether your CA supports it before planning around it.

## What breaks when certificates last 47 days

None of the failures below are new. They are the ones that already cause
[expired-certificate outages](/blog/ssl-certificate-expiry) once a year. At
twelve renewals a year they get twelve chances.

### Manual renewals

A CSR generated on a laptop, pasted into a CA portal, the certificate emailed
to someone who installs it. That process works once a year because someone
remembers. It doesn't survive monthly. Count your manual certificates and
multiply by twelve: that's the number of chances per year to get it wrong,
each needing the one person who knows how.

### Load balancers, CDNs and appliances

The ACME client renews on one server, but the certificate actually facing
users lives somewhere else: a hardware load balancer, a cloud load balancer
with an uploaded certificate, a firewall's VPN portal, a NAS, a printer's
admin page, a CDN with a custom certificate. The renewal succeeds. Nobody
copies the new file to the place that serves it.

Managed certificates from your cloud are not a free pass either. AWS
Certificate Manager, for example,
[renews DNS-validated certificates](https://docs.aws.amazon.com/acm/latest/userguide/dns-renewal-validation.html)
only while the certificate is in use by an AWS service and the CNAME
validation records it gave you are still in public DNS. Delete those records
in a zone cleanup and renewal stops.

### Pinned and embedded certificates

Mobile apps that pin the leaf certificate, IoT firmware with a certificate
baked in, partner integrations that allowlist your certificate's fingerprint.
Each of these breaks on every renewal by design. With 47-day certificates
that's monthly. If you must pin, pin a public key you control (with a backup
key), or the CA, never the leaf.

### Internal CAs

The ballot doesn't touch your private CA, and that is exactly the risk. The
internal certificate issued for five years in 2021, with no automation and
no monitoring, expires in 2026 on the VPN concentrator or the internal API
gateway. Shorter public lifetimes push teams to automate the public side,
while the internal side stays on a spreadsheet. Use the same tooling for
both: an internal ACME server such as step-ca, or Kubernetes cert-manager
with an internal issuer, gets you the same renewal loop.

### ACME automation gaps

Automation fails quietly. The usual causes:

- **Hardcoded schedules.** A cron job that renews every 60 days. Fine for
  90-day certificates, fatal for 47-day ones. Certbot changed its default in
  version 4.0.0: a certificate is now
  [ready for renewal](https://eff-certbot.readthedocs.io/en/stable/using.html)
  when less than a third of its lifetime remains. Before that it was a fixed
  30 days.
- **A dead timer.** The systemd timer or cron entry that didn't survive a
  server migration or an image rebuild.
- **Validation that stopped working.** HTTP-01 blocked by a new redirect, a
  WAF rule or a geo-block, or a DNS-01 API token that expired or lost its
  permissions.
- **No reload.** The new certificate is on disk, but nginx or HAProxy keeps
  serving the old one from memory until it reloads.

### Renewal succeeded is not the same as deployed

This is the most common gap. Your ACME client's logs say "renewed". The file
in `/etc/letsencrypt/live/` is new. And users still get the old certificate,
because:

- the process was never reloaded;
- one of four servers behind the load balancer didn't get the new file;
- the CDN edge has its own certificate that renews separately;
- the new certificate's SAN list dropped a name the old one had.

Anything that checks the file on disk will say everything is fine. Only a
check of the certificate actually presented in the TLS handshake, from
outside, tells you what users see.

## A checklist for automation and monitoring

### Automate renewal

1. **Inventory first.** Certificate Transparency logs record every public
   certificate issued for your domains, including the ones someone bought
   with a company card three years ago. Pull the list from crt.sh:

   ```bash
   curl -s 'https://crt.sh/?q=%25.example.com&output=json' \
     | jq -r '.[].name_value' | sort -u
   ```

2. **Use an ACME client everywhere it fits.** Certbot, acme.sh or lego on
   servers; Caddy and Traefik obtain and renew certificates themselves;
   cert-manager in Kubernetes. Prefer clients that support
   [ACME Renewal Information](https://www.rfc-editor.org/rfc/rfc9773) (ARI,
   RFC 9773, June 2025), which lets the CA tell the client when to renew,
   including early renewal after a mass revocation.
3. **Renew by fraction of lifetime, not by date.** About two thirds through,
   or whatever ARI suggests.
4. **Reload what serves the certificate.** With certbot, a deploy hook runs
   only after a successful renewal:

   ```bash
   certbot renew --deploy-hook "systemctl reload nginx"
   ```

   For appliances and load balancers, the deploy hook is where you call
   their API to upload the new certificate.
5. **Test the whole loop.** `certbot renew --dry-run` runs against the Let's
   Encrypt staging environment without saving certificates. Deploy hooks
   don't run during a dry run unless you add `--run-deploy-hooks`.
6. **Use DNS-01 with a narrowly scoped token** for wildcards and for names
   that aren't reachable from the internet. Give the token write access to
   `_acme-challenge` records only, if your DNS provider allows it.
7. **Publish CAA records** listing the CAs you actually use, so no other CA
   will issue for your domain (more in
   [DNS record types explained](/blog/dns-record-types-explained#caa--who-can-issue-your-certificates)).

### Monitor what is actually served

1. **Check the certificate in the handshake, from outside.** This is the one
   check that catches every failure above:

   ```bash
   echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
     | openssl x509 -noout -subject -issuer -enddate -ext subjectAltName
   ```

2. **Check every address behind a name.** A load balancer with one stale
   backend shows up only some of the time:

   ```bash
   for ip in $(dig +short A example.com); do
     printf '%s  ' "$ip"
     echo | openssl s_client -connect "$ip:443" -servername example.com 2>/dev/null \
       | openssl x509 -noout -enddate
   done
   ```

3. **Verify the chain, not only the leaf.** Browsers often repair a missing
   intermediate by fetching it or using a cached copy. Many other clients
   (curl, Go, Java with default settings) don't, and fail with a handshake
   error instead. Look for `Verify return code: 0 (ok)` in the `openssl s_client`
   output, and see [why handshakes fail](/blog/ssl-handshake-failed) for the
   other errors.
4. **Monitor every hostname, not every certificate.** One certificate with 40
   SANs can be deployed on ten different systems. What fails is a name on a
   system, so check each hostname people and integrations connect to,
   including mail (SMTPS on 465, STARTTLS on 587), IMAP, database endpoints
   and API subdomains.
5. **Set the alert threshold below your renewal point.** If a 47-day
   certificate normally renews with about 16 days left, an alert at 10 days
   means renewal is almost a week overdue and you still have 10 days to fix
   it. An alert at 30 days would fire on every healthy certificate.
6. **Watch Certificate Transparency** for certificates you didn't request.
   It's the early warning for a hijacked DNS record or a rogue issuance, and
   CISA made it one of the four required actions in its 2019 DNS-tampering
   directive.

## Watching certificates from outside with WatchFor

WatchFor's SSL monitor does item 1 of the monitoring list on a schedule. It
opens a TLS connection to the host and port you give it, reads the
certificate chain the server presents, and records what it finds: days until
expiry, issuer, subject and every SAN, whether the certificate covers the
hostname, whether the chain leads to a trusted root, and the negotiated TLS
version and cipher. Like every other check, it runs from the locations you
pick, and a failure is confirmed from several locations before anyone is
alerted.

![The WatchFor SSL monitor for en.wikipedia.org: up, 30 days until expiry and marked Expiring soon, on a certificate valid until 3 November 2026, issued by Let's Encrypt (YE2), with valid, hostname OK, chain trusted and TLS 1.3 badges](/blog/47-day-ssl-certificates-monitor.webp)

The probe result keeps the full certificate for each check, so after a
renewal you can see whether the new certificate is the one being served, and
whether it still carries every name it should:

![A probe result for the wikipedia.org certificate: subject *.wikipedia.org, issued by Let's Encrypt, valid from 5 August to 3 November 2026, a list of subject alternative names, TLS 1.3 with forward secrecy](/blog/47-day-ssl-certificates-certificate-details.webp)

That is a 90-day Let's Encrypt certificate, issued on 5 August and expiring
on 3 November. Under the 2029 rules the same certificate would last half as
long.

A few settings handle the setups above:

- **Target** is a domain (port 443) or `host:port`, so you can watch the
  certificate on `smtp.example.com:465` or a database endpoint, not only
  websites.
- **Server Name (SNI)** lets you point the monitor at one backend's IP
  address while asking for your real hostname. One monitor per backend is
  how you catch the server that missed the new certificate.
- HTTP, API and MCP monitors record days until expiry too, with their own
  **SSL Certificate** rule, so a site you already monitor over HTTPS is
  covered without a separate SSL monitor.

### The alert rules

The Alerting tab on an SSL monitor has these rules:

![The Alerting tab of an SSL monitor: Certificate Expiry set to warn when the certificate expires in less than 14 days, plus Hostname Match, Certificate Chain, Minimum TLS Version and a TLS Grade rule with B as the minimum acceptable grade](/blog/47-day-ssl-certificates-alert-rules.webp)

- **Certificate Expiry** is on by default: a warning when fewer than 14 days
  remain. The slider goes from 1 to 90 days, and you can make it critical
  instead of a warning. Following the threshold advice above, set it a few
  days below the point where your renewal normally happens.
- **Hostname Match** fires when the certificate doesn't cover the name you
  connect to, which is the "SAN list dropped a name" failure.
- **Certificate Chain** fires when the chain can't be verified against
  trusted roots, which catches a missing intermediate.
- **Minimum TLS Version** fires below your floor (TLS 1.2 or 1.3).
- **TLS Grade**, on plans that include TLS grading, fires when the A+ to F
  grade drops below the one you choose.

The expiry rule has one threshold today. Pick the number of days that gives
you time to fix a failed renewal calmly, and the incident goes to the same
channels as the rest of the monitor's alerts.

What WatchFor doesn't do: it doesn't renew certificates and it doesn't read
Certificate Transparency logs. It tells you what each hostname is serving
right now, from outside your network. Pair it with an ACME client and a CT
watcher.

SSL monitors are available on every plan, including Free. To look at a
certificate once without signing up, use the free
[SSL checker](/ssl-checker) or the [SSL/TLS grade checker](/ssl-grade-checker).
The [certificate monitoring docs](/docs/monitors/certificates) list every
setting and rule.

## A plan you can start this quarter

You have until March 2027 before the 100-day step and until March 2029 for
47 days. That's enough time if you start with the inventory, not the
tooling:

1. **Now:** list every public certificate from CT logs, and every internal
   one you know about. Mark each as automated, manual or unknown.
2. **Before March 2027:** move every manual certificate to ACME or a managed
   certificate, and add deploy hooks for anything not served by the machine
   that renews.
3. **Before Let's Encrypt's February 2027 change:** check that no client
   renews on a fixed 60-day interval.
4. **Ongoing:** monitor every hostname from outside, with an alert threshold
   that matches the new lifetimes, and watch CT logs for certificates you
   didn't ask for.

The industry is betting that short certificates force automation. That's
probably right. Short certificates also mean that a renewal which fails
quietly will expire on you within weeks, not months. Automate the renewal,
and check the result from where your users connect. For the basics of what
the certificate does in the handshake, see
[how HTTPS works](/blog/how-https-works).

---

Canonical page: https://watchfor.io/blog/47-day-ssl-certificates · All articles: https://watchfor.io/blog/all.md · Site guide: https://watchfor.io/llms.txt