Why are there versioned certificate folders

Help
1

I recently switched to route53 so I could “re-issue” an existing certificate as a wildcard certificate for my domain “mydomain”.

The valid non-wildcard certs files were in their respective directories:
/live/mydomain
/archive/mydomain

Upon running “certbot certonly --dns-route53 -d mydomain.com,*.mydomain.com”, certbot proceeded to make NEW “versioned” folders, rather than use the exiting ones:

/live/mydomain-0001
/archive/mydomain-0001

I no longer need the non-wildcard cert, I’d like to get rid of the -0001 folders. so my questions are:

  1. Why did certbot do this?
  2. Is there a certbot command that will clean this up?
  3. If not, can I “move” the “-0001” files into the original folders (of course Id have to redo the soft links)?

I’m hoping for a simple way to clean this up.

Thanks

2

I can only assume that it saw the complete set of names (SAN) as somewhat different.

This requires your manual intervention/verification.
You may have to manually modify which certs are being used in your vhost configs.
But the main certbot command for this is:
certbot delete --cert-name <name-of-cert>

If you need to fully "CLEAN" the directories {live/archive}, that is also a manual deletion process.

1 Like
3

Thanks Rudy…

I suspect you may be correct. upon review, I see the original cert command included the explicit

–cert-name mydomain.com

where as the wildcard did NOT have that, so likely thought it needed a new folder…

thanks again.

2 Likes
4

That’s right—when you ask for a certificate that contains example.com along with other names, and there’s already a different certificate that’s named example.com, Certbot will automatically do the -0001 thing unless you specify --cert-name (to replace the existing example.com certificate), or unless the new set of names you requested is a superset of the set of names on the existing example.com certificate.

For example, suppose you have a certificate that Certbot calls example.com, which covers example.com and www.example.com. If you request a new certificate with -d example.com -d "*.example.com", Certbot will call the new certificate example.com-0001 due to the lack of explicit coverage for www.example.com, unless you specify --cert-name example.com.

Certbot is probably much too inclined to think that users may have deliberately wanted to separately manage several partially-overlapping certificates. When we were first creating that mechanism, we thought that intention could be reasonably common, but it seems that it’s actually quite rare in practice (at least on the same server machine).

2 Likes
5

One possible (future) path would have certbot ask (and include the programmatic logic to facilitate) for a user choice:

“You already have a cert (cert.name) that covers name(s): one.name, two.name, three.name.”
“Do you want to replace that cert with this new one, or do you want to create a new additional cert?”
“(R)eplace / (N)ew” / (C)ancel"

6

Seth;

Thanks for taking the time to answer.

It might be worth including this tidbit of info in the documentation under the “where are my certificates” section, so people can have additional insight as to what certs are where, and why folders might have numeric extensions.

The reasoning presented makes sense, though to be fair, in the example you cite “www” is implicitly covered by “*”. As such, it might be worth giving certbot some heuristics for checking the domains included against the “default name” being created, and other existing certs with “same" name, and if a potential match found, as per Rudy’s suggestion, putting up a notification asking if it should reissue the existing cert or issue a new one, given as you said, MOST aren’t looking to issue multiple certs.

Thanks again.

-Avi

1 Like
7

It does that now, but only in cases that are supersets (duplicates or strict supersets) for an existing certificate—not for a partial overlap in which some old name is missing. (However, most users in that situation probably miss this and don't end up using that functionality the way we intended, or the way they intended.)

1 Like
8

I think this is a good point, and I filed this issue to track it:

1 Like
9

You would also have to deal with mydomain.conf and mydomain-0001.conf -- deleting one and editing the other -- in /etc/letsencrypt/renewal/, but yes.

Editing the links is simple, but failing to do so or making a mistake can break certbot renew in ways that can result in it issuing many certificates while failing to save any them correctly. So if you go that route, don't make a mistake. :grimacing:

1 Like
10

Probably simpler/safer to delete both and then just reissue the one you need.
*take some precaution on NOT restarting the web server in the middle of these steps.

11

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