Fail to renew | Directory not found

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., 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:
sudo mv certbot-auto /etc/letsencrypt/

It produced this output:
mv: cannot move ‘certbot-auto’ to ‘/etc/letsencrypt/’: Not a directory

My web server is (include version):
Google Cloud Platform

The operating system my web server runs on is (include version):
Distributor ID: Debian
Description: Debian GNU/Linux 9.11 (stretch)
Release: 9.11
Codename: stretch

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):
-bash: certbot-auto: command not found
-bash: certbot: command not found
I thought I was using certbot, at least I though I just downloaded it again, but it still gives me this output.

I already have a ssl certificate from Let’s Encrypt, but need to renew. I tried it the last time and failed miserably forcing me to move my domain and start all over. This snowballed in my client not having email and invoicingsystems working. The situation now is that I have to renew before the 12th of March, but cant manage to do so. Already at the first couple of steps for renewing I am encountering problems of it not finding the right directory. Leaving me clueless on how to continue.

Your help will be very much appreciated!

and why would you do that?

what does ls -la /etc/letsencrypt show?

is it possible you were using another client?

If that directory is not empty it’s plausible you did indeed use certbot and apt somehow made it disappear, probably unmet dependencies or something. It should be safe to just install it again.

I used that command because I am following the steps from this link:

I think I just reinstalled the certbot, because when I give the command ‘certbot-auto --version’ it gives me this output:
Requesting to rerun /usr/local/bin/certbot-auto with root privileges…
certbot 1.3.0.

But I still dont know now how to renew. I added this command ’ 1. echo “0 0,12 * * * root python -c ‘import random; import time; time.sleep(random.random() * 3600)’ && /usr/local/bin/certbot-auto renew -q” | sudo tee -a /etc/crontab > /dev/null’ But it seems as if that didnt do the trick, since the expire date is still on the 12th.

stop right now.

/etc is not the place for executables.

let that tutorial go and follow the instructions on certbot’s website:

Thanx, just went trhough those steps. But still not sure if the renewal worked looking at this:

Did it work? Is it automatically renewing or still ending at the 12th?

If you installed only, it will probably run with the cron/systemd timer.

But you can run certbot renew now and it will do it right now.

Also, configure your webserver a little bit better, please: :wink:

When I enter that certbot renew it shows me:
-bash: certbot: command not found

did you follow the instructions for apache on debian 9, as they are written on certbot’s website?

I feel dumb. I used the debian (other). But, now i did use the right one and followed the steps.
The command ‘certbot renew’ now gives me the following output:

The following error was encountered:
[Errno 13] Permission denied: ‘/var/log/letsencrypt/.certbot.lock’
Either run as root, or set --config-dir, --work-dir, and --logs-dir to writeable paths.

well… why don’t you run it as root?

Like said, I feel dumb haha. How do I do this?
If you couldnt tell before, still a noob at this…

sudo certbot renew

Thanx! That gave me this output:

Saving debug log to /var/log/letsencrypt/letsencrypt.log

No renewals were attempted.

Ok, just run sudo certbot and read carefully what it tells you

‘sudo certbot’

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator apache, Installer apache
No names were found in your configuration files. Please enter in your domain
name(s) (comma and/or space separated) (Enter ‘c’ to cancel):
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for
Enabled Apache rewrite module
Error while running apache2ctl graceful.
httpd not running, trying to start
Action ‘graceful’ failed.
The Apache error log may have more information.
AH00558: apache2: Could not reliably determine the server’s fully qualified domain name, using Set the ’
ServerName’ directive globally to suppress this message
(98)Address already in use: AH00072: make_sock: could not bind to address [::]:80
(98)Address already in use: AH00072: make_sock: could not bind to address
no listening sockets available, shutting down
AH00015: Unable to open logs

I guess your server is not apache after all. What’s your webserver?

(and why is ssllabs convinced it’s apache? – because it identifies as such…)

I guess because I was convinced it was apache… Didnt set it up myself so not 100% sure, got given this problem and obviously not an expert. Do you know how I can retrace this and figure out what the webserver is? My apologies for the obvious questions…

try with ss -tlpn | grep :443

It gives me this output:

LISTEN 0 128 :::443 :::*

you should probably run that as root