[GH-ISSUE #317] Lightsail Ubuntu api error: tlsv1 alert internal error #169

New issue

Open

opened 2026-03-13 16:02:13 +03:00 by kerem · 2 comments

kerem commented

2026-03-13 16:02:13 +03:00

Owner

Originally created by @gschaub on GitHub (Oct 3, 2022).
Original GitHub issue: https://github.com/acme-dns/acme-dns/issues/317

I am trying to configure acme-dns on a lightsail Ubuntu instance and I have a "tlsv1 alert internal error" return. As I dug into this, it appears that this can be caused by listening on port 53 for a non-public facing IP. This is where I believe lightsail is adding to my challenges. My understanding is that I need to update the listen address from loopback to public, either directly or via wildcard.

I get a dns conflict with systemd.resolvd when supplying a wildcard (0.0.0.0:53) because the 127.0.0.1 is already open with resolv. Lightsail directly exposes the internal IP address and I can configure that address, the service starts fine, but I get the error above when testing the api. Finally, the sevice will not start when I use the public assigned IP address through lightsail (listen udp4 107.22.246.55:53: bind: cannot assign requested address).

There could well be other issues with the configuration, but the errors I'm seeing appear to match this particular one. I will include my config.cfg below in case there are issues there with most of the comments removed. Really appreciate any help I can get with this issue.

Regards...Greg

[general]
# NOTE THIS IS THE INTERNAL IP ADDRESS BOUND TO eth0
listen = "172.26.2.101:53"
protocol = "both4"
domain = "theschaubs.com"
nsname = "theschaubs.com"
nsadmin = "web-master.theschaubs.com"
records = [
    # domain pointing to the public IP of your acme-dns server
    # NOTE THIS IS THE EXTERNAL IP ADDRESS
    "theschaubs.com. A 107.22.246.55",
    # specify that auth.example.org will resolve any *.auth.example.org records
    "theschaubs.com. NS theschaubs.com.",
]
debug = true

[database]
engine = "sqlite3"
connection = "/var/lib/acme-dns/acme-dns.db"

[api]
ip = "0.0.0.0"
disable_registration = false
port = "4443"
tls = "letsencryptstaging"
# only used if tls = "cert"
#tls_cert_privkey = "/etc/tls/example.org/privkey.pem"
#tls_cert_fullchain = "/etc/tls/example.org/fullchain.pem"
# only used if tls = "letsencrypt"
acme_cache_dir = "api-certs"
notification_email = "webmaster.theschaubs.com"
# CORS AllowOrigins, wildcards can be used
corsorigins = [
    "*"
]
use_header = false
header_name = "X-Forwarded-For"

[logconfig]
loglevel = "debug"
logtype = "stdout"
logformat = "text"

Originally created by @gschaub on GitHub (Oct 3, 2022). Original GitHub issue: https://github.com/acme-dns/acme-dns/issues/317 I am trying to configure acme-dns on a lightsail Ubuntu instance and I have a "tlsv1 alert internal error" return. As I dug into this, it appears that this can be caused by listening on port 53 for a non-public facing IP. This is where I believe lightsail is adding to my challenges. My understanding is that I need to update the listen address from loopback to public, either directly or via wildcard. I get a dns conflict with systemd.resolvd when supplying a wildcard (0.0.0.0:53) because the 127.0.0.1 is already open with resolv. Lightsail directly exposes the internal IP address and I can configure that address, the service starts fine, but I get the error above when testing the api. Finally, the sevice will not start when I use the public assigned IP address through lightsail (listen udp4 107.22.246.55:53: bind: cannot assign requested address). There could well be other issues with the configuration, but the errors I'm seeing appear to match this particular one. I will include my config.cfg below in case there are issues there with most of the comments removed. Really appreciate any help I can get with this issue. Regards...Greg ``` [general] # NOTE THIS IS THE INTERNAL IP ADDRESS BOUND TO eth0 listen = "172.26.2.101:53" protocol = "both4" domain = "theschaubs.com" nsname = "theschaubs.com" nsadmin = "web-master.theschaubs.com" records = [ # domain pointing to the public IP of your acme-dns server # NOTE THIS IS THE EXTERNAL IP ADDRESS "theschaubs.com. A 107.22.246.55", # specify that auth.example.org will resolve any *.auth.example.org records "theschaubs.com. NS theschaubs.com.", ] debug = true [database] engine = "sqlite3" connection = "/var/lib/acme-dns/acme-dns.db" [api] ip = "0.0.0.0" disable_registration = false port = "4443" tls = "letsencryptstaging" # only used if tls = "cert" #tls_cert_privkey = "/etc/tls/example.org/privkey.pem" #tls_cert_fullchain = "/etc/tls/example.org/fullchain.pem" # only used if tls = "letsencrypt" acme_cache_dir = "api-certs" notification_email = "webmaster.theschaubs.com" # CORS AllowOrigins, wildcards can be used corsorigins = [ "*" ] use_header = false header_name = "X-Forwarded-For" [logconfig] loglevel = "debug" logtype = "stdout" logformat = "text" ```

kerem commented

2026-03-13 16:02:19 +03:00

Author

Owner

@gschaub commented on GitHub (Oct 4, 2022):

All - Good news: I believe I have resolved part of the issue by stopping the systemd.resolved service and manually editing the resolv.conf file.

Bad news: I still have the same (or related) issue. I retested and got the same error. Syslog has the following (apparently) related error: http: TLS handshake error from 107.22.246.55:53446: no certificate available for 'theschaubs.com'"

I would think it expected that there is no certificate available because I am creating an initial certificate. Therefore, the error doesn't make sense to me. Any help in deciphering and troubleshooting this would be wonderful.

@gschaub commented on GitHub (Oct 4, 2022): All - Good news: I believe I have resolved part of the issue by stopping the systemd.resolved service and manually editing the resolv.conf file. Bad news: I still have the same (or related) issue. I retested and got the same error. Syslog has the following (apparently) related error: http: TLS handshake error from 107.22.246.55:53446: no certificate available for 'theschaubs.com'" I would think it expected that there is no certificate available because I am creating an initial certificate. Therefore, the error doesn't make sense to me. Any help in deciphering and troubleshooting this would be wonderful.

kerem commented

2026-03-13 16:02:24 +03:00

Author

Owner

@gschaub commented on GitHub (Oct 17, 2022):

Okay - I'm one step closer. It appears that tls = "none" is required if you do not already have a certificate (i.e., you are registering and Letsencrypt and do not already have a certificate on the server). When doing so, the protocol changes to http from https and the api then works.

I was able to register acme-dns, get a cname, have certbot issue the txt (with the api properly populating it in acme-dns). Great so far.

However, Certbot cannot access that txt record. It physically lives in the acme-dns database and dig works properly, returning the records. I validated this from both the host and an external computer. Can anyone help me to understand and resolve the this issue?

@gschaub commented on GitHub (Oct 17, 2022): Okay - I'm one step closer. It appears that tls = "none" is required if you do not already have a certificate (i.e., you are registering and Letsencrypt and do not already have a certificate on the server). When doing so, the protocol changes to http from https and the api then works. I was able to register acme-dns, get a cname, have certbot issue the txt (with the api properly populating it in acme-dns). Great so far. However, Certbot cannot access that txt record. It physically lives in the acme-dns database and dig works properly, returning the records. I validated this from both the host and an external computer. Can anyone help me to understand and resolve the this issue?