Improved error handling when result contains data-structure which might contain another status-flag that is related to the status of the related object and not the api call
Revert "Improved error handling"
This reverts commit fa6df1cfab.
Revert "Revert "Improved error handling""
This reverts commit 5a4b78392f.
In our environment we use DNS manual mode and take the TXT record
output of acme.sh and process it with Ansible to install the records
(then we call renew later when the records have been pushed to the DNS
servers by a whole bunch of other bits).
One problem is that after getting/showing the TXT records, acme.sh
always returns 1. This makes it difficult to tell if there is
actually an error condition.
Since we have set the manual-mode flag, not installing the DNS records
is an expected correct result. This returns a separate error code for
this situation (3), which can be distinguished in automation.
Some CAs auto-validate orders based on account-level rules and do not
require a challenge at all. Sectigo introduced a non-standard challenges
named 'sectigo-dns-01', presumably to work around this issue in certbot.
This also works for non-wildcard domains in acme.sh, but wildcard domains
are rejected because acme.sh hard-codes 'dns-01' as the only allowed
challenge for wildcard domains, which is not offered by Sectigo.
This change simply moves the '"status":"valid"' check up a bit and ignores
challenge type mismatches or missing tokens if no challenge is needed anyway.