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
uacme.sh uses /bin/sh in the shebang which often forces shells such as bash into compatibility mode which interprets echo -n as literal output and thus creates an invalid challenge:
uacme: the server reported the following error:
{
"type": "urn:ietf:params:acme:error:unauthorized",
"detail": "The key authorization file from the server did not match this challenge \"tt[...]Wuo\" != \"-n tt[...]Wuo\"",
"status": 403
}
above example was produced with
$ /bin/sh --version
GNU bash, version 3.2.57(1)-release (arm64-apple-darwin20)
and the echo behavior can be checked with
$ /bin/sh -c 'echo -n'
-n
The specs say that servers SHOULD accept challenges with trailing whitespace so the easiest fix is to remove -n. A more advanced fix would be to first check that -n is safe and not use it if it's not.
The text was updated successfully, but these errors were encountered:
@ndilieto thanks for the prompt response! I can confirm this fixes the issue on macOS where printf isn an external utility so is not impacted by the shell choice (quick check suggests same is true on Linux and OpenWrt).
uacme.sh
uses/bin/sh
in the shebang which often forces shells such asbash
into compatibility mode which interpretsecho -n
as literal output and thus creates an invalid challenge:above example was produced with
and the
echo
behavior can be checked withThe specs say that servers SHOULD accept challenges with trailing whitespace so the easiest fix is to remove
-n
. A more advanced fix would be to first check that-n
is safe and not use it if it's not.The text was updated successfully, but these errors were encountered: