starred/headscale
1
0
Fork 0
mirror of https://github.com/juanfont/headscale.git synced 2026-01-11 20:00:28 +01:00
Code Issues 98 Packages Projects Releases 10 Wiki Activity

TLS / LetsEncrypt / ACME support for nodes #36

New Issue
Closed
opened 2025-12-29 01:20:35 +01:00 by adam · 17 comments
adam commented 2025-12-29 01:20:35 +01:00
Owner
Copy Link

Originally created by @ptman on GitHub (Sep 24, 2021).

Would be extremely nice. Needs MagicDNS. https://tailscale.com/blog/tls-certs/ https://github.com/tailscale/tailscale/issues/1235

Originally created by @ptman on GitHub (Sep 24, 2021). Would be extremely nice. Needs MagicDNS. https://tailscale.com/blog/tls-certs/ https://github.com/tailscale/tailscale/issues/1235
adam added the enhancementstale labels 2025-12-29 01:20:35 +01:00
adam closed this issue 2025-12-29 01:20:36 +01:00
adam commented 2025-12-29 01:20:37 +01:00
Author
Owner
Copy Link

@juanfont commented on GitHub (Sep 26, 2021):

Hi ptman,

We are working on MagicDNS support - or our interpretation of it :)

In the meantime, you can use the DNS-01 challenge of ACME to get valid certificates in your internal Headscale machines.

@juanfont commented on GitHub (Sep 26, 2021): Hi ptman, We are working on MagicDNS support - or our interpretation of it :) In the meantime, you can use the DNS-01 challenge of ACME to get valid certificates in your internal Headscale machines.
adam commented 2025-12-29 01:20:37 +01:00
Author
Owner
Copy Link

@mannp commented on GitHub (Sep 29, 2021):

It would be great if we could use our own CA server for the certs rather than LE, so our devices are not open to the wider web, like they appear to be according to the tailscale docs.

@mannp commented on GitHub (Sep 29, 2021): It would be great if we could use our own CA server for the certs rather than LE, so our devices are not open to the wider web, like they appear to be according to the tailscale docs.
adam commented 2025-12-29 01:20:39 +01:00
Author
Owner
Copy Link

@qbit commented on GitHub (Sep 29, 2021):

A full ACME server setup to use your own CA seems a bit much to me - You could use something like microca to manage your own CA / generate signed certs for your hosts.

