Automatic Certificate Management Environment

Last updated
ACME logo ACME-protocol-icon.png
ACME logo

The Automatic Certificate Management Environment (ACME) protocol is a communications protocol for automating interactions between certificate authorities and their users' servers, allowing the automated deployment of public key infrastructure at very low cost. [1] [2] It was designed by the Internet Security Research Group (ISRG) for their Let's Encrypt service. [1]

Contents

The protocol, based on passing JSON-formatted messages over HTTPS, [2] [3] has been published as an Internet Standard in RFC   8555 [4] by its own chartered IETF working group. [5]

Client implementations

The ISRG provides free and open-source reference implementations for ACME: certbot is a Python-based implementation of server certificate management software using the ACME protocol, [6] [7] [8] and boulder is a certificate authority implementation, written in Go. [9]

Since 2015 a large variety of client options have appeared for all operating systems. [10]

API versions

API version 1

API v1 specification was published on April 12, 2016. It supports issuing certificates for fully-qualified domain names, such as example.com or cluster.example.com, but not wildcards like *.example.com. Let's Encrypt turned off API v1 support on 1 June 2021. [11]

API version 2

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 trusted TLS, 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. [12] A major new requirement in v2 is that requests for wildcard certificates require the modification of a Domain Name Service TXT record, verifying control over the domain.

Changes to ACME v2 protocol since v1 include: [13]

See also

Related Research Articles

<span class="mw-page-title-main">HTTPS</span> Extension of the HTTP communications protocol to support TLS encryption

Hypertext Transfer Protocol Secure (HTTPS) is an extension of the Hypertext Transfer Protocol (HTTP). It uses encryption for secure communication over a computer network, and is widely used on the Internet. In HTTPS, the communication protocol is encrypted using Transport Layer Security (TLS) or, formerly, Secure Sockets Layer (SSL). The protocol is therefore also referred to as HTTP over TLS, or HTTP over SSL.

Transport Layer Security (TLS) is a cryptographic protocol designed to provide communications security over a computer network. The protocol is widely used in applications such as email, instant messaging, and voice over IP, but its use in securing HTTPS remains the most publicly visible.

In computing, Internet Key Exchange is the protocol used to set up a security association (SA) in the IPsec protocol suite. IKE builds upon the Oakley protocol and ISAKMP. IKE uses X.509 certificates for authentication ‒ either pre-shared or distributed using DNS ‒ and a Diffie–Hellman key exchange to set up a shared session secret from which cryptographic keys are derived. In addition, a security policy for every peer which will connect must be manually maintained.

In cryptography, a certificate authority or certification authority (CA) is an entity that stores, signs, and issues digital certificates. A digital certificate certifies the ownership of a public key by the named subject of the certificate. This allows others to rely upon signatures or on assertions made about the private key that corresponds to the certified public key. A CA acts as a trusted third party—trusted both by the subject (owner) of the certificate and by the party relying upon the certificate. The format of these certificates is specified by the X.509 or EMV standard.

Extensible Authentication Protocol (EAP) is an authentication framework frequently used in network and internet connections. It is defined in RFC 3748, which made RFC 2284 obsolete, and is updated by RFC 5247. EAP is an authentication framework for providing the transport and usage of material and parameters generated by EAP methods. There are many methods defined by RFCs, and a number of vendor-specific methods and new proposals exist. EAP is not a wire protocol; instead it only defines the information from the interface and the formats. Each protocol that uses EAP defines a way to encapsulate by the user EAP messages within that protocol's messages.

<span class="mw-page-title-main">Secure Hypertext Transfer Protocol</span> Web encryption method similar to HTTPS

Secure Hypertext Transfer Protocol (S-HTTP) is an obsolete alternative to the HTTPS protocol for encrypting web communications carried over the Internet. It was developed by Eric Rescorla and Allan M. Schiffman at EIT in 1994 and published in 1999 as RFC 2660.

<span class="mw-page-title-main">Network Security Services</span> Collection of cryptographic computer libraries

Network Security Services (NSS) is a collection of cryptographic computer libraries designed to support cross-platform development of security-enabled client and server applications with optional support for hardware TLS/SSL acceleration on the server side and hardware smart cards on the client side. NSS provides a complete open-source implementation of cryptographic libraries supporting Transport Layer Security (TLS) / Secure Sockets Layer (SSL) and S/MIME. NSS releases prior to version 3.14 are tri-licensed under the Mozilla Public License 1.1, the GNU General Public License, and the GNU Lesser General Public License. Since release 3.14, NSS releases are licensed under GPL-compatible Mozilla Public License 2.0.

Simple Certificate Enrollment Protocol (SCEP) is described by the informational RFC 8894. Older versions of this protocol became a de facto industrial standard for pragmatic provisioning of digital certificates mostly for network equipment.

The Certificate Management Protocol (CMP) is an Internet protocol standardized by the IETF used for obtaining X.509 digital certificates in a public key infrastructure (PKI).

Security Support Provider Interface (SSPI) is a component of Windows API that performs security-related operations such as authentication.

Server Name Indication (SNI) is an extension to the Transport Layer Security (TLS) computer networking protocol by which a client indicates which hostname it is attempting to connect to at the start of the handshaking process. The extension allows a server to present one of multiple possible certificates on the same IP address and TCP port number and hence allows multiple secure (HTTPS) websites to be served by the same IP address without requiring all those sites to use the same certificate. It is the conceptual equivalent to HTTP/1.1 name-based virtual hosting, but for HTTPS. This also allows a proxy to forward client traffic to the right server during TLS/SSL handshake. The desired hostname is not encrypted in the original SNI extension, so an eavesdropper can see which site is being requested. The SNI extension was specified in 2003 in RFC 3546

A cipher suite is a set of algorithms that help secure a network connection. Suites typically use Transport Layer Security (TLS) or its deprecated predecessor Secure Socket Layer (SSL). The set of algorithms that cipher suites usually contain include: a key exchange algorithm, a bulk encryption algorithm, and a message authentication code (MAC) algorithm.

The Transport Layer Security (TLS) protocol provides the ability to secure communications across or inside networks. This comparison of TLS implementations compares several of the most notable libraries. There are several TLS implementations which are free software and open source.

DNS-based Authentication of Named Entities (DANE) is an Internet security protocol to allow X.509 digital certificates, commonly used for Transport Layer Security (TLS), to be bound to domain names using Domain Name System Security Extensions (DNSSEC).

In cryptography, the Salted Challenge Response Authentication Mechanism (SCRAM) is a family of modern, password-based challenge–response authentication mechanisms providing authentication of a user to a server. As it is specified for Simple Authentication and Security Layer (SASL), it can be used for password-based logins to services like LDAP, HTTP, SMTP, POP3, IMAP and JMAP (e-mail), XMPP (chat), or MongoDB and PostgreSQL (databases). For XMPP, supporting it is mandatory.

Let's Encrypt is a non-profit certificate authority run by Internet Security Research Group (ISRG) that provides X.509 certificates for Transport Layer Security (TLS) encryption at no charge. It is the world's largest certificate authority, used by more than 300 million websites, with the goal of all websites being secure and using HTTPS. The Internet Security Research Group (ISRG), the provider of the service, is a public benefit organization. Major sponsors include the Electronic Frontier Foundation (EFF), the Mozilla Foundation, OVH, Cisco Systems, Facebook, Google Chrome, Internet Society, AWS, NGINX, and Bill and Melinda Gates Foundation. Other partners include the certificate authority IdenTrust, the University of Michigan (U-M), and the Linux Foundation.

DNS Certification Authority Authorization (CAA) is an Internet security policy mechanism that allows domain name holders to indicate to certificate authorities whether they are authorized to issue digital certificates for a particular domain name. It does this by means of a "CAA" Domain Name System (DNS) resource record.

<span class="mw-page-title-main">Well-known URI</span>

A well-known URI is a Uniform Resource Identifier for URL path prefixes that start with /.well-known/. They are implemented in webservers so that requests to the servers for well-known services or information are available at URLs consistent well-known locations across servers.

The Enrollment over Secure Transport, or EST is a cryptographic protocol that describes an X.509 certificate management protocol targeting public key infrastructure (PKI) clients that need to acquire client certificates and associated certificate authority (CA) certificates. EST is described in RFC 7030. EST has been put forward as a replacement for SCEP, being easier to implement on devices already having an HTTPS stack. EST uses HTTPS as transport and leverages TLS for many of its security attributes. EST has described standardized URLs and uses the well-known Uniform Resource Identifiers (URIs) definition codified in RFC 5785.

DNS over TLS (DoT) is a network security protocol for encrypting and wrapping Domain Name System (DNS) queries and answers via the Transport Layer Security (TLS) protocol. The goal of the method is to increase user privacy and security by preventing eavesdropping and manipulation of DNS data via man-in-the-middle attacks. The well-known port number for DoT is 853.

References

  1. 1 2 Steven J. Vaughan-Nichols (9 April 2015). "Securing the web once and for all: The Let's Encrypt Project". ZDNet.
  2. 1 2 "ietf-wg-acme/acme-spec". GitHub . Retrieved 2017-04-05.
  3. ↑ Chris Brook (18 November 2014). "EFF, Others Plan to Make Encrypting the Web Easier in 2015". ThreatPost.
  4. ↑ Barnes, R.; Hoffman-Andrews, J.; McCarney, D.; Kasten, J. (2019-03-12). Automatic Certificate Management Environment (ACME). IETF. doi: 10.17487/RFC8555 . RFC 8555 . Retrieved 2019-03-13.
  5. ↑ "Automated Certificate Management Environment (acme)". IETF Datatracker. Retrieved 2019-03-12.
  6. ↑ "Certbot". EFF . Retrieved 2016-08-14.
  7. ↑ "certbot/certbot". GitHub . Retrieved 2016-06-02.
  8. ↑ "Announcing Certbot: EFF's Client for Let's Encrypt". LWN. 2016-05-13. Retrieved 2016-06-02.
  9. ↑ "letsencrypt/boulder". GitHub . Retrieved 2015-06-22.
  10. ↑ "ACME Client Implementations - Let's Encrypt - Free SSL/TLS Certificates". letsencrypt.org.
  11. ↑ "End of Life Plan for ACMEv1 - API Announcements". Let's Encrypt Community Support. 2021-05-05. Retrieved 2021-06-12.
  12. ↑ "ACME v2 API Endpoint Coming January 2018 - Let's Encrypt - Free SSL/TLS Certificates". letsencrypt.org.
  13. ↑ "Staging endpoint for ACME v2". Let's Encrypt Community Support. January 5, 2018.
  14. ↑ "Challenge Types - Let's Encrypt Documentation". Let's Encrypt . 2020-12-08. Retrieved 2021-05-12.
  15. ↑ Barnes, R.; Hoffman-Andrews, J.; McCarney, D.; Kasten, J. (2019-03-12). Automatic Certificate Management Environment (ACME). IETF. doi: 10.17487/RFC8555 . RFC 8555 . Retrieved 2021-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.
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.