From certbot 0.10 to 0.21


I’m upgrading my server from an old Debian 8 to a newer Ubuntu Server 16.04.

I’ve noticed that the certbot versions are quite different between those two: 0.10 on Debian and 0.21 on Ubuntu. And as I’m trying to move my certificates to the new server, I’ve discovered that the directory structure under /etc/letsencrypt/ has changed as well. Also, I was using --webroot (because nginx was not, or badly supported with 0.10), but --nginx seems to be working fine now on 0.21.

So, my question is: what is my best course of action? (issuing new certificates on the new server? moving the old certificates to the new server and, if so, how? is it really safe to use --nginx now? I haven’t seen a post explaining what it does exactly).

EDIT: well, I finally was able to try certbot --nginx on a temporary domain. The directory structure is not that different in the end, just a few more config files (cli.ini, ssl-dhparams.pem, etc…) and the directory renewal-hooks, that’s all.

That being said, I’m still unsure if I can simply reuse the certificates from my old server?


My domain is:

My web server is: nginx/1.10.3 (Ubuntu)

The operating system my web server runs on is: Ubuntu Server 16.04

I can login to a root shell on my machine: yes

I’m using a control panel to manage my site: no


Should be fine.

You can copy the entire /etc/letsencrypt/ directory and all its contents, making sure to use a method of copying that preserves symbolic links. You might do this if, say, you want to reuse the same account for some reason, or if you have a complex hook configuration that you don’t want to manually recreate on the new server. Otherwise there’s not much advantage and with the risk of accidentally messing up the symbolic links it’s likely more trouble than it’s worth.

Sure, --nginx is the recommended method for nginx users now. It works similarly to the --apache plugin, by temporarily modifying your nginx configuration to answer the validation challenges. So you no longer need to specify a webroot path for each domain. It also automatically installs the certificate for nginx to use (you can use certonly if you don’t want that).


An advantage I see reusing the same certificates is that I can’t easily reroute the user to the new server transparently (since I can’t create a new certificate for my domain on my new server as long as the DNS have not been updated). So by using the same certificates, I’d be able to proxy_pass from the old to the new server transparently, without any downtime.

Or maybe I am missing something? (I am no sysadmin :confused: )


Oh, sure, if you have an actual reason to make the effort to use the same certificates, go right ahead. The newer version of certbot will happily update the older directory structure. The main thing is to make sure to keep the symlinks intact.

There are other ways. You could use the DNS-01 challenge, in which case the new server could get its new cert before it’s actually reachable. Or you could proxy the HTTP-01 challenge requests from the old server to the new. But transferring the existing certificates across is an equally fine solution.

…Provided you keep the symlinks intact. Did I mention that?


Thanks for all these replies! That is truly appreciated!

I don’t know what the DNS-01 challenge is, but I do understand the solution about proxying the HTTP-01 challenge :thinking:

For the moment, I’ll do with copying the certificates over to the new server, because I’m starting to have an automation now.

About the --nginx plugin, does it reload nginx somehow? From what I understand, I guess it must add a rule for the .well-known directory, reload the server, make the challenge, remove the rule and reload the server again.

By doing everything by hand before, I kinda knew what was happening, but with the plugin it’s a bit more hidden and, as I like that I don’t have to precise the webroot, I don’t like much the modifications done in the nginx conf files. I prefer to follow the instructions given by Mozilla about it: Most notably the 301 redirection: the nginx plugin adds an if in the configuration file, and the nginx devs tell in their doc again and again that this is bad.


The --nginx plugin includes both an authenticator and an installer. The authenticator works pretty much exactly as you described above. The installer is what modifies your nginx configuration with the ssl_certificate directives and 301 redirect etc. If you don’t want that, you can use

certbot certonly --nginx

which will just use the authenticator to get the certificate without making any permanent changes to your configuration. In that case you’ll still need to configure nginx manually to install the certificate, and you’ll probably want a --deploy-hook to reload after renewal.



I’ve learned a lot in just a few hours thanks to you, thank you again :wink:


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