Installation d’un certificat SSL Let’s encrypt avec la méthode Webroot avec un serveur web Nginx
Il y a quelques semaines j’avais mis en place un certificat Let’s encrypt pour feub.net pour Nginx. A ce moment j’avais utilisé la méthode Standalone verification de Let’s encrypt qui est automatique mais qui a le désavantage d’utiliser le port 80, donc il faut stopper le serveur web pendant la génération du certificat, occasionnant un petit downtime du ou des site(s).
Ce petit inconvénient peut-être supprimé en utilisant la méthode Webroot proposée par Let’s encrypt, c’est celle-ci que je vais décrire ici et que j’ai utilisé pour renouveler le certificat pour feub.net.
Utilisation du plugin Webroot
Le plugin Webroot fonctionne de la sorte, un fichier est créé dans le répertoire .well-known à la racine du serveur web (pour le ou les domaines en question), puis le serveur de validation de Let’s encrypt va faire des requêtes HTTP pour chaque domaine afin de confirmer que les DNS résolvent bien vers le serveur exécutant Let’s encrypt.
Ensuite, pour générer le certificat avec la méthode Webroot, il suffit d’ajouter l’option –webroot et de préciser le chemin vers la racine du site web avec l’option -w /chemin/vers/racine/web . Voici comment générer le certificat pour le domaine feub.net et son sous-domaine www.feub.net :
Après quelques secondes, si tout se passe bien, un message de succès apparait :
- Congratulations! Your certificate and chain have been saved at
/etc/letsencrypt/live/www.feub.net/fullchain.pem. Your cert will
expire on 2016-07-25. To obtain a new version of the certificate in
the future, simply run Let's Encrypt again.
- If you like Let's Encrypt, please consider supporting our work by:
Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate
Donating to EFF: https://eff.org/donate-le
Dans ce billet, voyons comment créer un certificat ssl avec Let’s encrypt et configurer le serveur web Nginx en HTTPS pour l’admin de Wordpress.
La folie Let’s encrypt fait des ravages, tout le monde y passe (même la Freebox!), en même temps c’est tout à fait naturel, pouvoir obtenir un vrai certificat SSL gratuit pour son site web, reconnu par les navigateurs sans message de sécurité, c’est plutôt sympa.
Je n’avais pas vraiment prêté attention à ce buzz au début, mais j’ai franchi le pas, d’ailleurs cet article vous présente un pas-à-pas de l’installation d’un certificat Let’s encrypt pour un serveur Nginx. Et spécialement pour les utilisateurs de WordPress, nous allons sécuriser la partie administration du CMS afin de laisser le site non crypté, car c’est toujours mieux pour les moteurs de recherche et la SEO.
Let’s encrypt
L’installation sous Fedora et consorts se fait très simplement avec dnf :
$ sudo dnf install letsencrypt
Lorsque l’installation est terminée, il y a plusieurs moyens de prouver la propriété d’un domaine et ainsi générer un certificat, dans notre cas nous utiliserons la méthode standalone qui a juste un petit point négatif, le serveur web (tout de moins le serveur tournant sur le port 80, dans mon cas c’est plutôt Varnish) doit être stoppé, car le script Let’s encrypt va démarrer son propre serveur web sur ce port (et le 443) afin de se répondre à lui-même et ainsi prouver la propriété du domaine.
Pour stopper Nginx sous Fedora 23 :
$ sudo systemctl nginx stop
On peut maintenant lancer le script Let’s encrypt pour vérifier le domaine. Il est possible de spécifier plusieurs domaines en les séparant par des virgules, par exemple pour le domaine nu et sa version avec www :
Lorsque le script a terminé son exécution, il donne quelques informations sur le certificat créé, en particulier sur sa date d’expiration :
IMPORTANT NOTES:
- Congratulations! Your certificate and chain have been saved at
/etc/letsencrypt/live/www.feub.net/fullchain.pem. Your cert will
expire on 2016-05-10. To obtain a new version of the certificate in
the future, simply run Let's Encrypt again.
Configurer Nginx avec SSL
Le certificat étant créé, on peut configurer le serveur web Nginx. Pour le tutoriel je suppose que votre configuration se situe sous /etc/nginx/nginx.conf.
Comme expliqué en introduction, le but ici est de n’avoir que l’admin de WordPress en HTTPS, c’est-à-dire uniquement https://feub.net/wp-admin (et https://feub.net/wp-login). Pour ceci, on va définir deux server blocks pour le même domaine, un qui servira les pages sur le port 80 et un pour les pages sur le port 443 (HTTPS) et sur le site normal on redirigera vers HTTPS tout ce qui arrive sur /wp-admin.
server {
listen 80;
server_name feub.net;
root /var/www/html;
index index.php index.html index.htm;
# Redirection de l'admin WordPress en HTTPS
location ~ /wp-(?:admin|login) {
return 301 https://$host$request_uri;
}
location / {
try_files $uri $uri/ /index.php?$args;
}
# La configuration PHP
include global/php.conf;
include global/wordpress.conf;
include global/things_not_logged.conf;
}
server {
listen 443 ssl;
server_name feub.net;
ssl_certificate /etc/letsencrypt/live/www.feub.net/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/www.feub.net/privkey.pem;
root /var/www/html;
index index.php index.html index.htm;
# Redirect all other requests to HTTP.
location / {
return 301 http://$host$request_uri;
}
# Redirection de l'admin WordPress en HTTPS
location ~ /wp-(admin|login) {
# La configuration PHP
include global/php.conf;
try_files $uri $uri/ \1/index.php?$args;
}
}
Vérification de la configuration Nginx et si tout est ok redémarrage du serveur web :
$ sudo nginx -t
$ sudo systemctl nginx start
WordPress
Pour terminer nous allons dire à WordPress d’utiliser HTTPS pour l’admin en ajoutant cette ligne dans le fichier de configuration wp-config.php :
define( 'FORCE_SSL_ADMIN', true );
On vérifie que l’accès au site se fait bien normalement en se rendant sur le site, puis on essaie l’admin de WordPress, on voit que l’on est redirigé sur https://feub.net/wp-login. Cela fonctionne.
Les certificats Let’s encrypt expirent après 90 jours, il faut donc penser à le renouveler avant la date indiquée lors de sa création.
Mes sites ont migré sur un nouveau serveur Kimsufi SSD de OVH et les performances sont bien sympathiques grâce à Nginx et Varnish.
Petite évolution du serveur hébergeant feub.net et plusieurs autres sites qui reste chez Kimsufi d’OVH mais en version SSH cette fois-ci. Cela me titillait depuis un moment car il faut bien l’avouer le SSD lorsqu’on en goûte on ne peut plus s’en passer, côté desktop mais coté serveur aussi. Mais il fallait bien avouer que le boulot de la migration me faisait renoncer, je n’avais pas trop envie de passer des heures devant un terminal lorsque je passe déjà mes journées au boulot devant des lignes de code. Après moult réflexion donc, maintenant c’est fait, un Kimsufi moins cher (9.99€/mois) que celui d’avant, avec un couple processeur/mémoires similaire, mais aussi 20% de moins d’espace disque, passant d’1Tb à 40Gb.
Je reste fidèle à Fedora, en passant à la version 23, et le serveur web d’enfer Nginx se voit désormais épaulé par l’accélérateur d’applications web Varnish que je commence à apprivoiser et Memchached pour la mise en cache d’objets PHP. Belle petite équipe qui ne demande qu’à être optimisée ^.^
Je ne vais pas m’attarder sur le détail de mes configurations, mais ce sera certainement l’objet de prochains billets sur ce blog. Pour le moment ça roule, peut-être y’a-t-il quelques couacs à droite à gauche, alors n’hésitez surtout pas à me faire part de tout problème ou anomalie.
J’ai longtemps utilisé des certificats auto-signés pour mes connexions SSL/TLS, bien qu’un tel certificat assure le cryptage de la liaison, elle n’assure en aucun cas la validité de celui-ci. Lorsque c’est moi qui accède à un de mes sites, aucun problème (je peux encore me faire confiance je pense ^.^), mais quid des personnes tiers utilisant mes services? Elles ne peuvent se fier qu’à mes paroles. De plus un certificat auto-signé n’étant pas reconnu par les navigateurs, ceux-ci affichent cette page flashy indiquant les dangers d’accéder à un tel site.
D’un autre coté, un certificat délivré par une autorité compétente a un prix (plus ou moins variable). La solution intermédiaire est offerte par StartSSL, une société qui possède une offre gratuite de certificat SSL appelée Class 1 SSL. C’est un vrai certificat, certe basique et pour une utilisation personnelle, mais reconnu par les navigateurs, donc plus de page d’avertissement de ceux-ci avant de naviguer sur un site sécurisé. Celui-ci est gratuit, avec toutes vos informations d’identité, mais celles-ci ne sont pas vérifiées par StartSSL, donc c’est certainement un point délicat dans le cas d’un site d’e-commerce par exemple. Mais pour simplement sécuriser des pages d’administration, un back-office, c’est amplement suffisant.
Voici décrite ci-dessous la procédure de création et mise en place d’un certificat SSL pour Nginx.
Continue reading « Création et ajout d’un certificat gratuit StartSSL à Nginx »
En continuant d'utiliser ce site, vous acceptez l'utilisation de cookies. AccepterEn savoir plus
Privacy & Cookies Policy
Privacy Overview
This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.