Page MenuHomeMiraheze

Consider migrating to the Caddy webserver in our cache proxies
Open, LowPublic


So, I've been thinking on T11710 and thought "it sure would be easier to do that if we used Caddy". So I propose that SRE looks at using Caddy instead of NGINX at the cache proxies.

The reason for this is that Caddy automates certificate generation already! And it does so in a way that makes the Miraheze implementation of T11710 way easier for us. Caddy is capable of automatically generating certificates when it first sees the domain name on ClientHello messages (it calls this "on-demand TLS", docs). Since T11710 is the only significant blocker to RequestSSL left, this would basically make RequestSSL ready for deployment.

Event Timeline

Adding the RequestSSL tag since, while this is Miraheze-specific, it is of interest to me as a developer. If this is done it will define how I approach the Miraheze-specific hook handlers related to RequestSSL. could make such a migration possible, but of course rewriting the config in JSON or Caddyfile would be best.

I think I'm a bit confused with the terms here, since technically certificates are generated "automatically" (i.e. just with a command), so how would this make it easier for them to be generated based on a request sent by RequestSSL ?

It would be easier because you wouldn't need a command anymore, it would be fully automatic, which is the point of T11710. When Caddy sees a new domain name for the first time, it queries a HTTP server, and if it gets a 200 OK as a response, it generates a certificate for that domain. This all happens in the timespan of the first TLS ClientHello for that domain.