ACME profiles are where certificate policy becomes operational

What a profile actually controls

In ACME terms, a profile is a named set of certificate and validation characteristics. The useful way to think about it is this: the CA is saying, "Here are the shapes of certificate I am willing to issue from this directory."

For Lets Encrypt, the current profile documentation says the directory endpoint is the canonical source for what is actually available. The profile may affect practical things like:

• How long a pending authorization can sit before it expires.
• How long a completed authorization can be reused.
• How long the certificate is valid.
• Whether the certificate includes a Common Name.
• Whether DNS names only are allowed, or DNS and IP identifiers are allowed.
• How many names can be placed on the certificate.

That is not cosmetic. If you pick a six-day certificate profile for a service that still needs a manual reload, you have created a new incident source. If you pick a profile with a one-hour authorization window, your DNS automation needs to be reliable enough to complete inside that window.

Lets Encrypt: start conservative, then move toward automation

Lets Encrypt is the clearest public example because the profiles are documented. classic is the familiar default. tlsserver moves toward smaller, more modern TLS server certificates and a 45-day lifetime. shortlived goes much further, with a validity period of roughly six days and DNS/IP identifier support.

The operational advice is simple: use classic if you are still proving the workflow. Move to tlsserver when renewal, DNS challenge handling, cert delivery, service reload, and live probing are all boring. Treat shortlived as a test of discipline. If the renewal process still needs someone to SSH into a box, do not pick it.

Google Trust Services and commercial ACME: treat profiles as provider data

Not every ACME provider will publish the same names as Lets Encrypt. Some may only advertise a default profile. Some may expose profiles for staging, production, commercial validation paths, or EAB-bound accounts. That is why CertLocker stores profiles as directory metadata on the ACME client instead of hard-coding one CA's profile list.

For Google Trust Services, Sectigo, ZeroSSL, SSL.com, or a custom commercial CA, the pattern is the same: configure the ACME client once, refresh the directory metadata, and make profile selection a visible order-time decision. The team can then document which profile belongs to which estate rather than hiding that choice in a script argument.

Private ACME: profiles become internal certificate policy

Private ACME is where profiles get more interesting. A public CA profile is constrained by WebPKI rules. A private CA can publish profiles for internal TLS, IP SAN certificates, service mesh ingress, short-lived workload certificates, or a post-quantum pilot if the issuing stack supports it.

The important point is not the exact names in the screenshot. Those are demo names. The important point is that operators can see the policy before they create the order. "Internal platform CA with shortlived_ip" is much clearer than "run this renewal job and hope everyone remembers what flag was passed last year."

Where CertLocker puts profiles in the workflow

CertLocker supports ACME profiles as part of the normal certificate automation path. There is no separate "profile system" to learn. Profiles sit where operators already work: the ACME client, the order form, and the workflow detail.

1. ACME Clients: store the issuer, directory URL, EAB fields, contacts, groups, account key, and discovered directory profiles.
2. Update Profiles: refresh profile metadata from the live ACME directory when the CA changes what it advertises.
3. Create ACME order: choose an optional profile from the selected client. Leaving it blank keeps the provider default.
4. Workflow detail: record the selected profile next to the profile description from the client metadata.
5. Audit path: keep profile choice tied to the workflow, instead of losing it inside a local renewal command.

That last part matters during review. When an order succeeds or fails, the operator can see whether it used the default CA behaviour, the 45-day automation profile, or a short-lived internal policy. It is attached to the workflow, not just buried in the client command line.

This is useful now, and it becomes more useful as teams move away from annual certificate handling. If a platform team is standardising on Lets Encrypt for public edge, Google Trust Services for cloud workloads, and a private ACME directory for internal services, CertLocker gives them one place to manage the profile decision across all three instead of three different runbooks.

What teams should do now

Do not start with the most aggressive profile. Start by proving the renewal chain.

• Refresh the ACME directory metadata for each issuer you use.
• Record which profile is approved for public edge, internal services, IP certificates, and short-lived workloads.
• Use default profiles for systems that still have manual delivery or reload steps.
• Move automated endpoints toward profiles designed for shorter lifetimes only after probes confirm the renewed cert is live.
• Review failed workflows with the profile visible, because a failure under shortlived has a different urgency than a failure under a 90-day default.

The direction of travel is obvious: shorter certificate lifetimes, smaller certificates, less legacy baggage, and more pressure on automation. Profiles are how CAs expose those choices. Your job is to make sure the choice is deliberate and visible.

CertLocker is meant to be the control plane around that work: issuer setup, profile-aware orders, DNS challenge automation, certificate inventory, scoped delivery tokens, probes, and audit events. The profile is only one field, but it sits in the middle of a bigger question: can you prove the certificate you asked for is the certificate your service is actually serving?