Certificate Delegation with ACME and STAR Certificates

In early March 2020, just as the world was bracing for the COVID-19 pandemic, my co-authors and I published RFC 8739. This new standard introduced the concept of short-term, automatically renewed (STAR) certificates into the X.509 certificate universe, and specifically to the large and vibrant ACME ecosystem. A year and a half later, we followed that with the publication of RFC 9115 which builds on the ACME and STAR foundations to enable automated, easy to manage certificate delegation.

ACME is an open protocol for automated management of public-key certificates. It underlies the free and hugely successful Let’s Encrypt certificate authority (CA) and is now being adopted by commercial CAs as well. ACME enables to automatically order, renew and revoke certificates using a simple REST API, and there are many open source tools based on this API that make it easily usable by administrators of web servers. By making certificates free and easy to obtain, Let’s Encrypt played a central role in the transition of the web to encrypted-by-default.

As noted, RFC 8739 defines short-term, automatically renewable certificates in the framework of ACME. If you’re not familiar with this concept, you might want to go back to the blog post we published at the time. But in short, these are totally standard X.509 public key certificates that are issued for a short duration (think 24 hours). The CA is instructed to issue a series of certificates, and it keeps on issuing them periodically, with the web server pulling them automatically at the same frequency. Remember that a certificate without its private key is completely public, and so the server can easily retrieve it from the CA, with no special security required, and start using the certificate to protect HTTPS traffic. ACME STAR is still young, but it has already been implemented by servers and clients.

The concept of short-term certificates allows for simpler deployment of Public Key Infrastructure (PKI) without the need and ongoing operational costs of certificate revocation. So in essence, STAR can be considered an optimization of the standard PKI framework. In contrast, RFC 9115 takes ACME to entirely new use cases by supporting delegation of public key certificates.

Imagine a large financial institution with global customer reach. The organization needs to deploy its web presence across many countries, ensuring good performance to all customers, regardless of where they may be located. Sounds difficult, but this is actually a solved problem, with the solution provided by Content Delivery Networks, or CDNs. Obviously, this company’s web traffic is protected by TLS, with a certificate for verybigbank.com. Now consider the security implications: if the CDN is to terminate TLS connections on behalf of the company (its customer), it needs to present the certificate to TLS clients and more critically, it needs to keep a copy of the associated private key! The large company needs to trust the CDN with its private key, which may be used for other security functions beyond protection of web traffic. If at some point the company terminates its relationship with the CDN, it might try to revoke the certificate it handed over to the CDN (assuming a separate private key for the company’s in-house servers vs. the CDN), but for many reasons, certificate revocation is extremely unreliable in today’s Internet.

These issues are exacerbated by the practice of traffic outsourcing, where a top-level CDN hands the responsibility to one or more subordinate CDNs, in order to get better and more cost effective global coverage. As far as the company (again, the CDN’s customer) is concerned, the result is a hierarchy of CDNs, some of which may not even be known to the customer!

Another important scenario for certificate delegation is related to the lifecycle of virtual functions of whatever nature: virtual machines, containers, unikernels… This is especially applicable to edge environments, where instances of a concrete function may be scaled or migrated at a high rate, depending on traffic load or user mobility. Trust relationships would require certificates that are associated to a particular identifier, but cloning private keys as the virtual function footprint grows or moves does not seem the safest practice. The STAR delegation mechanism can support this highly dynamic lifecycle management without stretching too much the service trust fabric.

The problem of revocation is solved quite elegantly by using STAR certificates. The new RFC combines STAR with a profile of the ACME protocol that runs between the Delegate (the CDN or the function instances in the above examples) and the Identity Owner (the customer in the CDN example, the function identity in the edge case). See the figure below for a highly simplified description of the sequence of operations between the Delegate, the Identity Owner and the ACME CA.

So with the combination of the STAR and the ACME Delegation RFCs, we now have a handy solution to the problem of certificate delegation with a bunch of useful properties:

• All certificate issuance is controlled by the customer. The customer is aware of all certificates being issued, can revoke any of them, and can control the exact details (key usage, extension fields) of each certificate. More precisely, the customer can revoke a sequence of certificates, meaning it can stop the CA from issuing new ones.
• Private keys are segregated between the customer and each of the CDNs. Each certificate can be revoked without affecting the others.
• The protocol can be deployed “recursively”, through a chain of proxies. This accounts for CDN hierarchies, with each CDN only directly accessing the CDNs with which it has a direct commercial relationship, or to a chain of edge platform providers.
• Both RFCs are relatively small extensions to the well tested and widely implemented ACME protocol.
• Critically, the certificates are all standard X.509, and are understood by any TLS client out there. All the magic happens in the “back end”: between the certificate owner, the certificate issuer, and the delegate that owns the web server. While this requirement for backward compatibility may sound trivial, it is not true of other protocols in the space of certificate delegation.

Finally, I would like to thank co-authors for all the hard work that went into this standard: Diego López, Antonio Agustín Pastor Perales and Thomas Fossati, as well as the ACME working group members and its chairs. It has taken a long time, five years since the initial LURK discussion, and we are proud of the results and looking forward to see them used across the industry.