-
Notifications
You must be signed in to change notification settings - Fork 44
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
certs: update tscert dialer to connect to tsnet server #53
Conversation
e90764e
to
cf24886
Compare
I had a look at the original issue, but it's not very clear to me- is the goal to issue ts.net certs from a non-Tailscale issuer or to use the Tailscale-issued ts.net cert for a non-tailnet endpoint? Is there an example I can try out to see what this PR achieves? |
module.go
Outdated
|
||
// localAPIDialer finds the node that matches the requested certificate in ctx | ||
// and dials that node's local API. | ||
// If no matching node is found, the default dailer is used, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit:
// If no matching node is found, the default dailer is used, | |
// If no matching node is found, the default dialer is used, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's stil there
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done for real this time.
ah, good call out. It's really not obvious what this is doing. So, caddy has really good native SSL support. It supports HTTP-01 acme challenges, DNS-01 challenges with a whole host of DNS providers, etc. For Tailscale hostnames, neither of those will work, since the host isn't publicly available online (needed for HTTP-01) and the user can't directly edit DNS records for ts.net (needed for DNS-01). So caddy also has native support for calling out to Tailscale to have it get certificates as needed. You can see the docs here, but there isn't much there since most of the time it just works. You run caddy on a machine that already has Tailscale running, and include the full ts.net hostname in the config:
Caddy will detect that it is a Tailscale hostname, and use the Tailscale cert manager to get the certificate. That cert manager in turns uses tscert, which is a very minimal LocalClient that will call out to the local tailscaled to request the certificate be issued and pass it back to caddy to use. The caveat is that it only works with a tailscaled running on the local machine that it can talk to, so it doesn't work for tsnet at all. To initially support certs in caddy-tailscale, we basically ignored all of the above built-in functionality, and instead created the We should ideally be able to use a caddyfile like:
So for testing, I'm actually using this caddyfile:
Without this PR, caddy will call out to tscert like normal which will try to talk to the local tailscaled. That will result in the error:
With this PR, we override the dialer that tscert uses to connect to the LocalAPI, and have it connect to the relevant tsnet server. That should result in:
I guess this change ends up tickling caddy's QUIC support in ways we weren't before, so I also need to wait for tailscale/tailscale#12184 to fix our UDP support in tsnet. I'll also update docs to no longer recommend using the |
bc546c5
to
509c374
Compare
Signed-off-by: Will Norris <will@tailscale.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the detailed explanation, it makes perfect sense- tested a setup with a node without a full ts.net hostname specified and worked as expected.
Should we also change the example here https://github.com/tailscale/caddy-tailscale/blob/main/examples/proxyauth.caddyfile#L33 that still uses the tailscale+tls
listener?
At this time, the Tailscale plugin for Caddy doesn't support using Caddy's native HTTPS resolvers. | ||
You will need to use the `tailscale+tls` bind protocol with a configuration like this: | ||
Caddy's automatic HTTPS support can be used with the Tailscale network listener like any other site. | ||
If the site address includes the full `ts.net` hostname, no additional configuration is necessary: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe link https://tailscale.com/kb/1153/enabling-https from here? Or add a note that this will issue a LE cert for the tailnet hostname of the node (assuming that there will be some users who aren't that familiar with Tailscale HTTPS).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ooh, good idea. done.
oh, definitely! Thanks, I'll fix that. |
7316f15
to
4dae5bf
Compare
This provides an alternate implementation for tscert.TailscaledDialer that tries to find a tsnet server for the requested certificate. This allows caddy-tailscale to be used with caddy's auto_https support. Fixes #19 Signed-off-by: Will Norris <will@tailscale.com>
This provides an http.RoundTripper implementation that dynamically routes requests to the correct tsnet server's LocalAPI based on the ClientHelloInfo in the context. Previously, we were just overriding the tscert Dialer. That worked fine the first time it dialed a LocalAPI, and would correctly dial the right tsnet server. However, tscert caches the Transport with that Dialer, so requests that should be routed to different tsnet servers would be routed incorrectly. Updates #19 Updates #53 Updates #66
This provides an http.RoundTripper implementation that dynamically routes requests to the correct tsnet server's LocalAPI based on the ClientHelloInfo in the context. Previously, we were just overriding the tscert Dialer. That worked fine the first time it dialed a LocalAPI, and would correctly dial the right tsnet server. However, tscert caches the Transport with that Dialer, so requests that should be routed to different tsnet servers would be routed incorrectly. Updates #19 Updates #53 Updates #66 Signed-off-by: Will Norris <will@tailscale.com>
This provides an http.RoundTripper implementation that dynamically routes requests to the correct tsnet server's LocalAPI based on the ClientHelloInfo in the context. Previously, we were just overriding the tscert Dialer. That worked fine the first time it dialed a LocalAPI, and would correctly dial the right tsnet server. However, tscert caches the Transport with that Dialer, so requests that should be routed to different tsnet servers would be routed incorrectly. Updates #19 Updates #53 Updates #66 Signed-off-by: Will Norris <will@tailscale.com>
This provides an http.RoundTripper implementation that dynamically routes requests to the correct tsnet server's LocalAPI based on the ClientHelloInfo in the context. Previously, we were just overriding the tscert Dialer. That worked fine the first time it dialed a LocalAPI, and would correctly dial the right tsnet server. However, tscert caches the Transport with that Dialer, so requests that should be routed to different tsnet servers would be routed incorrectly. Updates #19 Updates #53 Updates #66 Signed-off-by: Will Norris <will@tailscale.com>
This provides an http.RoundTripper implementation that dynamically routes requests to the correct tsnet server's LocalAPI based on the ClientHelloInfo in the context. Previously, we were just overriding the tscert Dialer. That worked fine the first time it dialed a LocalAPI, and would correctly dial the right tsnet server. However, tscert caches the Transport with that Dialer, so requests that should be routed to different tsnet servers would be routed incorrectly. Updates #19 Updates #53 Updates #66 Signed-off-by: Will Norris <will@tailscale.com>
This provides an http.RoundTripper implementation that dynamically routes requests to the correct tsnet server's LocalAPI based on the ClientHelloInfo in the context. Previously, we were just overriding the tscert Dialer. That worked fine the first time it dialed a LocalAPI, and would correctly dial the right tsnet server. However, tscert caches the Transport with that Dialer, so requests that should be routed to different tsnet servers would be routed incorrectly. Updates #19 Updates #53 Updates #66 Signed-off-by: Will Norris <will@tailscale.com>
This provides an http.RoundTripper implementation that dynamically routes requests to the correct tsnet server's LocalAPI based on the ClientHelloInfo in the context. Previously, we were just overriding the tscert Dialer. That worked fine the first time it dialed a LocalAPI, and would correctly dial the right tsnet server. However, tscert caches the Transport with that Dialer, so requests that should be routed to different tsnet servers would be routed incorrectly. Updates #19 Updates #53 Updates #66 Signed-off-by: Will Norris <will@tailscale.com>
This provides an alternate implementation for tscert.TailscaledDialer that tries to find a tsnet server for the requested certificate. This allows caddy-tailscale to be used with caddy's auto_https support.
Fixes #19
This is a draft PR that relies on changes in both tscert and caddy, which will need to be merged in order: