The Certificate Nobody Renewed: 47-Day TLS, ACME Renewal Information, and the End of Revocation as a Safety Net

Every organisation that has run a website for more than a few years has the ticket. It recurs once a year, it says something like “Renew SSL certificate — www”, and it is assigned to whoever renewed it last time. The steps live in that person’s head, or in a wiki page last edited three reorganisations ago: generate a CSR on the box, paste it into the reseller’s portal, click the approval email, download a zip, work out which file is the intermediate, concatenate things in the right order, reload the web server, and hope.

The ticket works as long as three things hold: the person is still around, the calendar reminder still fires, and a year is long enough for the steps to be forgotten but short enough for somebody to still recognise them. That last condition is quietly ending. Since 15 March 2026, no publicly trusted TLS certificate can be valid for more than 200 days. On 15 March 2027 the cap falls to 100 days. On 15 March 2029 it falls to 47¹. A 47-day ceiling means at least eight renewals per certificate per year. Renew at a sensible point before expiry and it is closer to twelve.

The ticket will not survive that, and neither will the monitoring built around it. The expiry email you relied on may already have stopped arriving. Let’s Encrypt, the largest CA, switched off its expiration notification emails on 4 June 2025².

This post is about what replaces the ticket. We start with the schedule itself, read precisely, because much of what has been written about “47-day certificates” gets the half that matters most wrong. Then we look at why the browsers are doing this, which comes down to one sentence: revocation never worked. The rest is engineering. We cover what ACME (RFC 8555) already solved and the timing problem it left open, then how ACME Renewal Information (RFC 9773) closes that gap, with a working client. After that come certificate profiles, the new DNS-PERSIST-01 validation method, and monitoring that does not assume a year between events. We close with the parts of the fleet that will not automate, and what to do about them.

The schedule, read precisely

The change was made by CA/Browser Forum ballot SC-081v3, “Introduce Schedule of Reducing Validity and Data Reuse Periods”. Clint Wilson of Apple proposed it, and it was endorsed by Sectigo, Google Chrome and Mozilla. Voting ran 4–11 April 2025. Certificate issuers voted 25 yes, 0 no, 5 abstaining. All four certificate consumers voted yes³. No CA voted against. That matters, because the most common reaction to the ballot in engineering channels was to assume it is a browser imposition that CAs will fight or delay. They did not. The dates are in the Baseline Requirements (BRs) now.

The BRs’ own “Relevant Dates” table lists these changes. It is the authoritative place to read them¹:

There is a third column the table leaves out. From 2026-03-15, the maximum reuse period for Subject Identity Information is 398 days, down from 825¹³. That is the organisation-identity data behind OV and EV certificates.

Two things about this table are routinely misreported.

First, the lifetime is not the headline. The validation reuse is. A 47-day certificate is an inconvenience for anyone still renewing by hand. A 10-day validation reuse period changes the shape of the problem. Today a CA can validate that you control example.com once and then issue against that validation for months. From March 2029 it can rely on that proof for only ten days. Any certificate issued more than ten days after the last validation needs fresh proof of domain control. If your renewal involves a human answering an approval email, or someone adding a DNS TXT record by hand, that human now does it roughly every renewal. CAs are already applying these limits with a safety margin. DigiCert told customers that any domain validated on or after 24 February 2026 could be reused for up to 199 days, not 200⁴.

Second, the dates are cut-offs by issuance date, not a mass expiry. A certificate issued on 14 March 2027 with a 200-day validity stays valid for all of it. Nothing is revoked on the transition dates. The effect arrives gradually as certificates come up for renewal, which is exactly why it will be noticed late.

The ballot did not come out of nowhere. In March 2023 the Chromium root program published “Moving Forward, Together”, which stated its intent to propose a 90-day maximum. The rationale was agility, including the eventual migration to quantum-resistant algorithms, plus a shorter window in which outdated validation data can be trusted⁵. SC-081 is that intent, negotiated into a schedule with a longer run-up and a lower end state.

