The protocol, based on passingJSON-formatted messages overHTTPS,[2][3] has been published as an Internet Standard inRFC8555[4] by its own charteredIETF working group.[5]
API v1 specification was published on April 12, 2016. It supports issuing certificates for fully-qualified domain names, such asexample.com orcluster.example.com, but not wildcards like*.example.com. Let's Encrypt turned off API v1 support on 1 June 2021.[15]
API v2 was released March 13, 2018 after being pushed back several times. ACME v2 is not backwards compatible with v1. Version 2 supports wildcard domains, such as*.example.com, allowing for many subdomains to have trustedTLS, e.g.https://cluster01.example.com,https://cluster02.example.com,https://example.com, on private networks under a single domain using a single shared "wildcard" certificate.[16] A major new requirement in v2 is that requests for wildcard certificates require the modification of a Domain Name ServiceTXT record, verifying control over the domain.
The "resource" field of JWS request bodies is replaced by a new JWS header: "url"
Directory endpoint/resource renaming
URI → URL renaming in challenge resources
Account creation and ToS agreement are combined into one step. Previously, these were two steps.
A new challenge type was implemented, TLS-ALPN-01. Two earlier challenge types, TLS-SNI-01 and TLS-SNI-02, were removed because of security issues.[18][19]
^Barnes, R.; Hoffman-Andrews, J.; McCarney, D.; Kasten, J. (2019-03-12).Automatic Certificate Management Environment (ACME).IETF.doi:10.17487/RFC8555.RFC8555. Retrieved2021-05-12.The values "tls-sni-01" and "tls-sni-02" are reserved because they were used in pre-RFC versions of this specification to denote validation methods that were removed because they were found not to be secure in some cases.
