(DC) What is the ACME Protocol?
What is the ACME Protocol?
The Automated Certificate Management Environment protocol (ACME) is a protocol for automating certificate lifecycle management communications between Certificate Authorities (CAs) and a company’s web servers, email systems, user devices, and any other place Public Key Infrastructure certificates (PKI) are used. The ACME protocol has no licensing fees, and it requires very little time for IT teams to configure and execute their certificate management automation, making it an increasingly adopted component of enterprise security.
The Internet Security Research Group (ISRG) originally designed the ACME protocol for its own certificate service and published the protocol as a full-fledged Internet Standard in RFC 8555 by its own chartered IETF working group. ACME v2 API is the current version of the protocol, published in March 2018. (The previous version, ACME v1, was released in April 2016; it is now deprecated.)
The basis for PKI certificate issuance is that Certificate Authorities, like Sectigo, are trusted to authenticate that a certificate user legitimately represents the identities and domain name(s) associated with the PKI certificate. The process for exchanging information necessary for the CA to perform that authentication and issue certificates, and for the user to then deploy the issued certificates, is automated using the ACME protocol, rather than communicating this information manually. In addition to the certificate issuance process, the protocol also enables other certificate lifecycle management use cases like certificate revocation and renewal, using simple JSON-formatted messages over encrypted HTTPS communications.
Why use ACME instead of other options?
Other certificate automation standards are available like Enrollment over Secure Transport (EST) and Simple Certificate Enrollment Protocol (SCEP) as well as solutions associated with enterprise architectures like Microsoft Active Directory. So why is ACME an increasingly popular automation standard for many enterprises?
The primary reason lies in the complexity and scale of most enterprise certificate needs. Enterprises rely on PKI certificates to authenticate and encrypt everything from web servers in the cloud and on-premises, networked devices, mobile devices, user identities, email systems, network appliances, IoT devices, DevOps environments, and more. Making management of this vast ecosystem even more challenging, enterprises often operate across multiple IT infrastructures, not just one centralized architecture.
IT teams rely on ACME more and more to help them address their scale and complexity challenges as it offers:
an open standard with a full set of commands and robust error handling, making it easy to adopt both by the enterprise and CAs
best of breed TLS and other PKI security practices for both IT teams tasked with implementing and managing valid PKI certificates and trusted CAs that adhere to strict authentication procedures
ongoing enhancements and support by a community, not controlled by any one single vendor or organization
flexibility to add and support backup CAs
low cost, being free to use
How does the ACME protocol work?
The two communication entities in ACME are the ACME client and the ACME server. The ACME client uses the protocol to request certificate management actions like issuance or revocation. The client runs on the user’s server or device that needs to be protected by the PKI certificate. The ACME server runs at a Certificate Authority, like Sectigo. It responds to the client requests and executes the requested actions once the client is authorized. The communication between the two is based on JSON messages over a secure HTTPS connection.
The other important element to the process is the authentication step, known as an ACME challenge. The CA cannot issue a certificate or complete the request until the challenge is passed. The authentication requirements for this validation process ensure that certificates are only issued to trusted users.
ACME challenge types:
HTTP challenges
When a request from an ACME client is received by the ACME server, the CA sends a token back to the ACME client to install on the server. Then the client creates a file that contains that token and appends it with a thumbprint of the authorization key that was generated during setup. The file structure is (Token) || '.' || (Thumbprint of Authorization Key). Once the file is installed, the client informs the CA, which retrieves and validates the file and then completes the request.
DNS challenges
This challenge includes an additional verification factor by requiring the ACME agent to place a given value in a TXT record in the domain’s DNS space. The authentication process is similar to HTTP challenges with the CA sending a token to the client and the thumbprint of the authorization key is appended to create and install the challenge file. Once the agent notifies the CA that the challenge has been met, the CA attempts to make a DNS lookup and retrieve the TXT record.
The entire challenge process is fast, typically completed under 15 seconds for both types. However, according to RFC 8555, administrators should make sure server setup is complete prior to the ACME client sending any requests as it is not uncommon for ACME servers' queries to fail while a resource is still being set up on the users’ systems. For example, DNS or HTTP information or firewall rules take time to propagate across servers and the ACME server may report an error if it queries a system before the propagation is complete. The ACME server at the CA views the challenge as “in progress” and retries the query every 5 to 10 seconds as long as the client continues trying. So it is recommended that in the user setup the clients should not respond to challenges until they believe that the server's queries will succeed, as there may be a small delay between uploading the file or DNS record and the CA being able to retrieve them.
No Challenge
Sectigo’s “no challenge” ACME option is used when domain control validation is not performed through the ACME client during the certificate request. Instead, the required domain validation is completed in advance within Sectigo Certificate Manager (SCM), and the ACME client then uses the configured ACME endpoint and account only to request, retrieve, renew, and manage certificates for domains that have already been authorized. In Sectigo’s documentation, this model aligns with Universal ACME, where domain control validation must be completed before certificate enrollment, and with other SCM workflows where some certificate types or configurations require domains to be validated in SCM rather than by ACME challenge at issuance time. In practical terms, this means the ACME client does not need to respond to an HTTP-01 or DNS-01 challenge for each order, because Sectigo relies on the prevalidated domain status already recorded in SCM. This approach is especially useful in managed enterprise environments where validation is centrally controlled, where DNS or web-server challenge handling is undesirable, or where certificates must be issued only for domains that have already passed organizational approval and validation processes.
The University of Texas at Austin uses this method for most ACME certificate issuance. Since domain control validation (DCV) is required to be pre-completed in Sectigo Certificate Manager (SCM), certificate enrollment typically proceeds without the use of a standard RFC 8555 challenge such as HTTP-01 or DNS-01.
What types of TLS/SSL certificates and other PKI certificates does it support?
As mentioned earlier, the ACME standard supports PKI certificates for a company’s web servers, email systems, user devices, and any other place PKI is used as long as the CA supports ACME for that type of PKI certificate. For example, it supports SSL certificates that require different authentication modes - domain validation (DV), organization validation (OV), and extended validation (EV) certificates - taking into consideration that additional authentication steps may be required outside of what ACME facilitates.