Removing domains from certificate

Hello everyone and happy christmas :slight_smile:

I have a Let's Encrypt certificate with many "Alternative names". Some of these domains should no longer be included since they no longer are being handled by me. I have tried to find a guide on how to do this but have not found one yet.

The domains I want to remove have been using the certificate to (amongst other things) access on-premise Exchange, Nextcloud etc on my servers. They have now moved to MS365.

My certificate is up for renewal and I would very much like to remove the domains prior to renewing the certificate or is the safest route to simply ignore that the domains now are handled by someone else?


You may not want to ignore the domains you are no longer control of. Your ACME client might try to renew the certificate having all the domains you had at the previous issuance. However, it is not possible to give proof of ownership of all the domains any more, so the issuance of the whole certificate will fail.
I suggest to verify the documentation of your ACME client; how to decommission the domains in question from the configuration of the certificate?


@bruncsak - Thanks for your help! I am running certbot.

What is the best way of doing it?

I've seen "certbot remove domain" and "certbot delete" mentioned, or should one use:

certbot --cert-name -d


1 Like

Sorry, I am not using certbot, I use my own client. I do not know what is the appropriate way to handle with certbot. May be someone else could help you? There are many certbot experts here on the forum.

1 Like

Certbot doesn't have an option to easily remove hostnames from a certificate. The most commonly provided """solution""" (personally, I think it's more a workaround of an omission of certbot) is to re-issue the certificate like you did the first time, but now without the hostnames you want to remove.

You can also use the --allow-subset-of-names option, but you need to be careful with that. It will remove ANY hostname from the certificate which failed validation. That can either be because you aren't the owner of the hostname any longer (which is OK and why you want to use this option) or because something else went wrong with a hostname you DO want to include in the cert (which is BAD of course). You can run certbot renew first without the option and analyse the output thoroughly. If you're certain only hostnames you want removed from the certificate are failing, you can run the renew command again but now with the --allow-subset-of-names option, resulting in a certificate without the failing hostnames.


@Osiris - thanks for your help!

I tried a dry-run; here is the output:

root@certbot:~# certbot renew --dry-run Saving debug log to /var/log/letsencrypt/letsencrypt.log

Processing /etc/letsencrypt/renewal/

Simulating renewal of an existing certificate for and 47 more domains

Certbot failed to authenticate some domains (authenticator: standalone). The Certificate Authority reported these problems:
Type: unauthorized
Detail: Invalid response from Sign in to Outlook []: "\r\n\r\n\r\n\r\n<html dir="ltr" class="" lang="en">\r\n<h"

Type: unauthorized
Detail: Invalid response from Sign in to Outlook []: "\r\n\r\n\r\n\r\n<html dir="ltr" class="" lang="en">\r\n<h"

Hint: The Certificate Authority failed to download the challenge files from the temporary standalone webserver started by Certbot on port 80. Ensure that the listed domains point to this machine and that it can accept inbound connections from the internet.

Congratulations, all simulated renewals succeeded:
/etc/letsencrypt/live/ (success)


Perhaps I can simply ignore and just run

certbot renew

and use the new cert generated? I think this is what I did the last time I was in this situation....


Not sure how the dry-run would be successful with those failures? Unless you already have --allow-subset-of-names set somewhere, perhaps in your cli.ini?


This is also a bit troublesome:


@Osiris - I dont think I am using any cli.ini....

root@certbot:~# cd /

root@certbot:/# find . -name 'cli.ini'




1 Like

@rg305 - None of the settings have been changed the last year or so...probably even longer. We've had no issues. We allways renew cert manually. We still should consider changing something?

(I've "inherited" this certbot-setup so Im pretty new to all of this still)

1 Like

Then could you perhaps share the contents of the renewal configuration file /etc/letsencrypt/renewal/ ?


I would consider automating the whole process.


@Osiris - yes, you are correct:

root@certbot:/# cat /etc/letsencrypt/renewal/

version = 1.22.0
archive_dir = /etc/letsencrypt/archive/
cert = /etc/letsencrypt/live/
privkey = /etc/letsencrypt/live/
chain = /etc/letsencrypt/live/
fullchain = /etc/letsencrypt/live/

account = 672exxxxxxxxxxxxxxxxxxxxxxxxxxx
authenticator = standalone
server =
allow_subset_of_names = True

As for what this mean though, I am afraid I do not have enough knowledge....

1 Like

@rg305 - ah, yes - I see what you mean and I would very much prefer this. The challenge however for us is that the certificate that is generated around every 90 days is "inserted" manually into a firewall for which we have no way to automate unfortunately.

1 Like

It means any failing hostname, for whatever the reason, will be removed from the certificate on renewal. So if there's some kind of temporary hick-up when validating a hostname, important hostnames could be removed and the site could be without a functioning certificate.


Thanks again @Osiris for your time and help.

Ok, just to make sure I dont misunderstand; as long as we have "allow_subset_of_names" set to "True" all domains that fails for any reason will be removed from the certificate when we run a renew.

This is unproblematic as long as the only failing domains are domains I want removed.

If a domain I want to stay inside the certificate also fails (for any reason) it will also be removed and will render services for this domain unusable.


If so .... if a domain gets removed that I didnt want removed; is it hard to add it again when the "hick-ups" are gone?

(I understand best-practise probably is to set "allow_subset_of_names" to "False" and reissue the certificate without the hostnames I want to remove)


Correct. Any failing hostname will be removed from the certificate on renewal.


Correct. Running --dry-run of course lets you detect most of those things though, although production and staging aren't 100 % equal.

You'd need to re-run the initial certbot command again with all options and hostnames. Certbot doesn't have a function to add a single hostname to an already existing certificate. Just like it doesn't have a feature to remove one. A shame if you'd ask me, but it was decided against it, "because --cert-name was implemented, so it wasn't necessary any longer" or something like that.

Personally, I would remove the option from the renewal configuration file, but I'd use it manually on the command line as an option. First I'd use --dry-run to check if everything else works, then I would try to renew it without the --allow-subset-of-names option, so every non-failing hostname would get validated. That way those validations would be cached as valid and as long as they are cached (30 days at the moment), they can't fail. (Note that a valid validation using --dry-run is not enough, as that run would be on the staging environment.) After running certbot renew without the --allow-subset-of-names option and be certain only hostnames I want removed from the cert are failing, I'd repeat the certbot renew command but now with --allow-subset-of-names. Et voila, a renewed certificate.
Perhaps that would make it add the allow_subset_of_names option to the renewal configuration file again, so you'd have to remove that from the config file again.


Thanks again @Osiris !

Hmm...this was done by a former colleague. Is there a way to "dig it up"/"reconstruct" now so long after?


The renewal configuration file would give you the most information (used authenticator and installer [if applicable]). The hostnames can be found using the certbot certificates command.


This intrigues me...
Can you give any more details on this?

1 Like