Caddy and local HTTPS

[basil (Basil Hendroff)]

A general query…

For local HTTPS, Caddy uses SmallStep libraries to power its local CA server. I’m guessing that this is limited to a subset of SmallStep step-ca server capabilities. I’m curious to know how it might be limited? For instance, is the local HTTPS capability limited to Caddy CA and upstream Caddy endpoints?

[francislavoie]

I’ve never gone ahead and directly used smallstep, so I don’t have a good grasp of the full feature-set, but yes, Caddy only provides a subset of its features. Caddy does these things:

• Set up a local CA via the PKI app (which is automatically provisioned via the Caddyfile’s tls { internal } or local_certs global option), via JSON there’s some more control over how this is set up, i.e. changing the CA name fields, or providing your own root CA cert/key if you already have one set up that you’re migrating over; see JSON Config Structure - Caddy Documentation. You can also have more than one CA, each have a unique ID (default is local).

• Expose ACME server endpoints to allow ACME clients to use the CA to issue certs (for mTLS). See acme_server (Caddyfile directive) — Caddy Documentation. Can also specify the CA ID if you’re not using local.

• Automatically issue client certificates to use to connect to a proxy upstream, via the tls_client_auth HTTP transport option reverse_proxy (Caddyfile directive) — Caddy Documentation. Can be useful if you want your upstream to only accept requests from Caddy instances that have certs from the CA.

• Can use caddy trust and/or caddy untrust to make sure the system trusts the root CA cert (improvements to this are coming soon, I did some work on making this better last night: pki: Implement `GET /pki/certificates/<id>` API, rework `caddy trust` by francislavoie · Pull Request #4443 · caddyserver/caddy · GitHub)

That’s about it.

[basil (Basil Hendroff)]

@francislavoie Thanks for the clarification. It’s useful to know what Caddy’s scope is in this area and how this is developing.

I’ve been exploring the SmallStep products from the point of view of certificate lifecycle management for private PKI. It’s early days yet, but there are a couple of things I’ve come across where I’ve thought “Hmm… this would be nice to see in Caddy”.

Relax trust store dependency
Caddy CA depends on the root cert being inserted in the local trust store. It’s possible to explicitly specify the location of the root CA in programs such as curl e.g. curl --cacert= and applications such as SmallStep iff the root cert is not in located the trust store.

Bootstrapping

Smallstep has a bootstrap command to download the root cert from the CA to set up the current environment. This would be neat to have for upstream Caddy endpoints. It would avoid having to manually copy across the root cert, which is a little clunky. With lots of Caddy endpoints set up for local HTTPS, a caddy bootstrap command would streamline getting the root cert from the CA. While I can see this being useful for normal operations, it would really shine if the root key has to be rolled in a situation it’s been compromised.

Some food for thought

[francislavoie]

@basil

Relax trust store dependency
Caddy CA depends on the root cert being inserted in the local trust store. It’s possible to explicitly specify the location of the root CA in programs such as curl e.g. curl --cacert= and applications such as SmallStep iff the root cert is not in located the trust store.

I’m not sure I understand. What usage situation are you seeing this in?

@basil

Smallstep has a bootstrap command to download the root cert from the CA to set up the current environment.

That’s actually what I’m working on with the caddy trust command. It’ll read from the admin API instead of trying to load files directly from storage, meaning the command will depend on the running Caddy instance instead. You could run it from a different machine as well (if the admin API is exposed - I’ll have to think about a good way to do this without exposing the admin API).

[basil (Basil Hendroff)]

@francislavoie

I’m not sure I understand. What usage situation are you seeing this in?

An example is the trust not supported error starting around post #37 in the thread mTLS under FreeBSD.

{"level":"error","ts":"2021-05-10T21:41:57.226+0800","logger":"pki.ca.local","msg":"failed to install root certificate","error":"trust not supported","certificate_file":"storage:pki/authorities/local/root.crt"}

From what I understand here, for the local CA to operate, a mandatory Caddy requirement is that the root cert be installed in the local trust store.

Unless I’m reading it wrong, the SmallStep support article Getting Started, seems to suggest that having the root cert in the local trust store is an optional Smallstep requirement.

You may also wish to establish system-wide trust of your CA, so your certificates will be trusted by curl and other programs. Use the step certificate install command to install your root CA certificate into your system’s trust store:

Given the current workaround and a forthcoming fix as described in the thread Trust store issue under FreeBSD - follow-up , this suggestion is more of a 'wouldn’t it be nice to see this requirement relaxed` rather than a ‘I’m hangin’ out for this feature’.

[francislavoie]

@basil

An example is the trust not supported error starting around post #37 in the thread mTLS under FreeBSD.

{"level":"error","ts":"2021-05-10T21:41:57.226+0800","logger":"pki.ca.local","msg":"failed to install root certificate","error":"trust not supported","certificate_file":"storage:pki/authorities/local/root.crt"}

Oh, I think you can just turn on the skip_install_trust global option to get past that.

It’s not required really. Just the error handling might cancel continuing when it doesn’t make sense.

[basil (Basil Hendroff)]

That’s handy to know. Thanks!