By: Richard Barnes
Date: November 1, 2015
It is increasingly important to ensure that all Internet applications receive certain minimum security assurances [RFC 7202]. For many years now, the IETF has required that the protocols it publishes have built-in security mechanisms [RFC 3552]. In order for users to benefit from these mechanisms, however, they need to be deployed by the operators of Internet applications.
Deployment of security technologies presents several serious challenges for operators. The requirement for server authentication in Internet applications is especially challenging in operations. Most server authentication in the Internet is based on the notion of a digital certificate [RFC 5280], a signed statement associating a domain name with the public key of a public/private key pair. Such a credential is a statement by a Certificate Authority (CA) that the holder of the corresponding private key can legitimately represent that identity.
Obviously, before making such a statement, the CA needs to verify that the holder of the private key is also the holder of the claimed identity, and it is this process that accounts for much of the cost and risk associated with setting up a secure Internet application.
This process is highly manual today: Informal usability tests by the authors indicate that it takes a skilled administrator 1–3 hours to complete these steps. Clearly, this is not scalable to contexts involving many domains or many certificates for the same domain.
Instead, to achieve more universal security, there is a need for this certificate management process to be automated. We need a single protocol that can be integrated into application servers that need certificates, so that these servers can auto-configure themselves for secure operation.
Some CAs do expose automated issuance APIs that support some issuance scenarios, such as CloudFlare’s UniversalSSL service. But to date, these APIs have remained specific to each CA, which prevents the development of tools that can work with multiple CAs. The IETF ACME working group is working on a common protocol for managing certificates, known as the Automated Certificate Management Environment (ACME).
ACME is a simple client-server protocol based on HTTP. The client represents the applicant for a certificate (e.g., a web server operator), and the server represents the CA. The goal of ACME is to enable the CA to verify that the applicant owns some number of domains, and then to enable the applicant to request certificates for those domains.
ACME uses an extensible set of so-called challenges to allow the CA to verify an applicant’s ownership of a domain name. When an applicant requests authorization for a domain, the CA challenges him to do something that only the domain owner should be able to do:
Provision a file to an administrator-controlled directory on a web server
Provision a certificate for an HTTPS virtual host
Provision a DNS record
Once the applicant has chosen a challenge and notified the CA, the CA verifies that the challenge has been fulfilled, for example, by making an HTTP or DNS query to fetch the record that should have provisioned. If the expected value was provisioned, the CA knows that the domain owner has authorized this applicant to act on his behalf.
It is worth noting that this challenge process only verifies that the applicant has practical control over a domain, which is not always the same as being the domain owner. For example, a DNS or web hosting provider might be able to use these techniques to get certificates for a customer’s domain.
In addition, since the CA’s validation queries are done over nonsecure channels, the CA is vulnerable to things like DNS poisoning attacks. For better or worse, this reflects the state of the art in the public key infrastructure today (regardless of ACME), so at least it’s no worse. And the standardization ACME provides could make it easier to do validation from multiple perspectives, reducing the chance that an attacker can falsely demonstrate control of a domain.
Once an applicant has proved that he holds some set of domains, issuing certificates for them is simple. The applicant creates a Certificate Signing Request [RFC 2986] that expresses the public key and set of domains that the certificate should contain, and the CA responds with the certificate.
The separation between authorization and certificate issuance means that it is easy for an applicant with multiple domains to mix-and-match names in different certificates. For example, a web hosting provider that bundles 20 domains to a server could do one authorization transaction for each domain, then allocate those domains to server certificates in whatever way makes sense for the deployment environment.
All of this work on automation is at an early stage. ACME is being deployed by Let’s Encrypt (https://letsencrypt.org/), a newcomer to the CA market, but it will likely need some adaptation through the IETF process before it can be taken up by other CAs. There’s still a lot of opportunity for CAs and server operators to shape the ACME protocol to meet their needs by contributing in the working group.