How to change the installation path of certbot


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

I ran this command: 1. create a directory
2. cd /etc
3. cd letsencrypt
sudo wget

sudo chmod a+x certbot-auto

then I stopped all service
sudo /etc/letsencrypt/certbot-auto --nginx
It produced this output:
Congratulations! You have successfully enabled

You should test your configuration at:

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

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):yes

I’m using a control panel to manage my site (no, or provide the name and version of the control panel):I use ssh console, and I have ftp access

**Everything work fine, I have the certificate, the only problem is I wish to change the installation path of certbot auto because I mistakenly installed it in a directory with only root permissions (/etc/letsencrypt - user root group root) and this is a problem because I have to manually copy the certificate files each time and put them in another directory where my vm instance can read them **

Someone please can help me to make:

  1. a back up of the config certbot auto file
  2. unistall all directory and file from /etc/letsencrypt
  3. reinstall certbot auto

If after the unistall I reinstall certbot auto it make new certificate files ?

The reason is I would like to create, after reinstalling certbot auto, a procedure through cron to automatically renew the certificates


certbot-auto is just a small wrapper script. You can put it anywhere on your filesystem, and move it wherever you want. It’s safe.

certbot-auto actually installs certbot in /opt/

Your configuration and certificates are always stored in /etc/letsencrypt/. You can change this path by running certbot-auto with --config-dir /some/other-path/, but private keys are always protected by 0700 permissions for whatever user you run certbot-auto as.

