1.Configuration de Let’s Encrypt
Pour faire ce tutoriel, nous supposons que vous avez lu notre précédent article sur la configuration de NGINX. Votre serveur nginx doit être installé et fonctionnel. Maintenant que notre serveur web fonctionne correctement, nous pouvons essayer de faire des améliorations en sécurisant les échanges entre notre serveur et nos clients. Pour cela nous allons mettre en place du HTTPS. Au lieu d’acheter un certificat, nous allons utiliser ce petit projet gratuit, mais aussi génial qu’est Let’s Encrypt. Il va nous permettre de créer des certificats automatiques et gratuits pour chacun de nos sites et nous pourrons même utiliser ses certificats pour sécuriser les sites pour lesquelles nous jouons le rôle de serveur proxy.
1.1 Installation du Client Certbot
Le nouveau client recommandé pour let’s Encrypt est Certbot. Nous allons commencer par l’installer sur notre système. Pour cela nous allons ajouter dans notre liste de dépôt (/etc/apt/source.list) si ce n’est pas déjà le cas le dépôt qui contient certbot. Nous sommes sur debian 8 (Jessie) donc si vous avez une autre version de linux ou une autre version de debian je vous invite a retrouver le dépôt qui a certbot (informations sur https://certbot.eff.org) ou alors d’utiliser un autre client.
Ouvrir le fichier avec :
[pastacode lang= »bash » manual= »nano%20%2Fetc%2Fapt%2Fsources.list » message= » » highlight= » » provider= »manual »/]
Ajouter la ligne suivant à la fin du fichier :
[pastacode lang= »bash » manual= »deb%20http%3A%2F%2Fftp.debian.org%2Fdebian%20jessie-backports%20main%20non-free%20contrib%0Adeb-src%20http%3A%2F%2Fftp.debian.org%2Fdebian%20jessie-backports%20main%20non-free%20contrib%0Adeb%20http%3A%2F%2Fftp.debian.org%2Fdebian%20jessie%20main%20non-free%20contrib%0Adeb-src%20http%3A%2F%2Fftp.debian.org%2Fdebian%20jessie%20main%20non-free%20contrib » message= » » highlight= » » provider= »manual »/]
Ensuite, mettez à jour la liste des paquets et installer certbot
[pastacode lang= »bash » manual= »apt%20update%C2%A0%20%26%26%C2%A0%20apt-get%20install%20certbot%20-t%20jessie-backports » message= » » highlight= » » provider= »manual »/]
Maintenant Certbot est installé. Certbot dispose d’un mode automatique qui va installer les dépendances nécessaires à l’outil et mettre en place les certificats en fonction de votre configuration serveur. Cette méthode d’installation automatique fonctionne déjà très bien avec un le serveur web apache, mais reste à l’heure actuelle (26/09/2016) expérimentale pour nginx (ce qui a peux être changé entre-temps). Il possède aussi le mode manuel. Dans ce cas, vous allez vous-même lancer la commande de génération de certificat pour chacun des sites que vous voulez passer en HTTPS et modifier vous-même les fichiers de configuration pour rediriger automatiquement les requêtes HTTP vers HTTPS. Nous allons utiliser ce dernier mode.
1.2 Utilisation du client Certbot
1.2.1 Mode de fonctionnement et configuration
Pour générer nos certificats manuellement nous pouvons utiliser notre propre serveur web ou alors le serveur web interne à certbot.
- Pour utiliser le serveur web interne à certbot, il est recommandé de couper momentanément notre serveur web personnel pour libérer le port 80 (pas très pratique si vous avez des sites qui tournent déjà et que vous ne voulez pas les interrompre). Dans ce cas on utilise la commande certbot certonly –standalone -d example.com -d example.com
- Pour utiliser notre propre serveur Web interne, nous allons faire appel aux plug-ins WebRoot. Afin de vérifier que vous êtes bien le possesseur du nom de domaine pour lequel vous souhaitez obtenir un certificat, Let’s Encrypt va générer un fichier sur votre serveur et va ensuite essayer d’y accéder depuis son serveur. Donc votre site web doit déjà être présent, fonctionnel et accessible de l’extérieur via le port 80. Cette configuration permet à Nginx d’avoir accès au répertoire .well-known/acme-challenge afin de créer les fichiers utiles à la validation de votre nom de domaine. Ajouter dans les configurations du site le contenu suivant dans les balises server { }.
[pastacode lang= »apacheconf » manual= »%23%20.well-known%20doit%20rester%20accessible%20pour%20que%20NGINX%20puisse%20le%20manipuler%0A%0A%C2%A0%C2%A0%C2%A0%20location%20~%20%2F%5C.well-known%2Facme-challenge%20%7B%0A%0A%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%20allow%20all%3B%0A%C2%A0%C2%A0%C2%A0%20%7D%0A%0A%23%20On%20interdit%20habituellement%20l’acc%C3%A8s%20au%20dotfiles%20(les%20fichiers%20cach%C3%A9s)%0A%0A%C2%A0%C2%A0%C2%A0%20location%20~%20%2F%5C.%20%7B%0A%0A%09%09deny%20all%3B%0A%0A%09%09access_log%20off%3B%0A%0A%09%09log_not_found%20off%3B%0A%0A%C2%A0%20%C2%A0%C2%A0%7D » message= » » highlight= » » provider= »manual »/]
NB : Quand vous souhaitez utiliser NGINX comme proxy vous devez vous aurez plutôt à ajouter ceux-ci dans le virtualhost. Dans la partie HTTP de la requête avant la redirection vers le https.
[pastacode lang= »apacheconf » manual= »location%20~%20%2F.well-known%2Facme-challenge%20%7B%0A%0A%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%20root%20%2Fvar%2Fwww%2Fhtml%2F%3B%0A%0A%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%20allow%20all%3B%0A%0A%7D » message= » » highlight= » » provider= »manual »/]
1.2.2 Commande à utiliser
Pour utiliser chacune de ces méthodes vous avec le choix entre le mode interactif et le mode ligne de commande. Dans tous les cas noter que lorsque vous lancé la requête de demande de certificat avec let’s Encrypt, il vérifiera que le nom de domaine pour le qu’elle vous demandé un certificat correspond bien à l’adresse IP publique avec la qu’elle vous lancé la requête. IL faudra aussi se rassurer que le port 80 de votre IP public soit bien natté sur le serveur ou est installé le client Certbot.
- Pour appeler le mode interactif (graphique) utilisez la commande :
[pastacode lang= »bash » manual= »certbot%20certonly » message= » » highlight= » » provider= »manual »/]
Ensuite, suivez les indications données par l’interface et renseignez les informations qui vous sont demandées.
- Pour utiliser le mode commande, vous renseignez la commande suivante :
[pastacode lang= »bash » manual= »certbot%20certonly%20–email%20mon_adresse%40google.com%20–webroot%20-w%20%2Fvar%2Fwww%2Fexemple%20-d%20exemple.com%20-d%20www.exemple.com%20-w%20%2Fvar%2Fwww%2Fthing%20-d%20truc.fr%C2%A0-d%20m.truc.fr » message= » » highlight= » » provider= »manual »/]
Explication:
L’option –w permet de spécifier le répertoire racine (répertoire root) du ou des noms de domaine qui sont spécifiés juste après avec l’option –d (les noms de domaine (-d) spécifié avant la prochaine option –w pointe tous sur le même site).
L’option –email permet de spécifier une adresse email. Elle n’est pas obligatoire, mais elle vous permet de recevoir un mail lorsque votre certificat approche de sa date d’expiration (très pratique tout ça).
Donc dans ce cas il va créer :
- Un certificat pour le domaine example.com qui a aussi pour nom example.com et qui a pour répertoire Racine /var/www/exemple.
- Un Certificat pour pour le domaine thing.is qui a aussi pour nom m.thing.is et qui a pour répertoire racine /var/www/thing.
- La demande de renouvellement du certificat sera envoyée à l’adresse gkja2013@gmail.com
NB : Les certificats ne sont pas créés dans les répertoires racines des serveurs. Ce répertoire est utilisé juste pour la création des fichiers de validation du nom de domaine qui sont supprimés par la suite. Les certificats et clés de let’sEncrypt se trouvent dans les répertoires :
[pastacode lang= »markup » manual= »%2Fetc%2Fletsencrypt%2Farchive%0A%2Fetc%2Fletsencrypt%2Fkeys%0A%2Fetc%2Fletsencrypt%2Flive%0A%2Fetc%2Fletsencrypt%2Frenewal%2F » message= » » highlight= » » provider= »manual »/]
Les fichiers créés respectent à chaque fois la convention :
Dans le Dossier live :
[pastacode lang= »markup » manual= »Certificat%20principal%C2%A0%3A%20%C2%A0%2Fetc%2Fletsencrypt%2Flive%2Fmon_domaine.fr%2Fcert.pem%0AChaine%20de%20certificats%20suppl%C3%A9mentaires%C2%A0%20%3A%20%C2%A0%2Fetc%2Fletsencrypt%2Flive%2Fmon_domaine.fr%2Fchain.pem%0ACertificat%20principale%20%2B%20Chaine%20de%20certificats%20suppl%C3%A9mentaires%C2%A0%3A%20%C2%A0%2Fetc%2Fletsencrypt%2Flive%2Fmon_domaine.fr%2Ffullchain.pem%0ACl%C3%A9%20priv%C3%A9e%20du%20certificat%C2%A0%20%3A%20%C2%A0%2Fetc%2Fletsencrypt%2Flive%2Fmon_domaine.fr%2Fprivkey.pem » message= » » highlight= » » provider= »manual »/]
Dans le dossier Archive :
[pastacode lang= »markup » manual= »%2Fetc%2Fletsencrypt%2Farchive%2Fmon_domaine.fr%2Ffullchain.pem%0A%2Fetc%2Fletsencrypt%2Farchive%2Fmon_domaine.fr%2Fprivkey.pem%0A%2Fetc%2Fletsencrypt%2Farchive%2Fmon_domaine.fr%2Fchain.pem%0A%2Fetc%2Fletsencrypt%2Farchive%2Fmon_domaine.fr%2Fcert.pem » message= » » highlight= » » provider= »manual »/]
Donc en tapant
[pastacode lang= »bash » manual= »%C2%A0ls%20%2Fetc%2Fletsencrypt%2Flive%2F » message= » » highlight= » » provider= »manual »/]
vous aurez la liste des Certificats (en réalité le dossier parent qui les contient).
Si la génération de certificat se passe correctement vous devez avoir le message suivant :
Qui vous confirme que la génération de certificat a bien été effectuée.
1.3 Création des paramètres de session et configuration du Virtual Host
1.3.1 Création des paramètres de session
Attention : La création de paramètres de session n’est à effectuer qu’une seule fois sur le serveur et sera utilisée pour tous les sites. Vous pouvez néanmoins le relancer si vous souhaitez renouveler les paramètres (attention aux sessions en cours).
Après avoir créé les certificats, vous devez générer les clés de session et le paramètre Diffie-Helman (sert crypter le premier échange entre le serveur et le client). Ceux-ci n’est pas obligatoires, mais permet d’accroitre la sécurité (si vous ne l’utilisez pas pour une raison ou pour une autre pensez à supprimer les lignes correspondantes dans le fichier de configuration). Nous allons créer un répertoire nommé ssl dans le répertoire de configuration de NGINX pour y générer ces fichiers.
[pastacode lang= »bash » manual= »sudo%20mkdir%20%2Fetc%2Fnginx%2Fssl%0Asudo%20openssl%20rand%2048%20-out%20%2Fetc%2Fnginx%2Fssl%2Fticket.key%0Asudo%20openssl%20dhparam%20-out%20%2Fetc%2Fnginx%2Fssl%2Fdhparam4.pem%204096″ message= » » highlight= » » provider= »manual »/]
NB: La dernière commande (celle qui génère le paramètre Diffie-Helman) prend beaucoup de temps vu que j’ai spécifié une clé de 4096 pour un max de sécurité. Donc, soyez très patient. Bon la vitesse dépendra aussi un peu de votre configuration.
1.3.2 Configuration du Virtual Host
Modifier ensuite votre Virtual host (le fichier de configuration du site) comme celui-ci en adaptant les configurations. Pensez à modifier mon_domaine.fr par le nom de votre domaine et /var/www/html par le répertoire racine de votre site web. Ou alors, adaptez-le comme il faut pour un serveur proxy.
- Pour un Site web:
[pastacode lang= »apacheconf » manual= »%23%20Redirection%20HTTP%20vers%20HTTPS%0A%0Aserver%20%7B%0A%0A%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%20listen%2080%3B%0A%0A%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%20%23%20Vous%20pouvez%20en%20mettre%20plusieurs%20%C3%A0%20la%20suite%2C%20Bien%20s%C3%BBr%20faudrait%20qu%E2%80%99il%20ait%20%C3%A9t%C3%A9%20sp%C3%A9cifi%C3%A9%20dans%20le%20certificat%0A%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%20server_name%20mon_domaine.fr%20www.mon_domaine.fr%3B%0A%0A%C2%A0%20%09%09location%20~%20%2F.well-known%2Facme-challenge%20%7B%0A%0A%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%20%09root%20%2Fvar%2Fwww%2Fhtml%2F%3B%0A%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%20%09allow%20all%3B%0A%0A%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%20%7D%0A%0A%0A%09%09location%20%2F%20%7B%0A%0A%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%20return%20301%20https%3A%2F%2Fwww.mon_domaine.fr%24request_uri%3B%0A%0A%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%20%7D%0A%0A%7D%0A%0A%0A%0A%23%20Notre%20bloc%20serveur%0A%0Aserver%20%7B%0A%0A%C2%A0%C2%A0%C2%A0%20%23%20spdy%20pour%20Nginx%20%3C%201.9.5%0A%0A%C2%A0%C2%A0%C2%A0%20listen%20443%20ssl%20spdy%3B%0A%0A%C2%A0%C2%A0%C2%A0%20listen%20%5B%3A%3A%5D%3A443%20ssl%20spdy%3B%0A%0A%C2%A0%C2%A0%C2%A0%20spdy_headers_comp%209%3B%0A%0A%0A%C2%A0%C2%A0%C2%A0%20server_name%20mon_domaine.fr%20www.mon_domaine.fr%3B%0A%C2%A0%C2%A0%C2%A0%20root%20%2Fvar%2Fwww%2Fhtml%3B%0A%C2%A0%C2%A0%C2%A0%20index%20index.html%20index.htm%3B%0A%C2%A0%C2%A0%C2%A0%20error_log%20%2Fvar%2Flog%2Fnginx%2Fmon_domaine.fr.log%20notice%3B%0A%C2%A0%C2%A0%C2%A0%20access_log%20off%3B%0A%0A%0A%C2%A0%C2%A0%C2%A0%20%23%23%23%23%C2%A0%C2%A0%C2%A0%20Locations%0A%0A%C2%A0%C2%A0%C2%A0%20%23%20Si%20On%20veut%20cacher%20les%20fichiers%20statiques%0A%0A%C2%A0%C2%A0%C2%A0%20%23%20location%20~*%20%5C.(html%7Ccss%7Cjs%7Cpng%7Cjpg%7Cjpeg%7Cgif%7Cico%7Csvg%7Ceot%7Cwoff%7Cttf)%24%20%7B%20expires%20max%3B%20%7D%0A%0A%C2%A0%C2%A0%C2%A0%20%23%20On%20interdit%20les%20dotfiles%0A%0A%C2%A0%C2%A0%C2%A0%20location%20~%20%2F%5C.%20%7B%20deny%20all%3B%20%7D%0A%0A%0A%C2%A0%C2%A0%C2%A0%20%23%23%23%23%20SSL%0A%0A%C2%A0%C2%A0%C2%A0%20ssl%20on%3B%0A%C2%A0%C2%A0%C2%A0%20ssl_certificate%20%2Fetc%2Fletsencrypt%2Flive%2Fmon_domaine.fr%2Ffullchain.pem%3B%0A%C2%A0%C2%A0%C2%A0%20ssl_certificate_key%20%2Fetc%2Fletsencrypt%2Flive%2Fmon_domaine.fr%2Fprivkey.pem%3B%0A%0A%0A%0A%C2%A0%C2%A0%C2%A0%20ssl_stapling%20on%3B%0A%C2%A0%C2%A0%C2%A0%20ssl_stapling_verify%20on%3B%0A%C2%A0%C2%A0%C2%A0%20ssl_trusted_certificate%20%2Fetc%2Fletsencrypt%2Flive%2Fmon_domaine.fr%2Ffullchain.pem%3B%0A%0A%C2%A0%C2%A0%C2%A0%20%23%20Google%20DNS%2C%20Open%20DNS%2C%20Dyn%20DNS%0A%0A%C2%A0%C2%A0%C2%A0%20resolver%208.8.8.8%208.8.4.4%20208.67.222.222%20208.67.220.220%20216.146.35.35%20216.146.36.36%20valid%3D300s%3B%0A%C2%A0%C2%A0%C2%A0%20resolver_timeout%203s%3B%0A%0A%0A%0A%C2%A0%C2%A0%C2%A0%C2%A0%20%23%23%23%23%C2%A0%C2%A0%C2%A0%20Session%20Tickets%0A%0A%C2%A0%C2%A0%C2%A0%20%23%20%5BATTENTION%5D%20Session%20Cache%20doit%20avoir%20la%20m%C3%AAme%20valeur%20sur%20tous%20les%20blocs%20%22server%22%20et%20doivent%20%C3%AAtre%20g%C3%A9n%C3%A9r%C3%A9s.%0A%0A%C2%A0%C2%A0%C2%A0%20ssl_session_cache%20shared%3ASSL%3A100m%3B%0A%C2%A0%C2%A0%C2%A0%20ssl_session_timeout%2024h%3B%0A%C2%A0%C2%A0%C2%A0%20ssl_session_tickets%20on%3B%0A%0A%C2%A0%C2%A0%C2%A0%20%23%20%5BATTENTION%5D%20il%20faudra%20g%C3%A9n%C3%A9rer%20le%20ticket%20de%20session.%0A%0A%C2%A0%C2%A0%C2%A0%20ssl_session_ticket_key%20%2Fetc%2Fnginx%2Fssl%2Fticket.key%3B%0A%0A%0A%C2%A0%C2%A0%C2%A0%20%23%20%5BATTENTION%5D%20Les%20param%C3%A8tres%20Diffie-Helman%20doivent%20%C3%AAtre%20g%C3%A9n%C3%A9r%C3%A9s%0A%0A%C2%A0%C2%A0%C2%A0%20ssl_dhparam%20%2Fetc%2Fnginx%2Fssl%2Fdhparam4.pem%3B%0A%0A%0A%C2%A0%C2%A0%C2%A0%20%23%23%23%23%C2%A0%C2%A0%C2%A0%20ECDH%20Curve%0A%0A%C2%A0%C2%A0%C2%A0%20ssl_ecdh_curve%20secp384r1%3B%0A%C2%A0%C2%A0%C2%A0%20ssl_protocols%20TLSv1%20TLSv1.1%20TLSv1.2%3B%0A%C2%A0%C2%A0%C2%A0%20ssl_prefer_server_ciphers%20on%3B%0A%C2%A0%C2%A0%C2%A0%20ssl_ciphers%20’ECDHE-RSA-AES128-GCM-SHA256%3AECDHE-ECDSA-AES128-GCM-SHA256%3AECDHE-RSA-AES256-GCM-SHA384%3AECDHE-ECDSA-AES256-GCM-SHA384%3ADHE-RSA-AES128-GCM-SHA256%3ADHE-DSS-AES128-GCM-SHA256%3AkEDH%2BAESGCM%3AECDHE-RSA-AES128-SHA256%3AECDHE-ECDSA-AES128-SHA256%3AECDHE-RSA-AES128-SHA%3AECDHE-ECDSA-AES128-SHA%3AECDHE-RSA-AES256-SHA384%3AECDHE-ECDSA-AES256-SHA384%3AECDHE-RSA-AES256-SHA%3AECDHE-ECDSA-AES256-SHA%3ADHE-RSA-AES128-SHA256%3ADHE-RSA-AES128-SHA%3ADHE-DSS-AES128-SHA256%3ADHE-RSA-AES256-SHA256%3ADHE-DSS-AES256-SHA%3ADHE-RSA-AES256-SHA%3A!aNULL%3A!eNULL%3A!EXPORT%3A!DES%3A!RC4%3A!3DES%3A!MD5%3A!PSK’%3B%0A%0A%0A%0A%7D » message= » » highlight= » » provider= »manual »/]
Pensez vérifier que les configurations de nginx sont correctes avec :
[pastacode lang= »bash » manual= »nginx%20-t%C2%A0″ message= » » highlight= » » provider= »manual »/]
avant de faire un reload des configurations du serveur pour éviter de le faire cracher. Si tous est OK vous aurez le message suivant :
Si tout est OK faite un :
[pastacode lang= »bash » manual= »services%20nginx%20reload%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0″ message= » » highlight= » » provider= »manual »/]
ou
[pastacode lang= »bash » manual= »%20systemctl%20reload%20nginx » message= » » highlight= » » provider= »manual »/]
Vous pouvez aussi écrire un script qui fait cela tout seul. Vous lui passez juste en paramètre les noms de domaines et les chemins racines souhaités pour les sites et lui il s’occupe du reste. Le script peut également faire toute les vérifications nécessaires.
- Pour un site proxy :
Adapter les configurations précédemment utilisées pour le site web, pensez surtout à commenter ou a supprimer les 4 lignes suivantes :
[pastacode lang= »bash » manual= »%C2%A0%20root%20%2Fvar%2Fwww%2Fhtml%3B%0A%20%20%0A%C2%A0%C2%A0index%20index.html%20index.htm%3B%0A%20%20%0A%C2%A0%C2%A0error_log%20%2Fvar%2Flog%2Fnginx%2F%20mon_domaine.fr.log%20notice%3B%0A%20%20%0A%C2%A0%C2%A0access_log%20off%3B » message= » » highlight= » » provider= »manual »/]
Et à les remplacer par les lignes suivantes en remplaçant http://127.0.01:3000 par l’adresse IP réelle et le port (l’adresse complète) du site vers lequel vous souhaitez pointer. Si vous souhaitez accéder à un site en local utilisé plutôt localhost au lieu de 127.0.0.1.
[pastacode lang= »bash » manual= »%C2%A0%C2%A0%C2%A0%C2%A0%20location%20%2F%20%7B%0A%0A%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%20proxy_pass%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%20http%3A%2F%2F127.0.0.1%3A3000%2F%3B%0A%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%20%7D » message= » » highlight= » » provider= »manual »/]
Vous avez surement remarqué que j’utilise ici HTTP au lieu de HTTPS en fait, je suppose, ici que c’est votre serveur proxy qui héberge le certificat SSL. Vous pouvez adapter les configurations en fonction de votre architecture.
- Pour le site maitre :
C’est celui qui va être appelé par défaut si les autres sont indisponibles ou celui qui sera retourné tant que le nom de domaine pointe sur le serveur et n’est pas défini explicitement dans un virtual host(pour un Site). Cette configuration n’est pas absolument nécessaire. Vous la mettez en place sur un site si vous le souhaitez. Vous pouvez aussi tous simplement laisser le visiteur tomber sur une page d’erreur au cas où il tape mal l’adresse de l’un de vos sites. Cette option est particulièrement intéressante si vous avez référencé tous les sites que vous hébergez sur une page.
NB : Il ne peut y avoir qu’un seul site maitre sur un serveur NGINX.
- Ajouter simplement sur la ligne listen 80 ; de la configuration par défaut d’un site web le mot clé default_server. Vous aurez ceux-ci : listen 80 default_server;
- Et mettez le tild (_) comme nom de serveur : server_name _ ;
- Vérifier vos configurations :
Une fois que le SSL a été mis en place pour tester la robustesse de votre système il vous suffit de coller l’adresse de votre site ici. Se site testera si votre configuration respecte tous les principes de sécurité, car malgré l’utilisation du SSL si votre configuration est mal faite, il y aura des portes ouvertes pour les hackers.
1.4 Renouvellement du Certificat
Les certificats Let’sEncrypt ne sont valables que pendant 90 jours (3 mois). Donc il est très facile d’oublier de les renouveler. La commande suivante renouvelle les certificats sans interaction de votre part. Cette commande ne fera rien si le certificat n’a pas encore besoin d’être renouvelé:
[pastacode lang= »bash » manual= »certbot%20renew » message= » » highlight= » » provider= »manual »/]
Si cela fonctionne correctement vous pouvez ajouter une entrée a la cron table ou job systemd pour faire cela automatiquement.
Le job se lance avec la commande :
[pastacode lang= »bash » manual= »certbot%20renew%20-q » message= » » highlight= » » provider= »manual »/]
La cron table nous permettra d’exécuter une tâche de manière récurrente :
[pastacode lang= »bash » manual= »sudo%20crontab%20-e » message= » » highlight= » » provider= »manual »/]
Ensuite, choisissez votre éditeur si c’est la première fois que vous utilisez crontab et qu’il vous le demande. Entrer les lignes suivantes.
La syntaxe des lignes de ce fichier est la suivante : mm hh jj MMM JJJ tâche > log
mm : représente les minutes (de 0 à 59)
hh : représente l’heure (de 0 à 23),
jj : représente le numéro du jour du mois (de 1 à 31)
MMM : représente le numéro du mois (de 1 à 12) ou l’abréviation du nom du mois (jan, feb, mar, apr, …)
JJJ : représente l’abréviation du nom du jour ou le chiffre correspondant au jour de la semaine (0 représente le dimanche, 1 représente le lundi, …)
Tâche : représente la commande ou le script shell à exécuter
log : représente le nom d’un fichier dans lequel stocker le journal des opérations. Si la clause > log n’est pas spécifiée, cron enverra automatiquement un mail de confirmation. Pour éviter cela il suffit de spécifier > /dev/null.
Ex : tous les 23h30 : 30 23 * * * df >>/tmp/log_df.txt
Ajoutez les lignes suivantes dans votre cron table :
[pastacode lang= »bash » manual= »25%202%20*%20*%20*%20date%20%3E%3E%20%2Fvar%2Flog%2Fcertbot-renew.log%0A%0A30%202%20*%20*%20*%20certbot%20renew%20-q%20%3E%3E%20%2Fvar%2Flog%2Fcertbot-renew.log%0A%0A25%2012%20*%20*%20*%20date%20%3E%3E%20%2Fvar%2Flog%2Fcertbot-renew.log%0A%0A30%2012%20*%20*%20*%20certbot%20renew%20-q%20%3E%3E%20%2Fvar%2Flog%2Fcertbot-renew.log%0A%0A » message= » » highlight= » » provider= »manual »/]
Si nginx a du mal à prendre en compte le nouveau certificat vous pouvez rajouter la ligne suivante :
[pastacode lang= »bash » manual= »35%202%20*%20*%20*%20service%20nginx%20reload » message= » » highlight= » » provider= »manual »/]
NB : Si vous ajoutez la commande a la cron table ou à systemd, il est conseillé mettre une tâche récurrente qui se lance 2 fois par jour afin de rester actif auprès de let’sEncrypt . Cela vous permet de réduire les risques que votre certificat soit révoqué parce qu’arrivé à expiration ou pour une raison quelconque. De toutes les façons si le certificat n’a pas besoin d’être renouvelé, la commande ne fera rien.
1.5 Révocation de certificat
Si pour une raison ou une autre vous voulez révoquer votre certificat par exemple si votre clé privée a été corrompue, vous pouvez essayer la commande suivante :
[pastacode lang= »bash » manual= »certbot%20revoke%20–cert-path%20%2Fetc%2Fletsencrypt%2Flive%2Fmon_site.fr%2Fcert.pem » message= » » highlight= » » provider= »manual »/]
Dans mon cas généralement elle ne renvoie aucune erreur et par moment elle renvoie une erreur (là je suppose qu’en même qu’elle a bien fonctionné). Mais peut-être a-t-elle été mise à jour entre temps. J’ai parfois l’erreur suivante alors que je lance la commande de suppression d’un certificat d’un sous domaine pour la première fois.
[pastacode lang= »haml » manual= »An%20unexpected%20error%20occurred%3A%0AThe%20request%20message%20was%20malformed%20%3A%3A%20Certificate%20already%20revoked%0APlease%20see%20the%20logfiles%20in%20%2Fvar%2Flog%2Fletsencrypt%20for%20more%20details. » message= » » highlight= » » provider= »manual »/]
Dans tous les cas une fois que cette commande a été exécutée pensez à supprimer les fichiers de l’ancien certificat :
[pastacode lang= »bash » manual= »rm%C2%A0%20-r%20%2Fetc%2Fletsencrypt%2Flive%2Fmon_site.fr%0Arm%20-r%20%2Fetc%2Fletsencrypt%2Farchive%2Fmon_site.fr%0Arm%20%2Fetc%2Fletsencrypt%2Frenewal%2Fmon_site.fr.conf » message= » » highlight= » » provider= »manual »/]
NB : Je ne suis pas sûr que c’est très propre. Mais bon cela a le mérite de fonctionner.
Pour vérifier que votre certificat a bien été retiré de la liste de vos certificats, lancer la commande certbot renew. Elle vérifiera chacun de vos certificats et vous les affichera. Vous pouvez constater que le certificat qui a été révoqué et supprimé de la liste de vos certificats n’y est plus.
Si vous relancer la commande de création de certificats avec le même nom de domaine que vous avez précédemment révoqué vous pouvez constater que le certificat est créé de nouveau et que la date d’expiration est différente du précédent certificat elle est calculée à partir de la date à laquelle vous avez ressaisi la commande de création de certificats.
8 commentaires