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. crt.sh | 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 certonly --standalone -d mail.sieutoc.com and certbot certonly --force-renew --standalone -d mail.sieutoc.com
It produced this output:
FileNotFoundError: [Errno 2] No such file or directory: '/etc/letsencrypt/archive/mail.sieutoc.com/privkey3.pem'
Please see the logfiles in /var/log/letsencrypt for more details.
An unexpected error occurred:
FileExistsError: [Errno 17] File exists: '/etc/letsencrypt/archive/mail.sieutoc.com/privkey4.pem'
Please see the logfiles in /var/log/letsencrypt for more details.
My web server is (include version): Zimbra
The operating system my web server runs on is (include version): Ubuntu 20.04
My hosting provider, if applicable, is: i cant tell
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): no
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): certbot 0.40.0
This suggests your Certbot configuration is quite heavily damaged. Please make sure the contents of /etc/letsencrypt/ are sane, especially ./live/mail.sieutoc.com/ and ./archive/mail.sieutoc.com/.
And I agree with my fellow volunteer above: forcibly renewing a certificate without understanding, recognising and fixing the underlying problem will get you in this kind of trouble.
It's most likely possible to fix your Certbot. The certificates are publicly available (although not yet on crt.sh, only the pre-certs currently) or are stored in the Certbot log files. The only thing you need to do is match a cert with the corresponding private key. And of course fix the Certbot directory structure.
You have 5 days before your cert expires. At least the one used by your port 443 (HTTPS) service. Although you should review the nginx cert config as the cert and chain it sends out is not normal.
The rate limit for duplicate certs is not 168H and has not been for some time (see here). A recent Certbot version would show you the complete error message which gives the exact date and time when you can try again. Ubuntu easily supports a snap install for Certbot which is recommended.
Thanks Osiris, i will try it tomorrow. But let me ask one more, if running the 2 commands above reports failure, will the cert still be created in the log?
And if I try to rollback the VPS to a previous version before running the fail command, is there any way for me to check the key generated?
Good question, not sure. I would say it makes sense to either write the private key to disk before getting the cert orafter getting the cert. Not during. So I think the cert should be somewhere in the log, as I assume it will only write the private key after retrieving a cert.
I would backup the entire /etc/letsencrypt/ and /var/log/letsencrypt/ directories before rolling back your VPS.
In the meantime, if you fail to retrieve private key, and can't wait for the rate limit to elapse, you could request a certificate though one of other free ACME-compatible CAs:
