Skip to main content

ACME accounts

Configure registrations against the 9 supported public CAs that speak ACME. Most are open registration; a few require External Account Binding (EAB).

Supported CAs​

CACert typesEAB?Notes
Let's EncryptDVnoFree, 90-day validity, generous staging.
Google Trust ServicesDVyesFree for GCP customers; EAB via Cloud Console.
ZeroSSLDVyesFree 90-day; paid OV/EV via REST not ACME.
SectigoDV / OV / EVyesEnterprise contracts, multi-CA roots.
SSL.comDVyesTwo directories, split by key algorithm (ECC and RSA), both DV.
GoDaddyDV / OV / EVyesThree environments on one ACME endpoint.
ActalisDVyesEuropean CA; eIDAS QSeal options off-ACME. Wildcards not supported over ACME.
GlobalSignDV / OV / EVyesAtlas ACME; per-product directories.
DigiCertDV / OV / EVyesCertCentral ACME endpoints per profile.

Creating an account​

  1. Settings → ACME Accounts → New.
  2. Pick the provider environment. Its directory URL is used as-is — you cannot override it here. Changing a provider's directory URL is an owner-only operation on the CA provider itself.
  3. Email — used for expiry notices from the CA itself.
  4. (No key-type choice here — the account key is always ECDSA P-256. The RSA/ECDSA options you see elsewhere are certificate key types, chosen per certificate.)
  5. For EAB CAs, paste the kid and HMAC key. See EAB-bound CAs for where to find them per provider.
  6. Save. The server generates the account key, registers with the CA, and stores both the key and the registration URL.

Staging vs production​

Where a staging environment exists, create that account first, issue a couple of test certs against it, prove the DNS-01 flow works, then create the production account. Only Let's Encrypt and Google Trust Services ship a staging environment; the other seven providers are production-only.

The Let's Encrypt production limits are 50 certificates per registered domain per week and 5 duplicate certs per week. CertAutoPilot exposes both rate limits on the account detail page so you can see how close you are to the cap.

Replacing the account key​

The ACME keyChange rollover flow is not implemented — there is no rotate-key endpoint and no UI button.

The one path that replaces an account key is submitting new EAB credentials on a PATCH of the account: that generates a fresh account key, re-registers with the CA, and overwrites the stored registration URL.

OV/EV certificates — where the organization comes from​

For OV/EV certificates over ACME, the organization identity is not taken from the CSR. It is pre-validated by the CA and bound to your ACME account through EAB (External Account Binding). This is required by the CA/Browser Forum Baseline Requirements — the CA must independently vet the organization, so a self-asserted O= in a CSR can never, by itself, produce a trusted OV/EV certificate.

Consequences:

  • Public CAs (GlobalSign Atlas, Sectigo, DigiCert) ignore or override the organization fields (O, C, ST, L, and the EV jurisdiction fields) in the CSR and issue with their vetted record. The organization you pick when issuing must therefore match the CA-vetted organization tied to your EAB credentials.
  • Some strict CAs (notably GlobalSign Atlas) reject a request whose CSR subject conflicts with the vetted profile.
  • The organization record you configure in CertAutoPilot (Settings → Organizations) is a local convenience for selection/consistency; it does not override the CA's vetted identity.

Omit organization from CSR subject toggle. On an OV/EV ACME account (account detail page), enable this to send SANs only in the CSR — no O/C/ST/L or EV fields. Use it for public CAs that derive the organization from the EAB-bound profile (and reject conflicting CSR subjects, e.g. Atlas). Leave it off for CAs that do honor the CSR subject, where the fields you set are used. (Note that private/internal ACME CAs cannot currently be added — there is no create route for CA providers, and the owner-only directory-URL patch rejects private and loopback addresses.) Default: off (include organization), preserving behavior for private CAs.

Removing an account​

ACME account deactivation at the CA is not implemented — there is no deactivate endpoint, and the only account statuses are active and inactive. Deleting the account removes the local record; it does not tell the CA anything.

API​

GET    /api/v1/projects/{project}/acme-accounts
POST   /api/v1/projects/{project}/acme-accounts
GET    /api/v1/projects/{project}/acme-accounts/{id}
PATCH  /api/v1/projects/{project}/acme-accounts/{id}
DELETE /api/v1/projects/{project}/acme-accounts/{id}
POST   /api/v1/projects/{project}/acme-accounts/{id}/validate
GET    /api/v1/projects/{project}/acme-accounts/{id}/usage

See also​