Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.
I ran this command:acme.sh --issue --dns dns_yandex --dnssleep 180 -d vadim.com.ru
It produced this output:Using CA: https://acme-v02.api.letsencrypt.org/directory
[Fri Sep 16 21:10:02 MSK 2022] Single domain='vadim.com.ru'
[Fri Sep 16 21:10:03 MSK 2022] Getting domain auth token for each domain
[Fri Sep 16 21:10:05 MSK 2022] Getting webroot for domain='vadim.com.ru'
[Fri Sep 16 21:10:05 MSK 2022] Adding txt value: 4u-BCS9QpQphe8vL5vIHYhU7a8-8Cx7I_ysWtJ6nu3g for domain: _acme-challenge.vadim.com.ru
[Fri Sep 16 21:10:08 MSK 2022] The txt record is added: Success.
[Fri Sep 16 21:10:08 MSK 2022] Sleep 180 seconds for the txt records to take effect
[Fri Sep 16 21:13:09 MSK 2022] Verifying: vadim.com.ru
[Fri Sep 16 21:13:10 MSK 2022] It seems the CA server is busy now, let's wait and retry. Sleeping 1 seconds.
[Fri Sep 16 21:13:13 MSK 2022] Pending, The CA is processing your order, please just wait. (1/30)
[Fri Sep 16 21:13:17 MSK 2022] vadim.com.ru:Verify error:During secondary validation: DNS problem: NXDOMAIN looking up TXT for _acme-challenge.vadim.com.ru - check that a DNS record exists for this domain
[Fri Sep 16 21:13:17 MSK 2022] Removing DNS records.
[Fri Sep 16 21:13:17 MSK 2022] Removing txt: 4u-BCS9QpQphe8vL5vIHYhU7a8-8Cx7I_ysWtJ6nu3g for domain: _acme-challenge.vadim.com.ru
[Fri Sep 16 21:13:18 MSK 2022] Removed: Success
[Fri Sep 16 21:13:19 MSK 2022] Please add '--debug' or '--log' to check more details.
[Fri Sep 16 21:13:19 MSK 2022] See: How to debug acme.sh · acmesh-official/acme.sh Wiki · GitHub
My web server is (include version): nginx/1.18.0
The operating system my web server runs on is (include version):TrueNAS-SCALE-22.02.3
My hosting provider, if applicable, is:
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):
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):certbot 1.12.0
It is a new server with a fresh install. I have another server running Truenas-Core 13 with let's encrypt cert on nextcloud with the same domain name
I'm also thinking you might be running into Path MTU issues, if your authoritative nameservers were working with this configuration before July 27 when Let's Encrypt made a small change, based on the DNSViz report saying that it needed to use smaller packets in order to get replies:
_acme-challenge.vadim.com.ru/A (NODATA): The server returned a no error (NOERROR) response when queried for _acme-challenge.vadim.com.ru having record data of type A, but returned a name error (NXDOMAIN) when queried for _acme-challenge.vadim.com.ru having record data of type AAAA. (2a02:6b8:0:1::213, UDP_-_EDNS0_4096_D_KN)
_acme-challenge.vadim.com.ru/A (NODATA): The server returned a no error (NOERROR) response when queried for _acme-challenge.vadim.com.ru having record data of type A, but returned a name error (NXDOMAIN) when queried for _acme-challenge.vadim.com.ru having record data of type TXT. (2a02:6b8:0:1::213, UDP_-_EDNS0_4096_D_KN)
_acme-challenge.vadim.com.ru/A (NXDOMAIN): No response was received from the server over UDP (tried 7 times) until the NSID EDNS option was removed (however, this server appeared to respond legitimately to other queries with the NSID EDNS option present). (2a02:6b8::213, UDP_-_EDNS0_4096_D_KN)
_acme-challenge.vadim.com.ru/A (NXDOMAIN): The server returned a no error (NOERROR) response when queried for _acme-challenge.vadim.com.ru having record data of type AAAA, but returned a name error (NXDOMAIN) when queried for _acme-challenge.vadim.com.ru having record data of type A. (2a02:6b8::213, UDP_-_EDNS0_4096_D)
_acme-challenge.vadim.com.ru/AAAA (NODATA): No response was received until the UDP payload size was decreased, indicating that the server might be attempting to send a payload that exceeds the path maximum transmission unit (PMTU) size. (2a02:6b8::213, UDP_-_EDNS0_4096_D_KN)
_acme-challenge.vadim.com.ru/AAAA (NODATA): The server returned a no error (NOERROR) response when queried for _acme-challenge.vadim.com.ru having record data of type AAAA, but returned a name error (NXDOMAIN) when queried for _acme-challenge.vadim.com.ru having record data of type A. (2a02:6b8::213, UDP_-_EDNS0_4096_D)
_acme-challenge.vadim.com.ru/AAAA (NODATA): The server returned a no error (NOERROR) response when queried for _acme-challenge.vadim.com.ru having record data of type AAAA, but returned a name error (NXDOMAIN) when queried for _acme-challenge.vadim.com.ru having record data of type TXT. (2a02:6b8::213, UDP_-_EDNS0_4096_D_KN)
_acme-challenge.vadim.com.ru/AAAA (NXDOMAIN): No response was received until the UDP payload size was decreased, indicating that the server might be attempting to send a payload that exceeds the path maximum transmission unit (PMTU) size. (2a02:6b8:0:1::213, UDP_-_EDNS0_4096_D_KN)
_acme-challenge.vadim.com.ru/AAAA (NXDOMAIN): The server returned a no error (NOERROR) response when queried for _acme-challenge.vadim.com.ru having record data of type A, but returned a name error (NXDOMAIN) when queried for _acme-challenge.vadim.com.ru having record data of type AAAA. (2a02:6b8:0:1::213, UDP_-_EDNS0_4096_D_KN)
_acme-challenge.vadim.com.ru/TXT (NXDOMAIN): No response was received until the UDP payload size was decreased, indicating that the server might be attempting to send a payload that exceeds the path maximum transmission unit (PMTU) size. (2a02:6b8:0:1::213, UDP_-_EDNS0_4096_D_KN)
_acme-challenge.vadim.com.ru/TXT (NXDOMAIN): The server returned a no error (NOERROR) response when queried for _acme-challenge.vadim.com.ru having record data of type A, but returned a name error (NXDOMAIN) when queried for _acme-challenge.vadim.com.ru having record data of type TXT. (2a02:6b8:0:1::213, UDP_-_EDNS0_4096_D_KN)
_acme-challenge.vadim.com.ru/TXT (NXDOMAIN): The server returned a no error (NOERROR) response when queried for _acme-challenge.vadim.com.ru having record data of type AAAA, but returned a name error (NXDOMAIN) when queried for _acme-challenge.vadim.com.ru having record data of type TXT. (2a02:6b8::213, UDP_-_EDNS0_4096_D_KN)
It's looking like your DNS servers aren't always responding correctly, at any rate, so I'd suggest first looking at ensuring they give a response worldwide correctly while the record is there.
Sleep 360 seconds for the txt records to take effect
[Fri Sep 16 21:36:37 MSK 2022] Pending, The CA is processing your order, please just wait. (1/30)
[Fri Sep 16 21:36:40 MSK 2022] vadim.com.ru:Verify error:DNS problem: NXDOMAIN looking up TXT for _acme-challenge.vadim.com.ru - check that a DNS record exists for this domain
I don't know if I'm qualified to recommend the optimal DNS provider for you. I haven't used Cloudflare myself, but yes they have a well-supported API, and I'm guessing that they have experience with MTU issues. But checking with your current DNS provider to see if they can fix any problems they have might also be a workable solution.
@petercooperjr I am getting this now: Create new order error. Le_OrderFinalize not found. {
"type": "urn:ietf:params:acme:error:rateLimited",
"detail": "Error creating new order :: too many failed authorizations recently: see Failed Validation Limit - Let's Encrypt",
"status": 429
I'll give it another day or so and then will probably move to Cloudfare
Yes, like that link says, there's a limit to how many failures you can have, but that limit gets lifted relatively quickly.
You should use the Staging Environment for testing, and by the time you've got everything sorted out you'll probably be able to get your certificate in the production environment.
I see the most recent renew was on Aug25. And, there was about 2 months where no valid cert existed after your cert from Mar23 expired. See crt.sh history here. That does not look like it was working fine.
More important, I see you are not using a wildcard cert. Have you considered using the webroot or nginx methods instead of DNS? These use the HTTP Challenge method instead which uses your working nginx server. Many times these methods are easier to use. And, maybe will not fail as often as the DNS Challenge.
Well, the HTTP challenge still needs a working DNS in order to find the server address. I'd expect it to be less reliable since it needs both the DNS and web servers to be accessible, not just the DNS server.
Maybe so. Maybe not. The update of TXT records can be more problematic than just the A record lookup. Of course, if the comms to the server is unreliable that is hard to assess with what we see.
EDIT: We've seen some odd problems with yandex in the past. Especially regarding TXT sync.
@MikeMcQ As far as renewal it was my fault - I updated the nextcloud jail via pkg system instead of original ports when installed certbot and ended up with 2 python versions on the system which got me in dependencies hell. So it took me a while to figure it all out and it was finally renewed.
Wildcard might be a better choice or even nginx, but my nextcloud is not up and running yet to my liking
