I have installed letsencrypt on Ubuntu 14.03 following this guide:


I also created a cron job for certificate renewal as described in the guide, but then found the following problem:

  • certbot-auto renew (as a non-root user) and sudo certbot-auto renew both work when tested from the command line (certbot reports that the certificates are not due for renewal yet, as expected)
  • However, when the same command is run by cron (as root), certbot tries to upgrade itself.

Any idea why I am getting this different behaviour? What is the difference between running the command manually on a shell console and having it run by cron?

Update: I added --no-self-upgrade but it didn't make any difference. On further investigation I noticed the following:

  • sudo certbot-auto renew --dry-run works fine
  • sudo su; certbot-auto renew --dry-run tries to upgrade certbot first

For some reason, certbot seems to think it is not properly installed when running in the second form.

2 Answers 2


This issue occurs because of the way certbot was installed.

When not using a packaged distribution installation of certbot, it can't ensure that all dependencies are met so to make sure it can run properly, it creates a virtual environment in your $HOME. When running with sudo, this is still your own $HOME. However, when running as root, this turns to /root where the virtual environment is not present and thus, certbot cannot run without creating it. It's not upgrading itself so much as installing itself considering the new environment it is run from.

  • My doubt with this answer is: is it according to best practice to install certbot as root user? Thats the only way I accomplished to have the certbot renew command running on cron without problems. Sep 15, 2017 at 14:53


The issue here was that certbot-auto was first ran (initialized) using sudo while cron ran it as the root user. This resultet in certbot-auto trying to install dependenvies when executed by cron/root.

The solution would be to run certbot-auto as root, not using sudo.

I still want to mention --no-self-upgrade as this will keep certbot-auto from trying to upgrade itself. Useful when executed by a cronjob as you can/should monitor any upgrades by running it manually from time to time.

I do not see any difference when testing here on Debian Jessie using the latest certbot-auto. You could add '--no-self-upgrade' to the command. That way certbot-auto does not check for new versions.

I have this in '/etc/cron.d/letsencrypt'

# Check if we need to renew any certificates

4 4 * * * /opt/letsencrypt/certbot-auto renew --quiet --no-self-upgrade --post-hook "service nginx restart" >/dev/null 2>&1

This will run every once every day and then restart nginx if it had to renew any certificates but without trying to update certbot-auto itself.

  • I added --no-self-upgrade but it didn't help. I also found some extra info; please see the edit to my question.
    – Grodriguez
    Feb 1, 2017 at 10:45
  • Have you tried to allow certbot-auto to upgrade itself as root once? Adding --no-self-upgrade should force it not to check for upgrades unless it is missing something.
    – Ialokin
    Feb 1, 2017 at 10:49
  • That seems to be the problem indeed. But why is it triggered when running certbot as sudo su; certbot-auto but not when running as sudo certbot-auto ?
    – Grodriguez
    Feb 1, 2017 at 10:50
  • The difference between 'sudo su' and 'sudo' is a completely different question. But it is not the same. Try to renew (or register a new cert) as the root user ('sudo su' first). Install/upgrade as certbot-auto wants. Then try running renew again using sudo. It should work. Maybe certbot-auto installed some dependencies locally on the user you used when running "sudo".
    – Ialokin
    Feb 1, 2017 at 10:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.