Q: How to exclude domains from acme.sh renewal?

[GwynethLlewelyn]

Hello all! 👋

I have the following dilemma: on my Ubuntu 24.04.2 LTS (bare metal, octa-core Intel CPU with 64 GB of RAM), I have a few dozens of websites, managed with the open-source control panel ISPConfig3, which supports acme.sh natively (and it's even the recommended option and set as the default mechanism for issuing/renewing Let's Encrypt certificates).

acme.sh resides in its 'standard' directory, e.g. /root/.acme.sh.
The certificates are all stored under /etc/letsencrypt/<domain.name> or /etc/letsencrypt/<domain.name>_ecc for recently issued (or re-issued) ECC keys. In practice, I have symbolic links to make sure everything goes into the 'right' directory.

Over the years, a handful of domain names have been discarded/discontinued/paused/whatever. At any time, however, they may be restored — I just don't know when (or if) that will happen.

As such, these domains, websites, users, mailboxes, etc. are in 'hibernation', so to speak: the configuration, the files, everything is in place, but all that is prevented from working: nginx doesn't load any associated websites, postfix discards any emails sent or received to the mailboxes of those domains, dovecot refuses access to the mailboxes (while keeping them around!), ssh/sftp explicitly disallows any user from logging in, and so forth, one by one, for all other services.

So far, the only exception I found was acme.sh (one of the latest modules to have been integrated). It continues patiently to try to renew all those domains, one by one. Naturally enough, all will fail the renewal, as expected; even if I use a DNS API (which I usually do for all domains, anyway), my external DNS provider (Cloudflare), lacking any specific configuration for those domains, naturally will also reject any API calls. That part of the configuration works without flaws.

But why bother contacting Let's Encrypt at all? If the domains are down, let the keys expire. Save some bandwidth and CPU power (on LE's side!) by avoiding any external calls!

Now, the automation software running by ISPConfig3 removes /etc/letsencrypt/<hibernated.domain.name> correctly. And, as far as I can tell from looking at the source code, that is the only place where acme.sh deploys a <domain.name>.conf file — is that correct? As such, if those directories have been removed, acme.sh will never contact the Let's Encrypt servers again, right?

Unfortunately, that does not seem to be the case. acme.sh is still attempting to renew those certificates. Somehow, somewhere, it has stashed the configuration files for these domains and is still finding it. However, I'm pretty sure that such a configuration file is not present; neither under /root/.acme.sh, nor under the whole /etc hierarchy!

So... where does its data come from?

[Neilpang]

that is the only place where acme.sh deploys a <domain.name>.conf file — is that correct? As such, if those directories have been removed, acme.sh will never contact the Let's Encrypt servers again, right?

Yes, if the conf is remove, it should never be renewed.

[GwynethLlewelyn]

Huh... right, @Neilpang, that totally makes sense... I wonder, then, where acme.sh is finding those discontinued/hibernating domains, then. Note that it has plenty of information on them, namely, it 'knows' that these domains can only be renewed using the DNSAPI (as said, to Cloudflare), and the error they get is related to issues in adding new DNS entries (because Cloudflare obviously refuses to change anything on domains that are not under their control!) and/or setting up the usual web-based validation (because my own software has shut those websites down at the nginx level). acme.sh is acting 'as if' all these domains (well, they aren't that many) were still active, but... there is nothing there!

After doing some locate'ing, I noticed that I had some experimental versions spread around, leftovers of the time I was tinkering with acme.sh to get proper key rotation on TLSA records (for DANE compliance...). These have been superseded by current-generation versions of acme.sh that, allegedly, do all the work correctly, so my changes are pretty much useless at this stage and I can delete them on my server as well. Who knows, maybe any of those 'experiments' I had lying around interfered with the 'main' script (I don't really know how that could happen, but... who knows? A missing semicolon somewhere, and that might have triggered them...).

Let's see if this happens again in the near future, and, if it doesn't, I'll close this thread and assume your answer is correct.
Thanks for the help!