# What's expected
Since in `acme.sh` path strings are concatenated with a hardcoded slash in between, the left operand must never end with a trailing slash for the resulting path to be valid. Otherwise, obviously, the resulting path will have two adjacent slashes in the middle and will not be valid.
# What actually happens
Even though I cannot tell for each of the input params, I know this for sure for the the `--home` argument's value.
If I run `acme.sh` with `--home` argument's value being a path ending in a trailing slash,
```sh
acme.sh ... --debug ... --home /some/path/ ... -d somedomainna.me ...
```
I get the following (distinct) occurrencies of resulting invalid paths containing two adjacent slashes:
```
[...] Using config home:/some/path/
[...] DOMAIN_PATH='/some/path//somedomainna.me'
[...] _CURL='curl --silent --dump-header /some/path//http.header -L -g '
[...] The domain key is here: /some/path//somedomainna.me/somedomainna.me.key
[...] _CURL='curl --silent --dump-header /some/path//http.header -L -g -I '
[...] Your cert is in: /some/path//somedomainna.me/somedomainna.me.cer
[...] Your cert key is in: /some/path//somedomainna.me/somedomainna.me.key
[...] The intermediate CA cert is in: /some/path//somedomainna.me/ca.cer
[...] And the full chain certs is there: /some/path//somedomainna.me/fullchain.cer
```
# Suggested fix
Trim trailing slash in `--home` argument's value from the get-go.
There might be '|' in __val (e.g., SYNO_Password), which will cause that
all content of the conf file is cleared. Fix it by escaping '|'
manually.
Signed-off-by: Adam Tao <tcx4c70@gmail.com>
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.
When performing renewals acme.sh checks key length values to determine
if a new key should be created with createDomainKey(). However, older
acme.sh stored key length as an empty value if the default of 2048 was
desired. Now it is explicit and the explict check of 2048 against "" is
causing createDomainKey() to always be called with fails without
--force.
Fix this by converting the keylength value to 2048 if an empty string is
returned from the config file. acme.sh will then write out 2048 updating
old keys and configs to the explicit version.
Issue: 4077
neilpang
PMExtra
neil
plummer86
Kiril Isakov
Adam Tao
Klaus Frank
Monius
Ian Wienand
Marcel Hellkamp
Clark Boylan