ACME Protocol and the 47-Day TLS Certificate Era: Automating Short-Lived Certificates

For about a decade, “renew the certificate” was a calendar entry. Someone bought a one-year certificate, pasted it into a load balancer, and set a reminder for eleven months later. That workflow has a hard expiry date of its own. Under CA/Browser Forum Ballot SC-081v3, the maximum lifetime of a publicly trusted TLS certificate falls from 398 days to 200 days in March 2026, 100 days in March 2027, and 47 days in March 2029. A 47-day certificate has to be replaced roughly eight times a year, and no human process survives that cadence across hundreds or thousands of endpoints.

The only credible answer is the ACME protocol (Automatic Certificate Management Environment, RFC 8555), the machinery behind Let’s Encrypt and now supported by most public certificate authorities (CAs). This post walks through what the 47-day schedule really changes, how the ACME protocol works at the wire level, how to use renewal information, short-lived profiles and cert-manager to build renewal that does not page you at 3 a.m., and where the failure modes hide.

What this covers: the verified SC-081v3 timeline, the ACME order flow and challenge types, Let’s Encrypt’s short-lived and IP certificates, ACME Renewal Information (ARI), cert-manager patterns, rate-limit arithmetic, monitoring, and a pragmatic migration checklist.

Context and Background: Why Lifetimes Are Collapsing

Certificate lifetimes have shrunk in steps for years, most recently to a 398-day maximum in 2020. Each step was argued as a security improvement, and each time the industry coped with calendars and spreadsheets. SC-081v3 is different because it makes the step schedule explicit and ends at a number, 47 days, that manual processes cannot meet.

The ballot passed on April 11, 2025. It was authored by Clint Wilson of Apple, and by one account of the vote it carried 29 yes votes, no opposing votes and 5 abstentions, with all four browser root programs (Apple, Google, Microsoft and Mozilla) voting yes. The reasoning is mostly about revocation. Revocation checking through certificate revocation lists (CRLs) and the Online Certificate Status Protocol (OCSP) has never been dependable in browsers, so the practical protection against a mis-issued or compromised certificate is its expiry. Shorten the maximum lifetime and you shorten the window of exposure without relying on a mechanism that fails open.

The second driver is domain control validation (DCV) reuse. A CA may reuse a past proof that you control a domain for some period before demanding fresh proof. Under the schedule, that reuse window shrinks from 398 days to 200, 100, and finally 10 days. This matters as much as the certificate lifetime itself, because it means a CA must re-verify control of your domain almost every time it issues. Automation has to cover validation, not only issuance.

Put together, the verified schedule, applied by certificate issuance date, looks like this:

Issuance date	Max certificate validity	Max DCV reuse
Before 15 March 2026	398 days	398 days
15 March 2026 to before 15 March 2027	200 days	200 days
15 March 2027 to before 15 March 2029	100 days	100 days
On or after 15 March 2029	47 days	10 days

Two points are easy to miss. First, these are CA/Browser Forum Baseline Requirements limits that CAs and browsers enforce, not a W3C or IETF standard; individual CAs may go shorter, and Let’s Encrypt already does. Second, the schedule applies to publicly trusted TLS server certificates. Private PKI, such as the certificates issued inside your service mesh or by an internal CA, is not bound by it, although the operational argument for short lifetimes there is just as strong. If you run workload identity, our comparison of Kubernetes pod certificates, SPIFFE/SPIRE and cert-manager covers where each tool fits.

Finally, note what the ballot does not say. It does not mandate ACME. It mandates short lifetimes, and ACME is simply the only widely deployed, standardised protocol that makes short lifetimes survivable. The IETF’s RFC 8555 was published in 2019 after Let’s Encrypt had issued certificates for years on a pre-standard version of the same protocol.

The ACME Protocol Reference Architecture

The ACME protocol lets a client prove control of an identifier (a DNS name or, now, an IP address) to a CA and receive a signed certificate, all over HTTPS with JSON messages signed using JSON Web Signature (JWS). A client creates an account key, opens an order for identifiers, completes a challenge for each one, submits a certificate signing request (CSR) to finalize, and downloads the certificate chain. Everything is automated and machine-readable, which is what makes frequent renewal cheap.

Figure 1: The RFC 8555 order lifecycle, from directory discovery through finalization and download.

