After spending two days by reading docs and trying, it seems I am not getting some basics. We own nemuh.cz domain. We do not have access to primary name servers of that domain, but we have acme challenge record: _acme-challenge.nemuh.cz CN proxy.nemuh.cz. DNS server on proxy.nemuh.cz is accessible from internet and it is under our control via nsupdate. We need to generate certificates for the nemuh.cz domain (machine.nemuh.cz, *.nemuh.cz ...). Is this configuration correct for the letsencrypt automatism? Becuase I can not get acme.sh to work - tried it many ways, various options, but I can not get over (external?) DNS record verification.
Thanks, Michal
My domain is: nemuh.cz
I ran this command: ./acme.sh --log --issue --dns dns_nsupdate -d test.nemuh.cz --dnssleep 10 --server letsencrypt
It produced this output:
Wed Dec 13 09:03:16 CET 2023] Using CA: https://acme-v02.api.letsencrypt.org/directory
[Wed Dec 13 09:03:16 CET 2023] Single domain='test.nemuh.cz'
[Wed Dec 13 09:03:16 CET 2023] Getting domain auth token for each domain
[Wed Dec 13 09:03:18 CET 2023] Getting webroot for domain='test.nemuh.cz'
[Wed Dec 13 09:03:18 CET 2023] Adding txt value: soJ9lQZTJGOWJS_R5PxiLLid1zLKiTMZNLapjXCMuCA for domain: _acme-challenge.test.nemuh.cz
[Wed Dec 13 09:03:18 CET 2023] adding _acme-challenge.test.nemuh.cz. 60 in txt "soJ9lQZTJGOWJS_R5PxiLLid1zLKiTMZNLapjXCMuCA"
[Wed Dec 13 09:03:18 CET 2023] The txt record is added: Success.
[Wed Dec 13 09:03:18 CET 2023] Sleep 10 seconds for the txt records to take effect
[Wed Dec 13 09:03:29 CET 2023] Verifying: test.nemuh.cz
[Wed Dec 13 09:03:29 CET 2023] Pending, The CA is processing your order, please just wait. (1/30)
[Wed Dec 13 09:03:33 CET 2023] Invalid status, test.nemuh.cz:Verify error detail:DNS problem: NXDOMAIN looking up TXT for _acme-challenge.test.nemuh.cz - check that a DNS record exists for this domain
[Wed Dec 13 09:03:33 CET 2023] Removing DNS records.
[Wed Dec 13 09:03:33 CET 2023] Removing txt: soJ9lQZTJGOWJS_R5PxiLLid1zLKiTMZNLapjXCMuCA for domain: _acme-challenge.test.nemuh.cz
[Wed Dec 13 09:03:33 CET 2023] removing _acme-challenge.test.nemuh.cz. txt
[Wed Dec 13 09:03:33 CET 2023] Removed: Success
[Wed Dec 13 09:03:33 CET 2023] Please check log file for more details: /home/letsencrypt/.acme.sh/acme.sh.log
My web server is (include version): does not matter
The operating system my web server runs on is (include version): Red Hat Enterprise Linux release 8.9 (Ootpa)
In review of your claim...
I don't think you have everything as you claim, nor as you would need.
In short: I don't see any DNS zone delegation for "proxy.nemuh.cz".
In long:
There is only a CNAME.
The name "proxy.nemuh.cz" may point to an IP you control.
But DNS challenges go directly to the authoritative DNS servers [not to the IP] .
The authoritative DNS servers for "proxy.nemuh.cz" are the same as "nemuh.cz".
[which you already stated that you have no control over]
TLDR; You need to control the DNS server - not the IP that the CNAME points to.
certificate generation is failing for whole domain too:
./acme.sh --log --issue --dns dns_nsupdate -d "nemuh.cz" --dnssleep 10 --server letsencrypt
[Wed Dec 13 09:30:20 CET 2023] Using CA: https://acme-v02.api.letsencrypt.org/directory
[Wed Dec 13 09:30:20 CET 2023] Single domain='nemuh.cz'
[Wed Dec 13 09:30:20 CET 2023] Getting domain auth token for each domain
[Wed Dec 13 09:30:22 CET 2023] Getting webroot for domain='nemuh.cz'
[Wed Dec 13 09:30:22 CET 2023] Adding txt value: S0kvwhrofZ_3q7LaX87C2dtB2xBfynEZFjHOIieXmM4 for domain: _acme-challenge.nemuh.cz
[Wed Dec 13 09:30:22 CET 2023] adding _acme-challenge.nemuh.cz. 60 in txt "S0kvwhrofZ_3q7LaX87C2dtB2xBfynEZFjHOIieXmM4"
[Wed Dec 13 09:30:22 CET 2023] The txt record is added: Success.
[Wed Dec 13 09:30:22 CET 2023] Sleep 10 seconds for the txt records to take effect
[Wed Dec 13 09:30:33 CET 2023] Verifying: nemuh.cz
[Wed Dec 13 09:30:34 CET 2023] Pending, The CA is processing your order, please just wait. (1/30)
[Wed Dec 13 09:30:37 CET 2023] Invalid status, nemuh.cz:Verify error detail:No TXT record found at _acme-challenge.nemuh.cz
[Wed Dec 13 09:30:37 CET 2023] Removing DNS records.
[Wed Dec 13 09:30:38 CET 2023] Removing txt: S0kvwhrofZ_3q7LaX87C2dtB2xBfynEZFjHOIieXmM4 for domain: _acme-challenge.nemuh.cz
[Wed Dec 13 09:30:38 CET 2023] removing _acme-challenge.nemuh.cz. txt
[Wed Dec 13 09:30:38 CET 2023] Removed: Success
[Wed Dec 13 09:30:38 CET 2023] Please check log file for more details: /home/letsencrypt/.acme.sh/acme.sh.log
So it means I really can not generate certificates for machines without (acme_challenge) records in our public name servers automatically? No way to use letsencrypt automatism for internal servers? I thought the _acme-challenge for whole domain was intended to do exactly this - to redirect of any certificate generation DNS challenge queries for that domain to this DNS server.
To "redirect" DNS requests you need to use delegation - not CNAME.
Again, in another way:
TXT records are resolved in the DNS zone.
CNAMEs for TXT records only change which DNS server is responsible for the request
CNAMEs for TXT records won't directly change the authoritative name servers responsible
I ask you to provide me with the drivers license of your spouse.
You say: Go to my uncles' house that is where they are now.
I go to your uncles house and ask who for what?
I don't ask you uncle for his drivers license.
I don't ask your uncle for your spouses license either [as they shouldn't have it].
I start by asking your uncle if I can speak with your spouse.
Then I ask them for the license I need.
In the same way, LE needs to see a TXT entry in the DNS zone that contains the challenge response code for the name being requested [plus the prepended _acme-challenge.].
You've placed a [CNAME] sign at that location that states "we've moved to this other location: proxy.nemuh.cz".
LE sees the sign and follows it to the new location.
LE now needs to look for a TXT entry in the DNS zone that controls this new name.
[which are the exact same nameservers as before - the CNAME did not do what you thought it would]
So... If I register us on acme-dns.io and set
_acme-challenge.nemuh.cz. CNAME blahablah.auth.acme-dns.io
and I will be creating the challenge records in blahablah.auth.acme-dns.io, it will work for anything under nemuh.cz? *.nemuh.cz, machine.nemuh.cz?
OK, it seems I should have started with different question: is LE able to create certificates for machines without any records in public DNS? If not, then we should find another CA or rethink our certificate policy (eg use domain wildcards on internal servers).
Yes; But they must be names from a domain you control.
Names from REAL domain names.
Not anything like:
localhost
my.madeup.servername
some.random.name.fortesting
That said, you MUST create a matching TXT record for the name requested.
So, indirectly you must have a record in public DNS - not an IP for the name - a TXT record for it.
All publicly trusted CAs need some way to validate the hostname contained in a certificate. These hostnames need to be publicly accessible somehow. Whether that's with an IP address pointing to a webserver or a publicly reachable DNS server (either delegated using CNAME RRs or NS RRs or not), that doesn't matter.
Publicly trusted CAs are not allowed to issue certificates for non-public hostnames as mentioned by Rudy.
For the first I thank you for the work you do for internet commununity. Excuse my English, please, I am not native speaker. But I believe I understand what you say and I have two notes to what you are claiming.
We do (did) have acme_challenge record (CNAME) in our official domain DNS record pointing to publicly accessible DNS server (proxy.nemuh.cz). It is just not the official NS for our/any domain. I believe this IS SOMEHOW publicly accessible hostname (or publicly possible way how to verify we own the domain and/or the hostname at least). But it is probably a way you consider being not secure enough. I do not see why CNAME to ANY official public DNS server, beeing not related and/or authoritative for our original domain or hostnames in any way, is to be more secure - it is only more complicated, from my point of view. But OK, I have no problem with that, I just was not getting it right.
And we do have certificates for our internal hostnames (under nemuh.cz), not accessible from public internet, from other publicly trusted CA.
CNAMEs [of TXT records] don't point to DNS servers.
A CNAME points one name to another name.
All names must be resolved from their authoritative name servers.
The fact that the server at that IP is a DNS server is not relevant.
There will be no DNS request to the CNAMEd IP.
Yes, but it was just command line for one of my many tries. And for the CNAMEd DNS server -our own server- it was ok, the new records were not propagated anywhere.
I am not arguing with you
I am just trying to explain how I originally understood it. And it was: _acme-challenge.domain.com CNAME (record in official domain DNS) leads right to DNS server, where the certificate challenge records for the domain are to be verified.
Easy, simple, logical. For me. I was wrong.
Oh, my bad, this is rather embarrassing Yes, it is opened to internet (now), because I was trying to use it as the challenge DNS server. The internal 10. address should not be visible, of course.
