Automatic Certificate Management Environment (ACME) is a protocol that automates the request, validation, issuance, and renewal of digital certificates between a client and a certificate authority (CA). It replaces manual certificate enrollment with an API-driven exchange, and Versa devices can use it as a certificate server type starting in Release 22.1.3.
Key takeaways
- ACME automates certificate issuance, validation, and renewal through an API.
- It replaces manual CSR generation and certificate import steps.
- Domain or device control is proven with automated challenges.
- The IETF standardized ACME in RFC 8555; Let’s Encrypt popularized it.
- Versa devices support ACME as a certificate server type since Release 22.1.3.
On this page: Why it mattersHow it worksTypesACME & VersaFAQ
Why is ACME important?
Every TLS certificate has an expiration date, and one that lapses unnoticed breaks the service behind it – a common, avoidable cause of outages. Before ACME, keeping certificates current meant an administrator generating a CSR, submitting it to a CA, and importing the result before the old certificate expired, repeated for every host and renewal cycle.
ACME turns that manual workflow into an automated API exchange. A client requests a certificate, proves control of an identifier, and receives a signed certificate without a human in the loop – then renews it the same way, as often as needed. That automation made short-lived certificates practical at scale: Let’s Encrypt’s free, ACME-based CA drove mass HTTPS adoption, and the same pattern now extends to internal PKI, IoT fleets, and network devices needing routine certificate rotation.
What is ACME?
An ACME exchange runs between an ACME client (the device or software requesting a certificate) and an ACME server, operated by a certificate authority. The client registers an account with the CA using a key pair, then submits an order naming one or more identifiers – typically domain names – it wants certified.
To prove it controls those identifiers, the client completes one or more challenges the CA issues. Once validation succeeds, the client submits a CSR for the order, and the CA issues the signed certificate for download. Every message is a JSON Web Signature (JWS) request over HTTPS, so the whole lifecycle – order, validate, finalize, download, and later renew – happens without a human generating files or approving each step by hand.
Types of ACME challenges
ACME defines several challenge types to prove control of an identifier. HTTP-01 has the client serve a token at a well-known URL on port 80, which the CA fetches to confirm control of the web server. DNS-01 has the client publish a TXT record under the domain – it works without a public web server and is the only option for wildcard certificates. TLS-ALPN-01 presents the token in a self-signed certificate during a TLS handshake on port 443.
Beyond challenge types, ACME has gone through protocol versions: the original ACMEv1 used by early Let’s Encrypt clients is deprecated, and ACMEv2, standardized in RFC 8555, is current – adding an explicit order resource model and wildcard certificate support v1 lacked.
ACME & Versa
VOS devices support ACME as one of the certificate server types, alongside CMP, SCEP, KMIP, GCP, and CRL, since Release 22.1.3. An administrator adds it from Director’s per-device Certificate Manager (Configuration > Objects & Connectors > Connectors > Certificate Manager > Servers), selecting Server Type ACME and entering the CA’s enrollment URL, a retry interval, and the interface used to reach it. Release 22.1.3 also added Default CSR, which auto-generates a signing request using the device ID as common name instead of requiring every CSR attribute by hand.
The same option surfaces earlier in the workflow, too: creating a Secure SD-WAN tenant in Concerto with Certificate authentication (Release 12.1.1+) adds a Certificate step where Server Type can be set to ACME, CMP, or SCEP for the tenant’s CA. Once a server is defined, certificate requests specify validity, an autorenewal toggle, and a renew threshold – so a device’s ACME-issued certificate reissues automatically ahead of expiry rather than being tracked by hand.
Frequently asked questions
What does ACME stand for?
ACME stands for Automatic Certificate Management Environment (also written Automated Certificate Management Environment), standardized in IETF RFC 8555. It defines an API for requesting, validating, issuing, and renewing digital certificates between a client and a certificate authority without manual steps.
How does ACME prove domain or device control?
ACME issues one or more challenges – such as serving a token at a specific URL (HTTP-01), publishing a DNS TXT record (DNS-01), or presenting it during a TLS handshake (TLS-ALPN-01). The certificate authority issues the certificate only after the client successfully completes a challenge.
Does Versa support ACME for certificate enrollment?
Yes. Since Release 22.1.3, VOS devices can use ACME as a certificate server type, configured per device in Director’s Certificate Manager or as the CA type for a Secure SD-WAN tenant’s certificate authentication in Concerto, alongside CMP, SCEP, KMIP, GCP, and CRL server types.
What’s the difference between ACME, SCEP, and CMP on a Versa device?
All three are certificate server types a VOS device can enroll against: ACME is the IETF’s automated, API-driven protocol; SCEP is the Simple Certificate Enrollment Protocol; CMP is the Certificate Management Protocol. Versa configures all three the same way, as a Server Type choice on the certificate server object.
How does a VOS device renew an ACME certificate automatically?
Certificate requests on a VOS device support an Autorenewal toggle and a renew threshold – a percentage of the certificate’s validity period at which renewal kicks off automatically, so the device requests a fresh certificate from the ACME server before the current one expires.
More on ACME
If you want to learn more, these are sources we trust.
| RFC 8555: Automatic Certificate Management Environment | NIST Computer Security Resource Center |
|---|---|
| The core IETF standard: how ACME clients and certificate authorities exchange orders, challenges, and issued certificates over HTTPS. | NIST’s security resource hub, covering PKI and certificate-lifecycle guidance ACME implementations build toward. |
Related terms
If you’re reading about ACME, these are worth looking at next.
| Certificate Authority | Certificate Signing Request | Online Certificate Status Protocol |
|---|---|---|
| The trusted entity ACME talks to: it validates challenges and signs the certificates ACME requests. | The request ACME automates: a client’s public key and identity details, otherwise generated by hand. | Checks whether a certificate ACME issued has since been revoked, in real time. |