Confirm process for removing domain from certificate

Help
1

My domain is: enfeedia.com

I ran this command:
I ran an 'expand' with all current domains listed except deliberately left two out, to remove them from certificate. Notice "remove" is the intention.

It produced this output:
Dry-run concluded showing two certificates:

  1. the original cert named enfeedia.com showed all domains (i.e. including the two I omitted in the expand process)
  2. Another cert named enfeedia.com-0001 which lists them all except the two domains not listed that I want removed. Perfect.

I can login to a root shell on my machine (yes or no, or I don't know): yes
The version of my client is: certbot 1.11.0

I'm looking for confirmation that all I need to do is delete the original certificate named enfeedia.com to finish the job. (FWIW, I previously deleted the vhost entries for the two domains and rebooted server, and in so doing, proved the domains were no longer trusted by the browser.) I will be transferring ownership of the two domains to another party, and want to make sure that not owning the domains, all my remaining domains are still covered by the new enfeedia.com-0001 certificate.

Seem quite obvious, but I'm skittish about all-things certificates.

I will appreciate confirmation that I'm safe, that deleting the original enfeedia.com certificate doesn't have some nasty side effects.

2

Show:
certbot certificates

4 Likes
3

We nor Certbot can confirm that for you. It ultimately depends on which services using a certificate are using which certificate exactly.

4 Likes
4

Let me re-phrase:

I did this process: I used --expand with a current domain list except left out the one I wanted removed. Now I will delete the original certificate such that the new certificate is the only certificate I have.

Is that the logical equivalent of directly deleting a domain from a certificate by using cert-only (I guess) where, as I understand it, makes the change to that cert without creating a new one?

By logical equivalent, I mean they have the same end results to the 'state' of the certificates. Chose one approach or the other, it makes no difference.

The reason I think that must be true is because I think the documentation would include some warning or contrast the two ways, how they are the same and how they differ.

Thank you again.

1 Like
5

It is not possible to change a Let's Encrypt cert once it is issued. Adding or deleting a domain requires issuing a new cert with the new set of names.

I have never seen someone use Certbot --expand to remove domain names from a cert. I didn't test it myself and the docs describe a different use (link here).

Removing obsoleted names is sometimes done with --allow-subset-of-names but care must be taken to not remove domain names unintentionally.

You created a new cert with the -0001 which use different file names. Any of your services (like web servers) must now reference those new names.

Before deleting a cert you should refer to this:
https://eff-certbot.readthedocs.io/en/stable/using.html#safely-deleting-certificates

3 Likes
6

If I remember correctly, the only meaning of --expand is to suppress some interactive prompts in some situations; it isn't required (or forbidden) when replacing a certificate with one containing either more or fewer names.

However, if you don't use --cert-name to require Certbot to replace the old certificate with the new smaller one, then you get the -0001 certificate. (Perhaps unfortunately, it doesn't even print a warning about the existing related certificate, it just makes the new -0001 one.)

Deleting the old certificate is fine and appropriate if you're not using it any more, but

This is the key point: you might have configurations of other things that reference the old location (i.e. without the -0001), which would need to be updated to the new location (with the -0001), if they haven't been, before deleting the old version.

4 Likes
7

Well, you would know such internals better than me :slight_smile:

The docs say this

--expand
If an existing certificate is a strict subset of the requested names, always expand and replace it with the additional names. (default: Ask)

So, perhaps this means when --expand meets this criteria the prior cert file name is used without having to specify --cert-name. Is that it?

3 Likes
8

Yes, I think that's it. But note that the converse is not true: if the existing certificate is not a subset of the requested names, you will always get a -0001 certificate even if you specify --expand, and even if the names mostly overlap, unless you also specify --cert-name (which might be counterintuitive).

4 Likes
9

I appreciate the discussion, but find myself still uncertain.

The new -0001 cert is a subset of the original one, because of one domain being intentionally left out of the list.

I didn't make up using --expand to produce a subset. I read that on a previous thread on this forum about certbot, essentially that it's a legit way to eliminate one or more domains from the cert. There was no mention that a new cert being created.

I do acknowledge that the documentation of --expand is for adding domains, makes no mention of using it for eliminating domains, and no warnings about making a mistake of leaving a domain off the list. There's lengthy documentation so I might have missed that.

