Certificate automation is becoming more explicit about policy. Updated October 28, the IETF’s ACME Profiles Extension draft defines how an ACME server can advertise certificate profiles and how clients can request one. The draft notes implementations in multiple ACME servers and clients and deployment by Let’s Encrypt.
This is still an Internet-Draft and may change. Yet it surfaces an important inventory principle: the policy choice made during certificate issuance should remain connected to the certificate after it reaches a workload.
A certificate profile is more than a friendly label
Certificate authorities have long used profiles to describe what they issue. A profile can imply extended key usages, key usages, policy identifiers, constraints, validity behavior, or other certificate characteristics. The draft gives clients a standardized way to discover available profiles and identify the one requested in an ACME order.
For operations teams, a profile identifier should become governed data. A certificate record should connect:
- ACME server, directory, account, client, and order identifiers;
- the requested profile and the profile returned with the order;
- profile documentation, version or observation date, and governing policy;
- subject and subject alternative names, issuer, serial number, and validity;
- public-key algorithm, parameters, signature algorithm, and relevant extensions;
- application, service, endpoint, device, host, location, environment, and owner;
- key generation location, storage, custody, exportability, and rotation method;
- renewal automation, deployment path, reload behavior, and failure handling;
- discovery source, scope, timestamp, confidence, and coverage gap; and
- exception, remediation owner, evidence, and review date.
Without those relationships, teams can see a certificate but lose the reason it was issued in that form.
Requested, issued, deployed, and active are different states
Automation can make lifecycle ambiguity worse if every successful API response is treated as completed work. A client may request one profile, receive a certificate, fail to deploy it, leave an older certificate active, or install it on only part of a fleet. A proxy or managed edge may present something different from the origin.
Inventory should distinguish requested, authorized, issued, retrieved, deployed, activated, externally observed, renewed, revoked, and retired. Evidence for each state may come from different systems. ACME order data proves issuance activity; endpoint observation helps show what clients encounter; host or orchestration data helps explain where the material was installed.
No single discovery method proves completeness. Missing endpoint observations are not proof that a certificate or private key does not exist elsewhere.
Profiles can support migrations—but only with context
The draft documents real uses for moving away from a particular extended key usage and toward shorter-lived certificates. Profiles can help a CA present a controlled choice while clients adopt new policy. Similar mechanisms may eventually help organize other cryptographic transitions.
But a profile name alone does not establish compliance or post-quantum readiness. Teams must inspect the actual certificate, public-key and signature algorithms, chain, client behavior, relying-party support, and policy version. A profile can also change over time while retaining a stable identifier, so inventory needs an observation date and a link to authoritative documentation.
For post-quantum planning, connect certificate profiles to applications, protocol stacks, trust stores, peers, suppliers, and replacement dependencies. Vista tracks and governs that migration; engineering teams and certificate providers still perform the implementation and key operations.
Automation needs exception and rollback governance
Profile selection reduces free-form certificate requests, but it does not remove operational risk. Unsupported clients, unexpected extension handling, chain changes, renewal failures, or reload problems can interrupt service. A controlled rollout should identify the affected population, canaries, compatibility tests, rollback state, and accountable owner.
Exceptions should be explicit records with rationale, scope, expiration, approver, compensating controls, and review evidence. Otherwise an emergency fallback can quietly become the permanent certificate policy.
What organizations should do next
First, inventory ACME directories, accounts, clients, and renewal jobs. Determine which support profile discovery and selection, and record versions rather than assuming support from a product name.
Second, preserve profile identifiers and authoritative profile documentation alongside order and certificate records. Compare what was requested with what was issued and what is active.
Third, join certificate data to canonical infrastructure and application identifiers. Include physical or virtual location, business owner, service criticality, key custody, and supplier dependencies.
Fourth, test profile changes across issuance, deployment, reload, presentation, and renewal. Retain evidence for each stage and keep rollback conditions visible.
Finally, treat this draft as a developing standards signal. Follow the IETF process and supplier implementations before making the extension a mandatory control.
How Vista Platform helps
Vista Platform is a self-hosted infrastructure inventory and DCIM platform with cryptographic posture built in. It serves as a cryptographic system of record through discovery, canonical inventory, evaluation, action, and proof. Teams can connect cryptographic findings to applications, devices, hosts, locations, owners, suppliers, policy, exceptions, and migration evidence.
Vista Platform Core is free of charge and includes discovery, inventory, compliance and PQC assessment, and CBOM generation without asset, sensor, seat, or time caps. Vista tracks and governs post-quantum migration; it does not generate PQC keys or perform every migration. Selected-asset Active Scan is targeted rather than indiscriminate network scanning. Vista is not a vulnerability scanner, and discovery gaps are not proof of absence.
Explore Vista’s cryptographic inventory, post-quantum migration, and CBOM and compliance resources.
Where uncertainty remains
The extension has implementations, but the specification remains a work in progress. Final syntax, interoperability behavior, server policy, client support, and deployment timelines can evolve. A profile is also defined by the issuing CA; organizations must verify its actual contents and policy rather than infer meaning from its name.
Source
- Automated Certificate Management Environment (ACME) Profiles Extension, draft-ietf-acme-profiles-03, Internet Engineering Task Force, updated October 28, 2026.