Figure 1 shows the objects and states. A client begins by fetching the server’s directory, a JSON document listing the URLs for newNonce, newAccount, newOrder, revokeCert, keyChange and, on servers that support it, renewalInfo. Every POST carries a fresh anti-replay nonce obtained from the server, and a JWS signature that binds the request to the URL and to the account key.

Accounts, orders and authorizations

An account is just a key pair plus optional contact details. The client sends a newAccount request signed with the new public key embedded in the JWS header; subsequent requests reference the account by a kid URL. Losing the account private key means losing the ability to revoke certificates issued under that account, which is why cert-manager stores it in a Kubernetes Secret and documents the consequence.

An order lists the identifiers wanted. For each identifier the CA creates an authorization object that holds one or more challenge options. The order moves through pending, ready, processing and valid; an authorization moves from pending to valid, or to invalid on a failed check. The client only calls the finalize URL once every authorization is valid and the order is ready.

The three challenge types

Challenges are where the protocol meets your infrastructure, and choosing among them is the first real design decision.

http-01. The CA fetches http://<domain>/.well-known/acme-challenge/<token> and expects the body to be the token concatenated with the account key thumbprint. It needs port 80 reachable from the public internet, cannot issue wildcards, and works well for plain web servers and ingress controllers. It is the simplest option and the one most exposed to split-horizon and firewall surprises.

dns-01. The client publishes a TXT record at _acme-challenge.<domain> containing a digest of the key authorization. It works for wildcards, works for hosts not exposed to the internet, and requires an API credential for your DNS provider. That credential is the sensitive part; a compromised DNS token can mint certificates for your whole zone.

tls-alpn-01. Defined in RFC 8737, the CA connects on port 443 using the acme-tls/1 ALPN protocol identifier and expects a self-signed validation certificate with a specific extension. It needs no port 80 and no DNS access, which suits TLS-terminating proxies, but support across clients and CAs is narrower.

The key authorization at the heart of all three is token || "." || base64url(SHA-256(JWK thumbprint of account key)). Because it embeds the account key thumbprint, a third party who observes the token cannot answer the challenge without the account key.

Multi-perspective validation changes the network picture

Public CAs now validate from several network vantage points to resist BGP hijacks, and the CA/Browser Forum has made multi-perspective issuance corroboration a requirement. For you this means a challenge response must be reachable and consistent from multiple regions. A geo-blocking firewall rule that was harmless against one validation source can now fail some perspectives, and a failed validation counts against your failed-validation rate limit.

A runnable walk through the flow

You do not need to write an ACME client to see the flow, but you should have run one by hand against a staging server. This Certbot command exercises the full order lifecycle with dns-01 manual validation against Let’s Encrypt staging, using the shortlived profile:

certbot certonly \
  --server https://acme-staging-v02.api.letsencrypt.org/directory \
  --preferred-profile shortlived \
  --manual --preferred-challenges dns \
  -d example.com -d '*.example.com' \
  --agree-tos -m ops@example.com --dry-run

After issuance, inspect what you actually received. This confirms lifetime, SANs and the Authority Key Identifier you will need for ARI:

openssl x509 -in /etc/letsencrypt/live/example.com/fullchain.pem \
  -noout -dates -ext subjectAltName,authorityKeyIdentifier -serial

Flag names and profile availability change between Certbot releases, so check certbot --help all on your version; the point is that every step in Figure 1 happens inside that one command.

Short-Lived Certificates, IP Certificates and Profiles

Let’s Encrypt did not wait for 2029. Its 6-day and IP address certificate options reached general availability on January 15, 2026. The short-lived certificates are valid for 160 hours, just over six days, and you request them by selecting the shortlived profile in your ACME client. They are opt-in, with no current plan to make them the default.

The stated rationale is revocation. Without short lifetimes, a relying party may remain exposed to a bad certificate until it expires, up to 90 days for a standard Let’s Encrypt certificate. A 160-hour certificate makes revocation largely unnecessary because the certificate dies before most revocation pipelines would have propagated.

IP address certificates are a separate capability: Let’s Encrypt issues them for IPv4 and IPv6, and they must be short-lived certificates. The reasoning is that IP addresses change hands more often than domain names, so frequent revalidation matters more. The first IP certificate was announced on July 1, 2025. For the network-appliance and IoT-gateway world, this removes a long-standing workaround of reaching devices by hostname only to obtain a trusted certificate. For how mutually authenticated TLS behaves on constrained devices, see our analysis of the TLS 1.3 handshake, 0-RTT and mTLS on constrained IoT devices.

