acme.sh – Let’s Encrypt: Renewing using Le_API=https://acme.zerossl.com/v2/DV90

For a few days now, the cronjob which runs acme.sh to renew my Let’s Encrypt certificates was tossing out errors for the same two certs.

Today, I went looking in the logs.

In this post:

FreeBSD 15.0
acme.sh-3.1.3_1
hostnames have been altered to obscure those actually in use – the real reason I do this is to trigger the security by obscurity zealots

The cronjob

My cronjob looks like this:

[18:36 certs dvl /usr/local/etc/cron.d] % cat acme.sh
#
# By default, all entries in this file are commented and inactive.
# Please uncomment and customize as shown below.

# use /bin/sh to run commands, overriding the default set by cron
# uncomment, don't change the value
SHELL=/bin/sh

# mail any output to here, no matter whose crontab this is
# uncomment, set the addres
MAILTO=dan@langille.org

# uncomment, set mm and hh to the time (e.g. hh:mm) of day you want the
# cronjob to run - pick one of the following and enable it. Running more
# than one won't hurt, but you should avoid running them concurrently.
#
# the lockf ensures only one runs at a time.
# I tend to do this for most cronjobs

# This will send only errors to your email, everything else goes to /dev/null
# I find it lacks context.
# 28 17 * * * acme /usr/bin/lockf -t 0 /tmp/.acme.sh.cronjob /usr/local/sbin/acme.sh --cron --home /var/db/acme/.acme.sh > /dev/null

#
# This dumps STDERR and STDOUT to a file and should never generate an email.
# The resulting log file shows any errors in context, which I found more useful for debugging.
# I set this file to rotate daily, since the cronjob also runs daily.
# I still get email if something goes wrong, via the SAVED_MAIL_FROM and
# SAVED_MAIL_TO options in account.conf - I also use NOTIFY_HOOK='pushover,mail'
# which requires setting SAVED_PUSHOVER_TOKEN and SAVED_PUSHOVER_USER.
#
31 18 * * * acme /usr/bin/lockf -t 0 /tmp/.acme.sh.cronjob /usr/local/sbin/acme.sh --cron --home /var/db/acme/.acme.sh > /var/log/acme.sh.cronjob.log 2>&1

The logs

The logs (over in /var/log/acme.sh.cronjob.log.0)in looked something like this:

[Tue Jun  9 18:32:30 UTC 2026] Renewing: 'aws-1-pgbouncer.freshports.org'
[Tue Jun  9 18:32:30 UTC 2026] Renewing using Le_API=https://acme.zerossl.com/v2/DV90
[Tue Jun  9 18:32:30 UTC 2026] Sleeping for 10 seconds and retrying.
[Tue Jun  9 18:32:40 UTC 2026] Sleeping for 10 seconds and retrying.
[Tue Jun  9 18:32:50 UTC 2026] Sleeping for 10 seconds and retrying.
[Tue Jun  9 18:33:00 UTC 2026] Sleeping for 10 seconds and retrying.
[Tue Jun  9 18:33:11 UTC 2026] Sleeping for 10 seconds and retrying.
[Tue Jun  9 18:33:21 UTC 2026] Sleeping for 10 seconds and retrying.
[Tue Jun  9 18:33:31 UTC 2026] Sleeping for 10 seconds and retrying.
[Tue Jun  9 18:33:41 UTC 2026] Sleeping for 10 seconds and retrying.
[Tue Jun  9 18:33:51 UTC 2026] Sleeping for 10 seconds and retrying.
[Tue Jun  9 18:34:01 UTC 2026] Sleeping for 10 seconds and retrying.
[Tue Jun  9 18:34:11 UTC 2026] Cannot init API for https://acme.zerossl.com/v2/DV90
[Tue Jun  9 18:34:11 UTC 2026] Error renewing aws-1-pgbouncer.freshports.org.

That made me think: zerossl isn’t used any more, at least by me. What configuration settings do we have:

$ grep Le_API */*.conf
a.example.org/a.example.org:Le_API='https://acme-v02.api.letsencrypt.org/directory'
adguard.int.example.org/adguard.int.example.org:Le_API='https://acme-v02.api.letsencrypt.org/directory'
api.example.org/api.example.org:Le_API='https://acme-v02.api.letsencrypt.org/directory'
...

So, many certs are using https://acme-v02.api.letsencrypt.org/directory. Let’s just change the certs which are failing to renew.

$ cd /var/db/acme/certs
$ joe aws-1-pgbouncer.freshports.org/aws-1-pgbouncer.freshports.org.conf

I changed the Le_API from https://acme.zerossl.com/v2/DV90 to https://acme-v02.api.acmeencrypt.org/directory

I adjusted the next time for the cronjob. And waited. The certs renewed.

NOTE, there were other references to https://acme.zerossl.com/v2/DV90 within the file. I modified only the Le_API value.

After renewing the cert, those other values were refreshed and there were no remaining references to zerossl – the usual renewal process updates this file. Those other values were assigned to: