Let’s Encrypt: Advanced configuration

Let's Encrypt

This is our second article in the series startups’ tools. Let’s encrypt deeper into the configuration and use of Certbot, the primary tool to get and manage SSL certificates. We assume that you have already had a look at our previous article.

Read also on our blog

Let’s Encrypt: SSL for everyone

Certificates for other services

There are other services which use SSL certificates, like SMTP and IMAP servers. These services are also able to use Let’s Encrypt certificates. You simply have to specify their location in the corresponding configuration files.

Here is a short list of the configuration files for services:

Postfix, SMTP server (in file /etc/postfix/main.cf):

[code language="bash"]
# TLS parameters
smtp_tls_security_level = may

Dovecot, IMAP server (file /etc/dovecot/conf.d/10-ssl.conf):

[code language="bash"]
ssl_cert = </etc/letsencrypt/live/test.example.com/fullchain.pem
ssl_key = </etc/letsencrypt/live/test.example.com/privkey.pem

Obviously there are several other services using SSL certificates. The main idea is to use the file fullchain.pem in place of the “ordinary” certificate. Simply point to the link in the live folder.

Certificates for several sub-domains

Let’s Encrypt does not want to release wildcards certificates. These certificates are validating the domain without restriction for the sub-domain (for example: *.example.com), such certificates are interesting since they validate any sub-domain. Since Let’s Encrypt does not deliver such certificates you need to create certificates for every sub-domain that you are using. It could be annoying, since you would need as many requests to Let’s Encrypt as you have sub-domains. However, Certbot has a nice feature in order to deal with such demands:

[code language="bash"]
sudo certbot --apache -d test.example.com -d test1.example.com  -d test-special.example.com

With this single request you have created a certificate which can be used at the same time by three sub-domains. In this case, the files will be located in the folder /etc/letsencrypt/live/test.example.com in fact, test, test1 and test-special sub-domains will be stored in the field Certificate Subject Alt Name (in this case, the subject field contains example.com).

Let’s Encrypt certificates with nginx as a reverse proxy

Let's Encrypt: Nginx logo

A lot of people use nginx as a reverse proxy to dispatch entering connections to relevant services (and several sub-domains). With Let’s Encrypt such a situation could induce several problems:

  1. You do not want to interrupt your service while dealing with your certificates.
  2. Some sub-domains could be using Apache and some nginx.
  3. Different subdomains could have specific nginx configurations.

In such a context, invoking Certbot with --nginx option could not be appropriate. In that case it is safer to use the  --webroot option. This very efficient option does not proceed to any configuration after invocation, you need to configure the certificates by yourself. However, it enables to simply interact with specific files: you specify a folder for interaction with Let’s Encrypt servers (say /var/www-example). Then, you also configure your nginx to access this folder for a specific location. In order to answer requests from Let’sEncrypt infrastructure Certbot will have to create specific files within this folder, inside a sub-folder called .well-known.

To sum-up, you have to:

  1. Specify to nginx that access to /.well-known/ folder, for each sub-domain, is handled “locally” in a specific location (say /var/www-example).
  2. Reload nginx configuration.
  3. Launch Certbot using --webroot option and indicating the actual route for the relevant sub-domains.

For nginx, consider the file nginx.conf. Then, add a new location directive, within each server directive (corresponding, presumably to sub-domains):

[code language="bash"]
 location /.well-known/ {
   root /var/www-example; # This is a local folder with respect to nginx host and certbot

After inserting this new location for every sub-domain and reloading nginx configuration, you simply have to invoke Certbot:

[code language="bash"]
certbot certonly --webroot -w /var/www-example/ -d test.example.com -d test1.example.com  -d test-special.example.com

In some cases you want to specify several locations for sub-domains: you simply have to use the option -w more than once (each domain option is configured with the last occurence of -w option).

The great thing with this configuration is that renewal is automated like in the basic case (see our previous article).


This method for obtaining Let’s Encrypt is especially robust and works even when the nginx server is executing in a Docker container. It simply needs that the path of location /.well-known/ to be shared with the host. Obviously, according to the spirit of Docker, Certbot is executed on host server (not within the nginx container).

If you have any question with respect to Let’s Encrypt, do not hesitate to contact us.


About Open Agora

Nuanced and targeted consultations

Open Agora solutions allow you to collect rich opinions and easily reach consensus

Leave a comment

Your email address will not be published.