Caddy: Check with backend if should do On-Demand TLS

[francislavoie]

I had a "showerthought" this morning, a idea to potentially make on-demand TLS more viable for some SaaS modeled applications. Disclaimer: I personally don't have a use for this yet, but it might make it easier for when I do!

So with proxy, we have the health_check feature. I was thinking we could leverage the same kind of idea with tls to do a request to an internal API that the application would need to expose that would let Caddy ask the app if it "should" attempt on-demand TLS. That way Caddy would only make certs for domains that actually make sense to the application.

The only thing we have as a limiter right now (as far as I can tell?) is max_certs, which is a bit too hard of a limit if there's legitimate subdomains that should exist. Specifically, I'm thinking of the {customername}.example.com model specifically here.

I'm not totally sure what the API would look like, but it could be as simple as a GET to the endpoint specified with domain as a URL parameter like /api/domains?domain={subdomain} and the app should return a 2xx as a go-ahead or 4xx as a no-go.

I guess this might go along with https://github.com/mholt/caddy/issues/8 a bit, but in this case it would be a request that Caddy makes to reach out to the internally proxied/fastcgi'd application like with health_check.

[mholt]

I like this idea. Caddy should have a way of determining whether it's authorized to obtain a certificate for a certain hostname, rather than just "have we hit the limit yet?" - I think ultimately this is what I wanted to do, but I got lazy at first.

[mholt]

I envision a subdirective to tls that lets you set a URL where Caddy can ask whether a hostname should grant the certificate: ask localhost:1234/on-demand which then sends a request with the hostname. Something like that.

[tantalic]

@mholt I would be willing to work on this. A couple of questions/clarifications for how you would like to see this:

1. Should the request be a GET or POST? Since we are retrieving informaiton I propose a GET request.
2. Should the request include any information other then the domain being requested?
3. I propose any 2xx response would be considered an approval and any other response code would be considered a rejection. The response body would not be considered. Do you agree?
4. Should we follow 3xx redirects? At this time I would suggest we do not follow redirects. I believe redirects may provide an avenue for abuse and unnecessarily complicate the feature.

[mholt]

@tantalic

1. I agree: GET - just no request body
2. No, probably not. (We can change this later if there is an actual need)
3. Yes, let's keep it as simple as possible!
4. Um, no, you're definitely right.

Sounds like you have a pretty good grasp of this! Feel free to come back with any other questions. I like where this is heading.

[francislavoie]

:+1: from me too, that's what I had in mind!