Let’s Encrypt’s own roadmap to 45 days

Let’s Encrypt has published a staged plan that is more aggressive than the Forum’s floor. Per its December 2025 announcement:

13 May 2026: the opt-in tlsserver profile begins issuing 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 with a 7-hour authorization reuse period.

Staging receives each change about a month before production. Authorization reuse, which is Let’s Encrypt’s term for how long a validated authorization can satisfy a new order, drops from 30 days today to 7 hours. In practice that means by 2028 nearly every renewal triggers a fresh challenge.

Let’s Encrypt’s guidance on renewal timing is blunt: use ARI if your client supports it, and otherwise renew about two-thirds of the way through the certificate’s life. A hardcoded 60-day interval will no longer work for a 45-day certificate. If your cron job or Ansible role still says “renew every 60 days”, it is already a latent outage with a known date.

What the ecosystem knows and does not know

Profile names and exact lifetimes are CA-specific. Other CAs that speak ACME (for example commercial CAs that expose it with External Account Binding) will publish their own schedules. Treat each CA’s documentation as the source of truth and avoid encoding lifetimes in your tooling; read the notAfter from the certificate and the renewal window from ARI instead.

Deeper Analysis: The Arithmetic of Renewal at Scale

A shorter lifetime multiplies operational load roughly in inverse proportion. The numbers below are straightforward arithmetic, not benchmarks, and they assume renewal at two-thirds of lifetime as Let’s Encrypt recommends.

Lifetime	Renew at	Renewals per cert per year	Renewals per year, 1,000 certs
398 days	~265 days	~1.4	~1,400
90 days	~60 days	~6	~6,100
47 days	~31 days	~11.6	~11,600
45 days	30 days	~12	~12,200
6.67 days (160 h)	~4.4 days	~82	~82,000

Moving from 398-day certificates to 47-day certificates is roughly an eightfold increase in issuance events; moving to 6-day certificates is nearly sixty times higher. A process that fails one time in a hundred was tolerable at 1,400 events a year (about 14 failures, handled by a human). At 82,000 events it produces about 820 failures, so automation must be self-healing and idempotent, not merely scripted.

Rate limits become a design constraint

Let’s Encrypt’s published limits show why. New orders are capped at 300 per account every 3 hours. Certificates per registered domain are capped at 50 per 7 days (refilling one per 202 minutes), a limit shared across all accounts. Duplicate certificates, meaning the same exact set of identifiers, are capped at 5 per 7 days. Failed validations are capped at 5 per hour per identifier per account. Accounts per IP are capped at 10 per 3 hours.

Now consider 200 hostnames under one registered domain, each with its own 6-day certificate renewed every ~4.4 days. That is about 320 issuances per week against a limit of 50. The architecture does not fit. You have three levers: consolidate hostnames into multi-SAN certificates (up to 100 names per certificate), use wildcards where dns-01 is acceptable, or lean on ARI. Let’s Encrypt’s documentation states that ARI-coordinated renewals are exempt from all rate limits provided the new order includes at least one identifier from the certificate it replaces and that certificate has not already been replaced. Those conditions are why the replaces field matters, covered next.

ACME Renewal Information (ARI), RFC 9773

ARI, published as RFC 9773, flips the renewal decision from “client timer” to “CA advice”. The client asks the CA when to renew and the CA answers with a window.

Figure 2: The ARI loop. The client derives the certificate ID, polls renewalInfo, picks a time inside the suggested window and marks the new order as replacing the old certificate.

The mechanism is compact. The client constructs a certificate ID: the base64url-encoded Authority Key Identifier keyIdentifier, a period, then the base64url-encoded DER serial number (without tag and length bytes), with trailing = stripped. It sends an unauthenticated GET to the server’s renewalInfo URL plus that ID. The response contains a required suggestedWindow with RFC 3339 start and end timestamps and an optional explanationURL. The server uses a Retry-After header to say when to poll again.

The recommended client algorithm is to choose a uniformly random instant in the window. If it has already passed, renew immediately; if the client can schedule an exact attempt it does; if the instant falls before the client’s next wake-up it renews now; otherwise it sleeps until Retry-After. The randomness matters at scale. It spreads a fleet’s renewals across the window instead of stampeding the CA at the window’s start.

