#compsci 

The Automatic Certificate Management Environment (ACME) protocl is a communications protocol for automating interactions between [[Certificate authority|certificate authorities]] and their users' servers.

Designed by the [[Internet Security Research Group]] for their [[Let's Encrypt]] service.

The protocol, based on passing JSON-formatted messages over HTTPS, has been published as an Internet Standard in RFC 8555.

![[Pasted image 20260501034941.png]]
## History
An automated certificate management protocol was being developed simultaneously by a team led by Alex Halderman and Peter Eckersley and another team at Mozilla by Josh Aas and Eric Rescorla, who soon learned of each other's existence and teamed up.

Alternative to ACME - CMP, standardized in 1999, but ACME is "tailored to the needs of the Web PKI and ... designed with scalable, automated issuance as a core goal".

ACMEv1 was opened to the public in Dec 2015. The finalized standard was published in 2019 as RFC 8555.

## Function
1) An account is created by the client querying the server's directory URI, after which the server responds with extra info endpoints along with the CA's terms of service agreement
2) An ACME account is created after the client agrees to the terms by setting the relevant reply field to true
3) Client obtains pre-authorization from the server, ensuring the forthcoming certificate will meet the server's requiremenets, by sending a subset of the certificate's fields
4) Server replies with an 'order object' URL, which contains a list of authorization methods supported by the server which ensure the client is in possession of the subject of the potential certificate
5) The client downloads an authorization token from the URL indicated in the response and makes this token available, e.g. by creating a [[DNS]] record containing it or opening an HTTP endpoint responding with it. After the authorization token has been made available at the address of the desired certificate's subject, the client notifies the server that it is prepared for validation which is carried out by the server in accessing the authorization token.
6) Once the authorization is complete the client sends a certificate signing request which contains the certificate to be signed, resulting in an updated order object containing the decision of the CA
7) If the request was valid, the CA has signed the client's certificate and the client may download it at the returned URL

Functionality also exists for certificate revocation, account deletion, etc.

The validation processes are run multiple times over separate network paths. Checking whether DNS entries are provisioned is done from multiple geographically diverse locations to make DNS spoofing attacks harder to carry out.

## API versions
API v1 specification was published in 2016.
Supports: issuing certificiates for fully-qualifies domain names or subdomains (example.com or cluster.example.com), but not wildcards like *.example.com.

APIv1 was turned off on 1 June 2021.

API v2 was released in 2018, is not backwards compatible with v1.
API v2 supports wildcard domains. Major new requirement in v2 is that requests for wildcard certs require the modification of a DNS TXT record, verifying control over the odmain.