How can I delete all letsencrypt data and start again

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: tp23.org

I ran this command: certbot renew

It produced this output:

Attempting to renew cert (tp23.org) from /etc/letsencrypt/renewal/tp23.org.conf produced an unexpected error: Missing command line flag or config entry for this setting:
Select the webroot for radiolocal9.tp23.org:
Choices: [‘Enter a new webroot’, ‘/mnt/cipublish/www/htdocs-rpi.tp23.org’, ‘/mnt/cipublish/www/htdocs-ci.tp23.org’, ‘/mnt/cipublish/www/htdocs-sanename.org’, ‘/mnt/cipublish/www/htdocs-htmlbuffer.tp23.org’, ‘/mnt/cipublish/www/htdocs-tp23.org’, ‘/mnt/cipublish/www/htdocs-xtomp.tp23.org’, ‘/mnt/cipublish/www/htdocs-download.tp23.org’, ‘/mnt/cipublish/www/htdocs-jclosure.tp23.org’, ‘/mnt/cipublish/www/htdocs-linci.tp23.org’, ‘/mnt/cipublish/www/htdocs-markbook.tp23.org’, ‘/mnt/cipublish/www/htdocs-lxinitd.tp23.org’]

(You can set this with the --webroot-path flag). Skipping.
All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/tp23.org/fullchain.pem (failure)

My web server is (include version): nginx

The operating system my web server runs on is (include version):
linux

My hosting provider, if applicable, is: n/a

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.36.0

Today all my certs expired, and I need to rebuild them. I have split my hosts over two VMs so its not going to be possible to run existing config since the server that runs certbot no longer has access to the required webroots.

I did not realize that certbot renew required access to webroots forever when I set this up.

I have setup the new server as I did originally with a subset of domains and I have a valid cert, no idea if they will ever renew but 2 hosts on tp23.org work now.

Certbot no longer supports two domains with the same webroot which is annoying but I can fix that however it will take time and a few retries.

Problem is that certbox generates files dynamically in /etc/ which means its not easy to work out what can be deleted to start afresh.

Any tips what can I delete? there is also the problem that certbot will not let you recreate certs for a certain amount of time, how do I get around that? Its seems its impossible to automate certbot since it behaves differently and return 0 always even when it failed. Currenlty I have certs expi9red and I’m not allowed to regenerate them which is harsh.

I need a clean start, it now tacks -0001 on to file names which clearly breaks the automation I have setup so it needs a rewrite.

I will need to be able to manually regenerate certs every 3 months until I can automate certbot usage again.

Can you explain more about what went wrong? What does “sudo certbot certificates” show?

You can delete everything, or you can use the sudo certbot delete --cert-name example.com to delete particular certificates, but it’s usually a bad idea: there should be other ways to solve issues; it’s inefficient; if you encounter one of the rate limits, you may run into difficulties making more certificates; if your daemons try to use files that don’t exist, they may break, which can also make it more difficult to issue more certificates.

I’m not certain what’s happening there, but there was a bug in certain versions of Certbot (fixed around 0.33.0, if I remember correctly, which I might not) that would cause it to lose certain saved webroot path settings under certain circumstances, breaking renewal. 0.36.0 is fixed (I think), but it can’t automatically fix configuration files that were broken before.

You can fix it by running the command used to create the certificate again (sudo certbot certonly --webroot -w /path -d example.com or whatever).

It still supports that.

Which files do you mean?

What command did you run? It does that when using the --duplicate option, or when creating a new certificate that contains a partially-overlapping set of hostnames as an existing certificate. You can avoid the latter situation by not doing that, or by using the --cert-name option to force it to use a particular certificate name regardless of the hostnames.

1 Like

Thanks for the reply.

I ran certbot renew from cron, which must have been failing since I refactored the locations of the webroots.

And then
certbot certonly --webroot
-d tp23.org

with a different list hostnames, just the ones on that server.

I found a bash script that does the job.

https://github.com/srvrco/getssl

Support multiple domains from the same roots, multiple webroots without manual reconfiguration, supports webroots on different machines, and does not change its output location when adding hosts to the config. All generated files are in $HOME.

Seems like a better fit for my use case.

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