Skip to main content

​
Limits and naming

​
1–100 entries
Capped at 100 to stay inside the signing authority’s per-order limits.
​
unique per account
Matches ^[a-zA-Z0-9][a-zA-Z0-9._-]{0,253}$. It appears in the CRN, so it has to be URL-safe.
​
name-based, no region
crn:certificate::<account>:certificate/<name>. The region slot is empty — certificates are not region-bound — and because the CRN is built from the name, an IAM policy can wildcard a naming convention: crn:certificate::my-account:certificate/prod-*.

​
Troubleshooting

Read the challenges array. Each entry has its own verified flag and, when a check has failed, an error_message naming what was found against what was expected — for example CNAME = foo, want bar.The usual causes are a CNAME published at the wrong name (check cname_record_name rather than assuming), a trailing-dot mistake at the registrar, or simply DNS TTL — a record that replaced an older one is not visible until the previous value ages out.
That is the documented behaviour of POST /v1/certificates, not a failure. Challenges are planned by the issuance workflow moments later. Poll GET /v1/certificates/{certificate_id} until the status is pending_dns.
Wildcards validate at the parent name: *.example.com is proven by _acme-challenge.example.com, not by anything containing a *. Publish exactly the cname_record_name the challenge gives you.A wildcard also needs a wildcard-capable authority, so a wildcard order fails rather than falling back to one that cannot sign it.
error_message carries the last failure — commonly that the DNS challenge did not propagate before the deadline. Fix the record and create a new certificate; a certificate in error is not retried indefinitely.
A listener matches SNI against each attached certificate’s SANs and falls back to the one flagged is_default. A client seeing the default when it expected something else usually means the SAN it asked for is not on any attached certificate — check domains.