ACME Beyond the Web Server: Certificate Automation for Internal Services and mTLS

Shortening public TLS lifetimes towards an eventual 47 days has created an awareness that manual renewal no longer scales. What often gets overlooked: inside a company there are usually far more certificates than at the outward-facing edge. Service-to-service communication, mTLS in a service mesh, internal APIs and database connections all live on certificates, and these follow different patterns than the public web.

Why “internal” does not mean “simpler”

At the public web server the situation is tidy: a handful of domains, a public CA, a clearly defined validation path. Internally the ratio inverts. Here there are often hundreds or thousands of short-lived endpoints that appear and vanish dynamically, for instance when an orchestrator starts new containers. An internal CA issues certificates for them that nobody sees publicly, but which expire just the same, must renew just the same, and take down a service just the same when they fail.

The difference from the public world is therefore not lesser importance, but higher frequency and dynamism. With mTLS, where both sides authenticate each other with a certificate, the number of identities to manage doubles on top of that.

ACME is not just for Let’s Encrypt

ACME (RFC 8555) became known as the protocol for automatic issuance and renewal, above all through Let’s Encrypt on the public web. The protocol itself, however, is CA-agnostic. An internal CA can offer an ACME interface, and then internal services renew themselves through the same mechanism, without anyone ordering a certificate by hand.

For internal validation, different challenge types apply than on the public web. The HTTP challenge common for public domains rarely fits internal services. Instead, DNS-based methods or, depending on the environment, platform-bound identity proofs come into play. Service meshes partly solve this internally through their own identity layer and short-lived certificates with lifetimes of hours rather than weeks.

What makes the difference

Three capabilities decide whether internal automation holds.

Discovery facing inward too. The dangerous outage is rarely the well-tended front-end certificate. It is the forgotten one on an internal service, an appliance, or in a cluster nobody actively watches anymore. An inventory must capture internal endpoints as much as public ones.

A CA-agnostic view. In environments that have grown over time, several CAs usually coexist: a public one for the outer edge, one or more internal, and perhaps a cloud-native one. Management that offers a unified view and unified renewal across all of them prevents each CA from becoming its own island with its own gaps.

Renewal with control. Full automation is the goal, but not at the price of lost traceability. Where needed, automatic renewal includes a documented approval and logging step, so that even at high frequency it stays clear what was issued when.

Exactly this pattern, discovery first, then CA-agnostic automation with approval, underlies our NextPKI module. The thrust, though, holds independently of any tool: whoever masters the short lifetimes of the outer edge but overlooks the interior has not got the actual volume under control.

The 47-day discussion is a good occasion to widen the view. Most of a company’s certificates are not in the shop window, but in the engine room.