Acme.sh 3.0.5 problem and solution

Help
1

acme.sh updated to VER=3.0.5 and all my reissue started failing on all my servers, I noticed that they were trying to use zerossl even though these domains have been running file for 2 years.

~/.acme.sh/acme.sh --set-default-ca --server letsencrypt
Did not work.

I had to edit all the configuration files and by hand change the API back to lets encrypt:
from:
Le_API='https://acme.zerossl.com/v2/DV90'
to:
Le_API='https://acme-v02.api.letsencrypt.org/directory'

All the other settings were good.

Now everything is working again,

hope this helps someone.

2 Likes
2

Hi @lowerpower, and welcome to the LE community forum :slight_smile:

Thanks for the tip!

Can you add more detail on where the config files are found and their names?

4 Likes
3

v3.0.5 is currently in development and not officially released, so you probably ran acme.sh --upgrade recently?

This sounds like an issue that should have been fixed in 3.0.4 (Renew with `--renew-all` or `--cron` will always replace any domains' CA (`Le_API`) with `DEFAULT_ACME_SERVER` from global config · Issue #4069 · acmesh-official/acme.sh · GitHub), but if the renewed server was already persisted to config then yeah, that's unfortunate as that requires manual intervention.

5 Likes
4

No I configured the servers 2 years ago to automatically update acme.sh, so the software cron did it by itself. Maybe if I explicitly ran ~/.acme.sh/acme.sh --set-default-ca --server letsencrypt on the servers before the update it might of not happened I do not know.

5

in the ./acme.sh directory there is a directory for each domain, inside that directory is the conf file:

IE:
~./acme.sh/mydomain.com/mydomain.com.conf

1 Like
6

If I read the acme.sh code correctly, if --auto-upgrade is enabled, which is the default when using --upgrade (even if used just once it seems...) and a --branch is NOT set, acme.sh defaults to the git repository master branch. Which might contain unstable new code or regressions to the code.

The acme.sh repository does use a separate repository for running unit tests, but I'm not totally convinced it's got everything covered.

4 Likes
7

Osiris, wow good observation, I will check that out.

1 Like
8

You will no doubt have considered this already but for anyone else it's obviously a security risk to auto run software directly from a github repo, especially if the cron job is set to run as a privileged user. This represents a "supply chain" attack that could wipe out your system [or even worse, just infiltrate your network undetected]. Credential/token leaks do occasionally happen and if it happens to the wrong repo (there are other acme shell script clients which recommend updating via cron as well) then utter catastrophe is possible. Auto updates should at least have a signature or release version hash to confirm they are intentional and approved releases.

2 Likes
9

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.