How to Use ACME in Internal Networks

With Smallstep Certificate Manager you can deploy ACME on your internal network with ease. Before deploying, it's important to consider what deployment options works best for your organization, which include our hosted as well as our on-premise solutions. For each of those, it may be necessary to also deploy a Registration Authority (RA), which ensures ACME clients can be challenged on the internal network without opening additional ports and securely relays certificate requests to the CA. The deployment options, and whether or not an RA is required, are explained in Deployment Options.

The Smallstep platform supports some additional functionalities for ACME, including certificate issuance policies and External Account Binding (EAB). These two functionalities provide more control over which ACME clients can request a certificate. They are described in Additional Control.

With Smallstep Certificate Manager, you can deploy ACME on your internal network with ease. It is possible to use our hosted solution, or you can deploy the Smallstep platform to your own infrastructure using our on-premise solution. These options are described below.

Our hosted solution provides the quickest way to get started issuing certificates using ACME. Most of the infrastructure maintenance burden will be our responsibility. We say most, because we advise our customers to deploy and maintain a so-called Registration Authority (RA) on their own infrastructure. An RA is responsible for authenticating certificate requests and securely relaying these requests to the CA, hosted in Certificate Manager.

Deploying the RA on the internal network allows ACME clients to solve challenges on the internal network, instead of having to be accessible from outside by the Smallstep hosted infrastructure. This will cooperate nicely with DNS servers on the internal network, since these will resolve internal hostnames within the company network. The RA will be able to resolve the internal hostnames to internal IPs and can then challenge ACME clients.

It is possible to deploy ACME using our hosted solution without deploying an RA, but there's a caveat to that: anyone who knows the public endpoint for the ACME directory, will be able to request a certificate from it by default. This is generally problematic, because unknown third party clients could influence operation of your CA by requesting a high volume of certificates. It is possible to (largely) prevent abuse by configuring a certificate issuance policy, providing control over what domains are allowed to request a certificate, or by requiring External Account Binding (EAB) to be used, so that only known ACME clients can request a certificate.

It is also possible to deploy the Smallstep platform to your own infrastructure. If your infrastructure is not publicly available and the CA can reach all ACME clients on the internal network, then it's not necessary to deploy an RA. In case your infrastructure doesn't allow all ACME clients to be challenged successfully by the CA, adding an RA to the deployment is an option.

When deploying ACME, it's possible to configure your CA with some additional controls for certificate issuance. These are Certificate Issuance Policies and External Account Binding. They're explained in the following subsections.

Certificate issuance policies can be used to configure which certificate names the CA is allowed to sign. A policy consists of one or more rules that are evaluated when a new certificate is going to be signed. An example of a policy is to only allow certificates for subdomains of internal.corp.com, ensuring your CA won't ever sign a certificate for e.g. public.corp.com. More information about how certificate issuance policies work and how they can be configured, can be found here.

Certificate issuance policies can be applied to authorities as well as all provisioners, and is thus not specific to the ACME functionalities. Combining ACME and an authority or provisioner policy can result in a simpler deployment, however, if the policy only allows hostnames for specific, internal (sub)domains to be signed. Unknown third party ACME clients can still try to request a certificate, but if they're requesting certificates that are not part of the policy, they won't be authorized by the RA or CA.

ACME EAB can be used to bind an ACME account to an existing entity in another (external) system, such as an inventory of machines. Only ACME clients that were provided with a client-specific, shared secret will be able to register an account with the CA. After the ACME client registers a new account, the EAB key is marked as bound and can't be (re)used by other ACME clients. The client will authenticate itself using its private key in future interactions with the RA or CA.

The Smallstep platform also supports configuring a certificate issuance policy per ACME account when EAB is in use. By configuring a policy for an ACME account, issuance of specific hostnames or IP addresses can be limited to specific ACME clients.

Want to get started using ACME with Smallstep Certificate Manager? Follow these three simple steps and start issuing certificates: