Open Source

When to Use ACME in Internal Networks

At Smallstep we love the ACME protocol. If we could, we would advise to always use it to issue certificates. Unfortunately, not every certificate management use case can be implemented using the ACME protocol. The following sections describe the prerequisite requirements and some scenarios in which the ACME protocol can be used to issue certificates. We also describe some use cases for which ACME is less or not suitable, accompanying pointers to solutions for those use cases.

At a High Level

As described in "why you should use ACME", the ACME protocol requires ACME clients to request certificates via HTTPS. They must also be able to respond to challenges from an ACME server. Requesting a certificate and responding to challenges involves multiple requests and responses, each of which can fail. A certificate cannot be issued if one of the requests or responses fails to be sent or received in time.

For a certificate to be issued for an identifier, the ACME server contacts the system the identifier points to, either via DNS, HTTP, or HTTPS, to verify that the ACME client controls the requested identifier. If a client cannot respond to at least one of the challenges for the identifier, the ACME server won't issue a certificate. In case multiple identifiers are requested in a single certificate, at least one challenge for every identifier must be successful, for the certificate to be issued.

The ACME specification currently only officially supports domain names and IP addresses in certificate requests and challenges. Certificate requests for domain names and IP addresses are currently supported in the Smallstep platform.

Scenarios

The below listing is an overview of exemplary scenarios in which the ACME protocol can be used to issue certificates:

An environment requiring certificates for infrastructure, without certificates being included in Certificate Transparency logs. The ACME protocol is primarily well-suited for use cases that are similar as to how the Web PKI is used. This means it can be used for issuing certificates to internal workloads, including databases, proxies and queues. With the Smallstep platform, certificates issued using ACME are not recorded in a Certificate Transparency log, keeping your internal infrastructure confidential. It is also possible to deploy ACME with an on-premise deployment of the Smallstep platform, to be in full control over the system or to be used in airgapped networks, for example.

An environment requiring certificates for Mutual TLS, such as a service mesh. This use case is similar as the one above, but this time also includes client side authentication using a certificate. Considering the clients in those environments are often primarily concerned with infrastructural concerns, they can be issued a client certificate using ACME if they can solve challenges.

An internal development, staging or CI/CD environment with high certificate issuance rates and requiring high degree of equivalence to production environment. While the Let's Encrypt staging environment has quite generous rate limits, it's not a very suitable solution for integration with development, staging or CI/CD

Kubernetes, with cert-manager and the ACME issuer enabled. For this to work, challenges for the identifiers need to be solvable by cert-manager. An example detailing this use case is available here: Integrate Kubernetes cert-manager with an internal ACME CA.

When not to use ACME

There are certain situations in which ACME is less suitable to use or can't be used at all to manage certificates. These are summarized below:

The ACME protocol cannot be used in case an ACME client cannot proof control over the identifiers it wants to request. The ability to proof control over identifiers can be limited for various reasons, including technical and compliance reasons. For example, an ACME client may not have administrative control over DNS records for the example.com domain, so that it can't request a wildcard cert for *.example.com. Another example may be that an ACME server can't reach out to an ACME client, because it exists on a different network segment that is not routable.

Some cases that involve a technical issue or compliance requirement may still be supported when deploying an instance of the CA in Registration Authority (RA) mode. Our RA documentation page describes this configuration in more detail. Or contact us to see if we can support your use case.

A draft RFC for an ACME extension is in the making, describing how the ACME protocol can be used with challenges "solved" by a secure hardware component, like a Trusted Platform Module (TPM) or Secure Enclave (SE). This protocol extension, optionally combined with ACME External Account Binding, could obviate the need for a separate channel for solving challenges. At Smallstep we're closely monitoring progress of the RFC and may support this functionality in the future.

When a certificate requires email addresses to be signed, email signing certificates, for example. There is an informational extension to the ACME RFC that adds support for S/MIME certificates. The Smallstep platform doesn't currently support the extension, but we might do so in the future. Let us know if your use case involves certificates for humans to see if we can help, either by implementing support for the extension or using different means.

Use cases that involve URIs in certificates are not supported, because the ACME protocol currently doesn't support URI identifiers.

Use cases that involve customization of the certificate contents, like a custom Subject, additional key usages and additional (custom) extensions. The ACME protocol is fairly limited in terms of certificate contents. This works quite well for Web PKI certificates, but not so for internal PKI, which often requires customization of the certificate contents to support multiple, widely divergent, use cases. The Smallstep platform offers these capabilities using other provisioners and certificate flexibility.

The ACME protocol cannot be used to issue SSH certificates. It's designed to support X.509 certificates only. An alternative is Smallstep Single Sign-On SSH, which offers many similar benefits as the ACME protocol provides, but applied to short-lived SSH certificates.