Why the browsers want this: revocation never worked

The model behind a TLS certificate has a gap in the middle. A CA vouches that a key belongs to a name for a period of time. If something goes wrong within that period, the certificate is supposed to be revoked, and relying parties are supposed to notice. The key might be stolen, the name might change hands, or the CA might discover it validated wrongly.

The first half works. The second half has never worked well, and the Let’s Encrypt team said so plainly when announcing short-lived certificates: “revocation is an unreliable system so many relying parties continue to be vulnerable until the certificate expires”⁶.

The two classic mechanisms each failed in a different way:

• CRLs (Certificate Revocation Lists) are files of revoked serial numbers that the CA publishes. They are simple, but historically large, and clients downloading them on the hot path of a TLS handshake was never practical.
• OCSP (Online Certificate Status Protocol) lets a client ask the CA about one certificate in real time. It is smaller per query, but it adds latency to every handshake and is a single point of failure. Most importantly, it is a privacy leak. Every OCSP query tells the CA which site the user is visiting, from which IP address. Let’s Encrypt gave exactly this as its main reason for dropping OCSP⁷.

Because of the latency and availability cost, browsers mostly soft-fail on OCSP. If the responder does not answer, the connection proceeds. An attacker who can intercept the connection can often block the OCSP query too. A security check that passes whenever it cannot run is a check against honest failures only.

So the industry has walked away from real-time revocation checks. CA/B Forum ballot SC-063, effective 15 March 2024, made operating an OCSP responder optional for publicly trusted CAs and made publishing timely CRLs mandatory⁸⁹. Browsers now distribute compressed revocation data to clients out of band, instead of having each client ask the CA at connection time. Let’s Encrypt then went all the way:

• 30 January 2025. New issuance requests carrying the OCSP Must-Staple extension began failing, except for accounts that had used it before¹⁰.
• 7 May 2025. All Must-Staple requests failed, and certificates began carrying CRL URLs instead of OCSP URLs¹⁰.
• 6 August 2025. The OCSP responders were shut down. At their peak earlier that year they were answering roughly 340 billion requests a month, more than 140,000 per second⁷.

Short lifetimes are the other half of this move. If revocation is unreliable, the only dependable end to a compromised certificate’s usefulness is its notAfter date. A 398-day certificate with a stolen key is a 398-day problem in the worst case. A 47-day certificate is a 47-day problem. The BRs recognise the extreme end of this logic explicitly. A Short-lived Subscriber Certificate is exempt from the requirement to carry revocation information. That means a validity period of at most 10 days for certificates issued between 2024-03-15 and 2026-03-15, and at most 7 days (604,800 seconds) for those issued from 2026-03-15¹. Let’s Encrypt’s shortlived profile issues exactly this kind of certificate, valid for 160 hours, and has been generally available since 15 January 2026⁶.

Put simply, the ecosystem is replacing “we will tell you if this certificate goes bad” with “this certificate will not live long enough to matter”. That trade only works if issuance is fully automatic. Everything below is about making it so.

What ACME already solved

Most of the automation already exists and is seven years old. RFC 8555, Automatic Certificate Management Environment (ACME), was published in March 2019¹¹. It standardised what Let’s Encrypt had been doing since 2015:

1. The client creates an account, identified by a key pair. Every request is a JWS signed with that key.
2. The client submits an order for a set of identifiers (DNS names, or IP addresses).
3. For each identifier, the server returns an authorization with one or more challenges. http-01 asks the client to serve a token over HTTP. dns-01 asks for a TXT record at _acme-challenge.<name>. tls-alpn-01 asks for a special self-signed certificate on port 443.
4. Once the challenges pass, the client sends a CSR to finalize the order and downloads the certificate chain.

Any mature client does all of this unattended: certbot, acme.sh, lego, Caddy’s built-in client, cert-manager on Kubernetes, and win-acme on Windows. If you already run one of them with a cron job or timer, you have solved the issuance problem.