Then the new order includes replaces, the certificate ID of the predecessor. The server checks that the account matches, identifiers overlap and the predecessor has not already been replaced, returning HTTP 409 alreadyReplaced otherwise. This is the hook that both links renewals to the rate-limit exemption and prevents two clients from double-renewing.

The headline use case is mass revocation. Let’s Encrypt cites its January 2022 revocation of about two million certificates after a validation error. Revocation deadlines of 24 hours or 5 days are too short for people, but an ARI-aware client simply sees a window that has moved to “now” and replaces the certificate before the deadline. ARI can also smooth load spikes, although Let’s Encrypt says it does not currently use it for that.

Here is a small, runnable Python script that computes the ARI certificate ID and fetches the window. It requires cryptography and requests, and you should point it at a staging directory first:

import base64, sys, requests
from cryptography import x509
from cryptography.x509.oid import ExtensionOID

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

def ari_cert_id(pem: bytes) -> str:
    cert = x509.load_pem_x509_certificate(pem)
    aki = cert.extensions.get_extension_for_oid(
        ExtensionOID.AUTHORITY_KEY_IDENTIFIER).value.key_identifier
    s = cert.serial_number
    serial = s.to_bytes((s.bit_length() + 8) // 8, "big")  # DER INTEGER content
    return f"{b64u(aki)}.{b64u(serial)}"

def main(directory_url: str, pem_path: str):
    d = requests.get(directory_url, timeout=10).json()
    base = d["renewalInfo"]                      # absent if server lacks ARI
    cid = ari_cert_id(open(pem_path, "rb").read())
    r = requests.get(f"{base.rstrip('/')}/{cid}", timeout=10)
    r.raise_for_status()
    print("Retry-After:", r.headers.get("Retry-After"))
    print(r.json())          # {"suggestedWindow": {"start": ..., "end": ...}}

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

Run it as python ari_check.py https://acme-staging-v02.api.letsencrypt.org/directory cert.pem. The serial encoding line produces the minimal two’s-complement big-endian bytes, matching the DER integer content the RFC calls for.

DNS-PERSIST-01 and the validation bottleneck

If every renewal needs a fresh DNS TXT write, then your DNS API credentials are exercised constantly. dns-persist-01 addresses this. Instead of a per-issuance token, you publish one standing TXT record at _validation-persist.<domain> whose value starts with the CA’s issuer domain name (for example letsencrypt.org;) followed by an accounturi= tag identifying your ACME account. Optional tags include policy=wildcard, which extends the authorization to wildcard and subdomain names, and persistUntil, a UTC timestamp after which the record stops authorizing new validations.

The security trade-off is explicit: DNS write access is needed only once, so fewer systems hold DNS credentials, but the ACME account key becomes the asset to protect because the record stays valid. According to Let’s Encrypt, CA/Browser Forum ballot SC-088v3 passed in October 2025 and the IETF ACME working group adopted the draft the same month; their stated plan was staging in late Q1 2026 and production in Q2 2026. Check the current state before relying on it, because the draft was still evolving when this was written.

cert-manager ACME: Kubernetes Patterns

On Kubernetes, cert-manager is the dominant ACME client. It models CAs as Issuer or ClusterIssuer resources, certificates as Certificate resources, and the ACME dance as CertificateRequest, Order and Challenge objects reconciled by controllers.

Figure 3: cert-manager’s reconciliation chain. A Certificate spawns a CertificateRequest, which spawns an ACME Order and Challenges, and the result lands in a Secret consumed by workloads.

Configuring the ACME issuer

An ACME issuer needs an email, the server directory URL, a privateKeySecretRef for the account key, and a list of solvers. Each solver is either http01 or dns01, and a selector chooses which solver handles which names, using matchLabels, dnsNames (exact matches) or dnsZones (a zone and its subdomains). dnsNames outranks dnsZones; ties go to the solver with more matching labels, then the one listed first.

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: le-prod
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: ops@example.com
    privateKeySecretRef:
      name: le-prod-account-key
    profile: tlsserver
    solvers:
      - selector:
          dnsZones: ["example.com"]
        dns01:
          cloudflare:
            apiTokenSecretRef:
              name: cloudflare-token
              key: api-token
      - http01:
          ingress:
            ingressClassName: nginx
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: web
  namespace: prod
spec:
  secretName: web-tls
  dnsNames: ["app.example.com", "api.example.com"]
  issuerRef: {name: le-prod, kind: ClusterIssuer}
  renewBeforePercentage: 33

The profile field, available from cert-manager v1.18.0, selects an ACME profile. If unset, the server default applies, which is classic for Let’s Encrypt. If the server does not support profiles or does not recognise the name, cert-manager reports an error on the CertificateRequest rather than silently falling back, which is a useful guard against typos. Provider names inside dns01 vary; consult cert-manager’s documentation for your DNS provider.

Renewal knobs that matter at short lifetimes

Historically cert-manager renewed at two-thirds of lifetime by default, and renewBefore let you override it in absolute time. For short-lived certificates a percentage is the better expression, because an absolute renewBefore: 720h is longer than the certificate itself. Setting renewBeforePercentage keeps the policy proportional when lifetimes change. A 33 percent value renews with a third of life remaining, matching the two-thirds guidance.

cert-manager v1.21 added experimental ARI support behind the ACMEUseARI feature gate, per its release notes. When enabled, cert-manager polls the CA’s renewal endpoint and renews inside the suggested window. The release notes record a notable bug fixed in v1.21.3: a stale renewal window from the previous certificate caused repeated re-issuance until the CA rate limit was hit, and the fix tracks status.acme.ari.certID so ARI is re-fetched after each new issuance. The lesson is that an experimental feature gate on a renewal path deserves canarying, not a fleet-wide flip. v1.21 also introduced a renewal field that can schedule renewals into approved maintenance windows or disable automatic renewal, and a flag capping failed-request backoff, with a 32-hour default.

Other issuer options matter in specific setups. externalAccountBinding takes a key ID and a Secret holding a base64url MAC key for CAs that tie ACME accounts to commercial accounts. preferredChain selects an alternate chain by issuer common name. caBundle trusts a private ACME server’s CA, which is how you point cert-manager at an internal ACME CA such as step-ca. waitInsteadOfSelfCheck (v1.21.0 and later) skips the self-check and waits a fixed duration, useful when split-horizon DNS makes the self-check fail while the public validation would succeed.

Where Kubernetes ACME differs from VM ACME

On a VM, Certbot or acme.sh writes files and reloads a daemon. On Kubernetes the certificate lives in a Secret, and the consuming pod must notice. Many workloads read the certificate once at start, so a renewed Secret changes nothing until restart. With 47-day certificates this is an outage generator: the certificate is renewed on day 31 and the pod, serving the day-0 certificate, fails on day 47. Use libraries or sidecars that watch the mounted file, enable your ingress controller’s dynamic reload, or restart workloads on Secret change using a controller such as Reloader.

Trade-offs, Gotchas, and What Goes Wrong

Automation moves the failure from “a person forgot” to “a system is silently broken”. The following failure modes recur.

Figure 4: Where an ACME pipeline fails, from challenge reachability to workload reload, and which monitor catches each failure.

Challenge reachability drift. An http-01 path that worked for a year breaks when someone adds a redirect to HTTPS, a WAF rule, or geo-blocking. With multi-perspective validation, a partial block can pass from one region and fail from another. Each failure also burns the 5-per-hour failed-validation budget.

DNS credential sprawl. dns-01 needs write access to zones, often shared across teams. Scope tokens to the _acme-challenge records where your provider allows it, or delegate that label with a CNAME to a dedicated validation zone. Delegation limits the blast radius of a leaked token.

Retry storms. A failing renewal that retries aggressively consumes rate limits that you will need during an incident. Always use exponential backoff with jitter. cert-manager’s capped backoff exists for this reason, and its 32-hour default shows how long backing off can legitimately last.

Certificate not reloaded. Described above; renewal succeeds, serving does not change. This is the most common cause of expiry outages in otherwise automated environments.

Single CA dependency. If your only CA has an outage or revokes en masse, every certificate is affected on the same day. Consider a secondary ClusterIssuer on another ACME CA, tested regularly, with a documented switch procedure. ARI helps with the revocation case but does not help when the CA is unreachable.

Hardcoded lifetimes. Scripts that assume 90 days, monitors that alert at “30 days left”, and capacity plans built on 90-day cadence all misbehave when lifetimes change. A 30-day alert on a 6-day certificate is permanently firing; a 14-day alert on a 47-day certificate is far too late relative to a two-thirds renewal point.

Devices that cannot automate. Appliances, legacy middleboxes and embedded systems often cannot run an ACME client. Terminate public TLS on a front proxy that can, and keep the legacy device on a private CA behind it. This is an architectural boundary, not a workaround to feel bad about.

Pinning. Public key pinning of leaf certificates is incompatible with frequent reissuance unless you reuse the key across renewals. Pin to the issuing CA or, better, stop pinning. Reusing a key across renewals reduces some of the security benefit of short lifetimes, so prefer a new key per issuance.

Practical Recommendations

Start by inventorying. You cannot automate what you cannot list, and most organisations discover certificates they did not know existed. Use Certificate Transparency logs to enumerate every publicly trusted certificate issued for your domains; they are a CA-independent source of truth.

Next, standardise on one ACME client per platform: cert-manager on Kubernetes, one maintained client for VMs, and a front proxy for anything that cannot run either. Resist per-team bespoke scripts. Choose challenges deliberately: http-01 for public web endpoints, dns-01 for wildcards and internal hosts with scoped credentials or CNAME delegation, and watch dns-persist-01 as it matures.

Make renewal ARI-driven where the stack supports it, and canary it first. Where it does not, renew at two-thirds of lifetime expressed as a percentage, never as an absolute interval. Build monitoring from the certificate itself, not from the renewal job’s exit code: probe live endpoints, read notAfter, and alert on the fraction of life remaining. For a more detailed zero-trust identity model that complements this, read our SPIFFE/SPIRE workload identity architecture guide.

A short checklist to work through before March 2027, when the 100-day limit lands:

Inventory every public certificate through CT logs and your endpoint scans.
Remove every hardcoded 60-day or 90-day assumption from scripts, alerts and runbooks.
Move to percentage-based renewal and test a forced renewal monthly.
Ensure every workload reloads certificates without a manual restart.
Alert on remaining-life percentage at live endpoints, and on ACME failure counts.
Pilot shortlived or tlsserver profiles on one non-critical service.
Configure a second issuer on a different CA and rehearse the failover.
Rehearse the mass-revocation case: confirm ARI or an emergency reissue runbook works inside 24 hours.

Frequently Asked Questions

What is the ACME protocol?

The ACME protocol, standardised as RFC 8555, is an HTTPS and JSON-based protocol that lets a client prove control of a domain or IP address to a certificate authority and obtain a signed certificate automatically. A client registers an account key, opens an order, completes a challenge such as http-01 or dns-01, submits a CSR, and downloads the certificate. Let’s Encrypt popularised it, and many other public CAs now support it.

When do 47-day TLS certificates become mandatory?

Under CA/Browser Forum Ballot SC-081v3, the 47-day maximum applies to publicly trusted TLS certificates issued on or after 15 March 2029. Before that, the maximum is 200 days from 15 March 2026 and 100 days from 15 March 2027. The domain validation reuse window also falls, to 10 days by 2029. Individual CAs such as Let’s Encrypt are moving faster than the Forum minimums.

How often should I renew a short-lived certificate?

Use ACME Renewal Information if your client supports it, and let the CA’s suggested window decide. Without ARI, renew about two-thirds of the way through the certificate’s life, which is roughly day 31 for a 47-day certificate and day 30 for a 45-day one. Hardcoded intervals like 60 days will break as lifetimes shrink, so express the renewal point as a percentage of lifetime.

Does cert-manager support ACME Renewal Information?

Yes, experimentally. cert-manager v1.21 added support for RFC 9773 behind the ACMEUseARI feature gate. When enabled it queries the CA’s renewal endpoint for a recommended window. A bug where a stale window caused repeated re-issuance until the rate limit was reached was fixed in v1.21.3, so test in a non-production cluster and keep cert-manager current before enabling it broadly.

Are Let’s Encrypt short-lived certificates free, and can they cover IP addresses?

Let’s Encrypt’s service is free. Its short-lived certificates, valid for 160 hours, have been generally available since 15 January 2026 and are chosen with the shortlived profile. IP address certificates, for both IPv4 and IPv6, are also available but must be short-lived. Both options are opt-in, so you must request them explicitly in your ACME client or issuer configuration.

Do 47-day certificate rules apply to private or internal CAs?

No. SC-081v3 changes the Baseline Requirements for publicly trusted TLS certificates, enforced through browser root programs. Private PKI is outside that scope. Many teams nevertheless adopt short lifetimes internally because the same revocation weaknesses apply, and ACME-capable private CAs let the same cert-manager tooling serve both internal and public issuers.

ACME and the 47-Day TLS Certificate Era: Automating Short-Lived Certificates at Scale (2026)