ACME(Automated Certificate Management Environment) is a protocol that enables management of certificates. The specifications of the standard are available on RFC8555. For simply using it, you don’t need to understand the entire protocol. And if you were like me a few years ago, setting up some self hosted applications, you could have simply followed the tutorials for the applications themselves that usually come with a section for using Certbot with a webserver to manage the certificates. This post is an attempt to provide you a simple model for how all of this works, and how an understanding of an ACME client can really elevate the way you use it for certificate management and any of its gotchas.

ACME’s basic premise is this. The server issuing the certificate MUST know that you are the owner of the domain. After all, no one wants an impostor gaining a certificate to host a website that isn’t yours. There are a few ways this is made possible on ACME clients.

• Add one (or more) DNS entries to your DNS system that the ACME system has provided you as a “challenge” and then, the system can validate that the DNS lookup can indeed return the values it expected. The challenge is usually a TEXT record.
• Provide some “challenge” files that the ACME system has provided that you can place on a server that is yet to have SSL enabled. The ACME system will then attempt to access the challenge on the server through plain HTTP calls and confirm that you had access to put the files into that server.
• An EAB (Externally Bound Account) where you are provided with a key-secret pair, called Key ID and HMAC Key (the super secure secret) with which the ACME system knows beforehand that you are authorized to request certificates on behalf of a domain and therefore, needs no contact with the servers or DNS systems unlike in the previous two cases.

When the ACME system has validated that you are authorized to request certificates on behalf of a domain, it will then go to work and issue you a certificate. However, that isn’t the end of the story.

ACME’s system has another unique component in it called an account. This account is a combination of the local client and the server. If you change your computer and still use the same EAB key-secret pair, you get a new account on the server. If you delete a local storage of your ACME client, or decide to change the directory where the local storage is, you get a new account. The EAB key-secret pair is only used to create the local account itself. After that, the ACME client doesn’t require it for issuing certificates. It only validates if the domain is in the list that has been authorized for you. This account is how you would be able to revoke certificates if you’ve lost a private key(but seriously, always backup your keys to a safe, secure place like Vault or a password manager). There may be a case where the same domain certificate may be issued to multiple ACME clients, and as you guessed, different ACME accounts. This can be a case when you have multi-site systems and each site may have its own SSL termination layer, so this account concept is well thought out and very useful.

We talked about issuing certificates and accounts. What about renewals? Isn’t that what the M for management in the acronym stands for? The local storage not only comprises the ACME accounts, but also the private key, certificates and certificate chains. For ACME clients that interact directly with the web server to manage SSL, this usually means that the server reads the key and certificates from the ACME managed directories. The clients usually also come with a feature to set up scheduled jobs to run the commands to renew the certificate. When the certificate is due for renewal, the same private key is used to issue a new certificate and the certificate is loaded into the web server. If the account and local storage didn’t exist, we would be issuing a new certificate every time, and that isn’t productive.

We walked through ACME very quickly, but I hope this gives you an understanding of how the system works to manage your certificates and make websites secure. The protocol itself is quite elegant and powerful, and can handle use cases that involves renewing certificates without the client being installed on the server where the SSL termination happens, but that’s an advanced topic for another day!