# Prepare for 47-day certificates: a migration checklist

> Get ready for 200-, 100- and 47-day certificate limits and Let's Encrypt's 64/45-day defaults: inventory, automation, ARI, DCV and monitoring.

Source: https://ssl.sh/guides/prepare-for-47-day-certificates/
Last updated: 2026-11-10

Prepare for 47-day certificates by listing every public certificate you run, moving each one to renewal automation that adapts to the lifetime, removing manual installation steps, and adding external monitoring. The steps apply to all publicly trusted TLS certificates, whatever CA issues them, under the rules as of November 2026.

## Prerequisites

You need visibility into everything that terminates TLS for your names.

- The list of registered domains you own.
- Access to the servers, load balancers, CDNs, panels and appliances that serve those domains.
- Access to DNS for each domain (needed for DNS-01 validation and CAA records).

## Step 1: Know the dates

The maximum lifetime of public certificates drops in three steps between 2026 and 2029, and Let's Encrypt shortens its own defaults on a separate schedule:

| Date | What changes |
|---|---|
| March 15, 2026 | Maximum validity 200 days; domain validation reuse 200 days |
| May 13, 2026 | Let's Encrypt `tlsserver` profile issues 45-day certificates (opt-in) |
| February 10, 2027 | Let's Encrypt default (`classic`) becomes 64 days; authorization reuse 10 days |
| March 15, 2027 | Maximum validity 100 days; domain validation reuse 100 days |
| February 16, 2028 | Let's Encrypt default becomes 45 days; authorization reuse 7 hours |
| March 15, 2029 | Maximum validity 47 days; domain validation reuse 10 days |

The full history is on the [certificate validity timeline](https://ssl.sh/timeline/certificate-validity/), and the [validity calculator](https://ssl.sh/tools/validity-calculator/) shows what a given issuance date allows.

## Step 2: Inventory every certificate

Build the inventory from Certificate Transparency logs, which contain every public certificate, including ones nobody remembers. Search each domain with [CT search](https://ssl.sh/tools/ct-search/), then check what each host serves:

```bash
curl ssl.sh/example.com
curl ssl.sh/www.example.com
curl ssl.sh/api.example.com
```

The [bulk SSL checker](https://ssl.sh/tools/bulk-ssl-checker/) handles long host lists. Record for each host: issuer, expiry, where TLS terminates, and how the certificate got there.

## Step 3: Classify and fix the manual ones

Sort the inventory into three groups and work on the last two:

1. **ACME-automated** (Certbot, acme.sh, lego, Caddy, Traefik, cert-manager, win-acme): check they run at least daily and follow ARI, see [automatic renewal](https://ssl.sh/guides/renew-certificates-automatically/).
2. **Provider-managed** (AWS ACM, Azure App Service managed certificates, Google-managed certificates, CDN-issued certificates): these renew themselves as long as their DNS validation records stay in place.
3. **Manual** (certificates uploaded to a CDN or load balancer, copied to appliances, renewed from a reminder): replace with ACME or provider-managed certificates, or script the upload through the provider's API from an ACME deploy hook. If your commercial CA supports ACME with External Account Binding, point your client at it.

## Step 4: Plan for shorter domain validation reuse

By 2029 a CA may reuse a domain validation for only 10 days, so every renewal of a 47-day certificate will revalidate the domain. HTTP-01 handles that automatically if port 80 stays reachable. For DNS-01, give the client an API token limited to the zone, or delegate `_acme-challenge` with a CNAME to a dedicated validation zone so the main zone's credentials stay off the servers. Let's Encrypt has also announced a DNS-PERSIST-01 challenge type that validates with a long-lived record; check its documentation for availability before relying on it.

## Verify

After the changes, every host in the inventory should serve a certificate that an ACME client or the provider renewed, not one installed by hand. Confirm the live certificates with the [SSL checker](https://ssl.sh/tools/ssl-checker/), or from any terminal:

```bash
curl ssl.sh/example.com
```

For ACME clients, run a staging dry run (`sudo certbot renew --dry-run`, or `--staging` for acme.sh) to prove the path works without waiting for expiry. You can also opt into the 45-day `tlsserver` profile now to rehearse the 2028 lifetime (see [Let's Encrypt certificate profiles](https://ssl.sh/guides/lets-encrypt-certificate-profiles/)).

## Automatic renewal

The target state is the same for every certificate: a scheduler runs at least daily, the client renews based on ARI or a fraction of the actual lifetime (not a fixed number of days), a hook reloads every service, and monitoring watches the result from outside. Let's Encrypt stopped sending expiry emails on June 4, 2025, so the outside check is not optional; [ssl.sh monitoring](https://ssl.sh/monitor/) (in development) alerts before expiry and when a renewed certificate is not being served.

## Troubleshooting

- **Scripts assume 90 days**: hard-coded `--days 60`, `renew_before_expiry = 30 days` or calendar reminders; remove them and let the client compute timing.
- **Renewal storms hit rate limits**: many hosts renewing in the same minute; add jitter and see [Let's Encrypt rate limits](https://ssl.sh/errors/lets-encrypt-rate-limit/).
- **CAA blocks a new CA**: when moving manual certificates to ACME, update CAA records; see [CAA record prevents issuance](https://ssl.sh/errors/caa-record-prevents-issuance/).
- **Apps pin a certificate**: mobile apps that pin the leaf certificate break on every renewal; pin a public key you control or the CA instead, see [certificate pinning](https://ssl.sh/glossary/certificate-pinning/).
- **Expired certificate on a forgotten host**: see [NET::ERR_CERT_DATE_INVALID](https://ssl.sh/errors/net-err-cert-date-invalid/) and add the host to monitoring.