@qbit commented on GitHub (Sep 29, 2021): A full ACME server setup to use your own CA seems a bit much to me - You could use something like [microca](https://github.com/qbit/microca) to manage your own CA / generate signed certs for your hosts.
adam commented 2025-12-29 01:20:39 +01:00
Author
Owner
Copy Link

@mannp commented on GitHub (Sep 29, 2021):

Already manage them with step, presumed the ability to change the acme ca url from le would suffice.

@mannp commented on GitHub (Sep 29, 2021): Already manage them with step, presumed the ability to change the acme ca url from le would suffice.
adam commented 2025-12-29 01:20:40 +01:00
Author
Owner
Copy Link

@philhug commented on GitHub (Feb 22, 2023):

I'm experimenting with adding tailscale cert support to headscale. So the way it works, is that it sends a set-dns request to the controller to set the TXT record needed for letsencrypt, which then sets this in the DNS.
I see 2 options to implement this:

  • use an API to set this on an external DNS server (e.g. cloudflare, ...)
  • include an authoritative dns server (e.g. https://github.com/miekg/dns)

It seems the 2nd option is easier to implement and more generic, what do you think?

@philhug commented on GitHub (Feb 22, 2023): I'm experimenting with adding `tailscale cert` support to headscale. So the way it works, is that it sends a `set-dns` request to the controller to set the TXT record needed for letsencrypt, which then sets this in the DNS. I see 2 options to implement this: * use an API to set this on an external DNS server (e.g. cloudflare, ...) * include an authoritative dns server (e.g. https://github.com/miekg/dns) It seems the 2nd option is easier to implement and more generic, what do you think?
adam commented 2025-12-29 01:20:40 +01:00
Author
Owner
Copy Link

@tobru commented on GitHub (Feb 22, 2023):

I'm a big fan of https://github.com/joohoi/acme-dns for that specific purpose. From your suggestions I'd prefer the 2nd option.

@tobru commented on GitHub (Feb 22, 2023): I'm a big fan of https://github.com/joohoi/acme-dns for that specific purpose. From your suggestions I'd prefer the 2nd option.
adam commented 2025-12-29 01:20:43 +01:00
Author
Owner
Copy Link

@Zocker1999NET commented on GitHub (Feb 22, 2023):

I think there are setups where configuring your headscale server as an authoritative DNS server may not be feasible or easily possible for everyone (e.g. my server already has an authoritative DNS server running on port 53, but supports RFC 2136 / nsupdate). But the first option may introduce much work to support every service which most ACME clients are already trying to do.

Maybe it might be feasible to implement support for "DNS service plugins" another established ACME client already provides/supports (and publishes them using a compatible license). e.g. acme.sh has already support for many services (but maybe not license-compatible, GPL 3.0). So duplicated development work might be prevented.

@Zocker1999NET commented on GitHub (Feb 22, 2023): I think there are setups where configuring your headscale server as an authoritative DNS server may not be feasible or easily possible for everyone (e.g. my server already has an authoritative DNS server running on port 53, but supports RFC 2136 / nsupdate). But the first option may introduce much work to support every service which most ACME clients are already trying to do. Maybe it might be feasible to implement support for "DNS service plugins" another established ACME client already provides/supports (and publishes them using a compatible license). e.g. [acme.sh](https://github.com/acmesh-official/acme.sh/tree/master/dnsapi) has already support for many services (but maybe not license-compatible, GPL 3.0). So duplicated development work might be prevented.
adam commented 2025-12-29 01:20:44 +01:00
Author
Owner
Copy Link

@philhug commented on GitHub (Feb 23, 2023):

@tobru acme-dns sounds like an viable solution for headscale. it would also fall into the 1st option though, because from headscale's PoV it's just an API.
Let's try to list pros/cons of both approaches:

  1. external api
  • + no DNS code in headscale
  • - could end up supporting many different DNS APIs

1b. external api for acme-dns only

  • + solves some of the issues of bundling the authoritative DNS server, by uncoupling it from headscale
  • - additional complexity by having to run 2 processes
  1. built-in authoritative DNS
  • + only one code path
  • + less moving parts, better out of the box experience
  • - authoritative DNS might not be easy to expose (port 53, or even doing NAT to another port)

I have a working PoC with approach 2, but I think going with 1b seems reasonably, if people agree.

@philhug commented on GitHub (Feb 23, 2023): @tobru acme-dns sounds like an viable solution for headscale. it would also fall into the 1st option though, because from headscale's PoV it's just an API. Let's try to list pros/cons of both approaches: 1. external api * `+` no DNS code in headscale * `-` could end up supporting many different DNS APIs 1b. external api for acme-dns only * `+` solves some of the issues of bundling the authoritative DNS server, by uncoupling it from headscale * `-` additional complexity by having to run 2 processes 2. built-in authoritative DNS * `+` only one code path * `+` less moving parts, better out of the box experience * `-` authoritative DNS might not be easy to expose (port 53, or even doing NAT to another port) I have a working PoC with approach 2, but I think going with 1b seems reasonably, if people agree.
adam commented 2025-12-29 01:20:44 +01:00
Author
Owner
Copy Link

@tobru commented on GitHub (Mar 12, 2023):

At least for me, 1b would be the preferred way to go.

@tobru commented on GitHub (Mar 12, 2023): At least for me, 1b would be the preferred way to go.
adam commented 2025-12-29 01:20:45 +01:00
Author
Owner
Copy Link

@philhug commented on GitHub (Mar 12, 2023):

OK. I'll work on a PR for this.

@philhug commented on GitHub (Mar 12, 2023): OK. I'll work on a PR for this.
adam commented 2025-12-29 01:20:46 +01:00
Author
Owner
Copy Link

@evenh commented on GitHub (Mar 20, 2023):

Just want to chime in with an alternative ACME library in case anyone is looking: https://github.com/caddyserver/certmagic

@evenh commented on GitHub (Mar 20, 2023): Just want to chime in with an alternative ACME library in case anyone is looking: https://github.com/caddyserver/certmagic
adam commented 2025-12-29 01:20:47 +01:00
Author
Owner
Copy Link

@Stunt0265 commented on GitHub (Jul 5, 2023):

Anything more come of this? I'd love to share out a localhost website via Headscale and have the SSL certs created. Doing this with Tailscale now.

@Stunt0265 commented on GitHub (Jul 5, 2023): Anything more come of this? I'd love to share out a localhost website via Headscale and have the SSL certs created. Doing this with Tailscale now.
adam commented 2025-12-29 01:20:47 +01:00
Author
Owner
Copy Link

@tracure1337 commented on GitHub (Sep 17, 2023):

🚀

That'd be so useful.

@tracure1337 commented on GitHub (Sep 17, 2023): :rocket: That'd be so useful.
adam commented 2025-12-29 01:20:47 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Dec 21, 2023):

This issue is stale because it has been open for 90 days with no activity.

@github-actions[bot] commented on GitHub (Dec 21, 2023): This issue is stale because it has been open for 90 days with no activity.
adam commented 2025-12-29 01:20:47 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Dec 29, 2023):

This issue was closed because it has been inactive for 14 days since being marked as stale.

@github-actions[bot] commented on GitHub (Dec 29, 2023): This issue was closed because it has been inactive for 14 days since being marked as stale.
adam commented 2025-12-29 01:20:48 +01:00
Author
Owner
Copy Link

@Kladki commented on GitHub (Mar 3, 2024):

Does this feature exist yet in headscale then? If not, the issue should ideally be re-opened, since clearly some people are interested in this, so that it is at least clear that this feature has not been added yet.

@Kladki commented on GitHub (Mar 3, 2024): Does this feature exist yet in headscale then? If not, the issue should ideally be re-opened, since clearly some people are interested in this, so that it is at least clear that this feature has not been added yet.
adam commented 2025-12-29 01:20:48 +01:00
Author
Owner
Copy Link

@Kladki commented on GitHub (Mar 21, 2024):

When it comes to DNS ACME libraries, there is also lego, which supports many dns providers.

@Kladki commented on GitHub (Mar 21, 2024): When it comes to DNS ACME libraries, there is also lego, which [supports many dns providers](https://go-acme.github.io/lego/dns/).
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
CLI
DERP
DNS
Nix
OIDC
SSH
bug
database
documentation
duplicate
enhancement
faq
good first issue
grants
help wanted
might-come
needs design doc
needs investigation
no-stale-bot
out of scope
performance
policy 📝
pull-request
Mirrored from GitHub Pull Request
 question
regression
routes
stale
tags
tailscale-feature-gap
well described ❤️
wontfix
No Label enhancement stale
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/headscale#36
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?