Let’s Encrypt : configuration avancée

Let's Encrypt

Voici notre second article dans la série boîte à outil de la startup. A présent, nous allons approfondir la configuration et l’utilisation de Certbot, l’outil principal pour obtenir et gérer les certificats SSL. Nous considérons que vous êtes déjà familier de notre article précédent.

Lire aussi sur notre blog

Let’s Encrypt : la sécurité SSL pour tous

Des certificats pour d’autres services

Il y a de nombreux autres services qui utilisent des certificats SSL, tels que les serveurs SMTP ou IMAP. Ces services peuvent également utiliser les certificats Let’s Encrypt. Il est simplement nécessaire de préciser leur emplacement dans les fichiers de configuration.

Voici une courte présentation de quelques-uns de ces fichiers :

Postfix, serveur SMTP (dans le fichier /etc/postfix/main.cf):

 # TLS parameters smtp_tls_security_level = may smtpd_tls_cert_file=/etc/letsencrypt/live/test.exemple.com/fullchain.pem smtpd_tls_key_file=/etc/letsencrypt/live/test.exemple.com/privkey.pem smtpd_use_tls=yes 

Dovecot, serveur IMAP (dans le fichier /etc/dovecot/conf.d/10-ssl.conf):

 ssl_cert = </etc/letsencrypt/live/test.exemple.com/fullchain.pem ssl_key = </etc/letsencrypt/live/test.exemple.com/privkey.pem 

De même, il est possible de mettre en place les certificats Let’s Encrypt pour tous les services qui s’appuient sur SSL. Le principe général est d’utiliser le fichier fullchain.pem à la place du certificat ordinaire. Il suffit de pointer vers le lien contenu dans le dossier live.

Des certificats pour plusieurs sous-domaines

Il est fréquent d’utiliser des certificats SSL avec des jokers (wildcards), par exemple *.exemple.com, ces derniers sont pratiques car ils peuvent être utilisés sur tous les sous-domaines d’un domaine. Let’s Encrypt ne signe pas ces certificats. Il est donc indispensable de créer des certificats pour chacun de vos sous-domaines. Ceci peut se révéler fastidieux. Néanmoins, Certbot permet, en une seule demande, d’obtenir un certificat valide pour un ensemble de sous-domaines :

 sudo certbot --apache -d test.exemple.com -d test1.exemple.com -d test-special.exemple.com 

Cette simple requête permet la signature d’un certificat unique qui pourra être utilisé pour les trois sous-domaines de cet exemple. Ici, les fichiers sont tous placés dans le dossier /etc/letsencrypt/live/test.exemple.com. Concrètement, les noms des sous-domaines test, test1 et test-special sont mémorisés dans le champ « Subject Alt Name » du certificat (dans ce cas, le champ « Subject » contient exemple.com).

Les certificats Let’s Encrypt pour un serveur nginx en tant que « reverse proxy »

Let's Encrypt - Nginx logo

Beaucoup de service utilise le logiciel nginx pour servir de « reverse proxy ». C’est-à-dire que nginx distribue les connexions entrantes vers les services concernés (répartis suivant plusieurs sous-domaines). Cette situation peut induire plusieurs problèmes vis-à-vis de Let’s Encrypt:

  1. On ne souhaite pas interrompre le service pendant la signature des certificats.
  2. Certains sous-domaines peuvent utiliser Apapche et d’autres nginx.
  3. Chacun des sous-domaines peut avoir une configuration spécifique de nginx.

Dans ce cas de figure, invoquer Certbot simplement avec l’option --nginx pourrait se révéler inadapté. Ici, il est plus prudent d’utiliser l’option --webroot. Cette solution très efficace ne réalise pas la configuration des certificats pour nginx ou Apache, il est donc nécessaire de configurer les certificats « à la main ». En revanche, il permet une interaction très simple avec les fichiers : pour chacun des sous-domaines, on spécifie un dossier d’interaction pour certbot (par exemple /var/www-exemple). Ensuite, il suffit de spécifier à nginx d’accéder à ce fichier pour un emplacement précis (location dans la configuration de nginx). Pour pouvoir répondre aux défis lancés par l’infrastructure de Let’s Encrypt, Certbot va créer des fichiers spécifiques à l’intérieur de ce dossier, à l’intérieur d’un sous-dossier .well-known.

En résumé, on doit :

  1. spécifier à nginx le dossier local (par exemple /var/www-exemple) qu’il doit ouvrir lorsqu’il reçoit une requête sur le chemin /.well-known/, pour chacun des sous-domaines.
  2. Recharger la configuration de nginx.
  3. Lancer Certbot avec l’option --webroot et en indiquant le chemin utilisé pour les sous-domaines demandés.

Pour nginx, dans le fichier nginx.conf, pour chacune des directives server, il faut ajouter une directive location (qui correspond à ce sous-domaine) :

server{
 ...
 location /.well-known/ {
   root /var/www-exemple; # Il s'agit du dossier local par rapport au serveur nginx et à certbot
  }
}

Après avoir ajouté cette nouvelle directive pour chacun des sous-domaines et avoir rechargé la configuration de nginx, il ne reste plus qu’à appeler Certbot :

certbot certonly --webroot -w /var/www-exemple/ -d test.exemple.com -d test1.exemple.com  -d test-special.exemple.com

Dans certains cas, vous pouvez spécifier différents dossiers pour des sous-domaines différents, il suffit alors d’utiliser plusieurs fois l’option -w (chacun des sous-domaines est configuré avec le dossier défini par la dernière occurrence de l’option -w).

Comme dans le cas simple, le renouvellement des certificats est automatique (voir notre article précédent).

Conclusion

Cette méthode pour obtenir les certificats Let’s Encrypt est particulièrement robuste et fonctionne même si le serveur nginx s’exécute à l’intérieur d’un conteneur Docker. Il suffit que le dossier affecté au chemin /.well-known/ soit dans un espace partagé avec l’hôte. Naturellement pour respecter l’esprit Docker, la machine hôte exécutera Certbot.

Si vous avez la moindre interrogation sur Let’s Encrypt, n’hésitez pas à nous contacter.

avatar

A propos d’Open Agora

Consultations nuancées et ciblées

Les solutions Open Agora permettent de collecter des opinions riches et d’atteindre facilement le consensus

Partager / Share this...