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.
I ran this command: certbot renew --no-random-sleep-on-renew --cert-name {domainname} --force-renewal --config-dir "/tmp/certbot/config" --work-dir "/tmp/certbot/config" --logs-dir "/tmp/certbot/config" -v
It produced this output: certbot is generating new folders woith -0001 and -0002 extensions. Like www.manasra.academy-0001
My web server is (include version): Not using webserver. Using standalone certbot
The operating system my web server runs on is (include version): Ubuntu 22
My hosting provider, if applicable, is: NA
I can login to a root shell on my machine (yes or no, or I don't know): Yes
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):
Details of the issue: We are a LMS provider and generate SSL certificates for our clients. For most of the clients certificate renewal happens properly with no issues. For few clients (around 5%), when we renew the certificate certbot generates certificates in a new folder with -0001 extension. I have verified that we use the same domain name during renewal. Also previous renewals for the same domain was proper.
Can you please helo me to fix this issue. We want to generate certificates in the same folder not with -0001 extension.
You can always check which certificates you have by running certbot certificates, which shows you the names, locations, and domain name coverage of each certificate.
The -0001 issue in Certbot arises when you specify partially overlapping domain name coverage when requesting a certificate (in comparison to the domain name coverage of a prior certificate).
you will get a certificate called example.com-0001 because the new request partially overlaps with the coverage of the existing certificate, but does not include every name that was part of it (in this case, not example.net).
Certbot always expects you to list every name that you wish to be included on a certificate.
If you want to specify that a certificate should be saved under a specific name (for example, in order to intentionally reduce the domain name coverage of an existing certificate), then you can use the --cert-name option and specify the name under which the newly-requested certificate will be saved.
Two other points that I'm sure some of my colleagues on this forum would like me to point out:
If you use --config-dir for some Certbot commands, you should use it for all Certbot commands (including, for example, certbot certificates), as you'll always need to remind Certbot where to find the relevant certificate configuration files (in a non-default location).
The option --force-renewal is rarely useful or beneficial. Its only effect is to cause Certbot to renew certificates before they are otherwise considered due for renewal. This can eventually cause you to run up against Let's Encrypt rate limits if you do this repeatedly. If you want to test whether a renewal would succeed, you can instead use the --dry-run option in most cases.
What's the reason that you're using those --config-dir et c.?
Also, as already mentioned by @schoen it's strongly recommended NOT to use --force-renewal.
That said: from the first ZIP file with the logs it seems the renewal subcommand doesn't generate those new folders, but a command incorporating the --manual plugin. So the command you've provided in this thread is actually not the cause.
Also from those logs, it seems your Certbot config directory is messed up:
2024-02-27 13:37:52,867:DEBUG:certbot._internal.cert_manager:Renewal conf file /tmp/certbot/config/renewal/academy.blackperldfir.com.conf is broken. Skipping.
(…)
certbot.errors.CertStorageError: expected /tmp/certbot/config/live/academy.blackperldfir.com/cert.pem to be a symlink
So something (most of the time the user, also often due to copying without preserving symlinks) has messed up the symbolic links in /live/academy.blackperldfir.com/, thus making Certbot generating a new directory.
So you need to:
figure out why the symbolic links were broken
fix the above reason so it doesn't happen again
I believe modern Certbot versions (OP is running 2.6.0) ask the user what he/she/they would want to do: at least for expanding a certificate. Not 100 % sure what happens when "shrinking" a cert though.
We are saving entire config folder and then copy back again when we need to renew we copy the folder back. When we copy the folder we are restoring symlinks like below:
Only you can answer this: Certbot expected to find a symlink, but didn't. So something must have gone wrong with all the saving/backing up/restoring and that's something only you can diagnose and fix.
These four should suffice. Although I must say it sounds like quite a complicated setup prone for problems. Why so complicated?