Yeah the general TLS configuration is done in the caddyfile, but adding an exception to auto TLS via the caddyfile makes it easier for people to shoot themselves in the foot. Therefore the idea was to make the non default behavior a command line flag to make it more of an advanced config.
I think a command line flag is as easy to break things as a Caddyfile directive, FWIW. Iām not convinced a command line flag is the right way to approach this; TLS config is scoped to each individual site (where the Go std lib allows it) and I donāt think I like the idea of bringing TLS configuration out into a command line flag.
The idea was not to bring the TLS config per se into a command line flag, but prevent the special behavior of paths in general via that flag. As that was just an ideaā¦
For the TLS master idea in general it would probably be enough to have a config to set the server handling the challenge. Problem with that is that proxy stuff is not implemented in core.
As a result of the proxy not being available in core this flag would disable default behavior and depend on the proxy middleware.
I donāt believe master/slave w/ a proxy to the challenge path is a good way at all. Firstly, thatās not really HA unless you do leader election which can be difficult to implement natively, e.g. raft/paxos, as opposed to using something like Zookeeper, Consul, etcd, etc.
I think the way that has been discussed, shared storage for certs and challenge details, is the way to have truly HA. Whether you round robin your DNS or you do end-to-end encryption with a load balancer or haproxy-type setup in the middle, the point is the ACME protocol and letās encrypt specifically say there is no way to choose which server requests will go to for the HTTP challenge. Therefore, all servers in a truly HA setup need to be able to respond to any request from the CA and need to be able to auto renew at will. There needs to be no concept of a āmasterā because thatās not HA when the master can die (again, unless you have complicated leader election built in or use an external service).
Itās only master/slave for the certificates, which is a service, that could handle a failing master, which gets either reelected/restarted or something else. Renewal has enough overlapping time to not be failure sensitive.
If challenge data could be shared, that might be another interesting solution. The thought for using the proxy was ease of use and implementation (until the default behavior prevented the ease of use).
Any updates or ongoing developments ?
Yes, in fact. 
In the code, Caddy supports pluggable TLS asset storage providers thanks to some work by contributors. Iām kind of refining it, trying to get it just right, weāll eventually make it a first-class plugin that you can select on the download page. (First up is a kubernetes implementation which is already mostly done.)
6 Likes
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.