Acme-DNS Locally Hosted

Help
1

My domain is:

mydomain.us (not actual domain but same format)

I ran this command:

sudo certbot certonly -d "*.mydomain.us" -d "mydomain.us" --agree-tos --manual-public-ip-logging-ok --server https://acme-v02.api.letsencrypt.org/directory --preferred-challenges dns --manual --manual-auth-hook /etc/letsencrypt/acme-dns-client --debug-challenges --dry-run

It produced this output:

Certbot failed to authenticate some domains (authenticator: manual). The Certificate Authority reported these problems:
Domain: mydomain.us
Type: unauthorized
Detail: No TXT record found at _acme-challenge.mydomain.us

Domain: mydomain.us
Type: unauthorized
Detail: No TXT record found at _acme-challenge.mydomain.us

Hint: The Certificate Authority failed to verify the DNS TXT records created by the --manual-auth-hook. Ensure that this hook is functioning correctly and that it waits a sufficient duration of time for DNS propagation. Refer to "certbot --help manual" and the Certbot User Guide.

Some challenges have failed.
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.

My web server is (include version):

Nginx

The operating system my web server runs on is (include version):

Raspberry Pi Debian

My hosting provider, if applicable, is:

Google domains

I can login to a root shell on my machine (yes or no, or I don't know):

Yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel):

No

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):

Certbot 1.18.0

Additional info:

Basically i am trying to run my own local acme-dns server which i have attempted to run both locally on the same server as my domain as well as through my nginx reverse proxy at acme.mydomain.us

In both cases i can successfully update my locally ran acme dns server with username and txt, as witnessed in command prompt output live as certbot is called.

For whatever reason, certbot is not reading text files from my local acme dns instance. I realize i could do a call to an existing acme-dns server but have been bullheaded in my instance on running my own local server.

My DNS is through google domains and looks like the following:

*.mydomain.us IN CNAME mydomain.us

_acme-challenge.mydomain.us. IN CNAME 729f8f2e-f8c5-4b23-a0e2-8605d3e77cb7.acme.mydomain.us.

www.mydomain.us. IN CNAME mydomain.us

mydomain.us. IN A [SOMEPUBLICIP]

The acme-dns instance has been called via acme-dns-auth.py from acme-dns-certbot-joohoi/acme-dns-auth.py at master · joohoi/acme-dns-certbot-joohoi · GitHub
As well as from acme-dns-client from GitHub - joohoi/acme-dns-client-1: A client software for https://github.com/joohoi/acme-dns
with identical results. I can register values inside my acme-dns instance and i cannot call the stored TXT files from it at 729f8f2e-f8c5-4b23-a0e2-8605d3e77cb7.acme.mydomain.us

In fact, whenever i enable acme-dns instance i typically cannot resolve acme.mydomain.us.

I have attempted to store acme.mydomain.us. as an A record in my Google DNS with no avail.

My acme-dns config (/etc/acme-dns/config.cfg) that is running on a second local server instance looks like this:

[general]

DNS interface. Note that systemd-resolved may reserve por># In this case acme-dns will error out and you will need to># for example: listen = "127.0.0.1:53"

listen = "127.0.0.1:53"

protocol, "both", "both4", "both6", "udp", "udp4", "udp6">protocol = "both"

domain name to serve the requests off of

domain = "mydomain.us"

zone name server

nsname = "acme.mydomain.us" # admin email address, where @ is substituted with .
nsadmin = "admin.mydomain.us"

predefined records served in addition to the TXT