It seems deleting the original cert is OK because the new cert covers all domains I want (the listing upon conclusion of a --dry-run process lists each cert showing the expected domains), and go forward with the -0001 cert. But shoens's comment " Any of your services (like web servers) must now reference those new names " puzzles me. I thought doing the certbot process took care of everything, meaning nothing more for me to do.

What do I do? Where do I locate places where I reference a certificate? Perhaps when I see the answer, I will realize I'm having a brain fart.

My case seems rather simple. Need and have 14 domains under one cert. The original had 16 (I simplified the discussion, didn't want the domain and www subdomain for the same domain mess up the discussion). All domains are registered with GoDaddy.

It will kill me if transferring ownership of the domain to another party causes a browser "don't trust this site" error in users trying to open one of my remaining sites. I believe that deleting the original cert will solve the problem because it would be nowhere to be found. But a failure of me to take some action to make the new cert "in effect" or "active" with a disastrous result is keeping me awake.

BTW,
MikeMcQ says " It is not possible to change a Let's Encrypt cert once it is issued. Adding or deleting a domain requires issuing a new cert with the new set of names."
and also says " Removing obsoleted names is sometimes done with --allow-subset-of-names but care must be taken to not remove domain names unintentionally" implies a new cert is not created. Contradictory?

Sorry I'm not smarter about this. I am where I am, with a new cert and an original one I want disappeared, and believing there's nothing more for me to do.

Always thankful for the wisdom of others!

10

It might or it might not, depending on how you're using Certbot. We don't have enough information to say for certain. It's always a good idea to doublecheck before deleting a certificate.

No, just a matter of definition. Sometimes "certificate" is meant for different things. E.g., the certificate file cannot be changed: once signed it's "fixed" and any change to the certificate would invalidate the signature. However, often a certificate "entry" in Certbot (see the output of certbot certificates is also called "a certificate", even though at every renewal, the certificate file is updated, by default even with a new private key. But for reference to what is known to Certbot, it's often also called "a certificate", even when not speaking about a single certificate file strictly. Can be confusing at times indeed, especially for beginners.

3 Likes
11

misinformation...

Definitely NOT the case.

If you are not exactly sure of where that cert has been used, then I'd stick with reusing the same cert name [delete the -0001 - it can't be renamed (easily)]

There is no way for anyone outside of your system to be sure about that.

That is the right approach.
It may be possible to combine the two - and remove while adding names.
If not, then remove the names first [keeping the same cert-name].
Then add the new names last [keeping the same cert-name].

3 Likes
12

For example, they might be references in /etc/nginx if you use nginx, or /etc/apache2 or /etc/httpd if you use Apache, or elsewhere in /etc if you use some other server application. The server application has to be told through its configuration files which certificate files to use when receiving a TLS connection.

Certbot does have some ability to edit these files for you (specifically in the Apache and nginx cases; not for other kinds of server applications), which is why you don't necessarily have to edit them yourself when originally getting a certificate with Certbot, but it might not always get it right and might not always understand your configuration.

4 Likes
13

Good stuff.

My plan:

  1. Delete the newly created one (-0001).
  2. Carefully remove the obsoleted names from the original one using allow-subset-of-names. That means the cert name does not change (right?).

Therefore I don't need to track down wherever the cert is referenced because things have been going swimmingly with that cert.

So more broadly, nothing else for me to do. Great!

