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

Let's encrypt not reissuing certificates #562

New Issue
Closed
opened 2025-12-29 02:20:28 +01:00 by adam · 1 comment
adam commented 2025-12-29 02:20:28 +01:00
Owner
Copy Link

Originally created by @reynico on GitHub (Oct 6, 2023).

Bug description

Environment

  • OS: Ubuntu 20.04
  • Headscale version: v0.20.0
  • Tailscale version: 1.38.1
  • Headscale is behind a (reverse) proxy
  • Headscale runs in a container

To Reproduce

I received an email from Let's Encrypt:

Your certificate (or certificates) for the names listed below will expire in 7 days (on 2023-10-13). Please make sure to renew your certificate before then, or visitors to your web site will encounter errors.

This is my current TLS configuration on Headscale:

acme_url: https://acme-v02.api.letsencrypt.org/directory

# Email to register with ACME provider
acme_email: "admin@xx.com"

# Domain name to request a TLS certificate for:
tls_letsencrypt_hostname: tailscale.xx.io

# Client (Tailscale/Browser) authentication mode (mTLS)
# Acceptable values:
# - disabled: client authentication disabled
# - relaxed: client certificate is required but not verified
# - enforced: client certificate is required and verified
tls_client_auth_mode: relaxed

# Path to store certificates and metadata needed by
# letsencrypt
tls_letsencrypt_cache_dir: /var/lib/headscale/cache

# Type of ACME challenge to use, currently supported types:
# HTTP-01 or TLS-ALPN-01
# See [docs/tls.md](docs/tls.md) for more information
tls_letsencrypt_challenge_type: HTTP-01
# When HTTP-01 challenge is chosen, letsencrypt must set up a
# verification endpoint, and it will be listning on:
tls_letsencrypt_listen: ":8000"

## Use already defined certificates:
tls_cert_path: ""
tls_key_path: ""

note that tls_letsencrypt_listen is listening in port 8000 as headscale is running unprivileged, but I have a NAT rule to forward :80 -> :8000, and it's working as expected.

Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
 478K   29M REDIRECT   tcp  --  ens5   *       0.0.0.0/0            0.0.0.0/0            tcp dpt:80 /* Forward HTTP Lets Encrypt challenge traffic */ redir ports 8000

I haven't found any errors on the Headscale error log regarding something wrong with Let's Encrypt, other than a bunch of:

Oct 06 14:01:27 ip-10-10-11-52 headscale[674566]: 2023/10/06 14:01:27 http: TLS handshake error from 66.160.133.237:40136: acme/autocert: missing server name
Oct 06 14:24:26 ip-10-10-11-52 headscale[674566]: 2023/10/06 14:24:26 http: TLS handshake error from 66.160.133.234:41754: acme/autocert: missing server name
Oct 06 15:07:25 ip-10-10-11-52 headscale[674566]: 2023/10/06 15:07:25 http: TLS handshake error from 66.160.133.232:43372: acme/autocert: missing server name
Oct 06 15:17:10 ip-10-10-11-52 headscale[674566]: 2023/10/06 15:17:10 http: TLS handshake error from 66.160.133.242:44991: acme/autocert: missing server name

This was working as the Headscale node has over 200 days of uptime (hence, the certificate was renewed in the meantime)

Originally created by @reynico on GitHub (Oct 6, 2023). <!-- Before posting a bug report, discuss the behaviour you are expecting with the Discord community to make sure that it is truly a bug. The issue tracker is not the place to ask for support or how to set up Headscale. Bug reports without the sufficient information will be closed. Headscale is a multinational community across the globe. Our language is English. All bug reports needs to be in English. --> ## Bug description <!-- A clear and concise description of what the bug is. Describe the expected bahavior and how it is currently different. If you are unsure if it is a bug, consider discussing it on our Discord server first. --> ## Environment <!-- Please add relevant information about your system. For example: - Version of headscale used: v0.20.0 - Version of tailscale client - OS (e.g. Linux, Mac, Cygwin, WSL, etc.) and version - Kernel version - The relevant config parameters you used - Log output --> - OS: Ubuntu 20.04 - Headscale version: v0.20.0 - Tailscale version: 1.38.1 <!-- We do not support running Headscale in a container nor behind a (reverse) proxy. If either of these are true for your environment, ask the community in Discord instead of filing a bug report. --> - [ ] Headscale is behind a (reverse) proxy - [ ] Headscale runs in a container ## To Reproduce I received an email from Let's Encrypt: > Your certificate (or certificates) for the names listed below will expire in 7 days (on 2023-10-13). Please make sure to renew your certificate before then, or visitors to your web site will encounter errors. This is my current TLS configuration on Headscale: ``` acme_url: https://acme-v02.api.letsencrypt.org/directory # Email to register with ACME provider acme_email: "admin@xx.com" # Domain name to request a TLS certificate for: tls_letsencrypt_hostname: tailscale.xx.io # Client (Tailscale/Browser) authentication mode (mTLS) # Acceptable values: # - disabled: client authentication disabled # - relaxed: client certificate is required but not verified # - enforced: client certificate is required and verified tls_client_auth_mode: relaxed # Path to store certificates and metadata needed by # letsencrypt tls_letsencrypt_cache_dir: /var/lib/headscale/cache # Type of ACME challenge to use, currently supported types: # HTTP-01 or TLS-ALPN-01 # See [docs/tls.md](docs/tls.md) for more information tls_letsencrypt_challenge_type: HTTP-01 # When HTTP-01 challenge is chosen, letsencrypt must set up a # verification endpoint, and it will be listning on: tls_letsencrypt_listen: ":8000" ## Use already defined certificates: tls_cert_path: "" tls_key_path: "" ``` note that `tls_letsencrypt_listen` is listening in port 8000 as headscale is running unprivileged, but I have a NAT rule to forward :80 -> :8000, and it's working as expected. ``` Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 478K 29M REDIRECT tcp -- ens5 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 /* Forward HTTP Lets Encrypt challenge traffic */ redir ports 8000 ``` I haven't found any errors on the Headscale error log regarding something wrong with Let's Encrypt, other than a bunch of: ``` Oct 06 14:01:27 ip-10-10-11-52 headscale[674566]: 2023/10/06 14:01:27 http: TLS handshake error from 66.160.133.237:40136: acme/autocert: missing server name Oct 06 14:24:26 ip-10-10-11-52 headscale[674566]: 2023/10/06 14:24:26 http: TLS handshake error from 66.160.133.234:41754: acme/autocert: missing server name Oct 06 15:07:25 ip-10-10-11-52 headscale[674566]: 2023/10/06 15:07:25 http: TLS handshake error from 66.160.133.232:43372: acme/autocert: missing server name Oct 06 15:17:10 ip-10-10-11-52 headscale[674566]: 2023/10/06 15:17:10 http: TLS handshake error from 66.160.133.242:44991: acme/autocert: missing server name ``` This was working as the Headscale node has over 200 days of uptime (hence, the certificate was renewed in the meantime) <!-- Steps to reproduce the behavior. -->
adam added the bug label 2025-12-29 02:20:28 +01:00
adam closed this issue 2025-12-29 02:20:28 +01:00
adam commented 2025-12-29 02:20:28 +01:00
Author
Owner
Copy Link

@reynico commented on GitHub (Oct 9, 2023):

It turns out that there was no CAA record for letsencrypt.org under my domain name, so Let's Encrypt wasn't able to renew the cert.

@reynico commented on GitHub (Oct 9, 2023): It turns out that there was no CAA record for `letsencrypt.org` under my domain name, so Let's Encrypt wasn't able to renew the cert.
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 bug
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#562
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?