Lightsail Ubuntu api error: tlsv1 alert internal error

[gschaub]

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"

[gschaub]

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]

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?