ACME Certificate Profiles: Which One to Ask For, and What Breaks

What an ACME profile actually is

A profile is a named set of certificate parameters that the CA offers and the client selects. The ACME Profiles Extension adds exactly three things to RFC 8555: a profiles map in the meta object of the directory resource, a profile string on the order you POST to newOrder, and an invalidProfile error for names the server does not recognise. Accounts, authorizations, challenges and finalization are untouched.

The directory entry is a plain map of profile name to human-readable description, so discovery costs one GET. Ask for a profile the server has never heard of and it answers with a problem document of type urn:ietf:params:acme:error:invalidProfile. The same error comes back when the profile is real but incompatible with what you asked for, which is how a server refuses, say, an email identifier on a TLS server profile. When the order is accepted, the server echoes the profile it applied back in the order object, so a client can confirm it got what it asked for rather than assuming.

Worth knowing before you build on it: this is still a draft. Draft 02 of draft-ietf-acme-profiles landed in August 2026 on the Standards Track, and it has not been published as an RFC. Deployment ran well ahead of publication. The draft counts two server implementations, Boulder and Pebble, and at least seven clients, among them Certbot, lego, Caddy, dehydrated and Posh-ACME. Field names have been stable through the revisions, which is why clients shipped support early, but a draft is still a draft.

The three profiles on offer today

Let's Encrypt publishes three profiles as of September 21, 2026. classic issues 90-day certificates, allows up to 100 identifiers, and is what you get when your client asks for nothing. tlsserver issues 45-day certificates and caps you at 25 identifiers. shortlived issues certificates valid for 160 hours, a few hours under seven days, also caps at 25 identifiers, and is the only profile that will put an IP address in a certificate.

None of this is frozen. The tlsserver profile only became a 45-day profile on 13 May 2026; before that it was a shorter-lived experiment for early adopters. The classic default is scheduled to drop to 64 days on 10 February 2027 and to 45 days on 16 February 2028, which means the gap between doing nothing and opting in closes on its own over the next eighteen months. Six-day certificates and IP address certificates both reached general availability on 15 January 2026, after the first six-day certificate was issued in February 2025.

The identifier cap is the constraint people hit first and read about last. Dropping from 100 names to 25 is fine for a per-service certificate and painful for anyone who has been packing a hundred hostnames onto one SAN list to keep the renewal count down. That pattern was already a bad idea under a 90-day cycle, since one failed validation takes out every name on the certificate. Under a 45-day cycle it is worse. If the cap is what stops you moving, the fix is to split the certificate, not to stay on classic.

What the shorter profiles remove from your certificate

Both shorter profiles drop four things: the Subject Common Name, the Subject Key Identifier, the Key Encipherment key usage on RSA certificates, and the TLS Client Authentication extended key usage. shortlived drops a fifth, the CRL and OCSP revocation pointers, because a 160-hour certificate qualifies as a Short-lived Subscriber Certificate under the Baseline Requirements and is not required to carry them.

Each removal has a reason that survives scrutiny. The Common Name duplicates information already in the Subject Alternative Name extension and has been discouraged by the Baseline Requirements for years. The Subject Key Identifier does nothing useful in an end-entity certificate. Key Encipherment is only meaningful for RSA key exchange, which browsers removed because it is not forward-secret. The client authentication EKU has no business in a certificate you bought to serve TLS, and Let's Encrypt removed it from all issuance on 8 July 2026 regardless of profile.

In practice only two of the five ever produce a support ticket. The first is the Common Name. A surprising amount of infrastructure reads subject.CN and nothing else: inventory scripts, dashboards on network appliances, alerting that emails you the "certificate name" it found. Point those at a tlsserver certificate and they report an empty subject, which usually surfaces as a blank row rather than an error, so it goes unnoticed until someone needs it. The second is Key Encipherment, and it is rarer: a handful of embedded TLS stacks and very old Java deployments still negotiate RSA key exchange, and they will fail the handshake outright rather than degrade quietly.

The shortlived removal is different in kind. A certificate with no CRL distribution point and no OCSP responder cannot be revoked in any way a client would notice, which is the point: at 160 hours the certificate expires faster than revocation information reliably propagates. If your compliance posture involves demonstrating that revocation checking is enabled, or your monitoring asserts that every certificate carries an OCSP URL, both will need rewriting before you adopt that profile. It is easier to change the monitoring than to argue with the auditor afterwards.

The one-hour window is the real change

The tlsserver and shortlived profiles cut the pending authorization lifetime to one hour, down from seven days on classic. That is the single change most likely to break an existing deployment. A 45-day certificate only asks you to renew more often; a one-hour authorization asks you to complete domain control validation without a human anywhere in the loop.

Count the hour from when the order is created, not from when your script gets round to solving the challenge. That distinction matters more than it sounds. Plenty of renewal pipelines create the order, queue a job, wait for a worker, then handle the challenge. On a seven-day window the queue depth was invisible. On a one-hour window it is a failure mode.

DNS-01 takes the worst of this. Anything that pushes a TXT record into a zone with slow propagation, or into a provider whose API is eventually consistent, or through a change-approval ticket, is now racing a clock it was never designed to race. The honest fix is to shorten the path: an API-driven DNS provider, or a dedicated validation zone delegated with CNAME so the challenge record lives somewhere you can write to instantly. Retrying harder does not help, because each retry starts a new order against the same slow zone.

There is a second number worth knowing. Once an authorization has been validated it can be reused for seven hours on the shorter profiles, not seven days. That ceiling is not arbitrary: the Baseline Requirements oblige the CA to recheck CAA records within eight hours of issuance, so a seven-hour reuse window leaves an hour of headroom. If you batch issuance for many names across a maintenance window longer than seven hours, expect revalidation partway through.

How to request a profile in your client

In Certbot, pass --preferred-profile tlsserver to request a profile and fall back silently if the CA does not offer it, or --required-profile tlsserver to fail the order instead of falling back. Both flags landed in Certbot 4.0.0 on 7 April 2025. Run at least 4.1.0, released 10 June 2025, before you depend on either.

That version floor is the trap, and it is worth spelling out because the failure is silent. In Certbot 4.0.x the profile flags were honoured at issuance and then dropped: they were never written into the renewal configuration, so the first automated renewal quietly went back to classic. The certificate stayed valid, nothing alerted, and the only symptom was a 90-day certificate where a 45-day one was expected. Issue #10271 traced it to a missing entry in the STR_CONFIG_ITEMS list in renewal.py, and 4.1.0 fixed it by persisting both flags. If you are on 4.0.x today, check what your renewal .conf files actually contain before you trust the flag.

A short sanity pass after switching, in the order that catches problems earliest:

1. Confirm the CA advertises the profile at all: curl the directory URL and look for the profiles map inside meta.
2. Issue once against staging with --required-profile rather than --preferred-profile, so a CA that does not offer it fails loudly instead of handing you a classic certificate you did not ask for.
3. Read the issued certificate back and check the validity period, not the client's log line. Forty-five days means the profile applied; ninety means it did not.
4. Force a renewal and read it back a second time. This is the step that catches the 4.0.x persistence bug and anything else that only bites on renewal.

Other clients expose the same order field under their own spelling. lego implements the draft extension directly, and Caddy, dehydrated and Posh-ACME all shipped support. If you use Certbot for IP address certificates, note that --ip-address arrived separately in 5.3.0 on 3 February 2026, and Let's Encrypt requires --preferred-profile shortlived alongside it, since shortlived is the only profile that accepts an IP identifier.

Which profile should you ask for?

Take tlsserver if your issuance completes end to end, unattended, inside an hour, and nothing in your estate reads the Subject Common Name. Take shortlived only when you need an IP address certificate, or when you have a genuine reason to want a certificate that cannot be revoked. Stay on classic if a human, an approval queue or a slow DNS zone sits anywhere in the path.

The case for moving early is not really about certificate size. Maximum validity for publicly trusted TLS certificates already fell to 200 days on 15 March 2026 under CA/Browser Forum ballot SC-081v3, drops to 100 days on 15 March 2027, and reaches 47 days on 15 March 2029. Every pipeline is going to have to survive that. Opting into a 45-day profile now is the cheapest available rehearsal, and it runs with a CA whose defaults you can retreat to if the rehearsal goes badly.

Where I would not move yet: anywhere the renewal still depends on a person. Teams sometimes read the one-hour window as a tuning problem and try to solve it with tighter retry logic or a shorter cron interval. It is not a tuning problem. If a TXT record reaches the zone in ninety minutes, no retry schedule fixes that, and the failure arrives as an outage on a Sunday rather than as a warning on a Tuesday. Fix the validation path first, on classic, where a missed renewal still has weeks of margin behind it. Then switch.

One more sequencing note. Pair the move with ACME Renewal Information, which lets the CA tell your client when to renew, rather than hard-coding "renew at 30 days" and discovering that a 45-day certificate renews on day 15 of its life, or that a 160-hour one has already expired.

What this means if you buy OV or EV certificates

Profiles are a property of the ACME server, not of the certificate market, so a commercial CA issuing OV or EV over ACME does not hand you the same three-item menu. Your validity is set by the SC-081v3 schedule rather than by a profile name, and the thing that limits your automation is organization revalidation, not a one-hour challenge window.

That difference is easy to under-estimate when planning. A DV certificate from an ACME CA can be reissued unattended as often as you like, because domain control is the only thing being proved. An OV or EV certificate also carries vetted organization data, and that vetting has its own reuse clock. Automating issuance does not automate the paperwork behind it. Teams running both usually end up with two different renewal designs for that reason, which is fine as long as it is deliberate rather than discovered.

If you are deciding which kind of certificate belongs on which host before you design the automation, compare what DV, OV and EV certificates actually verify and what each one needs at renewal. The answer usually splits cleanly: ACME and a short profile for anything public-facing and machine-managed, a vetted certificate where a human reader is meant to learn who runs the site. For the middle ground, cert-manager can drive a commercial CA over ACME inside Kubernetes, which keeps one renewal mechanism across both.