Le processus repose sur des requêtes HTTPS signées en JWS avec une clé de compte : créer un compte, soumettre une commande qui liste les identifiants, relever un challenge par autorisation (http-01, dns-01 ou tls-alpn-01), envoyer une CSR à l’URL de finalisation (finalize) de la commande et télécharger la chaîne de certificats. Chaque requête porte une nouvelle valeur Replay-Nonce et est liée à son URL dans l’en-tête protégé.
Les réponses aux challenges sont dérivées d’une autorisation de clé (key authorization), token ‖ "." ‖ base64url(JWK thumbprint of the account key) (RFC 8555 §8.1), si bien qu’un autre compte ne peut pas les réutiliser. Extensions : tls-alpn-01 (RFC 8737), identifiants IP (RFC 8738), informations de renouvellement ACME (RFC 9773) et profils de certificat comme classic, tlsserver et shortlived chez Let’s Encrypt.
Parmi les clients figurent Certbot, lego, acme.sh, Caddy et cert-manager ; Let’s Encrypt, ZeroSSL, Google Trust Services, Sectigo, DigiCert et SSL.com font partie des AC qui proposent ACME, et des AC privées comme step-ca et Vault le prennent aussi en charge. Avec des durées de vie qui descendent vers 47 jours, ACME devient de fait obligatoire pour le TLS public.