You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are some long standing feature requests for tailscale cert and tailscale serve to work with HTTPS.
From a discussion with @Erisa, we talked about the steps for doing this and how it currently works, all should be possible, but will require a few building blocks.
This issue is intended to track the effort and to note down what is needed (while fresh in memory), to ultimately support a couple of things, but there are no ETA for this as we have a bunch of other things to do first.
Most of these features depend on each other, so it looks like it will be a pretty "linear" effort. There is a couple of side quests which likely will improve other things on the way.
Details / observations
It looks like HTTPS in tailscale serve is directly dependent on tailscale cert to work (as we need the ACME facilities for the certificate).
headscale needs to be able to set DNS for the base_domain zone on behalf of clients. This can likely be done with libdns
side quest: headscale currently has a ACME/letsencrypt implementation that dates back to the origin of the project. It only supports HTTP challenge (which is fine since the server must be public anyways). This can be replaced and simplified with something like certmagic (or the lower level acmez) to support DNS Challenge (and reuse the other config).
This side quest could potentially be leveraged to do something like a "embedded funnel", where funnel requests can be set up to go to the headscale instance and it can serve requests on behalf of clients. Please note that this is very hypothetical and might be unfeasible. There are more parts here to discover like having to run a Tailscale client inside the Headscale process. This will also not work with reverse proxies, leaving the users to decide if they want this feature.
Background
There are some long standing feature requests for
tailscale cert
andtailscale serve
to work with HTTPS.From a discussion with @Erisa, we talked about the steps for doing this and how it currently works, all should be possible, but will require a few building blocks.
This issue is intended to track the effort and to note down what is needed (while fresh in memory), to ultimately support a couple of things, but there are no ETA for this as we have a bunch of other things to do first.
Most of these features depend on each other, so it looks like it will be a pretty "linear" effort. There is a couple of side quests which likely will improve other things on the way.
Details / observations
It looks like HTTPS in
tailscale serve
is directly dependent ontailscale cert
to work (as we need the ACME facilities for the certificate).tailscale cert
requires headscale to implement/machine/set-dns
, which in terms requires headscale to automatically create TXT ACME records "somewhere" for the given domain.headscale needs to be able to set DNS for the
base_domain
zone on behalf of clients. This can likely be done withlibdns
side quest: headscale currently has a ACME/letsencrypt implementation that dates back to the origin of the project. It only supports HTTP challenge (which is fine since the server must be public anyways). This can be replaced and simplified with something like
certmagic
(or the lower levelacmez
) to support DNS Challenge (and reuse the other config).This side quest could potentially be leveraged to do something like a "embedded funnel", where funnel requests can be set up to go to the headscale instance and it can serve requests on behalf of clients. Please note that this is very hypothetical and might be unfeasible. There are more parts here to discover like having to run a Tailscale client inside the Headscale process. This will also not work with reverse proxies, leaving the users to decide if they want this feature.
TODO
base_domain
TXT recordsDNSConfig.CertDomains
tailscale cert
tailscale serve
The text was updated successfully, but these errors were encountered: