Summary

  • draft-ietf-acme-profiles-02 lets an ACME server advertise server-local certificate profiles and bind a selected profile to an Order. It remains a Standards Track Internet-Draft, not an RFC or universal profile registry.
  • A profile string records policy intent. Account eligibility, identifier control, issued-certificate conformance, installation and relying-party acceptance remain independent receipts.
  • The strongest operating model preserves the Directory and policy view used at selection time, then verifies the actual DER certificate and the endpoint that served it.

The renewal dashboard says the Order used tlsserver. The ACME exchange is correctly signed. The server returned the same profile name. Automation marks the run successful.

An engineer inspects the certificate and finds an unexpected Extended Key Usage. Another endpoint still serves the previous certificate. A third client builds a different chain and rejects it. Nothing about the profile string can answer which of those outcomes occurred. It records a policy selection, not the whole life of the credential.

That distinction is the useful governance problem in draft-ietf-acme-profiles-02. Dated 28 August 2026, the document is an ACME Working Group Standards Track Internet-Draft. It proposes a small protocol extension for a real operational need: certificate authorities offer different kinds of certificates, but RFC 8555 gives clients no clean way to discover and select those policies. The draft remains work in progress. Its implementation note names two servers and seven clients, and Let’s Encrypt documents production use, but those facts do not turn revision 02 into an RFC or a complete adoption census.

The protocol adds a selector, not a universal product catalogue

An ACME server that permits profile selection places a profiles object inside the meta member of its Directory. Each entry maps a short name to a human-readable URL. The server chooses both. A client may then include one name in the profile field of newOrder; an accepted Order echoes the selected name.

The compactness is deliberate. The protocol does not define a global vocabulary in which classic, tlsserver, shortlived or profile1 means the same thing at every CA. Nor does the description URL contain a required machine-readable list of certificate predicates. It can even be a data URI. What travels in the Order is therefore a selector into one server's policy, not an independently certified meaning.

That is enough to improve ACME. A client can state intent without stuffing policy wishes into a CSR. A server can expose choices without inventing a proprietary ordering endpoint. The selected policy can survive from Order creation to finalization. None of those gains requires the profile name to become more authoritative than it is.

Record the Directory URL, response bytes or digest, retrieval time, TLS peer, profile description bytes and any account-specific terms. Recording only profile=tlsserver discards the namespace that made the value meaningful. The same spelling on another endpoint may describe another certificate.

The draft moves policy out of arbitrary CSR fields

RFC 8555 allows identifiers and a requested validity range in newOrder, then receives a CSR at finalization. A CSR can contain many X.509 fields and extensions. The CA is still responsible for deciding what to issue, and copying untrusted CSR content has repeatedly created dangerous policy and parsing surfaces.

The profile extension narrows that surface. Its security section says that fields beyond Subject Alternative Names and the Subject Public Key no longer need to drive this policy decision. The CA constructs the certificate according to the selected profile instead of treating arbitrary client extensions as an issuance template.

The boundary needs exact language. The CSR is not irrelevant. Its public key remains essential, and its SANs relate to the identifiers the Order authorizes. The extension does not eliminate CA policy, certificate construction, chain selection, logging, signature or audit obligations. It simply creates a clearer place for profile selection.

This is Running-Code Primacy in a useful form: define the smallest interoperable control that removes ambiguity, then let implementations demonstrate the result. The wire field should not become a substitute for examining the bytes that the CA actually signed.

Client choice and server default are different events

A client can explicitly request a profile. If it does, the signed ACME message proves that the account key authorized a payload containing that string. The server must still evaluate the combination.

If a client omits the field while the server advertises profiles, the draft recommends that the server select one and associate it with the Order. In that path, the Order's profile is evidence of server choice, not client preference. A user interface that shows both as “selected profile” erases who controlled the decision.

Preserve selector origin. Store the client version and configuration source, the account identifier, the request payload, the accepted Order, the server policy version and the operator or process authorized to change each side. A migration can then distinguish “the subscriber opted in” from “the default moved beneath an unchanged client.”

This matters because defaults carry scale. Let’s Encrypt's published migration plans use profiles to introduce narrower EKUs and shorter lifetimes before changing the default. Early adopters can choose a new profile; later, unchanged clients can receive different certificate characteristics when classic changes. Both paths may be intentional. They do not assign the same responsibility.

Eligibility is not identifier control

The server must reject a profile that is incompatible with the rest of the Order. The draft gives two kinds of examples: an identifier type that does not fit the requested profile, and an account not present on an appropriate allowlist. The proposed error is invalidProfile.

Those checks are not ACME authorization. An enterprise account can be entitled to a private or premium profile and still fail to prove control of a domain. Another account can complete DNS-01 or HTTP-01 and still lack authority to request a constrained-sub-CA or transitional profile. Profile eligibility and identifier validation answer different questions.

Keep at least three receipts: why this account could request the profile; how each identifier was authorized; and why the CA's issuance policy accepted the final combination. External Account Binding, contracts, payment, incident approval or an internal allowlist can support the first. ACME challenge records support the second. The certificate and CA issuance record support the third.

Collapsing them is attractive because a successful Order looks like one transaction. It is still a sequence of authorities. A valid account signature proves control of an ACME account key, not control of every identifier or entitlement to every certificate capability.

The unadvertised path is intentional—and needs a stronger receipt

The server should reject a profile name that it is not advertising, but the draft allows exceptional acceptance. It mentions a private profile agreed out of band and replacement during a mass revocation when an older profile is no longer publicly offered.

This is not a loophole accidentally left in the design. It is an operational escape hatch. It prevents public discovery from becoming the sole source of authority during enterprise arrangements or emergency replacement.

