Error running initial command > "could not find the start of authority for _acme-challenge.MYDOMAIN.com"

[joergbattermann]

Hi there,

I have an UDM Pro with the 1.8.0 firmware, set up the .env file using my cloudflare api token (with the specified token permissions) but I do get the following errors:

# /mnt/data/udm-le/udm-le.sh initial
Attempting initial certificate generation
2020/11/28 12:05:04 [INFO] [jbedge.mydomain.com] acme: Obtaining bundled SAN certificate
2020/11/28 12:05:05 [INFO] [jbedge.mydomain.com] AuthURL: https://acme-v02.api.letsencrypt.org/acme/authz-v3/123456789
2020/11/28 12:05:05 [INFO] [jbedge.mydomain.com] acme: Could not find solver for: tls-alpn-01
2020/11/28 12:05:05 [INFO] [jbedge.mydomain.com] acme: Could not find solver for: http-01
2020/11/28 12:05:05 [INFO] [jbedge.mydomain.com] acme: use dns-01 solver
2020/11/28 12:05:05 [INFO] [jbedge.mydomain.com] acme: Preparing to solve DNS-01
2020/11/28 12:05:45 [INFO] [jbedge.mydomain.com] acme: Cleaning DNS-01 challenge
2020/11/28 12:06:25 [WARN] [jbedge.mydomain.com] acme: cleaning up failed: cloudflare: could not find the start of authority for _acme-challenge.jbedge.mydomain.com.: read udp 1.2.3.4:53531->8.8.8.8:53: i/o timeout
2020/11/28 12:06:25 [INFO] Deactivating auth: https://acme-v02.api.letsencrypt.org/acme/authz-v3/123456789
2020/11/28 12:06:25 Could not obtain certificates:
        error: one or more domains had a problem:
[jbedge.mydomain.com] [jbedge.mydomain.com] acme: error presenting token: cloudflare: could not find the start of authority for _acme-challenge.jbedge.mydomain.com.: read udp 1.2.3.4:53991->8.8.8.8:53: i/o timeout

The .env file looks like this:

#
# Required configuration
#

# Email for LetsEncrypt certificate issuance
CERT_EMAIL='jb@mydomain.com'

# The FQDN of your UDMP (comma separated fqdns are supported)
CERT_HOSTS='jbedge.mydomain.com'

# Enable updating Captive Portal certificate as well as device certificate
ENABLE_CAPTIVE='no'

# CloudFlare settings, see the README.md for information about other providers
# Note: Quoting your CLOUDFLARE_DNS_API_TOKEN below seems to cause issues
CLOUDFLARE_DNS_API_TOKEN=MYAPITOKEN
DNS_PROVIDER='cloudflare'

#
# Change stuff below at your own risk
#

# DNS_RESOLVERS supports a host:port if you need to override system DNS
DNS_RESOLVERS='8.8.8.8:53'

# Changing below requires changing line 6 of udm-le.sh
UDM_LE_PATH='/mnt/data/udm-le'

# These should only change if Unifi-OS core changes require it
CERT_IMPORT_CMD='java -jar /usr/lib/unifi/lib/ace.jar import_key_cert'
UBIOS_CERT_PATH='/mnt/data/unifi-os/unifi-core/config'
UNIFIOS_CERT_PATH='/data/unifi-core/config'

(replaced the personal domain/ids/ips/API Token with placeholder values)

I am a bit confused - this is basically a stock UDM Pro with no adjustments to the default firewall so I am a bit confused re: that I/O Error.. I can perform manual nslookups etc on the shell.. so maybe I am missing something and/or would somebody have any idea what's wrong here?

Thanks for any ideas/suggestions and especially thanks to @kchristensen for this project! 👍🏻

[kchristensen]

Odd, do you use mydomain.com for other things? Does dig +short SOA mydomain.com return the Cloudflare nameserver you expect it to?

Maybe try not setting DNS_RESOLVERS and see what happens?

[joergbattermann]

The domain itself (mydomain.com) is used for other things as well and i've added an A entry at cloudflare for the jbedge.mydomain.com pointing to the UDMs internal ip (192.168.0.1) here.

SOA wise the domain is referring to cloudflare, yeah:

mydomain.com has SOA record nash.ns.cloudflare.com. dns.cloudflare.com. 2035855280 10000 2400 604800 3600

And I already had tried with and without any DNS_RESOLVERS .. :-/

However, while writing this.. might it be a problem that the full domain (jbedge.mydomain.com) is pointing to said UDM's lan / internal IP? Maybe I just did that part wrong..

[kchristensen]

Just throwing this out there in case it helps -- I had someone else reach out to me about an issue similar to this where lego couldn't resolve the SOA for the domain they were using. After some back and forth I started to think it might be an MTU related issue and on their own they figured out that it was their modem causing issues.

They replaced their modem with a different model that had support for changing the MTU and it worked (even without them having to muck about with the MTU). I'm not necessarily suggesting you run out and buy a new modem but apparently this is an issue with some ISPs.

[SamErde]

The domain itself (mydomain.com) is used for other things as well and i've added an A entry at cloudflare for the jbedge.mydomain.com pointing to the UDMs internal ip (192.168.0.1) here. ... However, while writing this.. might it be a problem that the full domain (jbedge.mydomain.com) is pointing to said UDM's lan / internal IP? Maybe I just did that part wrong..

You're correct, the Cloudflare A record should not be pointing to an internal IP address. Do you have a static IP from your ISP, or do you have dynamic DNS setup?

On the CERT_HOSTS line of the .env file, you need to actually include the FQDN (full hostname) of your UDM. If you access it internally using UDM.JBEDGE.MYDOMAIN.COM, then you will want it to contain:

CERT_HOSTS='UDM.JBEDGE.MYDOMAIN.COM'
or:
CERT_HOSTS='UDM.JBEDGE.MYDOMAIN.COM,*.J BEDGE.MYDOMAIN.COM'

Then, make sure that you are able to resolve that FQDN from your local network to the internal/private IP of the UDM (192.168.0.1).