Open ianw opened 1 year ago
The logs for the issue (called by https://opendev.org/opendev/system-config/src/branch/master/playbooks/roles/letsencrypt-acme-sh-install/files/driver.sh#L45) and the renewal (called by https://opendev.org/opendev/system-config/src/branch/master/playbooks/roles/letsencrypt-acme-sh-install/files/driver.sh#L108) are below
This issue also breaks deploy scripts which currently rely on the correct folder name (folder name = certname). When using ECC-Certificates the folder name is changed to 'certname_ecc'. The deploy scripts report
[Fri Jan 6 12:54:50 UTC 2023] The domain 'example.com' is not a cert name. You must use the cert name to specify
the cert to install.
[Fri Jan 6 12:54:50 UTC 2023] Can not find path:'/acme.sh/example.com'
At a first glance manually renaming the folder name seems to solve this part of the issue.
@hoewer which deploy script did you use ?
@ianw sorry, but can you please try again with the latest dev code, I have fixed such kind of bugs recently.
acme.sh --upgrade -b dev
@Neilpang Sorry for the missing information. I'm using the Synology DSM deploy hook.
I have acme.sh running in a github action and because of the file path changes it almost broke our renewal pipeline. It's a fresh install of acme.sh each time and it started to default to ecc scripts in a different directory which didn't get packaged up correctly.
Install into the github action container is
wget -O acme.sh https://raw.githubusercontent.com/acmesh-official/acme.sh/master/acme.sh
Had to add a -k 2048
to force it back to RSA to get a renewal going.
@ianw sorry, but can you please try again with the latest dev code, I have fixed such kind of bugs recently.
acme.sh --upgrade -b dev
Apologies for the lengthy delay in response. I help manage the same systems as @ianw originally found this in, and we believe we're still seeing the same behavior which is blocking our attempts to upgrade from 3.0.5 to 3.0.6. Is running from the dev branch still a useful test at this point?
@hoewer Obtaining a list of domains should be done via acme.sh --list
possibly using specific info from acme.sh --info --domain domain.example
. However, one should limit reliance on acme.sh's internal structure, as it's changed before and may again. If you mainly need the certificate files, use an acme.sh --install-cert ... --reloadcmd ...
command to get and deploy them, even if that's only to temporary location before their actual deployment.
Change https://github.com/acmesh-official/acme.sh/commit/ec0e871592d286b8cd4e1d407411f0ba17c775e6 appears to break manual mode renewals.
What happens is that we run the issue step, and see
I think what happens is
_initpath
sets that up by using theisEccKey
functionWith https://github.com/acmesh-official/acme.sh/commit/ec0e871592d286b8cd4e1d407411f0ba17c775e6 the length is now marking this as a ECC key, and thus changing the
DOMAIN_PATH
.This issue is made, we get our TXT records to install into DNS and acme.sh exits. We install the records using our automation tools, then come back to run the
renew
step.What should happen then is that the domain
.conf
file should be read, where theLe_Vlist
will be set with the required tokens, and acme.sh will then attempt to authenticate the records and issue the certificate.However, the
renew
function gets called from the command-line parserwhere
$_ecc
is only set from the command-line flag; e.g.Thus the renewal path is now ends up setting the
DOMAIN_PATH
with no_ecc
; we see in the logs for the renewalThe renewal then falls into
Now the
Le_Vlist
is empty -- because it's using the wrongDOMAIN_PATH
directory, and it falls into themake new order request
part and tries to re-authenticate the domain again.In general, I'm not sure this change is backwards-compatible because of the way
ecc
keys have been separated out into a separate directory. It seems like this will mean that everyone will start creating keys in<domain>_ecc
by default, which is not where they are expected to be?