Automatic Certificate Management Environment

Last updated
ACME logo ACME-protocol-icon.svg
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, such as the Internet. 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.

<span class="mw-page-title-main">Public key infrastructure</span> System that can issue, distribute and verify digital certificates

A public key infrastructure (PKI) is a set of roles, policies, hardware, software and procedures needed to create, manage, distribute, use, store and revoke digital certificates and manage public-key encryption.

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 public key certificate, also known as a digital certificate or identity certificate, is an electronic document used to prove the validity of a public key. The certificate includes the public key and information about it, information about the identity of its owner, and the digital signature of an entity that has verified the certificate's contents. If the device examining the certificate trusts the issuer and finds the signature to be a valid signature of that issuer, then it can use the included public key to communicate securely with the certificate's subject. In email encryption, code signing, and e-signature systems, a certificate's subject is typically a person or organization. However, in Transport Layer Security (TLS) a certificate's subject is typically a computer or other device, though TLS certificates may identify organizations or individuals in addition to their core role in identifying devices. TLS, sometimes called by its older name Secure Sockets Layer (SSL), is notable for being a part of HTTPS, a protocol for securely browsing the web.

The Online Certificate Status Protocol (OCSP) is an Internet protocol used for obtaining the revocation status of an X.509 digital certificate. It is described in RFC 6960 and is on the Internet standards track. It was created as an alternative to certificate revocation lists (CRL), specifically addressing certain problems associated with using CRLs in a public key infrastructure (PKI). Messages communicated via OCSP are encoded in ASN.1 and are usually communicated over HTTP. The "request/response" nature of these messages leads to OCSP servers being termed OCSP responders.

<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 Netscape's dominance of the browser market led to HTTPS becoming the de facto method for securing web communications.

<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).

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.

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.

The Internet Security Research Group (ISRG) is a public-benefit non-profit corporation based in California which focuses on Internet security. The group is known for hosting and running the Let's Encrypt service, which aims to make Transport Layer Security (TLS) certificates available for free in an automated fashion. Josh Aas serves as the group's executive director.

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.

<span class="mw-page-title-main">Rustls</span> Open-source implementation of TLS in Rust

Rustls is an open-source implementation of the Transport Layer Security (TLS) cryptographic protocol written in the Rust programming language. TLS is essential to internet security, and Rustls aims to enable secure, fast TLS connections. Rustls uses Rust's enforcement of memory safety to reduce the risk of security vulnerabilities. It is part of efforts to improve internet security by replacing memory-unsafe software libraries, such as OpenSSL, with memory-safe alternatives.

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.