I manage several domains, but only one of them created a directory under the name "domain-0001" upon the renewal. Both live and archive have this new directory besides the original named "domain". This domain has been initially issued a few weeks apart from the rest, and this is the only difference that is obvious to me.
The rest of the domains had received their renewal certs in the same directories as the original ones.
I checked the log but it only said that it created this directory and no errors occurred around that renewal attempt.
Is this due to me doing something wrong?
1 Like
That's strange. Renewal shouldn't result in creation of new lineages (i.e. /etc/letsencrypt/{live,archive}/ directories) under any circumstances.
Things might go wrong if you modified files under /etc/letsencrypt/archive/ or /etc/letsencrypt/live/, but all bets are off if you do that.
Usually this will only happen in the set of circumstances described in this post.
Could you post that log file?
4 Likes
I am always baffled by these explanations. They make perfect sense for the one who is doing the explaining but none for the one who asks the question. From my personal perspective, I have a domain "domain" that needs an SSL cert. What else on Earth is there to consider? Why is it so important to download the renewal into another directory, breaking all automation scripts in the process? Anyway, I digress.
No, I do not manually modify anything whatsoever under Certbot directory. Yada-yada-yada.
I will certainly not post my logs online. For starters, are you a Certbot developer? If you are not, then you are not privileged to see my logs, needless to say the rest of Earth's population.
Like I said, renewals would never go into a new directory, unless there is an unknown bug in Certbot, or there was some other intermediate user action.
So yes, it should work in the way you expect.
If you want help in figuring out how why it isn't this way, it would help to be forthcoming with information. I would love to directly solve your problem with the minimal information given, but that's not always possible. It's your choice, anyway.
5 Likes
What is your role here?
His role is that of someone trying to help you.
3 Likes
I asked him a direct question: is he a Certbot developer. He is being evasive, and now you are being evasive too. What's up?
He is not a certbot developer (Edit: well, seems he is after all 
). If you can only receive help from a certbot developer open an issue on github https://github.com/certbot/certbot/issues
3 Likes
I welcome help from anyone but will not show them logs since am responsible for the privacy of these domains. Thanks for the pointer!
You can check the logs for privacy issues: there are none. The domains are logged publically anyway due to certificate logs. And besides the domain names, there's nothing privacy sensitive in the logs (no private keys are ever logged for example).
If certbot created a domain-0001 kind of lineage, you didn't renew with certbot renew, but probably ran the certbot command again. There have been huge improvements in certbot and some ancient versions of certbot had some trouble with recognising already issued certificates when the certbot run or certbot certonly command was ran again, resulting in such a domain-0001 lineage, but recent versions of certbot have fixed most of those (if not all) bugs.
However, your post does not even specify a certbot version. Normally, when opening a thread in the Help section, you're provided with a questionnaire. I don't know if you've decided to delete the whole questionnaire of if for some reason you weren't provided with one, but it isn't too much to ask for logs as my other volunteers of this Community here have asked.
Here's the questionnaire again, please answer all questions to the best of your ability:
Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.
My domain is:
I ran this command:
It produced this output:
My web server is (include version):
The operating system my web server runs on is (include version):
My hosting provider, if applicable, is:
I can login to a root shell on my machine (yes or no, or I don't know):
I'm using a control panel to manage my site (no, or provide the name and version of the control panel):
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):
5 Likes
In certain situations, like:
If you ask for:
certbot -d domain.one
Then afterwards ask for:
certbot -d domain.one -d www.domain.one
It will have both certs, but can't use the same name for both certs, so it will add -0001 to the second cert name.
Try showing us what you already have with:
[which cert contains which names]
certbot certificates
6 Likes
This is certainly one of the design decisions in Certbot that confuses people the most, but the original idea was that if you asked for overlapping but not identical certificates with your -d options, even for a relatively small change, we assumed that you actively wanted both of them, rather than that you wanted one to replace the other.
Later the --cert-name option was added as a straightforward way to specify a modification to an existing certificate, but Certbot still does not very proactively warn people about circumstances in which that would be a better option (still basically making the assumption that, given the differences in domain name coverage between the times when you ran Certbot, you deliberately wanted both versions). Something that I think might help a lot now is some kind of warning before creating the -0001 name ("The new certificate you've requested would be a subset of an existing certificate example.com; did you want to modify that certificate's coverage, renew that certificate instead, or create a partially overlapping certificate?"). But I don't know how it could be done in a way that actually let the user reliably interrupt the process without potentially breaking some people's scripts in unusual situations.
@super I'm sorry for how confusing Certbot's decision to create the -0001 names can be; I'm well-aware of how people often find it counterintuitive since I've helped dozens of people here on the forum with questions about that behavior. However, I wrote the original version of the certbot renew functionality myself and I can assure you that it doesn't call the code that adds the -0001 suffix. If you never used certbot, certbot certonly, or certbot run for a renewal attempt, but only used certbot renew, you wouldn't ever get the -0001 variants.
6 Likes
One subtlety in that case, and to add to what @schoen said, is that Certbot will first ask you to instead expand the existing certificate:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
You have an existing certificate that contains a portion of the domains you
requested (ref: /etc/letsencrypt/renewal/example.com.conf)
It contains these names: example.com
You requested these names for the new certificate: example.com, www.example.com.
Do you want to expand and replace this existing certificate with the new
certificate?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(E)xpand/(C)ancel: c
To obtain a new certificate that contains these names without replacing your existing certificate for example.com, you must use the --duplicate option.
Certbot won't generate -0001 automatically when the new certificate is a superset of the old certificate, such as in the above case.
The situation in which it will create an -0001 lineage, without warning, is when it's overlapping but not a superset.
So if your starting point is:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Found the following certs:
Certificate Name: example.com
Serial Number: 3ce6061efcc74904
Key Type: RSA
Domains: example.com www.example.com
Expiry Date: 2025-12-25 10:53:10+00:00 (VALID: 1825 days)
Certificate Path: /etc/letsencrypt/live/example.com/fullchain.pem
Private Key Path: /etc/letsencrypt/live/example.com/privkey.pem
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
and you ran:
certbot certonly --webroot -w /tmp -d example.com -d app.example.com
(i.e. example.com is overlapping but www.example.com is not!) ...
then you will end up with example.com-0001, without any warning at all.
I'd be in support of adding another prompt here (interactive-only) that calls out the fact that a duplicate lineage is about to be created and to hint that the user may want to be updating an existing lineage instead. My gut instinct tells me that editing the existing lineage is what the user meant to do in 99% of cases, but who knows.
6 Likes
Oh yes he is.
I just didn't want to out him, but he titled himself, so no harm now.
4 Likes
Seems I've been disconnected for a long time 
3 Likes
Glad to have you around though. Welcome back to our little circus. 
4 Likes
His profile is private for a reason....
3 Likes
True. Sometimes people not understanding your role in the grande play can create trust issues. It's not so much a matter of pride (though I have no problem with one taking pride in where one stands).
When someone comes along offering very complex and detailed advice, the following of which could greatly affect one's business (or at the very least one's future), one wants to be absolutely certain of the effectiveness of the advice, the judgment of which relies heavily upon assessing its source.
3 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.