What does embedded ACME server do?

Can anyone explain to me what the “Embedded ACME server” in the 2.1 beta does, that was harder or not possible in previous versions? My brain is fried by current events, please use small words.

Is there some beta documentation of acme_server that I can look at? I currently have a local testing environment using local_certs, does this help me with that?

1 Like

Good question!

Caddy 2 is already a CA: it has a pki app that manages a CA root certificate and intermediate/signing certificate so that it can serve internal sites like localhost or 192.168.1.3 over HTTPS without any need for an external CA – automatically. It even keeps the signing certs renewed, as you might expect. But until today this feature could only be accessed within the same Caddy instance, i.e. each Caddy instance could only sign certificates for its own sites.

ACME is the protocol by which certificates are issued/managed. It’s how Caddy gets certificates from Let’s Encrypt and renews them automatically. Caddy can also sign its own certificates that are trusted on the local machine, but it doesn’t use the ACME protocol (it happens all in-process and no validation is performed). ACME lets you get certificates from a remote authority across a network.

Until today, Caddy was only an ACME client, meaning it could only request certificates from a remote ACME CA such as Let’s Encrypt or Smallstep.

But now Caddy is an ACME server, so it can issue certificates to other ACME clients. (We embed Smallstep’s ACME server.)

This means you can set up other Caddy instances (or any other ACME client) across your network/infrastructure and configure them to use a single Caddy instance as the CA. This means you only have 1 root certificate you need to trust internally.

You can use Caddy as an ACME server by adding the acme_server handler to your routes:

{
    "handler": "acme_server"
}

Or with the acme_server Caddyfile directive.

This lets any ACME client get certificates from Caddy’s internal CA by using the directory endpoint of https://localhost/acme/local/directory for example. (local is the name of Caddy’s default CA.)

Combined with the reverse proxy’s client certificate automation feature, Caddy 2.1 offers fully-automatic mTLS. This means Caddy-as-a-client can get its own client certificate and keep it renewed, and Caddy-as-a-server can both obtain or issue its own certificates and keep them renewed.

More details:

https://github.com/caddyserver/caddy/pull/3198

One could really write a book about this, but I guess for now it’ll take some dedicated users to dig into the docs and write a wiki post explaining it better. :slight_smile:

3 Likes

Thanks for the explanation! I think I understood all of that despite my news-addled brain :slight_smile:

I just want to note that I searched for acme_server in the documentation search field and didn’t find either of the two documents you linked here (handler or Caddyfile directive). Is that intentional? If not, then the search function isn’t very good.

It’s a free, hosted search by Algolia. I think it takes a day or two for the index to update.

This should probably be its own topic, but I just wanted to mention some cool options for self-hosted search on a static site:

I realize that tinkering with search on your website may not be your highest priority, but something fast and open source sounds appealing to me :slight_smile:

FYI we use this.

And you’re right, it’s a very low priority, we have something that’s “good enough”.

This topic was automatically closed after 30 days. New replies are no longer allowed.