The consequence is that absence from the Directory is not proof of invalidity. A public inventory can differ from the server's accepted policy. That makes evidence more important, not less. For an unadvertised Order, retain the agreement or incident reference, accounts and identifiers in scope, approving authority, start and end time, constraints, replacement objective and evidence that ordinary accounts could not invoke the path.

Private does not mean improper. Undocumented means unauditable. The governance question is whether an exception can later be connected to a named authority and bounded purpose without exposing sensitive commercial terms to every client.

Profile retirement has two clocks

An advertised profile can disappear while Orders created under it remain live. The draft addresses the collision directly: if the CA is no longer willing to issue at finalization, the server must return invalidProfile. It recommends avoiding that outcome by allowing Orders for the profile to expire before issuance stops.

The Directory clock and the Order clock are therefore separate. The Directory says what a fresh client can discover now. An existing Order reflects a decision made earlier and has its own expiry, authorizations and finalization state.

Track profile advertisement start and stop, default changes, last accepted Order, latest possible Order expiry, final issuance, outstanding renewals and emergency exceptions. Without that ledger, a client sees only a late invalidProfile and may misclassify the event as a network, CSR or authorization failure.

The difficult case is semantic drift under a stable name. A CA can change a profile's lifetime, EKUs, validation reuse or chain policy while continuing to advertise the same selector. That may be a legitimate policy evolution. It also means old screenshots of the profile page cannot prove what a later renewal received. Freeze the policy view per Order and verify every issued certificate.

The Order is the commitment; the certificate is the conformance object

An accepted Order says the server bound a profile name to a transaction. The certificate is the output that can be examined independently.

A conformance test should parse the DER certificate and compare it with a versioned predicate for that profile: exact SAN set and identifier types; public-key algorithm and parameters; Key Usage and Extended Key Usage; Basic Constraints; certificate policies and criticality; validity; issuer; signature algorithm; chain; serial and encoding rules; transparency evidence; and prohibited fields.

The test should also bind the certificate to the Order, authorization records and CSR public key. Otherwise an operator can prove that a certificate matches a policy while failing to prove it belongs to the transaction under review.

Human-readable documentation helps an operator choose. It is a weak input to automation. A CA could publish a machine-checkable conformance manifest as an operational supplement. That would not require turning profile names into a centrally governed catalogue. It would let subscribers test the CA's output against the CA's own frozen promise.

The same check belongs after every renewal. Reusing a profile name does not guarantee the same policy version, lifetime, chain or extension set. Automation that validates only the ACME response has verified the control plane and skipped the credential.

Transparency and CAA are independent evidence

Certificate Transparency can show that a certificate or precertificate was submitted to a log. It does not show that the subscriber selected this profile, that the CA followed the associated policy, or that the certificate was installed.

CAA can constrain permitted issuers and, under its own parameters, account or validation choices. It does not select an ACME profile or prove the fields of the result. Both controls are valuable because they add separate observations. Neither should be used to fill gaps in the profile receipt.

The same discipline applies to chain building. A CA may offer or deliver one chain; a relying client may build another available path under its local trust store. Profile intent cannot command the client's result. The relying party controls the final acceptance decision.

Deployment is where the label meets a live system

After issuance, the certificate still has to reach the intended endpoint with the corresponding private key. Load balancers, regional replicas, secret stores, sidecars and stale processes can create partial deployment. A renewal job can report success while a subset of traffic continues to see the old credential.

Bind the certificate DER hash and public-key hash to each installation target. Observe the certificate served externally. Check activation time, protocol role, SNI or service identity, chain, staple where relevant and retirement of the predecessor. Then test representative relying parties.

This is the end of the evidence chain: discover -> preserve -> select -> qualify -> authorize identifiers -> bind order -> finalize -> inspect -> deploy -> observe -> renew.

Each arrow can fail while the previous step remains valid. That is why a profile should not produce one green badge. It should produce linked receipts.

Let’s Encrypt shows the migration value and the time problem

Let’s Encrypt describes a profile as characteristics of both validation and final certificate content. Its documentation says most subscribers can rely on automatic selection, while operators with special needs can request a profile.

Its published EKU migration used a tlsserver path without TLS Client Authentication, a later change to the default classic behavior, and a temporary tlsclient option for subscribers needing more time. Its lifetime plan uses opt-in profiles for 45-day and six-day certificates before later default changes.

This is meaningful running-code evidence. Profiles can stage change without requiring all clients to move on one day. They can separate early adoption, default migration and bounded compatibility.

It also demonstrates why a label needs a timestamp. Certificate lifetime, validation reuse, EKUs and availability move on different schedules. The evidence does not show that every subscriber migrated successfully or that every listed client supports every path. It shows that one CA is using the selector as an operational migration surface.

Build a profile evidence receipt

A useful receipt sits beside ACME rather than changing it. Bind the Directory response and documentation hash; profile name and selector origin; account and configuration authority; identifiers, validity request and public-key hash; eligibility rule; ACME authorization records; accepted Order and expiry; finalization and CSR hash; certificate DER, serial, issuer, chain and transparency evidence; conformance result; installation targets; external observations; relying-client tests; renewal schedule; exception authority; and rollback or revocation path.

The receipt should distinguish observations from assertions. “The Order echoed tlsserver” is an observation. “The certificate complies with profile revision X” is a test result. “This endpoint served the DER hash” is another observation. “This service met its availability objective” is a later operational conclusion.

The protocol remains small. Local systems preserve the evidence they need. That is a better design than asking an IETF registry or CA label to settle every downstream decision.