certificat letsencrypt

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 ê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 économies de CPU.
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 1d;

# On positionne le certificat Diffie-Hellman généré précé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 écoute sur le port 443
        listen 443 ssl;

        # On référence la clef publique et la clef privé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 :

ssl info chrome

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.

test ssl qualys

  • Clone carte RFID Mifare

    Hacking : Comment cloner une carte RFID ?

    Les cartes RFID Mifare 1K possèdent deux protections principales : Le block 0 est en lecture seule, seul le constructeur de la carte peut initialiser ce block. Les données écrites sur les cartes sont encryptées. Il existe cependant des solutions pour outrepasser ces protections et permettre de créer des copies exactes. Cet article détaille la procédure pour cloner une carte RFID Mifare 1k sous Linux.

  • Tutoriel Backtrack 5 : Comment cracker un réseau Wifi protégé avec du WPA

    Voici un tutoriel intéressant sur les outils de bruteforce WPA mis à disposition dans la distribution Linux Backtrack 5.

1. Le , 14:01 par Pierrick
5afe0856bc099c5f28e3b3b98f0c3e88

Sans vouloir entrer dans un grand débat, je ressens une inquiétude par rapport à la facilité d'accès à un certificat dans le cas de site de phishing par exemple.

Ajouter un commentaire

Le code HTML est affiché comme du texte et les adresses web sont automatiquement transformées.