How do I properly remove domains from certbot's renewal efforts?

I manage a pair of servers that host around 50 or so domains, most with subdomains, and, of course things change with time. And when I renew certs, I get "renewal failure(s)" warnings that are about known changes. And, of course, sometimes I get these warnings and the reason isn't immediately known.

I'd like to remove the spurious warnings so I can better notice the things I have to pay attention to.

Sometimes these changes are a domain name that was dropped entirely, and sometimes it's a change that, for whatever reason(s) has caused certbot to add in a numerical suffix of the form -0001, for example.

I have read warnings about just deleting stuff that's found in /etc/letsencrypt. ... OK, so what's the right way?

That is sign that something hasn't gone to plan and should be corrected.

"How do I properly remove domains from certbot's renewal efforts?"
The most common way [when you know a name must be removed from a cert] is to use:

But I think you should consider using more certs [combining only names that need to be combined].
Keeping track of which names were added and which names have been removed to ensure the cert renews with the correct set of names does not scale well.


@stwm The three main things you'll need to know about are:

  • Use certbot certificates to view all of your certificate names and coverage (you might already be doing this).
  • Use --cert-name when requesting a new certificate to specify which existing certificate it should replace. Make sure to specify every name (with -d) that you want to be included in the new certificate, because the new certificate will contain exactly the names given with -d, and no others. (The way that -0001 certificates end up being created is by requesting overlapping coverage to an existing certificate, including intentionally removing names, or even omitting a single existing name, but without specifying --cert-name; Certbot refuses to decrease the coverage of an existing certificate at all when --cert-name is not specified, so it will create a new separate certificate under a different name in this case.)
  • If a particular certificate is completely redundant and is not referenced in your web server configuration, use certbot delete to delete it completely from /etc/letsencrypt.

Or other services using it, such as mailservers et cetera!


@rg305 Thanks for the suggestion to use --allow-subset-of-names. I'll check into it.

@schoen Your last bullet point is exactly what I was looking for, your middle one is VERY helpful - now I know WHY it does this. And your first one ... Of course!

I've got some cleanup to do based on both of these imput.


RIGHT, Osiris! We do use these web-created certificates for other purposes, especially email.


Make sure the certificate(s) marked for deletion aren't used anywhere any longer :wink:


Now that I've done the needed cleanup, and now that I know what causes the numeric suffixes to be created and how to avoid that; how do I go about "cleaning up" the various numerically suffixed paths, so I have an easier time with the various config files that use the certs?

That is, now that I have removed all the "overlap", I'd like to "reset" the paths to be:


instead of:


...I'm guessing I have two choices:

  1. Delete these certs entirely (via certbot delete) and recreate the certs as if for the first time, or;

  2. Rename the paths "by hand" - after all, the certs ARE valid at the moment.

I also guess the first method is the official strategy, but the second could work, though I don't have a clue if certbot keeps track of what was there formerly and therefore would break somehow.

Yeah, stay away from option #2.


There are like 4 different things that you would have to change in unison in order to rename a certificate, and if you miss one you can get a configuration that confuses Certbot and prevents proper renewals. So yeah, it's not really recommended to attempt that...


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