What RFC 8555 did not solve is when. The spec says nothing about when a client should renew. Every client and every in-house script therefore invented its own rule, and nearly all of them look like this:

if cert.not_after - now < 30 days:
    renew()

That rule has three failure modes, and the new schedule triggers all three.

It is brittle to lifetime changes. “Renew at 30 days left” is two-thirds of the way through a 90-day certificate. For a 45-day certificate it means renewing after fifteen days. For a 6-day certificate the condition is true from the moment of issuance, so the client renews on every run. Shopify ran exactly this pattern in production: a 30-day static threshold on 90-day certificates, with a random jitter of 0–72 hours per certificate. Their engineers later listed brittleness to lifetime changes as one of three reasons they abandoned it¹².

It is blind to revocation. If the CA must revoke your certificate early, the threshold rule will not find out until the handshake failures start. The CA might have mis-validated it, or found a key-generation bug, or had some other compliance incident.

It herds. Every client that issued on the same day renews on the same day. At a CA’s scale, fixed thresholds turn issuance spikes, including those caused by incidents, into renewal spikes months later.

The second failure mode is not hypothetical. In July 2024, DigiCert found that one code path in its CNAME-based domain validation had omitted a required underscore prefix from the random value. That was a BR violation, and it went back to a 2019 system rewrite. The BRs required the affected certificates to be revoked within 24 hours. That meant 83,267 certificates belonging to 6,807 customers¹³. CISA issued an alert warning that the revocations “may cause temporary disruptions to websites, services, and applications”¹⁴. Some operators of critical infrastructure asked for more time, and DigiCert revoked everything by 3 August 2024¹³. None of that was the subscribers’ fault. For many of them the only signal was a phone call, an email, or an outage. Their automation, if they had any, was waiting for a date.

ACME Renewal Information, field by field

RFC 9773, ACME Renewal Information (ARI) Extension, published in June 2025 by Aaron Gable of ISRG, fixes the timing problem by inverting it¹⁵. Instead of each client guessing when to renew, the CA tells the client, per certificate, and can change its answer at any time.

The mechanism is small.

1. A new directory entry. The ACME directory gains a renewalInfo URL. Clients that do not see it fall back to their old behaviour.

2. A certificate identifier. ARI has to refer to a specific certificate without sending the whole thing. The identifier is two base64url strings joined by a dot, with all trailing = padding removed:

• the keyIdentifier from the certificate’s Authority Key Identifier extension, and
• the serial number, as the bytes of its DER INTEGER encoding, excluding the tag and length.

The RFC’s worked example uses an AKI keyIdentifier of 69:88:5B:6B:87:46:40:41:E1:B3:7B:84:7B:A0:AE:2C:DE:01:C8:D4 and a serial of 00:87:65:43:21. It produces the identifier aYhba4dGQEHhs3uEe6CuLN4ByNQ.AIdlQyE¹⁵. Note the leading 00 byte on the serial. A DER INTEGER is two’s-complement, so a positive number whose high bit is set gets a zero byte in front. Leave it out and your identifier points at a different certificate.

3. The response. A GET to <renewalInfo>/<identifier> returns:

{
  "suggestedWindow": {
    "start": "2025-01-02T04:00:00Z",
    "end": "2025-01-03T04:00:00Z"
  },
  "explanationURL": "https://acme.example.com/docs/ari"
}

with a Retry-After header (21600 seconds, six hours, in the RFC’s example) telling the client when to ask again¹⁵. explanationURL is optional. It exists so that a CA which pulls a window into the past can point the operator at the incident report.

4. The client algorithm. The RFC tells the client to¹⁵:

1. fetch the suggested window;
2. pick a uniformly random time within it;
3. if that time is in the past, renew immediately;
4. if the client can schedule itself to wake at that exact time, do so;
5. otherwise, if the time falls before the client’s next normal wake-up, renew now;
6. otherwise, sleep until Retry-After and start again.