If you want to copy keys and certificates to another location (or with other permissions), you probably want to use a --deploy-hook (documented on


Hi,the problem is that I am using jetware : and services are not starting as root.

To copy the files manually from /etc/letsencrypt/ to /jet/etc/pki/tls/certs and to /jet/etc/pki/tls/private/
I did :

sudo cp /etc/letsencrypt/live/ /jet/etc/pki/tls/certs

sudo cp /etc/letsencrypt/live/ /jet/etc/pki/tls/private/

sudo chmod 600 /jet/etc/pki/tls/private/privkey.pem
sudo chmod 644 /jet/etc/pki/tls/certs/fullchain.pem

sudo chown user:group /jet/etc/pki/tls/private/privkey.pem

sudo chown user:group /jet/etc/pki/tls/certs/fullchain.pem

and everything work fine.

Now I wish , I need to move all directory letsencrypt from etc/ (root permission ) to jet/etc (no root permission) and change ("I don’t know if I have to change ") some param into the config ini file (i.e. Installation path and config dir, and I think I have to change all permissions from root to my jeware premissions (user, group) .

Meanwhile I will give a look to

After this I will be able to do a cron process to auto renew the certificate.


You should pretty much just be able to do something like creating /etc/letsencrypt/renewal-hooks/deploy/

#!/usr/bin/env bash

set -euf -o pipefail

for domain in $RENEWED_DOMAINS; do
        case $domain in
                cp "$RENEWED_LINEAGE/fullchain.pem" "/jet/etc/pki/tls/certs/"
                cp "$RENEWED_LINEAGE/privkey.pem" "/jet/etc/pki/tls/private/"

                chown user:group /jet/etc/pki/tls/private/privkey.pem
                chown user:group /jet/etc/pki/tls/certs/fullchain.pem

                chmod 0400 /jet/etc/pki/tls/private/privkey.pem
                chmod 0400 /jet/etc/pki/tls/certs/fullchain.pem


and make sure you chmod +x it.

When certbot-auto runs as root and renews your certificate, it will also run the hook and copy the certificate.

No need to make other changes.


I only have one more question to better understand: when I renew the certificate, more or less 30 days before the expiry date, the certificate file (fullchain.pem) is modified with another encrypted code or the certification authority updates the date expiration and the file remains the same?

I ask this because as I have copied the file in a readable directory, if the file is not changed I can safely avoid to copy it again when it is renewed


The former. A certificate is an immutable data structure that includes, among other things, its expiration date. “Renewing a certificate” is just getting a whole new certificate.

fullchain.pem is a symlink to a file named something like fullchain1.pem. When the certificate is renewed, Certbot creates a new file and changes the symlink.

(By default, Certbot also creates a new private key.)

You have to copy it again. :slightly_frowning_face:

You can use a deploy hook to have Certbot automatically copy the certificate (and key) to the other location.


Ok thank you don’t warry :smile: , I will read the documentation.

I have an other question:
if I have the two certificate in this directory:

and instead of copy the two file I wish create two simlink
in this directory:

how can I do it?


ln -s /etc/letsencrypt/live/ /jet/etc/pki/tls/certs/simlinktofullchain.pem
ln -s /etc/letsencrypt/live/ /jet/etc/pki/tls/certs/simlinktoprivkey.pem


Hi Schoen, thank you.

I tryed with the simlinks but for some reason that I do not understand, even with the symlinks, my custom image vm instance (jetware lemp7 optimized for google compute engine can not read the certificate files.
So I had to move the whole directory from /etc/letsencrypt to /jet/etc/letsencrypt
sudo mv /etc/letsencrypt /jet/etc
sudo chown -R user:group /jet/etc/letsencrypt/

I have updated the file

renew_before_expiry = 30 days

version = 0.27.1
archive_dir = /jet/etc/letsencrypt/archive/
cert = /jet/etc/letsencrypt/live/
privkey = /jet/etc/letsencrypt/live/
chain = /jet/etc/letsencrypt/live/
fullchain = /jet/etc/letsencrypt/live/

Options used in the renewal process

authenticator = nginx
installer = nginx

I have updated the default_ssl.vhost file with the new path directories

  ssl_certificate "/jet/etc/letsencrypt/live/";
  ssl_certificate_key "/jet/etc/letsencrypt/live/";

Everything seems to work well and now I don’t need to copy the ssl certificate files from a directory to an other.

My first question is:
having moved the whole directory I have to change setting in some other file, in addition to those that I have already modified ?

My second question is:

if I want to configure a cron job how do I do it?
which files should I create and where should I go to place them?

I think I need need something like this :
0 */12 * * * root -x /jet/etc/letsencrypt/certbot-auto renew --pre-hook “stop” --post-hook “start”
the syntax is correct ?

where I have to put this cron file ?

I have to create some other files to insert into this directory?


One guess (which I’m not sure of because we didn’t experiment with this to find other possible causes) is that your server might be using a chroot, where while running it can’t see any files on the filesystem outside of its prefix (including following symlinks).

You need to set the --config-dir to /jet/etc/letsencrypt every time that you run Certbot in order for it to look in /jet/etc/letsencrypt instead of the default /etc/letsencrypt. For example, you would use certbot-auto renew --config-dir /jet/etc/letsencrypt instead of just certbot-auto renew.

This should probably work; if it doesn’t, we can look into why not.

There are several options—you can add a line to /etc/crontab, or you can run crontab -e, which will start a text editor editing your “personal” crontab file. (In the latter case you should run this command as root to ensure that the affected crontab file is root’s rather than a regular user’s.)

The root part is only appropriate in /etc/crontab (the shared system crontab file), where the user that the job should run as needs to be specified. It’s not appropriate in an individual user’s crontab.

The -x doesn’t make sense to me; I don’t think it belongs here.

You would need to add the --config-dir option that I specified above in order to make it look at /jet/etc/letsencrypt instead of /etc/letsencrypt.

The "stop" and "start" are incomplete by themselves. If you want to make Certbot restart the web server during a renewal, you need to specify complete commands that have this effect, because Certbot will literally run the commands that you specify in the hook options. stop and start won’t work because these aren’t complete commands that can be run.

That isn’t necessary unless there’s an additional script that you want to have Certbot run after the renewal. This is probably a different strategy to the one that you’re currently attempting, so if your current approach works, you wouldn’t need to put anything there.


Ok Schoen thank you very much, I have just made a test of this command:

sudo /jet/etc/letsencrypt/certbot-auto renew --config-dir /jet/etc/letsencrypt

and seems to work fine, I received the following reply from the server:

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Processing /jet/etc/letsencrypt/renewal/
Cert not yet due for renewal
The following certs are not due for renewal yet:
_ /jet/etc/letsencrypt/live/ expires on 2019-01-14 (skipped)_
No renewals were attempted.

About the command “start” and “stop” I wrote this because (sorry …I should have written a note on this before) to stop or to start my instance from the ssh console of google cloud I need to use this commands which are described in the jetware documentation:

Services control
Available services: cron exim memcached monit mysqld nginx orientation php-fpm redis
Start all services: start
Stop all services: stop
Service commands: available enabled disabled enable disable start stop status restart servicename

Now I will try to configure the crontab

thank you


Well here’s what I did after the first test above described:

for test I have added a line to /etc/crontab
*/15 * * * * root /jet/etc/letsencrypt/certbot-auto renew --config-dir /jet/etc/letsencrypt --pre-hook “stop” --post-hook “start”

to see if every 15 minutes it would give me the command inside crontab

after 20 minutes I gave the command nginx -s reload to see if everything works fine. Generally if there is an error the vm instance does not allow me to restart nginx and I have to perform another procedure to fix the error. Fortunately, nginx has restarted.

Once this was done for testing I went again to edit the crontab file on /etc/crontab
and I modified the line from:
*/15 * * * * root /jet/etc/letsencrypt/certbot-auto renew --config-dir /jet/etc/letsencrypt --pre-hook “stop” --post-hook “start”
0 4 * * 0 root /jet/etc/letsencrypt/certbot-auto renew --config-dir /jet/etc/letsencrypt --pre-hook “stop” --post-hook “start”

so every Sunday at 4.00 AM it should check for renewal … I hope :smile:


I believe that these are probably describing arguments to some other command which you should run. These don’t appear to be complete command names by themselves. For example, on some operating systems you can run something like service nginx stop and service nginx start.

The renewal check uses very few resources of any kind, so we usually recommend running it twice a day to allow for more opportunities to attempt the renewal. (With your current configuration it should try up to about 4 times before the certificate is expired, while with our recommendation it would try up to about 60 times, if necessary.)


ok I have changed crontab line to:

* */12 * * * root /jet/etc/letsencrypt/certbot-auto renew --config-dir /jet/etc/letsencrypt --pre-hook "service nginx stop" --post-hook "service nginx start"

the only doubt I have left is whether to write: “service nginx start” and “service nginx stop” or
“nginx start” and “nginx stop”

I hope that this way works because when, the first time, I created the certificates, without completely stopping the vm instance, then it would give me an error (pid file not found) and I could not restart the instance.

After I repeated the procedure completely stopping the instance and everything went well and I managed to restart the instance.

Ok I have set everything I just have to wait to see if everything works well.

Thanks again for everything


You can try running the start and stop command variants on the command line yourself and see whether they work! You don’t have to wait until a renewal to test that.


Hi Schoen, I did it and the only working command line are:

stop nginx and start nginx this from command line work as root and as user

service nginx stop and service nginx stop from command line doesn’t work

systemctl stop nginx and systemctl start nginx from command line work only as root


sorry …
systemctl stop nginx this work as root
systemctl start nginx this return an error :slight_smile:

Job for nginx.service failed because the control process exited with error code.
See “systemctl status nginx.service” and “journalctl -xe” for details.
root@lemp7-optimized-g2-1-vm:~# systemctl reload nginx
nginx.service is not active, cannot reload.
root@lemp7-optimized-g2-1-vm:~# systemctl status nginx.service
● nginx.service - A high performance web server and a reverse p
roxy server
Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor pres
et: enabled)
Active: failed (Result: exit-code) since Sat 2018-11-17 13:2
4:02 UTC; 2min 21s ago
Docs: man:nginx(8)
Process: 25264 ExecStart=/usr/sbin/nginx -g daemon on; master_process on
; (code=exited, status=1/FAILURE)
Process: 25262 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_p
rocess on; (code=exited, status=0/SUCCESS)
Main PID: 668 (code=killed, signal=KILL)
Nov 17 13:24:01 lemp7-optimized-g2-1-vm nginx[25264]: nginx: [emerg] bind(
) to failed (98: Address already in use)
Nov 17 13:24:01 lemp7-optimized-g2-1-vm nginx[25264]: nginx: [emerg] bind(
) to failed (98: Address already in use)
Nov 17 13:24:01 lemp7-optimized-g2-1-vm nginx[25264]: nginx: [emerg] bind(
) to failed (98: Address already in use)
Nov 17 13:24:01 lemp7-optimized-g2-1-vm nginx[25264]: nginx: [emerg] bind(
) to failed (98: Address already in use)
Nov 17 13:24:02 lemp7-optimized-g2-1-vm nginx[25264]: nginx: [emerg] still
could not bind()
Nov 17 13:24:02 lemp7-optimized-g2-1-vm systemd[1]: nginx.service:
Control process exited, code=exited status=1
Nov 17 13:24:02 lemp7-optimized-g2-1-vm systemd[1]: Failed to star
t A high performance web server and a reverse proxy server.
Nov 17 13:24:02 lemp7-optimized-g2-1-vm systemd[1]: nginx.service:
Unit entered failed state.
Nov 17 13:24:02 lemp7-optimized-g2-1-vm systemd[1]: nginx.service:
Failed with result ‘exit-code’.
Nov 17 13:25:27 lemp7-optimized-g2-1-vm systemd[1]: nginx.service:
Unit cannot be reloaded because it is inactive.

so the only command I ame sure are:

stop nginx and start nginx


But I’m thinking of one thing: is there a procedure to uninstall certbot and delete the definitive certificates even from the authority and do a clean installation on another directory? because my brain is melting :slight_smile:


the reason why i want to uninstall everything and do a clean install is because i believe there are two cron job:

one is here: /etc/cron.d/certbot
and it was created during the installation
and if i run stis command:
systemctl list-timers --all it return this:

Sat 2018-11-17 18:00:58 UTC 2min 38s left Sat 2018-11-17 06:28:44 UTC 11
h ago apt-daily.timer apt-daily.service
Sat 2018-11-17 18:09:00 UTC 10min left Sat 2018-11-17 17:39:06 UTC 19
min ago phpsessionclean.timer phpsessionclean.service
Sat 2018-11-17 18:44:54 UTC 46min left Fri 2018-11-16 18:44:54 UTC 23
h ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
Sun 2018-11-18 00:51:51 UTC 6h left Sat 2018-11-17 12:02:17 UTC 5h
_ 56min ago certbot.timer certbot.service_
Sun 2018-11-18 06:41:46 UTC 12h left Sat 2018-11-17 06:14:52 UTC 11
h ago apt-daily-upgrade.timer apt-daily-upgrade.service
5 timers listed.

the other one is the line I put in ect/crontab (sudo nano ect/crontab)

I need to do some order first in my head and then maybe even on the vm instance.
OK, the solution will come sooner or later.
Happy weekend to everyone


Probably something works because in /var/log/letsencrypt/letsencrypt.log
I have this report:
2018-11-18 00:51:52,993:DEBUG:certbot.main:Root logging level set at 30
2018-11-18 00:51:52,994:INFO:certbot.main:Saving debug log to /var/log/letsencrypt/letsencrypt.log
2018-11-18 00:51:52,994:DEBUG:certbot.main:certbot version: 0.10.2
2018-11-18 00:51:52,994:DEBUG:certbot.main:Arguments: [’-q’]
2018-11-18 00:51:52,994:DEBUG:certbot.main:Discovered plugins:
2018-11-18 00:51:52,995:DEBUG:certbot.renewal:no renewal failures

but I think that it depend from /etc/cron.d/certbot and not from the line I have added in

there is a way to understand if it’s all set ? May I delete the line I have added in ect/crontab : ?


0 */12 * * * root /jet/etc/letsencrypt/certbot-auto renew --config-dir /jet/etc/letsencrypt --pre-hook “stop nginx” --post-hook “start nginx” >> /var/log/letsencrypt/letsencrypt.log


this is the file that I think produce the report in /var/log/letsencrypt/letsencrypt.log
/etc/cron.d/certbot: crontab entries for the certbot package
Upstream recommends attempting renewal twice a day
Eventually, this will be an opportunity to validate certificates
haven’t been revoked, etc. Renewal will only occur if expiration
is within 30 days.
SHELL=/bin/sh PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
0 */12 * * * root test -x /usr/bin/certbot -a ! -d /run/systemd/system && perl -e ‘sleep int(rand(3600))’ && certbot -q renew