If a domain was already verified by http-01 method, when we try to issue a cert for them same domain with dns-01 method, we just get only one challenge object of type http-01 with "valid" status, from the authz-v3 url. So, we report error that we are not able the validate the domain, because of that we don't find dns-01 challenge.
This behavior is not the same as before. I believe it was changed by the letsencrypt CA.
If a domain was already verified by http-01 method, when we try to issue a cert for them same domain with dns-01 method, we just get only one challenge object of type http-01 with "valid" status, from the authz-v3 url. So, we report error that we are not able the validate the domain, because of that we don't find dns-01 challenge.
This behavior is not the same as before. I believe it was changed by the letsencrypt CA.
In _send_signed_request and _check_dns_entries, return 1 when the
timeout (or number of retries) has been exhausted. This allows
the calling function to correctly handle the error.
In _debug_bash_helper use eval as we are seeing issues with busybox
systems having issues with array access. Even though they aren't
actually running the code they appear to be parsing it and failing.
Also older versions of busybox have a bug with eval and double quotes,
so make sure to use single quotes when using eval.
Resolves: #2579
* support jdcloud.com
* fix format
* ttl 3000
* Escape slashes (#2375)
* Change 1.1.1.1 to 1.0.0.1 to probe compatibility (#2330)
As we can see, 1.1.1.1 is not routed or routed to an Intranet devices due to historical reason. Change 1.1.1.1 to 1.0.0.1 will have a better compatibility. I found this problem on my Tencent Cloud server.
* check empty id
* fix error
* Add dnsapi for Vultr (#2370)
* Add Vultr dns api
* PushOver notifications (#2325)
* PushOver notifications, using AppToken, UserKey, and optional sounds
* fix errors
* added dns api support for hexonet (#1776)
* update
* minor
* support new Cloudflare Token format
fix https://github.com/Neilpang/acme.sh/issues/2398
* fix wildcard domain name
* add more info
* fix https://github.com/Neilpang/acme.sh/issues/2377
* fix format
* fix format
As we can see, 1.1.1.1 is not routed or routed to an Intranet devices due to historical reason. Change 1.1.1.1 to 1.0.0.1 will have a better compatibility. I found this problem on my Tencent Cloud server.
Please remove the phrase `No news is good news.` as it suggests to decide to go on with a bad operational habit.
Why I am stating this is because that `no news` also could mean that:
- your `cron` daemon stopped working,
- your MTA has issues (in case or mail notifications of course),
- anything in between the host running `acme.sh` and your client went wrong.
(... and probably you will not notice in time if `acme.sh` would otherwise send an error notification (if it runs anyway))
If you expect a daily mail (using `--notify-level 3`) you can always be sure that `acme.sh` has ran successfully before. You can also tick the `acme.sh` checkbox in the daily operational report of your enterprise. ;)