Best tutorial for configuring acme-dns server

Help
1

Having issues configuring my acme-dns server for certbot communication. Specifically the parms in config.cfg. TIA for any suggestions.

2

The official docs should address everything you need to get up and running. What are you stuck on?

4 Likes
3

Thanks for the response, Jonathan. Specifically, trying to understand better how to configure the acme-dns instance parms.

Our chosen domain is “_acme-challenge.sample.com” (substituting sample.com for our real TLD, a.b.c.d for the public IP addr of the acme-dns server). So should this be our values:

domain = "_acme-challenge.sample.com"

nsname = "_acme-challenge.sample.com"

records = [

domain pointing to the public IP of your acme-dns server

"_acme-challenge.sample.com. A a.b.c.d",

specify that auth.example.org will resolve any *.auth.example.org records

"_acme-challenge.sample.com. NS _acme-challenge.sample.com.",

]

In our authoritative nameserver, we should delegate the stub zone and create this Address record:

_acme-challenge.sample.com in a a.b.c.d

_acme-challenge.sample.com in ns a.b.c.d

TIA.

gary

4

Please use either one of example.com, example.net or example.org as per RFC 2606 as sample.com is an actual registered domain being used by someone.

3 Likes
5

or .example if you want to go for gTLDs.

I'm not sure you're supposed to use that domain for acme-dns directly, you can't access a domain with an underscore over http. https://stackoverflow.com/a/2183140

3 Likes
6

We're not actually using "sample.com", just replacing our real domain with that for this question.

7

To be more direct: this will not work. Use something like acme.example.com or auth.example.com.

4 Likes
8

Yes, you said that. What my fellow volunteers were saying is that is a valid domain name owned and used by someone. Please don't use domain names belonging to others. Use example.com or the others instead.

3 Likes
9

We understand, but usage of the domain sample.com should not be used as such a substitute, as it's a REAL domain name.

2 Likes
10

A leading underscore is allowed in DNS labels/records, but is NOT allowed in records corresponding to DNS hostnames. You could do acme-challenge.example.com or acme-auth.example.com.

Basically the leading underscore is used to create an DNS entry that does not map to a domain - such as SRV and TXT records, though CNAMEs can use them when pointing to record types that support them.

domain = "_acme-challenge.sample.com"
nsname = "_acme-challenge.sample.com"

my functional setup is as below; i use a dedicated ns record

domain = "acme-auth.example.com"
nsname = "ns.acme-auth.example.com"
records = [
    # default A
    "acme-auth.example.com. A 1.2.3.4",
    # NS A 
    "ns.acme-auth.example.com. A 1.2.3.4",
    # NS NS
    "acme-auth.example.com. NS ns.acme-auth.example.com.",
4 Likes
11

Thanks, this is what I wanted clarification for. So in my authoritative nameserver, I would create:

ns.acme-auth.example.com in a 1.2.3.4
acme-auth.example.com in a 1.2.3.4 (delegated stub)
ns.acme-auth.example.com in ns acme-auth.example.com

Does this only need to be available in external DNS view open to CA or to all certbot clients on internal views, as well.

TIA for your assistance.

12

I assume you have a split-horizon dns setup (internal lan vs global public internet)?

It's easiest if this is viewable to all. The ACME Server needs the NS + A records to make port 53 DNS queries. Your client (Certbot) needs the A record to make the HTTP queries to the acme-dns restful API server. IIRC, it's possible to configure the client to access it under a different name (i don't think acme-dns does hostname checking), but you're highly likely to encounter weird setup issues if you do.

3 Likes
13

There is a relevant note on https://si.okiefrog.org/

2 Likes
14

Regarding "tls" parm, how should it be set? My CA is InCommon, so should I use "cert" or "none"? If cert, what FQDN should be used for the privkey?
If there are docs explaining this config better, please point me to them. TIA.

15

I don't understand this question; private keys have no tie to FQDNs (or anything in the CN/DN arena). They're just big numbers with very specific qualities.

Um, as appropriate to your installation? I don't think the docs are unclear on this:

If you want to provide your own cert, use cert. If you want acme-dns to obtain and renew its own cert, which is recommended, set it to letsencrypt.

3 Likes
16

If you have a cert for the domain already, choose “cert” and set the path with the next 2 params in the config.

If you are running it behind a service that terminates ssl, or don’t want it running TLS, “none”.

“LetsEncrypt” will obtain and manage a cert using the filepaths in the next 2 config params.

2 Likes
17

Thank you, that was the explanation I wasn't seeing in the doco. Assuming the cert dirs should be R/W for the non-priv auth-dns user? Thanks, again.

18

There's no reason acme-dns would need to write to either of those files--if you set it to cert, acme-dns is expecting some other service to provide them. It can have write permission if you like, but it isn't needed.

3 Likes