[Feature] Support self-signed TLS (other than Let's Encrypt) #835

Closed
opened 2025-12-29 02:24:39 +01:00 by adam · 3 comments
Owner

Originally created by @cg31 on GitHub (Oct 18, 2024).

Use case

We can use self-signed TLS service without outside service like Let's Encrypt, for simple network.

Description

Headscale support Let's Encrypt, but it still needs domain name, and it also makes Headscale depending on other service.

Nowadays we can use mkcert or openssl to generate self-signed certificate, they can be done with IP only.

Contribution

  • I can write the design doc for this feature
  • I can contribute this feature

How can it be implemented?

  1. User generate local CA with mkcert or openssl
  2. User installs the CA on all nodes
  3. User creates a new certificate with CA for the headscale server
  4. Headscale uses the certificate with ListenAndServeTLS to provide TLS service, client nodes (Tailscale) use the installed CA to verify the certificate.
Originally created by @cg31 on GitHub (Oct 18, 2024). ### Use case We can use self-signed TLS service without outside service like Let's Encrypt, for simple network. ### Description Headscale support Let's Encrypt, but it still needs domain name, and it also makes Headscale depending on other service. Nowadays we can use mkcert or openssl to generate self-signed certificate, they can be done with IP only. ### Contribution - [ ] I can write the design doc for this feature - [ ] I can contribute this feature ### How can it be implemented? 1. User generate local CA with mkcert or openssl 2. User installs the CA on all nodes 3. User creates a new certificate with CA for the headscale server 4. Headscale uses the certificate with ListenAndServeTLS to provide TLS service, client nodes (Tailscale) use the installed CA to verify the certificate.
adam added the enhancement label 2025-12-29 02:24:39 +01:00
adam closed this issue 2025-12-29 02:24:40 +01:00
Author
Owner

@hopleus commented on GitHub (Oct 18, 2024):

Isn't that what you're suggesting?

https://headscale.net/ref/tls/#bring-your-own-certificate

@hopleus commented on GitHub (Oct 18, 2024): Isn't that what you're suggesting? https://headscale.net/ref/tls/#bring-your-own-certificate
Author
Owner

@cg31 commented on GitHub (Oct 18, 2024):

I tried it with certificate, but it doesn't work, and headscale report error "headscale/cli/utils.go:124 > Could not connect: context deadline exceeded"

When I look inside headscale, it still uses ListenAndServe, ListenAndServeTLS can use paths to cert and key directly.

@cg31 commented on GitHub (Oct 18, 2024): I tried it with certificate, but it doesn't work, and headscale report error "headscale/cli/utils.go:124 > Could not connect: context deadline exceeded" When I look inside headscale, it still uses ListenAndServe, ListenAndServeTLS can use paths to cert and key directly.
Author
Owner

@cg31 commented on GitHub (Oct 23, 2024):

Isn't that what you're suggesting?

https://headscale.net/ref/tls/#bring-your-own-certificate

Turns out... it works after trying again, only I need to use 443 as serving port.

But "headscale nodes list" seems not working anymore, but it doesn't matter.

@cg31 commented on GitHub (Oct 23, 2024): > Isn't that what you're suggesting? > > https://headscale.net/ref/tls/#bring-your-own-certificate Turns out... it works after trying again, only I need to use 443 as serving port. But "headscale nodes list" seems not working anymore, but it doesn't matter.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/headscale#835