Let's Encrypt: Configurez votre serveur NGINX pour activer le HTTPS

Je vous l'avais indiqué dans un précédent article, Letsencrypt se prépare à distribuer gratuitement des certificats signés par une autorité publique reconnue par les navigateurs Web du marché.

J'ai profité de cette opportunité pour m'inscrire à Letsencrypt, j'ai pu obtenir gratuitement des certificats pour mon blog avant la date de lancement du service en version beta prévue pour début décembre.

La grande surprise du service proposé est que tout se fait en ligne de commande sous Linux, aucune inscription sur un portail Web n'est nécessaire, l'outil en ligne de commande "letsencrypt-auto" développé en Python et mis à disposition sur Github est suffisant pour obtenir des certificats signés en quelques secondes de la part de Letsencrypt.

La récupération de certificats se fait de la manière suivante depuis un serveur Web qui héberge le domaine sur lequel vous souhaitez obtenir le certificat :

$ sudo ./letsencrypt-auto certonly -a webroot --webroot-path /var/www/www.geeek.org/public_html/ --agree-dev-preview -d geeek.org -d www.geeek.org --server https://acme-v01.api.letsencrypt.org/directory  --rsa-key-size 2048

Le script doit probablement générer un fichier aléatoire dans le webroot du serveur pour permettre aux serveurs de Letsencrypt de s'assurer du propriétaire du domaine.

Cette commande initialise toute une arborescence de répertoires dans "/etc/letsencrypt/" et provisionne la clef privée et la clef publique nécessaire à la configuration du serveur Web. Dans mon cas, j'ai utilisé des clefs RSA en 2048 bits, largement suffisantes pour assurer l'anonymisation du contenu vu par mes visiteurs sur la toile, mais considérées insuffisante pour l'échange d'informations personnelles.

Une fois les certificats générés et signés par Letsencrypt, j'ai du offrir les droits d'accès en lecture au répertoire "live" et "archives" pour l'utilisateur www-data utilisé par le serveur NGINX afin qu'il puisse accéder à ces certificats :

 
$ sudo  chmod 750 ./live ./archive
$ sudo  chgrp -R www-data ./live ./archive

''NB : Vous le remarquerez, les certificats courants présents dans le répertoire "live" sont des liens symboliques vers les certificats présents dans le répertoire "archives"''

Ensuite, j'ai généré une clef de chiffrement Diffie-Hellman pour renforcer la sécurité du site :

$ sudo openssl dhparam -out /etc/ssl/private/dhparams.pem 2048

Une fois cette commande effectuée, j'ai configuré le fichier "nginx.conf" et le fichier de configuration du "virtual host" présent dans le répertoire "site-enabled" afin de leur préciser les paramètres HTTPS à utiliser et le chemin vers les clefs privées et publiques. J'ai positionné dans le fichier "nginx.conf" l'ensemble des paramètres que je souhaite partager pour tous les vhosts de mon serveur.

Voici mes modifications du fichier "nginx.conf" :

# On autorise une large liste de cypher pour C*tre compatible avec le maximum de navigateurs
ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK';
ssl_prefer_server_ciphers on;

# On n'autorise pas le SSLv3 qui souffre de la faille Poodle.
ssl_protocols TLSv1.1 TLSv1.2;

# On met en cache les sessions TLS pour faire des C)conomies de CPU.
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 1d;

# On positionne le certificat Diffie-Hellman gC)nC)rC) prC)cC)demment 
ssl_dhparam /etc/ssl/private/dhparams.pem;

# On active le SSL Stapling avec les DNS de Google
ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 8.8.4.4 valid=86400;
resolver_timeout 10;

Voici ensuite les modifications du "virtual host" pour appliquer les éléments de configuration spécifiques au "virtual host":

$ sudo vi /etc/nginx/sites-enabled/geeek.org

Tout d'abord, je redirige en 301 tous les flux HTTP de tous les sous-domaines vers le "virtual host" en HTTPS. Cela me permet d'effectuer la migration tout en douceur sans perdre les liens entrants vers mon blog.

server {
        listen 80;
        server_name *.geeek.org *.geeek.fr geeek.org geeek.fr;
        return 301 https://www.geeek.org$request_uri;
}

Ensuite, voici la déclaration du serveur HTTPS :

server {
        # On active le SSL et on C)coute sur le port 443
        listen 443 ssl;

        # On rC)fC)rence la clef publique et la clef privC)e
        ssl_certificate /etc/letsencrypt/live/www.geeek.org/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/www.geeek.org/privkey.pem;

        # Pour le SSL Stapling 
        ssl_trusted_certificate /etc/letsencrypt/live/www.geeek.org/chain.pem;

        # On force l'utilisation du HTTPS au travers d'un header HTTP
        add_header Strict-Transport-Security max-age=15768000;

        server_name www.geeek.org;
        ....

Une fois ces modifications réalisées, il suffit de redémarrer le processus NGINX pour prendre en compte ces nouveaux paramètres :

$ sudo /etc/init.d/nginx restart

Un petit test sur un navigateur est nécessaire afin d'identifier l'ensemble des ressources qui ne se chargent plus pour des raisons de sécurité. Cela est peut-être le cas si vous avez des ressources statiques chargées avec leurs protocoles : CSS, JS ...

Assurez-vous de la bonne prise en compte du certificat par le navigateur :

Enfin, un test Qualys SSL Lab s'impose pour vérifier la configuration HTTPS de votre site Internet :

Si vous avez suivi cet article, vous devriez obtenir une note A+ tout comme ce blog.

---