Certificate authorities
Any CA can issue
With certificate: "self", the default, you run the ACME client and choose the CA. Our domains name Let's Encrypt and Google Trust Services in CAA, so those two need nothing from you; for any other CA, publish a CAA record on your hostname and it applies instead. See CAA below.
The acme-dns endpoint publishes _acme-challenge.<hostname> TXT, which is what every CA checks. It carries no CA-specific behaviour. See the quickstart.
The newest two TXT values for a name survive; older ones are pruned. That matches acme-dns, and it is what the apex-plus-wildcard double validation needs.
Both validate against the address the hostname points at, so they need no involvement from us and work with any CA.
External Account Binding
Some CAs will not create an ACME account without it. This applies whichever mode you use, and it is the most common reason a first run against a new CA fails.
External Account Binding (RFC 8555 section 7.3.4) ties an ACME account to an identity the CA issued out of band. A CA requiring it will not create an account without one.
Google Trust Services and ZeroSSL do. Let's Encrypt and Buypass do not.
Enable the Public CA API on a Google Cloud project, grant roles/publicca.externalAccountKeyCreator, then run gcloud publicca external-account-keys create. It returns a key ID and an HMAC. There is no charge for certificates.
Not hex and not standard base64. Decoding it the wrong way produces a well-formed binding that the CA rejects as unauthorized, with no error indicating the encoding rather than the key.
certbot takes --eab-kid and --eab-hmac-key. Caddy takes an external_account block. acme.sh takes --eab-kid and --eab-hmac-key on --register-account.
A Google EAB pair is valid for 7 days. It authorises creating the account, not using it, so an account registered inside that window keeps working afterwards.
Managed certificates: the CAs we run
With certificate: "managed" or certificate: "csr" we run ACME for the hostname, so the CA has to be one we hold an account with. That is a shorter list than the one above - it is what we can issue from, not what you can. Both support DNS-01, wildcards and ACME Renewal Information (RFC 9773), and neither charges for certificates.
The two modes differ in who holds the key, not in which CAs are reachable. On csr you keep it and renew on your own schedule; on managed we generate it and renew for you. See Certificate modes.
| CA | ca value | EAB | ARI | Production directory |
|---|---|---|---|---|
| Let's Encrypt | letsencrypt | Not required | Yes | https://acme-v02.api.letsencrypt.org/directory |
| Google Trust Services | Required | Yes | https://dv.acme-v02.api.pki.goog/directory |
Choosing one for managed
The ca field on POST /v1/hostnames.
Let’s Encrypt. Omit ca and you get it, unless selection has reason to pick otherwise.
Send {"certificate": "managed", "ca": "google"} to POST /v1/hostnames. Valid values are letsencrypt and google.
That is certificate: "managed" and certificate: "csr". Sending it with certificate: "self" is a 400 rather than an ignored field. On self you run the client, so the CA is a choice you make there.
Let's Encrypt, unless it has recently rate-limited orders for your domain and another CA is configured. Its cap is 50 certificates per registered domain per 7 days, and no domain is shared between accounts, so that budget is yours alone.
A renewal goes back to the CA that issued, always. The ARI identifier it carries is only resolvable by that CA, and renewals coordinated through ARI are exempt from rate limits.
GET /v1/hostnames/{id}/certificate returns ca and issuer alongside the chain.
CAA
Every domain we operate publishes a CAA record naming Let's Encrypt and Google Trust Services, plus an address for violation reports. A CA outside that list is refused at issuance, which is the point: it means a mis-issuing CA cannot quietly produce a certificate for your hostname.
You can override it on your own hostname. Publish a CAA record through the records API and it applies to your name instead of ours - a CA reads the closest record set to the name it is certifying and ignores everything above it. That is how you use a CA we have not listed. Deleting your record puts the domain policy back.
We serve exactly what you publish and do not merge it with ours. So a record naming only your CA excludes ours for that hostname, which is either what you wanted or worth knowing before you write it. We deliberately do not restrict the challenge type, so HTTP-01 and TLS-ALPN-01 against your own IP keep working.