The RFC also bounds Retry-After. Clients treat values under one minute as one minute, and values over one day as one day¹⁵. That keeps a buggy server from making clients hammer it, and keeps a buggy client from not checking for weeks.

5. replaces. When the client places the new order, it includes a replaces field containing the old certificate’s identifier. That tells the CA the order is a renewal of a specific certificate¹⁵. The CA can then track which revoked certificates have really been replaced, and the RFC lists giving such orders higher priority or letting them bypass rate limits as things a server’s policy may do. It also keeps two clients from racing to renew the same certificate. If the identified certificate has already been marked as replaced by another order that is not invalid, the server returns HTTP 409 with the problem type alreadyReplaced¹⁵.

Step 2 fixes herding: the CA spreads load by choosing the window, and clients add randomness inside it. Revocation blindness goes away because the CA can move a window into the past. In the DigiCert case, an ARI-aware fleet would have seen every affected window jump to “now” on its next poll and renewed without anyone picking up a phone. The RFC acknowledges this use case directly. It warns that when “a server places the suggested renewal window wholly in the past to encourage a client to renew immediately, a client with a sufficiently slow clock might nonetheless see the window as being in the future”¹⁵. Keep NTP healthy. And brittleness to lifetime changes disappears because the CA, which knows the lifetime it issued, computes the window. When Let’s Encrypt moves its default from 90 days to 64 to 45, an ARI client needs no code change. That is exactly why Shopify switched. In their words, “Shopify now delegates the responsibility of determining renewal timing to Let’s Encrypt”¹².

A working ARI check in Python

Most teams should get ARI by upgrading their ACME client, not by writing one. Certbot added ARI support in 4.1.0 (10 June 2025)¹⁶. But an ARI check is worth understanding, and worth having standalone. It is a read-only, unauthenticated GET, so a monitoring job can ask the CA whether any certificate in your inventory should be renewed now, regardless of which client issued it.

"""ari_check.py — ask the issuing CA when a certificate should be renewed (RFC 9773)."""
import base64
import datetime as dt
import random
import sys

import requests
from cryptography import x509


def b64u(raw: bytes) -> str:
    return base64.urlsafe_b64encode(raw).rstrip(b"=").decode("ascii")


