TLS / LetsEncrypt / ACME support for nodes

[ptman]

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

[juanfont]

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.

[mannp]

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.

[qbit]

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.

[mannp]

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

[philhug]

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?

[tobru]

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.

[Zocker1999NET]

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.

[philhug]

@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.

[tobru]

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

[philhug]

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

[evenh]

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

[Stunt0265]

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.

[tracure1337]

:rocket:

That'd be so useful.

[github-actions[bot]]

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

[github-actions[bot]]

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

[Kladki]

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]

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