Skip to content
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

Allow automatic use of Headscale certs? #5197

Open
edgar-vincent opened this issue Nov 10, 2022 · 5 comments
Open

Allow automatic use of Headscale certs? #5197

edgar-vincent opened this issue Nov 10, 2022 · 5 comments
Labels
feature ⚙️ New feature or request

Comments

@edgar-vincent
Copy link

Hello,

The docs mention that Headscale, a libre implementation of the Headscale control server, can be used with Caddy. However, Caddy only automatically uses Tailscale for *.ts.net domains, which are specific to Tailscale services. Headscale users, on the other hand, obviously get to define their own domain name.

Would it be possible, for example, to be able to define the domain used by Headscale in Caddy's configuration, in order for it to use its TLS certificates automatically?

Thanks a lot!

EV

@mholt mholt added the feature ⚙️ New feature or request label Nov 10, 2022
@mholt
Copy link
Member

mholt commented Nov 10, 2022

Yeah, I think we can do this. Not sure how yet, but most likely doable!

@edgar-vincent
Copy link
Author

Thank you very much!

@motiejus
Copy link

motiejus commented Nov 22, 2023

Headscale or tailscaled would need to know how to nudge the DNS server to add the dns txt records for verification. This is hard, because everyone uses a different DNS server and API/process to change the records.

It works so easily with tailscale, because tailscale-the-company controls *.ts.net, tailscale control plane and tailscaled (the daemon on everyone's machine). They can easily couple everything and have just 1 combination of software to worry about. Tailscale offering https to their-controlled domain is not a coincidence. :)

Caddy asking for a cert is the icing. The hard part is getting the pieces to talk to each other.

I have implemented https for headscale domains. For the curious, here is a public domain bitwarden.jakstys.lt pointing to 100.<...> ip: https://git.jakstys.lt/motiejus/config/src/commit/d60677822f3e340c1f6a96533de432884e10bc77/data.nix#L170 and implementation: https://git.jakstys.lt/motiejus/config/src/commit/d60677822f3e340c1f6a96533de432884e10bc77/modules/services/nsd-acme/default.nix

I had to change my dns server from unbound to nsd to make it work, because I couldn't reliably update the zone from a shell script.

As you can see, it's convoluted. A better place to start for the adventurous would probably be headscale, not here. :).

(And the mention of headscale should probably removed from the caddy docs, since it's not fundamentally not possible today, not due to Caddy's fault).

@francislavoie
Copy link
Member

@motiejus I don't use Tailscale nor Headscale so I'm not equipped to help much here, but it sounds like we need to integrate Caddy's DNS plugins to make this happen. I don't know what the triggers are here, but that does sound solvable.

@teleclimber
Copy link

Note that Headscale does not yet fetch certs to use with server over TLS but it probably will some day:

juanfont/headscale#1921

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature ⚙️ New feature or request
Projects
None yet
Development

No branches or pull requests

5 participants