I’m reading through the config examples for the caddy-l4/layer4/Project Conncept plugin because I’m looking to use it to terminate TLS for a TCP connection.
Now if it wants to terminate TLS it will need a hostname so it can obtain certificates, right? Where do I put this hostname? In the "listen": ["blah.com:1234"] part? Or somewhere in the tls matcher or even tls handler?
Another question… my TCP-over-TLS can use port 443 or a different port, both is fine for me. But as far as I know layer4 and regular HTTPs cannot share the same port, so it’ll be a different port. I also vaguely remember that the challenge still has to be done on port 80 (for HTTP-01) or 443 (for TLS-ALPN-01). Does Caddy know that? Will it use port 80/443 to do the challenge and then use the obtained certificate on the port that layer4 is listening on?
They can, as long as you split the traffic using a matcher (like SNI). So you can pass any connections without matching SNI (i.e. domains that are not for your HTTPS sites) to your TCP handling.
Not sure what you mean by “know”. The tls app will try both challenges by default so either way it should work. It’s only needed to obtain the cert, it doesn’t matter which one is used after either one succeeds.
@matt will need to chime in on making ACME TLS-ALPN work with layer4, I’m not sure if there’s something that needs to be done to make sure the challenge handler is loaded.
I saw that I can match by SNI with it, but will that same name also be used as SAN when fetching the certificate?
I meant does Caddy know that it has to do the challenge using the normal HTTP/HTTPs ports instead of whatever port layer4 is listening on?
If it isn’t too much trouble, I’d appreciate an example JSON config for layer4 that just terminates TLS for one hostname and proxies the connection to a TCP port. There is one in the readme (second example under config examples) but it uses localhost and a self-signed certificate.
Hey @AndreKR – sorry it took me a few days to get to this.
Also, apologies that documentation for caddy-l4 is not very good (yet). I never quite got around to enhancing it. So I understand your confusion… I think @francislavoie may have understood differently. Let me see if I read this right.
Correct. Or you can provide a cert, but yes basically Caddy will need a cert.
With JSON config, there are connection policies and automation policies. Automation policies tell Caddy what certificates to automate and how to do that. Connection policies tell Caddy how to serve TLS connections.
Connection policies are typically configured close to the server that is using them, i.e. the layer4 app, in the tishandler.
Automation policies, however, are configured in the tisapp module because any/all other apps can reuse the certificates that the tis app is managing:
So the name(s) to have certificates for are specified in the tis app, in an automation policy. Could be very simple, like so:
The layer4 app does support multiplexing, so you can share a port. (It has some bugs we’re working out but in the meantime it’s easy to tweak your config to work around them.)
All of Caddy’s TLS listeners are capable of solving the TLS-ALPN challenge automatically. If you are using the layer4 app, the HTTP challenge is not supported automatically because that’d require setting up an HTTP server, which isn’t a given with layer4. However, if you do set up Caddy’s HTTP server on port 80 then it should be able to solve the HTTP challenge as well.
I’m not super keen on converting my entire Caddyfile to JSON because I like how simple it is, so I was planning on trying out this plugin and see how far it gets me.
If I got your explanation correctly, it doesn’t actually matter how the certificate was obtained, it will still be used by all apps? So I could actually obtain the certificate just by configuring an HTTPs server for the domain name and if it matches the tls* matcher in the layer4 config Caddy will see that the names match up and use the cert?
* By the way, you wrote tis, which I assumed was a typo but you wrote it three times so now I’m not so sure…