records = [

domain pointing to the public IP of your acme-dns ser>

"acme.mydomain.us. IN A [SOMEPUBLICIP] ", "ns1.acme.mydomain.us. IN A [SOMEPUBLICIP] ",

debug = false

[database]

Database engine to use, sqlite3 or postgres

engine = "sqlite3"

Connection string, filename for sqlite3 and postgres://$u>

Please note that the default Docker image uses path /var/>connection = "/home/ubuntu/mydatabase.db"

#connection = "/var/lib/acme-dns/acme-dns.db" # connection = "postgres://user:password@localhost/acmedns_>
[api]

listen ip eg. 127.0.0.1 ip = "0.0.0.0"

disable registration endpoint

disable_registration = false

listen port, eg. 443 for default HTTPS

autocert_port = "80"
port = "771"

possible values: "letsencrypt", "letsencryptstaging", "ce>tls = "none"

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

TL;DR

Can't read stored TXT records in ACME-DNS generated example.acme.mydomain.us addresses. Suspect DNS issue or port issue or nginx forwarding issue, have attempt 5 days of fixing this with no avail, attempted local install of ACME-DNS on webserver and no difference in ability to resolve acme-dns instance generated subdomains. Please help.

acme-dns-client check or list all return proper credentials stored and CNAMES properly resolving, but this specific check does not query for the TXT record and that is what is not resolving.

1 Like
2

Note that you can format config files etc by using multiple backticks ` around the content which makes it easier to read.

acme-dns questions are best directed to GitHub - joohoi/acme-dns: Limited DNS server with RESTful HTTP API to handle ACME DNS challenges easil

Yes you do either need to disable any other service using port 53, or use a different port and forward UDP/TCP port 53 requests to that other port.

You can test basic DNS responses using dig @your-acme-dns-ip examplename , that way you know acme-dns is responding on port 53 (tcp and udp) before trying to use it with an acme client.

Regarding firewalls, only your client needs to be able to talk to the acme-dns server on http/https ports, but port 53 tcp/udp must be open to the world and forwarded to the correct server for public DNS challenge response validation.

3 Likes
3

I am amazed that some people here are generous enough with their time and patience to entertain "problems" like this.

2 Likes
4

Thank you for your kind response.

I just tried editing my original posts with the ticks and couldn't get that to format better, my apologies.

I guess i am simply stuck at reading from my acme-dns generated subdomain, I cant figure out why i can't read it, i have tried multiple methods such as creating A record in google DNS pointing to my subdomain, i have set and reset my acme-dns to listen on 127.0.0.1:53 and various permutations such as 0.0.0.0:53. I am able to register and update it via custom port 881, but just am not able to get a txt record served at example.acme.mydomain.us from my local server via dig or by using google dig tools.

Is this an instance where i would have set up something like DNS over TLS to serve my acme-dns instance, or am i just overthinking this? Both are on the same public ip but are distinct servers with their own local ip addresses, or i can run acme-dns on the one server running my main domain.

When i register my domain with https://auth.acme-dns.io i have no issues. In hindsight, you are correct and i should have posted in acme-dns github. If i don't find a solution here i will be reposting there. I would appreciate any further direction if you have it, however.

1 Like
5

Yeah it's not easy. I built Certify DNS (a cloud hosted managed acme-dns compatible service) because configuring and running your own acme-dns is often harder than just setting up and maintaining just a web server, but the concept is still pretty good.

You first need to validate that your acme dns works locally when you query it for DNS, that rules out basic ports being open on the server. Then you need to make sure that public DNS queries on port 53 (UDP or TCP) are forwarded to your server (public DNS queries work). For your own acme-dns to work you also generally need to have an NS record in your domain DNS to delegate serving a subdomain (like auth.yourdomin.com) so that DNS queries for x.auth.yourdomain.com go to your acme-dns server (not just your normal DNS).

2 Likes
6

Link ? :wink: I had no idea!

2 Likes
7

If you are comfortable running your own acme-dns that's still the best option :slight_smile: but for everyone else it's very useful.

3 Likes
8

I run my own acme-dns for production, but wow this would be great for dev usage. I may end up buying a subscription just for that.

Our production systems only enable dns traffic and the acme-dns server during acme order processing. We don’t have the resources to properly monitor and safeguard it as a 24/7 service, but it’s fine for ephemeral usage.

For development/internal domains, we have a manual process to procure certs - which basically involves signaling a production system to enable acme-dns for a moment. Since these domains are internal use only and nested subdomains and we sandbox cookies, I would not have a problem delegating their namespace to a third party.

3 Likes
9

Cool! Well it's free for now while it's in beta (it's been running for a couple of months) thereafter it will be some low monthly subscription most likely billed via any of the major cloud provider marketplaces (so you can add it to an existing cloud account).

It's an independent implementation using a combination of cloudflare workers, google data store + functions, (UDP/TCP) load balancing and a custom dns service on an auto scaling cluster. The dns layer is sacrificial and intended to be abused/crushed by all the random internet traffic it receives (famous last words!).

2 Likes
10

Sounds like the business plan my local dealer has :rofl:

Note: just a joke, I don't do drugs besides ethanol :wink:

3 Likes
11

Yes indeed. It's definitely a for profit service, I have enough hobbies already, I don't need more of those :slight_smile:

2 Likes
12

You should try this stuff called "schadenfreude". It is absolutely exhilarating, though highly addictive.

3 Likes
13

What is this "happiness at the misfortune of others" of which you speak? Do you have samples?

:upside_down_face:

1 Like
14

it's honestly the best hashtag on every social network.

2 Likes
15

Aren't there plenty of those in this forum to keep you joyful all day long?

Call the train authorities... this topic has been derailed.

2 Likes
16

We're back on track now!

:train:

1 Like
17

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.