ACME clients: how to choose one by class, not by name

Choosing by those properties is durable. Choosing by a list of names is not, because the list changes and the properties do not.

The four classes

• Built into the server

  The software that terminates connections obtains certificates itself. Nothing separate runs, nothing needs to deploy anything, and the certificate is in use the moment it exists because the thing that got it is the thing that serves it.

• A separate program run on a schedule

  The traditional arrangement: a tool runs periodically, renews what needs renewing, writes files, and reloads the server. Flexible, works with anything, and has the most moving parts.

• A library inside your own application

  The application obtains and manages its own certificates. Suited to software distributed to others, or to services that create hostnames dynamically.

• A platform that does it for you

  Certificates are a property of the hosting or delivery layer rather than something you operate. Nothing runs on your side at all.

Those four cover essentially everything, and the differences between individual tools within a class are much smaller than the differences between classes.

The questions that decide

Five, in the order that eliminates fastest.

• What terminates your connections?

  If it is software that can obtain certificates itself, that is usually the answer, because the deployment problem disappears entirely. If termination happens on a platform, the question is already settled.

• Can the client deploy the result?

  Obtaining a certificate is the easy half. Something must place the files and reload the service, and a client that cannot do that leaves you writing the missing step yourself, which is where most homemade automation breaks.

• Which challenge do you need?

  Wildcards require DNS validation, so the client must be able to change your DNS, which not all can do for every provider. See DNS-01.

• What happens when it fails?

  Whether failures are visible, whether they are retried, and whether anything reports them. A client that fails silently is functionally the same as no client at all until the certificate expires.

• Who maintains it?

  Anything running unattended for years needs to still be receiving updates. This matters more than feature comparisons, and it is the question most easily checked and most often skipped.

What the class decides for you

Each class has a characteristic failure and a characteristic strength, and knowing them predicts your experience better than any feature table.

A client built into the server cannot fail to deploy, because there is nothing to deploy. The cost is coupling: certificate behaviour is whatever that software implements, and changing servers means revisiting it.

A separate program works with anything, and pays for it in joints. The schedule, the challenge, the file placement and the reload are four things that can stop working independently, and only the last two are visible from outside.

A library keeps certificates with the application wherever it runs. In exchange, certificate management becomes your code's responsibility, including its failures.

On a platform none of that applies, which is both the point and the limit. The behaviour is the platform's to define, and where it does something you need differently there is often no lever.

What not to choose on

Three criteria that look relevant and are not.

• Feature counts

  The protocol is the same. Extra features usually concern integration with specific providers, which matters only if you use that provider.

• Popularity

  A widely used client is well tested and is not therefore suited to your termination arrangement, which is the question that decides.

• Speed of issuance

  Issuance takes seconds in every case, and renewal happens well before expiry, so a difference measured in seconds affects nothing.

Where the client should run

A question people answer by default rather than deliberately, and the default is often wrong.

• On the server that terminates connections

  is the obvious choice and the right one when that server is long-lived and managed directly. The certificate is obtained where it will be used, and nothing has to travel.

• On the machine that builds or deploys

  suits infrastructure rebuilt from images, where anything written onto a running server is lost at the next deployment. Here the certificate belongs in the deployment pipeline, not on the instance.

• Somewhere central

  suits fleets: one place obtains certificates and distributes them, which avoids every instance holding credentials and avoids rate limits from many machines requesting the same names.

The question that decides is what happens to the server. If it is replaced regularly, a client running on it will be replaced too, and whatever it obtained goes with it. That mismatch is a recurring cause of automation that worked once and then quietly stopped.

The one thing to verify before committing

Whether it can deploy to your setup, end to end, unattended.

Obtain a certificate with it and let it complete the whole sequence, including placing files and reloading, then confirm from outside that the new certificate is being served. That single test distinguishes a client that will work for years from one that will need a person every renewal, and it takes one run rather than a comparison.

If the sequence needs a script you write to bridge a gap, that script is now part of your certificate infrastructure and deserves the same monitoring as everything else, which is covered on renewal automation.

FAQ