#page { background: url("https://www.coolcoyote.net/wp-content/themes/coolcoyote2/images/kubrickbgwide.jpg") repeat-y top; border: none; } */ ?>

Configurer un certificat Let’s Encrypt sur Debian

Sources :

Cette installation a été effectuée sur une Debian Wheezy avec Apache 2.2.x mais cette doc fonctionne également sur une Jessie. Les commandes ci dessous sont lancées en root (pensez à rajouter les sudo si besoin).

Nous allons ici utiliser Certbot qui est le client officiel Let’s Encrypt pour gérer les certificats sur votre serveur. Il existe cependant d’autres alternatives.

Première chose à faire, vérifier que le module SSL d’Apache est bien activé (dans /etc/apache2/mods-enabled). Si ce n’est pas le cas :

> a2enmod ssl
> service apache2 restart

Installer ensuite le client Let’s Encrypt  dans le répertoire /usr/local/sbin

> cd /usr/local/sbin
> wget https://dl.eff.org/certbot-auto
> chmod a+x certbot-auto

Par défaut le client LE est censé pouvoir modifier automatiquement les virtualhosts Apache. Non seulement pour moi ça n’a pas du tout fonctionné, mais en plus je n’aime pas trop que des scripts tiers viennent trifouiller mes virtualhosts. La procédure décrite ci-dessous ne fait donc que générer les certificats, nous aurons à configurer Apache manuellement par la suite.

On peut maintenant lancer la génération des certificats :

> certbot-auto --apache certonly -d www.mondomaine.fr

On vous demandera quelques informations, dont une adresse email qui recevra toutes les informations notamment celle de renouvellement. Ne pas mettre n’importe quoi donc !

Note : vous pouvez créer un certificat pour un domaine et ses sous-domaines dans la même commande :

> certbot-auto --apache certonly -d domaine.fr -d www.mondomaine.fr -d admin.mondomaine.fr

Vous pouvez aussi inclure d’autres domaines dans la liste, mais un seul certificat sera créé pour tous les domaines. Certbot ne créera pas un certificat par domaine. Dans ce cas il faudra relancer la commande pour chaque domaine dont vous voulez un certificat différent.

Note : il semble que pour le moment il ne soit pas possible de générer un certificat pour un domaine et tous ses sous-domaines via une wildcard (par exemple *.mondomaine.fr), il faut spécifier tous les sous-domaines à activer.

Note2 : Dans notre cas, la configuration a été faite sur une Debian Wheezy qui est un peu ancienne. Il se peut qu’en voulant créer le certificat vous ayez le message d’erreur suivant :

The apache plugin is not working; there may be problems with your existing configuration.
The error was: NotSupportedError('Apache plugin support requires libaugeas0 and augeas-lenses version 1.2.0 or higher, please make sure you have you have those installed.',)

Pour corriger ce problème nous allons devoir utiliser le dépôt backports de Wheezy. Dans /etc/apt/sources.list, rajouter la ligne :

deb http://ftp.debian.org/debian wheezy-backports main

On va ensuite mettre à jour la config et installer les packages qui nous manquent :

> apt-get update
> apt-get install -t wheezy-backports libaugeas0 augeas-lenses

Il n’y a pas ce problème sur une Jessie.

Autre problème que l’on peut rencontrer sur une Wheezy et que l’on peut également rencontrer lors de la mise à jour des certificats : Let’s Encrypt n’arrive pas à se connecter à notre serveur pour valider le domaine. On a un message du genre :

urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Failed to connect to xxx.xxx.xxx.xxx:443 for TLS-SNI-01 challenge

Sans rentrer dans les détails, si vous rencontrez cette erreur il faut modifier le fichier /etc/apache2/ports.conf et remplacer

<IfModule mod_ssl.c>

par

<IfModule ssl_module>

Vous pouvez désormais relancer votre commande de création de certificat.

Le client a créé un répertoire /etc/letsencrypt dans lequel il a placé toutes les infos, notamment :

  • un fichier options-ssl-apache.conf qui contient des directives de configuration à insérer dans notre virtualhost
  • les certificats de notre/nos domaine(s) dans /etc/letsencrypt/live/

Maintenant, on peut modifier notre virtualhost Apache.

On va partir du principe que l’on a une configuration très basique :

<VirtualHost *:80>
    ServerName www.mondomaine.fr

    DocumentRoot /var/www/mondomaine.fr/web

    <Directory /var/www/mondomaine.fr/web>
        Options -Indexes
    </Directory>
</VirtualHost>

<VirtualHost *:80>
    Servername mondomaine.fr
    Redirect permanent / http://www.mondomaine.fr/
</VirtualHost>

On va commencer par modifier le port du virtualhost et y insérer les commandes de base SSL :

<VirtualHost *:443>
    ServerName www.mondomaine.fr

    DocumentRoot /var/www/mondomaine.fr/web

    <Directory /var/www/mondomaine.fr/web>
        Options -Indexes
    </Directory>

    SSLEngine on
    SSLCertificateFile /etc/letsencrypt/live/www.mondomaine.fr/cert.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/www.mondomaine.fr/privkey.pem
    SSLCertificateChainFile /etc/letsencrypt/live/www.mondomaine.fr/chain.pem

</VirtualHost>

On va ensuite récupérer les infos supplémentaires dans le fichiers options-ssl-apache.conf et les rajouter. Les directives qui nous intéressent sont : SSLProtocol, SSLCipherSuite, SSLHonorCipherOrder, SSLCompression et SSLOptions. Ce qui donnera par exemple :

<VirtualHost *:443>
    ServerName www.mondomaine.fr

    DocumentRoot /var/www/mondomaine.fr/web

    <Directory /var/www/mondomaine.fr/web>
        Options -Indexes
    </Directory>
 
    SSLEngine on
    SSLCertificateFile /etc/letsencrypt/live/www.mondomaine.fr/cert.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/www.mondomaine.fr/privkey.pem
    SSLCertificateChainFile /etc/letsencrypt/live/www.mondomaine.fr/chain.pem
 
    SSLProtocol all -SSLv2 -SSLv3
    SSLCipherSuite ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS
    SSLHonorCipherOrder on
    SSLCompression off
    SSLOptions +StrictRequire
</VirtualHost>

A noter qu’il est tout à fait possible également d’inclure le fichier options-ssl-apache.conf dans le VirtualHost si celui-ci vous convient tel quel. Notre virtualhost est fin prêt. Il nous reste maintenant à rediriger les requêtes http vers https. Pour cela on va modifier notre redirection d’origine :

<VirtualHost *:80>
    Servername mondomaine.fr
    Redirect permanent / http://www.mondomaine.fr/
</VirtualHost>

en :

<VirtualHost *:80>
    Servername mondomaine.fr
    ServerAlias www.mondomaine.fr
    Redirect permanent / https://www.mondomaine.fr/
</VirtualHost>

Avant de reloader le serveur on va vérifier que la config est OK et que l’on n’aura pas de mauvaise surprise :

> apachectl -t

Si pas de soucis, on peut recharger la config :

> service apache2 reload

Il se peut que vous ayez un warning lors de la validation de la config Apache :

[warn] _default_ VirtualHost overlap on port 443, the first has precedence

Dans ce cas il faut éditer le fichier /etc/apache2/ports.conf et rajouter la ligne :

NameVirtualHost *:443

sous :

NameVirtualHost *:80

Votre domaine est prêt ! Si votre domaine fonctionne en https, vous pouvez compléter vos tests avec le site https://www.ssllabs.com/ssltest/index.html qui va tester le certificat et vous produire un rapport.

Il nous reste un dernier détail à régler. Le certificat délivré par Let’s Encrypt est valable 90 jours. Il faut donc qu’il soit renouvelé avant son expiration. Pour cela il faut lancer la commande :

> certbot-auto renew

Cette commande va vérifier automatiquement tous les certificats de votre serveur et renouveler ceux qui vont expirer dans moins de 30 jours. Dans un premier temps, il est bon de vérifier que cette commande fonctionnera bien le moment venu. Pour cela on peut lancer une simulation de renouvellement via :

> certbot-auto renew --dry-run

L’idéal bien sûr est maintenant d’automatiser cela via un cron qui s’exécutera deux fois par jour (recommandé par certbot) :

30 2/12 * * * /usr/local/sbin/certbot-auto renew >> /var/log/le-renew.log

Le fait d’exécuter la commande deux fois par jour permet, en cas de problème lors du renouvellement ou si une révocation imprévue intervient du côté de Let’s Encrypt, de pouvoir renouveler rapidement les certificats. Cette commande ne lancera le renouvellement que si votre certificat est éligible.

 



Laisser une réponse

Vous devez être connecté pour publier un commentaire.