kchristensen
commented
4 months ago If you login to DigitalOcean and look at your DNS zone, do you see it successfully creating the temporary acme records when trying to issue a certificate?
Closed jnichel closed 4 months ago
kchristensen
commented
4 months ago If you login to DigitalOcean and look at your DNS zone, do you see it successfully creating the temporary acme records when trying to issue a certificate?
jnichel
commented
4 months ago If you login to DigitalOcean and look at your DNS zone, do you see it successfully creating the temporary acme records when trying to issue a certificate?
Thank you for the reply. Yes, the TXT record is there with a TTL of 30 seconds.
kchristensen
commented
4 months ago Odd. Can you set DNS_RESOLVER to whatever you've got set on your UDMP for DNS? You don't happen to live somewhere that blocks access to Google or Cloudflare DNS servers or anything weird, right?
kchristensen
commented
4 months ago You might also try setting DNS_RESOLVERS to whatever your ISP DNS servers are and see if that works.
kchristensen
commented
4 months ago Ah, I see what the issue is.
1) You're going to want to edit your first post and redact the URL that is prefaced with Deactivating auth since that is a log of your attempt and exposes your domain name.
2) Your domain name seems to be missing NS records:
❯ whois YOURDOMAIN.net | grep "Name Server" | head -3
Name Server: NS1.DIGITALOCEAN.COM
Name Server: NS2.DIGITALOCEAN.COM
Name Server: NS3.DIGITALOCEAN.COM❯ dig +short NS YOURDOMAIN.net
~ ❯❯❯If you create NS records on DigitalOcean for ns1/ns2/ns3 things should start working after a bit.
Edit: I do see you have an NS record set for home.YOURDOMAIN.net, but I think it is having trouble validating the _acme records based on the main zone not having NS records. That's my theory anyway.
jnichel
commented
4 months ago Your theory was correct sir. I added the NS records to the domain, waited a few minutes and ran it gain. Worked like a charm. Thank you very much.
kchristensen
commented
4 months ago Glad I could help!
Hi, as the title says, the script "could not determine authoritative nameservers" when run. I've tried with the default 127.0.0.1:53, 8.8.8.8 and 8.8.4.4 to no avail. When I ssh into a server not on the same network, I can ping my domain name and it resolves to the proper IP. Really not sure where to go at this point. My env file (with redactions) and results are below:
`#
Required configuration
#
Email for LetsEncrypt certificate issuance
CERT_EMAIL="certs@***.net"
The FQDN of your UDMP (comma separated fqdns are supported)
CERT_HOSTS="home.***.net"
Enable updating certificate keystore used by Captive Portal and WiFiman as well as device certificate
ENABLE_CAPTIVE="no"
Import only the server certificate for use with Captive Portal and WiFiman.
WiFiman requires a single certificate in the .crt file and does not work if
the full chain is imported as this includes the CA intermediate certificates.
Setting NO_BUNDLE="yes" only has effect if ENABLE_CAPTIVE="yes".
WARNING: Experimental support. Not serving the full certificate chain may result in
some clients not being able to connect to Captive Portal if they do not already have
a cached copy of the CA intermediate certificate(s) and are unable to download them.
NO_BUNDLE="no"
Enable updating Radius support
ENABLE_RADIUS="no"
Allows CNAMEs to be resolved. When true, allows resolving _acme-challenge.* in case it
has a CNAME pointing to a different domain. With this, make sure the DNS provider config
is for the provider the CNAME points to.
#
Leave this disabled if you don't know what this means as most configurations don't need it.
LEGO_EXPERIMENTAL_CNAME_SUPPORT=false
The DNS resolver used to verify records. Change this to a public DNS resolver if you have
modified your UDM's upstream DNS servers to point to an internal resolver that is the
authoritative name server for any domain that you are trying to request certificates for.
DNS_RESOLVER="127.0.0.1:53"
DNS_RESOLVER="8.8.4.4"
#
DNS provider configuration
See README.md file for more details
#
Digital Ocean
Note: Quoting your DO_AUTH_TOKEN below seems to cause issues
DNS_PROVIDER="digitalocean" DO_AUTH_TOKEN=**
#
Change stuff below at your own risk
#
DNS_RESOLVERS supports a host:port if you need to override system DNS
DNS_RESOLVERS=""
Changing below requires changing line 7 of udm-le.sh, as well as the paths within systemd service files
UDM_LE_PATH="/data/udm-le"
LetsEncrypt Configuration
LEGO_VERSION="4.11.0" LEGO_SHA1="41fb3736156ed6d42fba551127905c834e5b0ab0" LEGO_DOWNLOAD_URL="https://github.com/go-acme/lego/releases/download/v${LEGO_VERSION}/lego_v${LEGO_VERSION}_linux_arm64.tar.gz" LEGO_BINARY="${UDM_LE_PATH}/lego" LEGO_PATH="${UDM_LE_PATH}/.lego"
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_CONTROLLER_CERT_PATH="/data/unifi-core/config" UBIOS_RADIUS_CERT_PATH="/data/udapi-config/raddb/certs" UNIFIOS_CERT_PATH="/data/unifi-core/config" UNIFIOS_KEYSTORE_PATH="/usr/lib/unifi/data" UNIFIOS_KEYSTORE_CERT_ALIAS="unifi" UNIFIOS_KEYSTORE_PASSWORD="aircontrolenterprise" `
Results of attempt: