Certbot allows the automatic generation of Letsencrypt SSL certificates on the web for any web server or web application. Some well known web servers, such as Apache and Nginx, are directly supported through standard plugins, while others are supported through a generic mode that can work with just about any web application.
If you run Apache or Nginx, you can use the –apache or –nginx switch to automatically generate, renew, and then install Letsencrypt certificates. If your web server doesn’t have a specific plugin, you can still use the –webroot switch which only assumes that your web server has a root file system, which all web servers do have. Or if you don’t have a web server on the box at all, you can still use certbot-auto’s own built-in web server to get the certificates, invoked by the –standalone switch.
You must be on the production box
For automated certificate generation with Certbot to work, we must make sure that we run it on the box where we will eventually run the web application. The DNS has to be set up for the box correctly. The certificates will be issued based on that.
1. Install Certbot
sudo wget https://dl.eff.org/certbot-auto
sudo mv certbot-auto /usr/local/bin/certbot-auto
sudo chown root /usr/local/bin/certbot-auto
sudo chmod 0755 /usr/local/bin/certbot-auto
2. Install Cron if you don’t have it
sudo apt-get update &&\
apt-get install -y cron &&\
apt-get clean
3. Obtain your first certificate
If you run a supported web server, Apache or Nginx
This is the easiest case of all for both getting the initial certs and renewing them. For example, if you run Apache, Certbot can take care of everything for your through its Apache plugin, which you can invoke with the –apache switch. It will not only get the certificate automatically, but it will also be able to install it for you.
/usr/local/bin/certbot-auto certonly -n --agree-tos \
-m admin@example.com --apache
This will create a so called web challenge, which is just a file under your root at <webroot>/.well-known/acme-challenge/<a special unique key>, which will contain another special key inside. Then Certbot will query http://<your-domain>/.well-known/acme-challenge/<the same special key>. If it can find the content, it will issue a certificate, which will be copied into /etc/letsencrypt/live. From there you can copy it into your webserver, wherever it expects to find its certificates. This is what you see when this process succeeds:
You get this message if successful
Nginx is another web server that Certbot supports directly through its standard plugins. While I did not test with that web server, the same rules should apply as for Apache above. It falls in the category of supported specific web servers.
I typically choose not to have Certbot install my certficates, because I don’t want it to touch my Apache configuration files. But it is possible to set up Apache in a way that its config files for SSL point to /etc/letsencrypt/live/<domain-name>, where Certbot stores the certificates. So Apache will find them there after a restart anyway. If you want to use Certbot this way specify the certonly flag, so that it won’t try to install it.
Another piece of good news for you if you run Apache, is that Certbot can create the correct certificate format for Apache without any further work. Keep in mind though that if you use the Apache plugin, you must have Apache available on the box, because the plugin will try to use it. I was trying to only generate certificates with the certonly flag to force the key files into the Apache format not expecting that it would be looking for the web server, but it was:
If you run into this situation, you have to the –webroot switch, which does not require any specific web server to be present, which is described in detail in the next section.
If you run an unsupported web server
You can still use certbot-auto certonly to obtain your first certificate. You need to give it the root of your web server, so that it will know where to install the web challenge. You also must tell it what domain the certificates will be for.
/usr/local/bin/certbot-auto certonly -n --agree-tos \
-m admin@example.com --webroot -w /www -d example.com
Note that when you do this, Certbot won’t know what format your web server requires, so you may end up having to convert them into the correct format. For Apache, this wasn’t an issue, because it happens to be compatible with what is generated here out of the box.
If you don’t run your own web server
Certbot has a so called standalone mode. When you use it this way, it does not require that you have a running web server on the box. All you must do is run certbot –standalone on the box with the final DNS setup where you need the certs and open up port 80. The rest will be handled by Certbot.
/usr/local/bin/certbot-auto certonly -n --agree-tos \
-m admin@example.com --standalone
Certbot will fire up its own tiny web server, generate the challenge and install it at the the required web address on your box, and you will be issued a certificate. Just make sure you don’t run any other software that uses port 80. In particular make sure that if you have a web server you stop it while doing this, to avoid a port clash.
4. Install your certificate
cat /etc/letsencrypt/live/example.com/fullchain.pem \
/etc/letsencrypt/live/example.com/privkey.pem > /tmp/fullcert.pem
openssl pkcs12 -export -out /tmp/fullchain.p12 -in /tmp/fullcert.pem -passout env:JKS_PASSWORD
mv /tmp/fullchain.p12 /var/certificates/example.com.p12
Assuming your web server will be looking in /var/certificates, this is what you would do. If you are using Docker make sure this points to some persistent storage that survives reboots.
Notice how we are creating a java key store (JKS). If you are doing this for a Java web app you need this. Otherwise, you might be able to import fullchain.pem and privkey.pem above, directly and, if so, you can skip this step entirely. For instance, Apache will let you use the two keys generated directly without any additional work.
5. Renew regularly (< 3 months)
Letsencrypt certs expire every three months. It’s a good idea to renew before that happens. Use the following command to renew:
/usr/local/bin/certbot-auto renew
If you are not close to the deadline yet, the command will not renew. It will tell you it’s too early instead:
To do this right, you must do it at the correct intervals. Set up a Cron job like this. This will try it every week, and will only actually renew when it’s time to do so.
0 0 * * 0 /usr/local/bin/certbot-auto renew
6. Install the renewed certs
Don’t forget to install after the renewal. Your keys will be copied into /etc/letsencrypt/live, just like before. So your web server won’t know about them unless you install the keys. Therefore you must repeat step 4 to install the keys, each time your certs are renewed. It’s a good idea to drive this from Cron as well.
When to use automatic mode
Automatic mode is Certbot’s “normal” mode of operation as it is trying to make the process as easy and seamless for the average web as possible. In many cases, especially smaller web site operators can run Certbot on their production web servers without any problem. If you have a small blog, you should probably set up Certbot this way, using one of the patterns described above. Otherwise you should look at our manual mode tutorial.
Conclusion
That’s all you need to do to automate certificate generation and renewal for most web servers. You can make this work for just about any web app.