def ari_cert_id(cert: x509.Certificate) -> str:
    aki = cert.extensions.get_extension_for_class(x509.AuthorityKeyIdentifier).value
    if aki.key_identifier is None:
        raise ValueError("certificate has no AKI keyIdentifier; ARI cannot address it")
    serial = cert.serial_number
    # DER INTEGER content octets: minimal big-endian two's complement.
    # (bit_length + 8) // 8 leaves room for a leading 0x00 when the high bit is set.
    serial_der = serial.to_bytes((serial.bit_length() + 8) // 8, "big")
    return f"{b64u(aki.key_identifier)}.{b64u(serial_der)}"


def parse_rfc3339(s: str) -> dt.datetime:
    return dt.datetime.fromisoformat(s.replace("Z", "+00:00"))


def check(directory_url: str, pem_path: str) -> int:
    with open(pem_path, "rb") as f:
        cert = x509.load_pem_x509_certificate(f.read())

    directory = requests.get(directory_url, timeout=10).json()
    if "renewalInfo" not in directory:
        print("CA does not advertise ARI; fall back to renewing at 2/3 of lifetime")
        return 3

    resp = requests.get(f"{directory['renewalInfo']}/{ari_cert_id(cert)}", timeout=10)
    resp.raise_for_status()
    window = resp.json()["suggestedWindow"]
    start, end = parse_rfc3339(window["start"]), parse_rfc3339(window["end"])

    # RFC 9773: pick a uniformly random point inside the window.
    target = start + (end - start) * random.random()
    now = dt.datetime.now(dt.timezone.utc)

    # Retry-After may also be an HTTP-date; a real client should handle both.
    try:
        retry = int(resp.headers.get("Retry-After", "21600"))
    except ValueError:
        retry = 21600
    retry = min(max(retry, 60), 86400)  # clamp to [1 minute, 1 day]

    explanation = resp.json().get("explanationURL")
    if target <= now:
        print(f"RENEW NOW (window {start:%F %T} .. {end:%F %T} UTC)")
        if explanation:
            print(f"CA explanation: {explanation}")
        return 2
    print(f"ok: renew at {target:%F %T} UTC; poll again in {retry}s")
    return 0


if __name__ == "__main__":
    sys.exit(check(sys.argv[1], sys.argv[2]))

Run it against Let’s Encrypt’s production directory:

python3 ari_check.py https://acme-v02.api.letsencrypt.org/directory /etc/ssl/www/fullchain.pem

For a full chain file, load_pem_x509_certificate reads the first PEM block, which is the leaf. The exit codes are chosen to drop straight into a Nagios-style check: 0 for OK, 2 for critical, 3 for unknown. The one real subtlety is the serial encoding covered above. An encoding that forgets the sign byte works for about half of all serials and fails for the rest, which is the worst kind of bug. Test against the RFC’s example identifier before trusting it.

When the CA does not support ARI, fall back to a fraction of lifetime, never to a fixed number of days. Let’s Encrypt’s own guidance on the move to 45 days treats renewing at roughly two-thirds of the way through the current certificate’s lifetime as acceptable automation behaviour, and recommends ARI above that¹⁷.

The quieter half: 10-day validation reuse and DNS-PERSIST-01

Go back to the table. From March 2029, domain validation evidence is good for ten days. Let’s Encrypt is getting there early. Its timeline cuts authorization reuse from 30 days to 10 on 10 February 2027, and to 7 hours on 16 February 2028¹⁷. In practice, every renewal will validate again.

For single servers using http-01 that changes nothing, because the challenge was already answered automatically each time. It matters a great deal in three situations:

• dns-01 with a DNS provider API. Each validation writes a TXT record. That needs a DNS API credential on every host that issues certificates, which is a powerful secret to spread around a fleet. The usual mitigation is to delegate _acme-challenge with a CNAME to a zone that is used only for validation.
• Multi-tenant platforms that issue certificates for customer-owned domains. The platform needs the customer to point DNS at it once. It cannot ask the customer to add a record every time the platform renews.
• Wildcards, which in practice need a DNS-based challenge.

The answer the ecosystem is converging on is DNS-PERSIST-01. Instead of a fresh random token each time, the domain owner publishes one long-lived TXT record that authorises a specific ACME account at a specific CA¹⁸:

_validation-persist.example.com. IN TXT (
  "letsencrypt.org;"
  " accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/1234567890"
)

Optional parameters extend it. policy=wildcard covers wildcard certificates and subdomains, and persistUntil=<unix time> sets an expiry on the authorisation itself¹⁸. The underlying validation method was added to the BRs by ballot SC-088v3, which passed unanimously in October 2025. The IETF ACME working group adopted the draft the same month¹⁸¹⁹. Let’s Encrypt announced plans for staging in late Q1 2026 and production in Q2 2026¹⁸.

Look closely at the security trade. With dns-01, the asset to protect is the DNS credential. With DNS-PERSIST-01 it is the ACME account key. Anyone holding that key can obtain certificates for every name that authorises it, for as long as the record stands¹⁸. For a multi-tenant platform this is a good trade: one account key in an HSM or secrets manager instead of a DNS credential per customer. But it deserves the same controls you would give a signing key. That means rotation, restricted access, and an audit trail. It also moves an obligation onto the customer’s side. Removing the TXT record is now how a domain owner revokes a platform’s authority, so your offboarding flow should tell them to.

Profiles: choosing a lifetime on purpose

In the past, a CA changing its default lifetime would have been a flag day for every subscriber. The emerging answer is ACME profiles. The draft-ietf-acme-profiles extension lets a CA list named profiles in its directory and lets a client choose one per order²⁰. Let’s Encrypt currently exposes three¹⁷⁶:

• classic: the default and the most conservative. Let’s Encrypt plans to move it from 90 days to 64 days on 10 February 2027 and 45 days on 16 February 2028¹⁷.
• tlsserver: the forward-looking profile, scheduled to switch to 45-day certificates on 13 May 2026 so early adopters can find their breakages ahead of the default¹⁷.
• shortlived: 160-hour certificates, below the BRs’ short-lived threshold. IP-address certificates, IPv4 and IPv6, are available only in this profile, because IP assignments churn faster than domain ownership⁶.

This gives operators a practical way to prepare that does not depend on the calendar. Put a canary service, ideally one with real traffic and a real on-call rotation, on the shortest profile you expect to face, now. If your stack survives 45-day or 6-day certificates, the CA/B dates are non-events. If it does not, you find out on a service you picked, at a time you picked, instead of across the whole fleet on the day a default changes.

Monitoring that survives short lifetimes

Most certificate monitoring today is a check that fires when notAfter - now < N days, with N somewhere between 14 and 30. That breaks in both directions:

• On a 6-day certificate, N = 14 is always true, so the alert fires constantly and gets muted. Muted alerts are how outages happen.
• On a 47-day certificate renewed at two-thirds of its life, N = 30 fires routinely before the renewal is even due. The alert again becomes noise.

The fix is the same as for renewal: alert on the fraction of lifetime remaining, from outside, against the certificate that is actually being served.

#!/bin/sh
# cert_lifetime_check.sh <host> [port] — alert on fraction of lifetime left, not days.
host=$1; port=${2:-443}
pem=$(openssl s_client -connect "$host:$port" -servername "$host" </dev/null 2>/dev/null \
      | openssl x509 2>/dev/null) || { echo "UNKNOWN: no certificate from $host:$port"; exit 3; }

nb=$(printf '%s\n' "$pem" | openssl x509 -noout -startdate | cut -d= -f2)
na=$(printf '%s\n' "$pem" | openssl x509 -noout -enddate  | cut -d= -f2)
nb_s=$(date -d "$nb" +%s); na_s=$(date -d "$na" +%s); now=$(date +%s)

life=$((na_s - nb_s)); left=$((na_s - now))
[ "$left" -le 0 ] && { echo "CRITICAL: $host expired $na"; exit 2; }
pct=$((100 * left / life))

# Renewal is expected at ~2/3 of lifetime (33% left). Warn once it is overdue, page well before expiry.
if   [ "$pct" -lt 15 ]; then echo "CRITICAL: $host ${pct}% of lifetime left (expires $na)"; exit 2
elif [ "$pct" -lt 25 ]; then echo "WARNING: $host ${pct}% of lifetime left (expires $na)"; exit 1
fi
echo "OK: $host ${pct}% of lifetime left (expires $na)"

This needs GNU date -d. The thresholds encode the policy directly. Renewal is expected at about 33% remaining. At 25% something has missed its window, and at 15% a human needs to act. The same script is correct for a 398-day certificate, a 47-day one and a 6-day one.

Two further signals are worth adding:

• The ARI check above, run from monitoring rather than from the ACME client. It is the only signal that fires when a CA wants an early renewal, which is precisely when threshold-based checks say everything is fine.
• Certificate Transparency. Every publicly trusted certificate is logged to public CT logs under RFC 6962²¹. A CT monitor watching your domains will see a renewal the moment it is issued, and will also see a certificate issued for your name that you did not ask for. With renewals every few weeks, “a certificate was issued” stops being noteworthy. “A certificate was issued by a CA or account we do not use” is the alert that matters.

The parts that will not automate

Every certificate inventory has a long tail that does not speak ACME. That includes load-balancer appliances with a web UI and no API, and embedded devices that take a certificate by manual upload. It includes vendor SaaS that wants a PFX file emailed to support, mobile apps that pin a leaf certificate, and payment terminals or partner integrations that pin a specific certificate rather than a CA or key. At 398 days, each of those was a yearly chore. At 47 days, and with 10-day validation reuse, each one is a monthly incident waiting to happen.

Sort the tail into three groups.

Terminate TLS in front of it. For most appliances and legacy servers, the right answer is to stop serving the public certificate from them at all. Put an ACME-capable reverse proxy, CDN or cloud load balancer in front and let it own the public certificate. The appliance can keep a long-lived certificate from your private CA on the inside hop. The BRs govern publicly trusted certificates only. Your internal PKI can set its own lifetimes, as long as it is not chained to a public root.

Pin keys or CAs, never leaves. A mobile app that pins a leaf certificate breaks at every renewal. At 47 days that becomes a forced app release roughly every month. If you must pin, pin a public key you control and reuse across renewals, or pin a set of acceptable CA keys, and ship a backup pin. Better still, ask whether the pin is buying anything that CT monitoring does not.

Replace it. Some things cannot be fronted and cannot be automated. Those are now on a clock. The 100-day step in March 2027 is the practical deadline, because that is when manual renewal goes from twice a year to four times, and people stop being able to remember the steps between renewals.

A note for teams in markets like ours. In Bangladesh, and across much of the region, a large share of production TLS still arrives through local resellers of commercial certificates. It is installed by hand through a hosting control panel and renewed from an annual invoice. Those workflows were built for 398 days and are about to be under real pressure. The good news is that ACME is free, the major clients run on the same shared hosting and VPS platforms, and a commercial CA account with ACME support fits the same model. If you run or advise such a shop, the migration is small, but it has to happen before the 100-day step, not after the first outage.

What changes for the CA relationship

It is worth being explicit about one more shift. Under the old model, the relationship with a CA was a yearly transaction. Under the new one it is a continuous dependency. With 10-day validation reuse and renewal every few weeks, an outage at your CA’s ACME endpoint, or a rate limit you hit during an incident, becomes a production risk in a way it never was when certificates lasted a year.

The mitigations are ordinary reliability engineering:

• Renew early enough to ride out a CA outage. Renewing at two-thirds of a 47-day lifetime leaves about 15 days of margin, which is plenty. Renewing with two days to spare leaves none.
• Configure a second ACME CA. Several publicly trusted CAs speak ACME. Keep a second one configured and tested, with a CAA record permitting it, so failover is a config change rather than a procurement exercise.
• Use replaces. RFC 9773 allows a CA to give renewals that carry replaces higher priority, or to let them bypass rate limits. Clients that skip it look like brand-new orders to the CA¹⁵.
• Keep account keys backed up and inventoried. With DNS-PERSIST-01 they become the root of your authority over your names¹⁸.

The judgment

Everything in this post comes down to one claim: a certificate renewal that a human has to remember is already a defect. It was a latent defect at 398 days. It survived because a year is long enough to hide it and short enough for a calendar reminder to cover it. At 100 days it is a recurring incident. At 47 days, with validation evidence expiring after ten, it is simply not a viable way to run a service.

The standards have done their part. RFC 8555 made issuance automatic, and RFC 9773 made timing the CA’s problem, not a constant hard-coded in your cron job. Profiles let you rehearse future lifetimes today, and DNS-PERSIST-01 removes the last reason to spread DNS credentials across a fleet. The industry has already stopped pretending revocation works: OCSP is optional in the BRs, and Let’s Encrypt, the largest CA, has switched its responders off. What remains is organisational. That means finding every certificate, putting each one behind a client that speaks ARI, alerting on fractions of lifetime rather than days, and giving the long tail a plan with a date on it.

The dates are fixed: 15 March 2027, then 15 March 2029. The cheapest time to find out what breaks under short-lived certificates is now, on a canary you chose. Otherwise you find out during an incident that someone else chose, like the one DigiCert’s customers got in 2024. The old ticket, “Renew SSL certificate — www”, should be closed as won’t fix, and replaced by the monitoring check that makes sure no one ever needs it again.