(BTW, just an aside, I use apache. I removed the vhost code blocks corresponding to the domain being dropped. And rebooted the server. No impact to websites that I am continuing with. The one being dropped, in which I updated to have just a simple hello word comment, results in "This Connection Is Not Private" in browser. But that's not satisfying in the sense of not updating the certificate because I still would not know what happens when the new owner builds a site with the same domain name. Feels like a bomb would go off.)

Yes, I'm a beginner. Who appreciates support like this.

Honestly, I will be shaking like a dry leaf on a tree on a windy day, hoping to hang on, when I do the above.

1 Like
14

The new owner cannot use your "old" cert with all those names because they do not have the matching private key for it. Only you have that (it's the privkey.pem from Certbot).

They can get a new cert that has just that transferred domain name and they will get a new private key for that. The public DNS will point to their server which will send out just this new cert and private key. They have no access to the cert files on your server.

3 Likes
15

hmm...
I must have read too fast or forgot what I had read too quickly - LOL
I thought you wanted to remove some AND also add some other names.
If only removing, yeah - you should be AOK with those steps.

2 Likes
16

We often discourage people from using --allow-subset-of-names because it reduces the certificate coverage based on whatever happens at the time of validation, which is to say both expected reasons (that domain name no longer exists or no longer points at that server!) and unexpected reasons (that domain name is misconfigured or had a temporary unexpected outage!). Unfortunately we don't have a "check for failures but only act on expected failures" feature. :slight_smile:

However, you could use --allow-subset-of-names and check what happened afterward (with certbot certificates) and make sure that the new certificate coverage is exactly what you expect it to be.

3 Likes
17

I'm removing only, not adding.

Please help me here, when you say I should be AOK with those steps. Please point me those steps.

18

The steps you listed:

3 Likes
19

@rg305... about those steps, color me embarrassed.

I have more confusion. Should I in fact be deleting the new one or is it the operative one. The sites work, so one of them is. How can I tell? I don't want to delete the operative one. I include this question in my "Summing Up" below, no need to answer that here.

This was referred to me by MikeMcQ:
Before deleting a cert you should refer to this:
User Guide — Certbot 2.2.0 documentation
Just so you know, deleting is not trivial (for me). Indeed I will (need to) follow that once I know which to delete.

But if the original is the operative one, then I should delete the new one. Do I follow those same instructions regardless of which cert I'm deleting?

Additionally, my step two of my plan calls for using --allow-subset-of-namesafter [carefully] deleting the new cert. And schoen discourages people from using --allow-subset-of-names explaining the reasons. It feels like I have to try it and then see if it worked -- something like that -- but that carries the risk of shutting down my customer websites. Even if I hadn't started this whole process by using --expand and used --allow-subset-of-names instead, I would still face that scary proposition.

I just have to say, It seems logical that if I can add a domain to a cert using --expand and keep the same cert name, then why can't --expand be used to remove a domain and keep the same cert name? I guess the answer is: that's just the a way it is, accept it.

Summing up:

1: Which cert is the operative one that is keeping my sites up? I already removed the Apache vhost block for the domain I'm wanting to dump. Should I reinstate the vhost block to see whether that gets the unwanted domain working again? Will that definitively tell me which cert is the operative one?

2: If it's the original, can I just delete the new one -0001 without going through the self-signed certificate process in the User Guide? Then fearlessly use --allow-subset-of-names to remove the unwanted domain in the original cert? Or is here a less scary way to remove a domain name from a cert? "Scary" because I would probably panic if it failed. I have customers who would be "disappointed".

3: If it's the -0001 cert, and all is in fact working, can I just delete the original cert without going through the self-signed certificate process in the User Guide? That would mean I wouldn't have to do --allow-subset-of-names because the unwanted domain is not included in the new cert.

Thank you for not giving up on me.

1 Like
20

I'd say this is a defect, or at least a confusing point, in Certbot's design from back in the mid-2010s. Roughly speaking, adding names to a certificate makes it "better" and removing names makes it "worse". Because of this asymmetry, we over-optimized for the case of adding names (making Certbot do it relatively automatically and in a relatively convenient and unsurprising way) while under-optimizing for the case of removing names (making Certbot never do it automatically, and initially not even having an official way to do it at all).

Compounding this, we wanted it to always be possible to run Certbot non-interactively (where it wouldn't be able to ask the user for help or guidance about what to do), which also encouraged only implementing features that have some sensible default option in the face of ambiguity. One might say that reducing a certificate's name coverage (and replacing the old larger certificate with the new smaller one) does not have such a sensible default available, which also discouraged us from implementing that.

Finally, without --cert-name, there's an inherent potential ambiguity about subsets of names. Suppose you had two existing certificates with overlapping coverage, one for foo.example.com and bar.example.com, and the other for foo.example.com and qux.example.com. If you now asked for a certificate for just foo.example.com, without --cert-name, Certbot wouldn't be able to figure out which certificate to replace, but replacing the wrong one could be very bad.

For adding names, there is a similar ambiguity, but the outcome of guessing arbitrarily there is usually not very bad, because the server usually just becomes capable of responding successfully to requests for more names.

3 Likes