Le HTTPS, vous connaissez ? C’est la version sécurisée du protocole HTTP, à l’aide d’une couche de SSL ou TLS. Votre site n’a pas encore ce petit cadenas à côté de son URL ? Vous payez chaque année votre certificat ? Vous êtes obligés de faire une flopée d’opérations manuelles pour renouveler le certificat en question ? Alors cet article est fait pour vous.
Nous allons voir comment, à l’aide de Let’s Encrypt, obtenir un certificat pour votre site, gratuitement, simplement, et avec un renouvellement automatique.
Pour ceux qui ne comprendraient pas l’intérêt de tout ça, voici quelques raisons de passer vos sites en HTTPS :
- Le HTTPS améliore le référencement ! Les sites en HTTPS reçoivent en effet un coup de boost dans les recherches Google.
- Le fameux cadenas rassure tout le monde. Les gens hésitent de plus en plus à mettre leur mot de passe sur une page non sécurisée ! Et ils ont raison ! Le cadenas (vert, gris, tout dépend du navigateur) donne tout de suite confiance à l’utilisateur et de la crédibilité au site qu’ils visitent.
- Les principaux navigateurs ont choisi de rendre obligatoire le HTTPS pour le protocole HTTP/2 (qui permettra notamment d’augmenter considérablement les performances de vos sites web).
- Le HTTPS permet d’assurer l’authenticité et l’intégrité des données chargées pour l’utilisateur, tout en protégeant sa vie privée.
- Le HTTPS est obligatoire pour utiliser les services workers. En avant pour l’offline first !
- Le HTTPS permet de se préparer à l’arrivée du « physical web » : par exemple, il est obligatoire pour broadcaster une URL via un beacon.
Et maintenant les meilleures raisons :
- Le HTTPS c’est gratuit !
- Le HTTPS c’est vraiment simple à mettre en place.
« Mais Let’s Encrypt, qu’est-ce que c’est ? »
Let’s Encrypt
Let’s Encrypt est ce qu’on appelle une autorité de certification, ou CA (pour Certificate Authority en anglais). C’est une nouvelle autorité de certification qui fournit des certificats gratuits à l’aide d’un processus complètement automatisé.
Let’s Encrypt est sponsorisé par des géants du Web et son principal but est que l’ensemble des sites Web soient à terme sécurisés. C’est cette autorité de certification qui va nous délivrer un certificat.
Ce certificat est unique, propre au site visé et est signé par l’autorité de certification qui l’attribue. Elle doit donc vérifier qu’elle le délivre à la bonne personne, celle à qui appartient le site. Si vous avez déjà demandé un certificat SSL à un autre organisme, cette validation peut consister en un code envoyé sur l’adresse email « postmaster@mondomaine.com ». De cette manière, si vous recevez le code par email, c’est que vous êtes bien le propriétaire (ou le gestionnaire) du domaine. Et vous avez de fait le droit de demander un certificat SSL pour ce domaine.
Let’s Encrypt nous propose quelque chose de différent.
« No validation emails, no complicated configuration editing, no expired certificates breaking your website. »
Avec Let’s Encrypt, plus besoin de boîte mail, plus de code de validation. Let’s Encrypt nous propose une nouvelle manière, un nouveau processus pour l’obtention de notre certificat. Nous verrons cela un peu plus loin.
Car il est temps après ces présentations de passer à la pratique pour aborder la question qui doit vous bruler les lèvres :
« Comment migrer mon site en HTTPS avec Let’s Encrypt ? »
Use case : Apache
Nous allons utiliser le client officiel de Let’s Encrypt, appelé Certbot. Il fonctionne avec un ensemble de plug-ins qui vont dépendre des utilisations. Ici, nous allons donc commencer par découvrir le plug-in Apache.
Sur la page principale de Certbot, on choisit notre serveur web – dans notre cas Apache – et notre OS. Puis, on suit les instructions pour l’installer.
J’entends déjà des protestations : « Mais j’utilise Nginx !« . Ne vous inquiétez pas, nous traiterons ce point un peu plus loin. Occupons-nous d’abord des 50% de cas classiques.
La situation initiale
Partons du principe que vous avez un serveur, accessible depuis internet, avec votre site web servi par un serveur Apache. Vous avez votre site actuellement servi en HTTP et votre fichier de configuration basique ressemble à :
<VirtualHost *:80>
ServerAdmin webmaster@mondomaine.com
ServerName mondomaine.com
DocumentRoot /var/www/html
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>
Parfait ! C’est le cas de base vraiment bien géré par Certbot.
Certbot
Ensuite, on lance Certbot avec la commande :
$ sudo certbot
Une interface s’ouvre :
- Certbot repère vos configurations Apache, et vous êtes invité à choisir le ou les domaines que vous souhaitez sécuriser (on utilise la touche espace pour sélectionner/désélectionner).
- On vous demande de lire et d’accepter le contrat de licence.
- Puis, on vous demande si vous souhaitez garder votre site accessible en HTTP en plus du HTTPS, ou en HTTPS uniquement.
Dans le second cas, Certbot va modifier votre configuration Apache pour ajouter une redirection du HTTP vers le HTTPS. Quoi qu’il arrive, Certbot ajoute un nouveau fichier dans les sites-availables d’Apache avec un VirtualHost sur le port 443. Ce VirtualHost contiendra la même configuration que votre VirtualHost initial, mais avec les directives nécessaires au fonctionnement de votre site en HTTPS. Certbot active ce site, recharge la configuration Apache et vous rend la main.
Bravo, vous avez migré votre site en HTTPS en seulement une ligne !
Notez que votre nouveau certificat est valable pour une durée de 90 jours.
« Donc je vais devoir recommencer tous les 3 mois ? »
Heureusement que non ! Certbot a tout prévu. Il installe un cron qui va s’occuper de renouveler tous les certificats de façon automatique. Et ça n’est pas 3 mois, mais bien 90 jours… Tout cela paraît un peu magique, mais il y a un vrai processus qui s’exécute en arrière-plan pour délivrer le certificat. Voyons comment ça marche.
La délivrance du certificat
Le certificat et la chaîne de confiance
Le certificat qui vous est délivré est signé par Let’s Encrypt à l’aide de son propre certificat. Étant une autorité de certification, Let’s Encrypt a le droit de vous délivrer ce dernier, et pour que tous les navigateurs reconnaissent votre certificat comme étant authentique, une chaîne de confiance entre les différentes autorités de certification est établie.
Plusieurs autorités de certifications, dites « racines » (des autorités de certification enregistrées et certifiées auprès des autorités publiques), fournissent et signent les certificats des autres autorités de certifications, qui s’en servent à leur tour pour signer les certificats qu’elles délivrent. C’est ce qu’on appelle la chaîne de confiance. Ça fait beaucoup de répétitions, mais avec un schéma ça sera plus simple pour suivre…
Les navigateurs connaissent pour la plupart les certificats racines, et pour authentifier votre certificat, le navigateur a besoin de faire le lien entre le certificat racine et votre certificat. C’est le certificat intermédiaire de Let’s Encrypt qui dans notre cas aura ce rôle d’intermédiaire.
De cette manière, le navigateur peut s’assurer que la chaîne de confiance est bien respectée et que votre certificat a bien été délivré par un organisme qui lui même a obtenu son certificat auprès d’un organisme qu’il connaît.
La validation du domaine
C’est pour ne pas casser cette chaîne de confiance que Let’s Encrypt doit valider que le domaine pour lequel vous demandez un certificat vous appartient bien. Pour comprendre comment les différents plug-ins de Certbot fonctionnent, il faut comprendre le processus de validation du domaine effectué par Let’s Encrypt.
Let’s Encrypt part du principe que si vous avez accès à la machine vers laquelle pointe votre domaine, c’est que c’est bien votre domaine (ou tout du moins que vous en êtes le gestionnaire), et donc que vous avez le droit de demander un certificat SSL pour ce domaine.
Il ne reste plus qu’à vérifier que vous avez bien la main sur la machine en question. Rien de plus simple : Certbot va créer un « challenge », autrement dit un fichier formaté contenant un code, et vous demander d’exposer une URL de son choix qui renverra ce challenge. Cette URL sera sur le domaine pour lequel vous voulez obtenir un certificat.
Let’s Encrypt vérifie que l’URL répond bien ce qui vous a été demandé, et si oui, c’est que vous avez bien la main sur le serveur, et donc que vous gérez le domaine. Hop, votre certificat est livré.
Le plug-in manuel
Le plug-in manuel permet de bien voir et comprendre le processus de validation du domaine. Essayons de demander un certificat pour le domaine mondomaine.com via ce dernier, en tapant la commande suivante :
$ sudo certbot certonly --manual -d mondomaine.com
Let’s Encrypt va alors vous demander d’exposer par exemple l’URL suivante :
http://mondomaine.com/.well-known/acme-challenge/CIDAZIFEFEIdazzoifze887dzde
et que cette page affiche le contenu :
CIDAZIFEFEIdazzoifze887dzde.dzafez6556DZA64dzadza5
Il vous propose même un petit bout de code python qui va permettre de lancer un serveur web temporaire et d’exposer ce challenge à cette URL. Let’s Encrypt vérifie que l’URL répond bien ce qui a été demandé, et si oui, il délivre votre certificat.
« Ça avait l’air beaucoup plus simple avec le plug-in Apache ! »
En effet, le plug-in Apache masque cette complexité en configurant pour vous un VirtualHost temporaire qui va répondre le challenge attendu à l’URL voulue. Mais au final la vérification reste la même !
Attention :
- avec le plug-in manuel, le renouvellement automatique n’est pas possible. Il faudra donc faire la manipulation tous les 90 jours maximum. Le plug-in manuel est donc à utiliser uniquement si les autres plug-ins ne répondent pas à votre besoin !
- si vous utilisez le plug-in manuel sur un serveur ayant déjà un serveur web, et que vous utilisez le bout de code Python fournit par Certbot pour exposer le challenge, vous allez devoir couper votre serveur web actuel. Cela peut être vraiment gênant si votre site web tourne dessus, de devoir couper l’accès à votre site pour obtenir un certificat. Dans ce cas, il vaut mieux utiliser un autre plug-in que le plug-in manuel.
« Alors pourquoi j’utiliserais le plug-in manuel ? »
Il peut être intéressant dans le cas où vous ne voulez pas (ou ne pouvez pas) installer Certbot sur le serveur pour lequel est destiné le certificat. Par exemple si votre serveur est sous Windows, ou votre application est hébergée sur un PaaS.
Mais je sens les utilisateurs d’Nginx s’impatienter derrière leur écran. Occupons-nous de leur cas.
« J’utilise Nginx, mais j’ai aussi un site qui tourne sous Lighthttpd… Ça marche aussi ? »
À la date de rédaction de cet article, le plug-in Nginx de Certbot est en développement, et est très expérimental. Nous allons donc préférer utiliser le plug-in « webroot » qui permet d’obtenir un certificat avec n’importe quel serveur web. En contrepartie, nous allons devoir faire la configuration SSL nous-mêmes. Mais ce plug-in webroot fonctionne avec n’importe quel serveur web : Nginx, Lighthttpd, etc.
Le plug-in webroot
Ce plug-in va permettre d’exposer sur le serveur web le fichier de challenge pour la vérification du domaine. De ce fait, nous allons pouvoir obtenir un certificat sans couper le serveur web. Et ça nous arrange ! Qui voudrait avoir à couper son site de production pour obtenir un certificat ?
L’obtention du certificat
Pour utiliser le plug-in webroot, il faut créer sur le serveur un dossier /var/www/certbot/ qui va servir à Certbot à placer les fichiers contenant les challenges utiles lors de la vérification du domaine.
De cette manière, c’est le plug-in webroot qui ira placer les fichiers voulus au bon endroit sur le serveur. Il ne nous reste qu’à exposer le dossier /var/www/certbot/.well-known/acme-challenge/ utilisé par Certbot à l’URL http://mondomaine.com/.well-known/acme-challenge/.
On ajoute la directive « location » pour exposer le dossier que l’on veut au sein de la configuration qui expose le port 80.
Par exemple pour Nginx :
server {
listen 80;
root /var/www/mondomaine.com/;
index index.html;
server_name mondomaine.com www.mondomaine.com;
location ~ /.well-known/ {
allow all;
default_type "text/plain";
root /var/www/certbot/;
}
}
Ensuite on exécute le plug-in webroot de Certbot :
$ sudo certbot certonly --webroot \
--webroot-path /var/www/certbot/ \
-d mondomaine.com -d www.mondomaine.com
Remarquez qu’on peut préciser plusieurs domaines ou sous-domaines dans notre ligne de commande pour que notre certificat soit valide pour tous ces domaines ou sous-domaines.
Le plug-in webroot s’exécute, utilise le dossier que nous avons spécifié et exposé via Nginx pour placer les challenges, valide notre domaine, et nous délivre un certificat.
L’utilisation du certificat
Les certificats ainsi délivrés sont placés dans le dossier /etc/letsencrypt/live/ et rangés par domaine. On retrouve dans le dossier correspondant à notre domaine plusieurs fichiers :
.
├── cert.pem -> ../../archive/mondomaine.com/cert1.pem
├── chain.pem -> ../../archive/mondomaine.com/chain1.pem
├── fullchain.pem -> ../../archive/mondomaine.com/fullchain1.pem
└── privkey.pem -> ../../archive/mondomaine.com/privkey1.pem
On remarque que tous ces fichiers sont en fait des liens symboliques qui pointent vers des sources situées dans le dossier /etc/letsencrypt/archives/mondomaine.com/. Comme ça, le dossier « archives » garde tout l’historique des certificats que nous avons eus, alors que dans le dossier “live”, nous avons toujours le certificat le plus récent et valide.
Ces quatre fichiers ont chacun un rôle bien particulier :
- cert.pem est le certificat en lui même
- chain.pem est le certificat intermédiaire de Let’s Encrypt
- fullchain.pem est la concaténation de cert.pem et de chain.pem
- privkey.pem est la clé privée du certificat
Nous allons donc maintenant ajouter la configuration Nginx nécessaire pour que notre site soit exposé en HTTPS à l’aide de notre certificat fraîchement obtenu.
server {
listen 443 ssl;
root /var/www/mondomaine.com/;
index index.html;
server_name mondomaine.com www.mondomaine.com;
ssl on;
ssl_certificate /etc/letsencrypt/live/mondomaine.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/mondomaine.com/privkey.pem;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-RC4-SHA:ECDHE-RSA-AES128-SHA:AES128-SHA:RC4-SHA;
ssl_session_cache shared:SSL:10m;
add_header Strict-Transport-Security max-age=31536000;
}
Et voilà ! Notre site est accessible en HTTP et en HTTPS.
Attention : pour permettre le renouvellement automatique de notre certificat, il faut laisser dans la configuration HTTP le bloc suivant :
location ~ /.well-known/ { … }
Les limitations
Let’s Encrypt apporte donc une solution efficace pour obtenir facilement, automatiquement et gratuitement des certificats. Mais tout n’est pas parfait. Ça serait trop simple ! Il faut donc bien connaitre ses limitations. Par exemple, Let’s Encrypt ne délivre pour l’instant que des certificats de classe 1, c’est-à-dire les certificats DV.
Il y a plusieurs niveaux de certificats. Les différents niveaux sont généralement appelés « classes ».
- Le certificat DV (Domain Validation) : parfait pour chiffrer toutes les communications, mais n’offre aucune preuve de l’identité du propriétaire du site.
- Le certificat OV (Organisation Validation) : affiche le nom de l’organisme dans les détails du certificat, consultable sur les navigateurs. Pour obtenir ce type de certificat, une vérification plus poussée est effectuée lors de la délivrance par l’autorité de certification.
- Le certificat EV (Extended Validation) : affiche directement le nom de l’organisme dans la barre d’URL du navigateur (par exemple le site de PayPal, Symantec, Globalsign).
Vous l’aurez compris : pour les autres classes de certificats, des vérifications manuelles doivent être effectuées par les autorités de certification, et il est donc impossible d’automatiser le processus.
Il y a aussi des limitations en ce qui concerne le nombre de certificats délivrés : prenez connaissance de la liste complète de ces limites ! Exemple : la limite pour chaque domaine est de 20 certificats par semaine.
Migrer en HTTPS
Si votre site est déjà en ligne en HTTP, il y a quelques précautions à prendre pour le passer en HTTPS. Vérifiez en premier lieu que tous les liens présents dans vos pages pointent vers des contenus en HTTPS ! En effet, si depuis votre page en HTTPS vous chargez une image qui est en HTTP, le navigateur affichera un warning :
Ce warning prévient de la présence de « mixed-content passifs » sur la page. Ça n’est qu’un warning et il n’aura pas d’incidence néfaste sur le site pour sa consultation, mais il sera responsable de l’absence de cadenas à côté de votre URL… La mission qui consiste à rassurer les utilisateurs sera donc un échec.
Il y a un autre type de « mixed-content« , qui lui est dit “actif”. Si depuis votre page en HTTPS, vous chargez par exemple un script qui est lui en HTTP, dans ce cas le navigateur affichera une erreur et refusera tout simplement de charger le script.
Dans ce screenshot, on peut voir que sur ce site, le fichier JavaScript contenant la librairie JQuery est chargé en HTTP. Le navigateur refuse de le charger, et cela provoque des erreurs par la suite. Dans ce cas, c’est nettement plus gênant puisque le site fonctionnera certainement mal (ou pas) s’il manque des librairies importantes.
Pour plus d’informations sur les mixed-contents vous pouvez regarder cette page.
tl;dr
Le HTTPS devient accessible à tous, gratuitement, très simplement, et de façon automatique. Que vous utilisiez Apache, Nginx ou un autre serveur web, il existe une solution pour que vous puissiez obtenir votre certificat grâce à Let’s Encrypt. Le HTTPS permet de gagner la confiance des utilisateurs et une certaine protection de la vie privée de ces derniers. Bref, foncez. Même si parfois il faudra bien prendre en compte l’architecture existante pour éviter les pépins !
The post HTTPS everywhere, avec Let’s Encrypt appeared first on SFEIR Mag.