I would like to host non-HTTP TLS services on port 443 (specifically, OpenVPN, to get around silly firewalls). I've seen a past bug for this closed because Caddy wants to focus on HTTP, which is fair.
My alternative is to use a TLS SNI proxy, which inspects the requested hostname in the TLS handshake, and routes either to Caddy listening on localhost:1234, or to my other TLS-requiring services. The proxy itself doesn't terminate TLS, it just proxies bytes after picking the right backend, so this is mostly invisible to Caddy.
However, this currently breaks automatic TLS cert issuance, because Caddy uses the bind address when configuring the ACME client, and localhost doesn't work well over the internet. So, to make my setup work, I would need a way to tell Caddy use some other address for ACME issuance, and trust me to plumb things together.
Is this something you'd be open to adding as an option to the tls directive? Alternatively, if Caddy's stance has changed on doing TLS proxying in addition to HTTP handling... I'd be happy to discuss how to contribute that :).
I realize this wasn't made clear in my original report, but: I'm offering to contribute patches to make stuff happen, I'm mostly looking for design guidance as to what you think is best for Caddy.
I think this could be done. A command-line option for the ACME challenge address, perhaps? One for the HTTP challenge, another for the TLS-SNI challenge?
I would like this feature as well. Reasons are similar but not exactly the same.
I'm running Caddy on openbsd. To my knowledge there is no equivalent of setcap cap_net_bind_service=+ep /usr/local/bin/caddy to allow my caddy user to open ports 80 or 443.
It's relatively easy to have Caddy listen on, say 8080 and 8443, then use relayd to forward tcp traffic on 80 and 443 to those ports.
I don't know how ACME works under the covers. But I wonder if Caddy receives an HTTPS request on port 8443, and has been configured for automatic TLS, could it simply assume that requests to 80 and 443 will reach it (Caddy) and that it will be able to complete the ACME protocol on whatever ports it happens to be listening on. I'm wondering whether it even needs a new command line option.
@danderson @dncohen Is specifying the port via command line flag sufficient, or do you need to be able to specify the whole address?
Edit: On second look, I think just a flag to set the ports is all that would be needed, since the ACME client respects the bind directive and will bind to that IP on a per-site basis.
For my case, just the ports is fine. I want some way to say to Caddy, "you're not bound to 443 but don't worry, traffic to 443 will make its way to you."
If you want me to test a patch, I'm happy to do that.
@dncohen
I want some way to say to Caddy, "you're not bound to 443 but don't worry, traffic to 443 will make its way to you."
Great way to put it. This makes a lot of sense!
If you want me to test a patch, I'm happy to do that.
Coming soon! Please test it thoroughly -- very, very thoroughly. Ha.
@dncohen Patch submitted! Let me know what you think.
I ran into issues using the https-port and http-port flags.
So 80 is forwarded to 8080 and 443 is forwareded to 8433.
Both port flags reflect this and use 8080/8443.
Now when a request comes in for something like a proxy it works:
page.example.com {
proxy / http://example.local {
transparent
header_downstream -Server ""
}
}
Using the redirect directive it adds the port to the redirection:
kubernetes.opensourcesoftware.rocks {
redir https://kubernetes.io{uri}
}
-> kubernetes.opensourcesoftware.rocks:8443, which as expected fails as publicly no 8443 is served.
Is this expected behavior? Might be good to clarify this in the docs, if it is.
@stp-ip I can't repeat this locally -- maybe I'm misreading your comment. Can you open an issue and answer all the questions so I can see the same thing? Then I can get an answer for you.
Most helpful comment
I realize this wasn't made clear in my original report, but: I'm offering to contribute patches to make stuff happen, I'm mostly looking for design guidance as to what you think is best for Caddy.