Replies: 1 comment 6 replies
-
|
You should use |
Beta Was this translation helpful? Give feedback.
-
|
Another thing I don't quite understand is why |
Beta Was this translation helpful? Give feedback.
-
|
I think you are behind a firewall, or you are using something that interacts with DNS calls.
If, when you use ACME is an RFC, not a server. The goal of the propagation check is to wait before asking the ACME server (Let's Encrypt) to ensure the record availability when the ACME server does the challenge. |
Beta Was this translation helpful? Give feedback.
-
By default, lego checks ANS (Authoritative Nameservers) and RNS (Recursive Nameservers).
If you are not using |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for the clarification! It puzzles me that certbot works but lego doesn't, even if it's the same DNS setup and test environment. As I'm not familiar with the details of either tool, I'll dig deeper another time. |
Beta Was this translation helpful? Give feedback.
-
It's because certbot doesn't check the propagation; it just uses a sleep. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Welcome
What did you expect to see?
Check the delegated nameserver instead of the "main" nameserver during the DNS record propagation check step. (#1597 similar issue?)
Details: Assume I own
example.comand wait to obtain a certificate fortest.i.example.com. Due to security concerns around API access, I delegatedi.example.comfrom provider A to Cloudflare by creating NS records fori.example.com. I tried to obtain a certificate fortest.i.example.comvia the dns-01 challenge using the commandlego --dns cloudflare --domains "test.i.example.com" --email someone@example.com --dns.resolvers 1.1.1.1:53 run. However,legostuck at "acme: Waiting for DNS record propagation." and timed out 2 minutes later, reporting that it could not find the TXT record for_acme-challenge.test.i.example.comon the nameserver from provider A. The same error is observed when using NixOS'ssecurity.acmesetting instead of lego cli.Update 1: Tried the latest Docker image, same error.
Update 2: Tried
--dns.propagation-disable-ans=truebut consistently got the error of "invalid authorization: acme: error: 400 :: urn:ietf:params:acme:error:dns :: DNS problem: NXDOMAIN looking up TXT for _acme-challenge.test.i.example.com - check that a DNS record exists for this domain".With this option on, I didn't see any pause to wait for DNS propagation. So I suspect the ACME server checked the record before the update is propagated. That's why my current workaround is
--dns.propagation-wait 10s.Debug effort: I tried
dig @1.1.1.1 _acme-challenge.test.i.example.com TXTand it returned the correct result. I also triedcertbot, which can successfully obtain the certificate.Current workaround: Use the
--dns.propagation-wait 10sflag to skip the propagation check and hope that 10s is enough for propagation.What did you see instead?
Follow the NS records of
i.example.comto retrieve DNS records from Cloudflare instead of provider A, and successfully obtain the certificate.How do you use lego?
Docker/Binary
Reproduction steps
example.comon Cloudflare.i.example.comto Cloudflare by adding correspondingNSrecords.example.comwith theDNS:Editpermission.legowithlego --dns cloudflare --domains "test.i.example.com" --email someone@example.com --dns.resolvers 1.1.1.1:53 run.Effective version of lego
lego version 4.22.2 linux/amd64Logs
(Sensitive information is removed or redacted.)
Go environment (if applicable)
N/A.
Beta Was this translation helpful? Give feedback.
All reactions