pinkeen
commented
3 years ago I love the idea as it would allow to avoid having to provision client nodes' trust store with the private CA certificates. This is very convenient as this setup (and later maintenance) can become really complex, especially in big heterogenous environments, embedded devices, etc.
I'd like to add some random input (rambling) to this request too.
Certificate cache
Cache all certificates returned on behalf of the ACME upstream to prevent failures that would be caused by rate limits of the upstream ACME authority.
Possible use-case scenario from real-life experience: Stateless and/or ephemeral cloud nodes which need to request a new certificate on each start, often for the same domains.
Custom authentication challenge (zero-configuration?)
Authenticate the requester by verifying the trust relationship inferred from existing configuration - e.g. requester is an upstream with known client certificate.
I don't have any good idea for verifying the authorization to receive specific certificate though. I wonder if step-ca's provisioning providers could be used for this... Possibly, if the requester is already an upstream and the requested domain matches any of the the ones that it already handles traffic from then there is no challenge needed at all.
Setup I have that would benefit from this feature:
- I've got a lot of web services running in my home network (behind a double NAT) which I am exposing publicly.
- I've set up two caddy instances:
- Public - serves as an https-terminating public reverse-proxy
- Private - upstream¹ of the public caddy which also serves as an https-terminating aggregator for the private network services²
- When on the home network I want to be able to access the local services directly using the same hostnames in order to avoid unnecessary roundtrip and be able to do that even if the private network has got intermittent connection problems (prevent the ingress being a SPOF for local access).
¹ The ingress is connected to the upstreams via Nebula Overlay Mesh Network. ² There might be multiple private instances of course, but in my case at most two or three (per virtualization host I guess) as it's usually much less work to set up and manage (monitor) a single caddy instance that to configure each service separately to use acme for its certs. Especially that these services are usually running on very different hardware/virt and software platforms.
PS On an unrelated topic - I've just come up with a crazy but vague idea. Nebula is golang too, also uses PKI authentication and has a built-in DNS server (which I actually use as a sub-zone of my primary domain's zone). It would be super-cool to marry the two together. Not sure how though - maybe one could partially automate or provide services for the other so common-usage scenarios could be simplified using one piece of software. Huh, this would be kind of an HTTP routing mesh with out-of-the-box private overlay network.
👆 I've just realized how utterly pointless my setup is. 😞 I can just use nginx on the public node as it can pass-through encrypted traffic while still retaining the ability to route it based on SNI Host (ngx_stream_ssl_preread_module. I've even done this before... Though it's not possible to do any custom handling of the encrypted traffic on the ingress server though so I cannot use a singe authorization portal for all of the upstreams (planned to use caddy for this).
mholt
francislavoie
m-martin-78
This allows other ACME clients (like Caddy under privite networks) to use another Caddy as an ACME endpoint, and proxy/convert ACME challenge to upstream like Let's Encrypt.