How to prepare for 47-day TLS certificates

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:

The full history is on the certificate validity timeline, and the 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, then check what each host serves:

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

The 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.
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, or from any terminal:

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).

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 (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.
• CAA blocks a new CA: when moving manual certificates to ACME, update CAA records; see 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.
• Expired certificate on a forgotten host: see NET::ERR_CERT_DATE_INVALID and add the host to monitoring.