You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I tried to issue a new certificate today, but I messed up my nginx config so the issuing failed initially. Subsequent attempts also failed, but after staring at the debug log a bit, it seemed to me that it was an issue with acme.sh.
The debug log makes the issue pretty clear.
[Wed Dec 27 10:49:00 UTC 2023] _idn_temp
[Wed Dec 27 10:49:00 UTC 2023] _candidates='cloud.arborusgroup.com,{"identifier":{"type":"dns","value":"example.com"},"status":"invalid","expires":"2024-01-26T09:37:10Z","challenges":[{"type":"http-01","url":"https://acme.zerossl.com/v2/DV90/chall/X_zibH7gBsX9FDpNLsKPvw","status":"invalid","error":{},"token":"O4-YzxyoyvzhVw54KSGFCIZSXyvG2RW_B_rKOshx5CE"}]}#https://acme.zerossl.com/v2/DV90/authz/h60LmUF30XYAqWDFop_azg'
[Wed Dec 27 10:49:00 UTC 2023] response='{"identifier":{"type":"dns","value":"example.com"},"status":"invalid","expires":"2024-01-26T09:37:10Z","challenges":[{"type":"http-01","url":"https://acme.zerossl.com/v2/DV90/chall/X_zibH7gBsX9FDpNLsKPvw","status":"invalid","error":{},"token":"O4-YzxyoyvzhVw54KSGFCIZSXyvG2RW_B_rKOshx5CE"}]}#https://acme.zerossl.com/v2/DV90/authz/h60LmUF30XYAqWDFop_azg'
[Wed Dec 27 10:49:00 UTC 2023] _authz_url='https://acme.zerossl.com/v2/DV90/authz/h60LmUF30XYAqWDFop_azg'
[Wed Dec 27 10:49:00 UTC 2023] entry='"type":"http-01","url":"https://acme.zerossl.com/v2/DV90/chall/X_zibH7gBsX9FDpNLsKPvw","status":"invalid","error":{'
[Wed Dec 27 10:49:00 UTC 2023] token
[Wed Dec 27 10:49:00 UTC 2023] Error, can not get domain token "type":"http-01","url":"https://acme.zerossl.com/v2/DV90/chall/X_zibH7gBsX9FDpNLsKPvw","status":"invalid","error":{
The extracted variable entry from response is not correct. It gets cut off right on the closing brace of the error:{ JSON object.
The problem is that the regex _egrep_o '[^\{]*"type":"'$vtype'"[^\}]*' can not properly handle the error objects, because it starts looking for the first closing } after finding the type of challenge that was requested. This is problematic when the challenge entry itself contains an object which, of course, needs to be terminated with a } leading to this unintended behavior.
I would have submitted a PR to fix this, but I just could not figure out a good way to extract the entry with regex when the error object can be arbitrarily complex.
The error can be arbitrarily complex, because the ACME RFC specifies:
error (optional, object): Error that occurred while the server was
validating the challenge, if any, structured as a problem document
[RFC7807]. Multiple errors can be indicated by using subproblems Section 6.7.1. A challenge object with an error MUST have status
equal to "invalid".
And Section 6.7.1 gives a good example of a possible arbitrarily complex error object
{
"type": "urn:ietf:params:acme:error:malformed",
"detail": "Some of the identifiers requested were rejected",
"subproblems": [
{
"type": "urn:ietf:params:acme:error:malformed",
"detail": "Invalid underscore in DNS name \"_example.org\"",
"identifier": {
"type": "dns",
"value": "_example.org"
}
},
{
"type": "urn:ietf:params:acme:error:rejectedIdentifier",
"detail": "This CA will not issue for \"example.net\"",
"identifier": {
"type": "dns",
"value": "example.net"
}
}
]
}
If anyone has a good idea for how to deal with these error objects that would fit into the codebase, I'd be happy to write it out and submit a PR.
The text was updated successfully, but these errors were encountered:
Please upgrade to the latest code and try again first. Maybe it's already fixed. acme.sh --upgrade If it's still not working, please provide the log with --debug 2, otherwise, nobody can help you.
… validation types
Fix for empty error objects in the response which mess up the extraction of domain validation types due to the closing brace in the error object prematurely matching the end of the search pattern.
This seems to be a recent change with ZeroSSL in particular where "error":{} is being included in responses.
There could potentially be a related issue if there is a complex error object ever returned in the validation check response where an embedded sub-object could lead to an incomplete extraction of the error message, roughly around line 5040.
Adapted from fix suggested here: acmesh-official#4933 (comment)
I tried to issue a new certificate today, but I messed up my nginx config so the issuing failed initially. Subsequent attempts also failed, but after staring at the debug log a bit, it seemed to me that it was an issue with acme.sh.
The debug log makes the issue pretty clear.
The extracted variable
entry
fromresponse
is not correct. It gets cut off right on the closing brace of theerror:{
JSON object.acme.sh/acme.sh
Lines 4693 to 4718 in afacdfc
The problem is that the regex
_egrep_o '[^\{]*"type":"'$vtype'"[^\}]*'
can not properly handle the error objects, because it starts looking for the first closing}
after finding the type of challenge that was requested. This is problematic when the challenge entry itself contains an object which, of course, needs to be terminated with a}
leading to this unintended behavior.I would have submitted a PR to fix this, but I just could not figure out a good way to extract the entry with regex when the error object can be arbitrarily complex.
The
error
can be arbitrarily complex, because the ACME RFC specifies:And Section 6.7.1 gives a good example of a possible arbitrarily complex
error
objectIf anyone has a good idea for how to deal with these
error
objects that would fit into the codebase, I'd be happy to write it out and submit a PR.The text was updated successfully, but these errors were encountered: