TOC

Comment sécuriser Nginx avec Let’s Encrypt sur Debian 8

introduction

Let’s Encrypt est une nouvelle autorité de certification qui fournit un moyen simple d’obtenir et d’installer des certificats TLS / SSL gratuits, permettant ainsi le cryptage HTTPS sur des serveurs Web. Il simplifie le processus en fournissant un logiciel client, + certbot + (précédemment appelé + letsencrypt +), qui tente d’automatiser la plupart (sinon la totalité) des étapes requises. Actuellement, l’ensemble du processus d’obtention et d’installation d’un certificat est entièrement automatisé uniquement sur les serveurs Web Apache. Cependant, Let’s Encrypt peut être utilisé pour obtenir facilement un certificat SSL gratuit, pouvant être installé manuellement, quel que soit le logiciel de serveur Web choisi.

Dans ce tutoriel, nous allons vous montrer comment utiliser Let’s Encrypt pour obtenir un certificat SSL gratuit et l’utiliser avec Nginx sur Debian 8. Nous vous montrerons également comment renouveler automatiquement votre certificat SSL. Si vous utilisez un autre serveur Web, suivez simplement la documentation de votre serveur Web pour savoir comment utiliser le certificat avec votre configuration.

image: https: //assets.digitalocean.com/articles/letsencrypt/nginx-letsencrypt.png [Nginx avec certificat Let’s Encrypt TLS / SSL et renouvellement automatique]

Conditions préalables

Avant de suivre ce tutoriel, vous aurez besoin de quelques choses.

Vous devriez avoir un serveur Debian 8 avec un utilisateur non-root qui a les privilèges + sudo +. Vous pouvez apprendre à configurer un tel compte utilisateur en suivant notre tutoriel initial initial pour Debian 8.

Si vous n’avez pas encore installé Nginx sur votre serveur, procédez comme suit: this guide.

Vous devez posséder ou contrôler le nom de domaine enregistré avec lequel vous souhaitez utiliser le certificat. Si vous ne possédez pas déjà un nom de domaine enregistré, vous pouvez en enregistrer un auprès d’un des nombreux bureaux d’enregistrement de noms de domaine (par exemple, Namecheap, GoDaddy, etc.).

Si vous ne l’avez pas déjà fait, veillez à créer un * A Record * qui pointe votre domaine vers l’adresse IP publique de votre serveur (si vous utilisez le DNS de DigitalOcean, vous pouvez suivre https://www.digitalocean.com/community / tutorials / comment-configurer-un-nom-hôte-avec-digitalocean [ce guide]). Cela est nécessaire en raison de la façon dont Let’s Encrypt a confirmé que vous êtes propriétaire du domaine pour lequel il émet un certificat. Par exemple, si vous souhaitez obtenir un certificat pour + example.com +, ce domaine doit être résolu sur votre serveur pour que le processus de validation fonctionne. Notre configuration utilisera + example.com + et + www.example.com + comme noms de domaine, donc * les deux enregistrements DNS sont requis *.

Une fois toutes les conditions préalables remplies, passons à l’installation du logiciel client Let’s Encrypt.

Étape 1: Installez Certbot, le client Let’s Encrypt

La première étape pour utiliser Let’s Encrypt pour obtenir un certificat SSL consiste à installer le client + certbot + Let’s Encrypt sur votre serveur.

Le paquet + certbot + n’était pas disponible lors de la publication de Debian 8. Pour accéder au paquetage + certbot +, nous devrons activer le référentiel de backports Jessie sur notre serveur. Ce référentiel peut être utilisé pour installer des versions de logiciel plus récentes que celles incluses dans les référentiels stables.

Ajoutez le référentiel de backports sur votre serveur en tapant:

echo 'deb http://ftp.debian.org/debian jessie-backports main' | sudo tee /etc/apt/sources.list.d/backports.list

Après avoir ajouté le nouveau référentiel, mettez à jour l’index de paquetage + apt + pour télécharger les informations sur les nouveaux paquetages:

sudo apt-get update

Une fois le référentiel mis à jour, vous pouvez installer le package + certbot + en ciblant le référentiel de backports:

sudo apt-get install certbot -t jessie-backports

Le client + certbot + devrait maintenant être prêt à être utilisé.

Étape 2: Obtenir un certificat SSL

Let’s Encrypt propose diverses méthodes pour obtenir des certificats SSL, par le biais de divers plug-ins. Contrairement au plugin Apache, qui est couvert dans a tutoriel différent, la plupart des plugins ne vous aideront qu’à obtenir un certificat que vous devez configurer manuellement pour votre serveur Web. Les plug-ins qui obtiennent uniquement des certificats et ne les installent pas sont appelés «authentificateurs» car ils permettent d’authentifier si un serveur doit recevoir un certificat.

Nous allons vous montrer comment utiliser le plugin * Webroot * pour obtenir un certificat SSL.

Comment utiliser le plugin Webroot

Le plug-in Webroot fonctionne en plaçant un fichier spécial dans le répertoire + /. Notable + de la racine du document, qui peut être ouvert (via votre serveur Web) par le service Let’s Encrypt pour validation. En fonction de votre configuration, vous devrez peut-être explicitement autoriser l’accès au répertoire `+ /. Notoirement + '.

Si vous n’avez pas encore installé Nginx, procédez comme suit: this tutorial. Continuez ci-dessous lorsque vous avez terminé.

S’il vous plaît, laissez Let Encrypt pour validation, modifiez rapidement la configuration de Nginx. Par défaut, il se trouve dans + / etc / nginx / sites-available / default +. Nous allons utiliser + nano pour l’éditer:

sudo nano /etc/nginx/sites-available/default

Dans le bloc serveur, ajoutez ce bloc d’emplacement:

Ajouter au bloc de serveur SSL

       location ~ /.well-known {
               allow all;
       }

Vous voudrez également rechercher le contenu de votre racine de document en recherchant la directive + racine +, car le chemin est requis pour utiliser le plugin Webroot. Si vous utilisez le fichier de configuration par défaut, la racine sera + / var / www / html.

Sauvegarder et quitter.

Vérifiez votre configuration pour les erreurs de syntaxe:

sudo nginx -t
Outputnginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Si aucune erreur n’est trouvée, redémarrez Nginx avec cette commande:

sudo systemctl restart nginx

Maintenant que nous connaissons notre + webroot-path +, nous pouvons utiliser le plugin Webroot pour demander un certificat SSL avec ces commandes. Ici, nous spécifions également nos noms de domaine avec l’option + -d +. Si vous souhaitez qu’un seul certificat fonctionne avec plusieurs noms de domaine (par exemple, + example.com + et + www.example.com +), assurez-vous de tous les inclure. Assurez-vous également de remplacer les pièces mises en surbrillance par le chemin d’accès à la racine Web et le nom de domaine appropriés:

sudo certbot certonly -a webroot --webroot-path= -d  -d

Après l’initialisation de + certbot +, vous serez invité à entrer votre courrier électronique et à accepter les conditions d’utilisation de Let’s Encrypt. Ensuite, le défi sera lancé. Si tout a réussi, vous devriez voir un message de sortie qui ressemble à ceci:

Output:IMPORTANT NOTES:
- Congratulations! Your certificate and chain have been saved at
  fullchain.pem. Your cert
  will expire on . To obtain a new or tweaked version of
  this certificate in the future, simply run certbot again. To
  non-interactively renew *all* of your certificates, run "certbot
  renew"
- If you lose your account credentials, you can recover through
  e-mails sent to [email protected].
- Your account credentials have been saved in your Certbot
  configuration directory at /etc/letsencrypt. You should make a
  secure backup of this folder now. This configuration directory will
  also contain certificates and private keys obtained by Certbot so
  making regular backups of this folder is ideal.
- If you like Certbot, please consider supporting our work by:

  Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
  Donating to EFF:                    https://eff.org/donate-le

Vous voudrez noter le chemin et la date d’expiration de votre certificat, qui ont été mis en évidence dans l’exemple de sortie.

Fichiers de certificat

Après avoir obtenu le certificat, vous aurez les fichiers suivants codés PEM:

  • * cert.pem: * Le certificat de votre domaine

  • * chain.pem: * Le certificat de chaîne Let’S Encrypt

  • * fullchain.pem: * + cert.pem + et + chain.pem + combinés

  • * privkey.pem: * la clé privée de votre certificat

Il est important que vous connaissiez l’emplacement des fichiers de certificat que vous venez de créer afin de pouvoir les utiliser dans la configuration de votre serveur Web. Les fichiers eux-mêmes sont placés dans un sous-répertoire dans + / etc / letsencrypt / archive +. Cependant, Let’s Encrypt crée des liens symboliques vers les fichiers de certificat les plus récents du répertoire + / etc / letsencrypt / live / +. Les liens pointant toujours sur les fichiers de certificat les plus récents, il s’agit du chemin que vous devez utiliser pour faire référence à vos fichiers de certificat.

Vous pouvez vérifier que les fichiers existent en lançant cette commande (en remplaçant votre nom de domaine):

sudo ls -l /etc/letsencrypt/live/

Le résultat devrait être les quatre fichiers de certificat mentionnés précédemment. Dans quelques instants, vous allez configurer votre serveur Web pour qu’il utilise + fullchain.pem + en tant que fichier de certificat et + privkey.pem + en tant que fichier de clé de certificat.

Générer un groupe Diffie-Hellman fort

Pour renforcer encore la sécurité, vous devez également générer un groupe Diffie-Hellman fort. Pour générer un groupe de 2048 bits, utilisez cette commande:

sudo openssl dhparam -out /etc/ssl/certs/dhparam.pem 2048

Cela peut prendre quelques minutes, mais une fois terminé, vous aurez un groupe DH fort à + ​​/ etc / ssl / certs / dhparam.pem +.

Étape 3: Configurer TLS / SSL sur le serveur Web (Nginx)

Maintenant que vous avez un certificat SSL, vous devez configurer votre serveur Web Nginx pour l’utiliser.

Nous allons faire quelques ajustements à notre configuration:

  1. Nous allons créer un extrait de configuration contenant notre clé SSL et les emplacements des fichiers de certificat.

  2. Nous allons créer un extrait de configuration contenant des paramètres SSL forts pouvant être utilisés avec tous les certificats ultérieurement.

  3. Nous allons ajuster les blocs du serveur Nginx pour gérer les demandes SSL et utiliser les deux extraits ci-dessus.

Cette méthode de configuration de Nginx nous permettra de conserver des blocs de serveur propres et de placer des segments de configuration courants dans des modules réutilisables.

Créer un extrait de configuration pointant sur la clé et le certificat SSL

Commençons par créer un nouvel extrait de configuration Nginx dans le répertoire + / etc / nginx / snippets +.

Pour bien distinguer le but de ce fichier, nous allons le nommer + ssl- + suivi de notre nom de domaine, suivi de + .conf + à la fin:

sudo nano /etc/nginx/snippets/ssl-.conf

Dans ce fichier, nous devons simplement définir la directive + ssl_certificate sur votre fichier de certificat et le` + ssl_certificate_key` sur la clé associée. Dans notre cas, cela ressemblera à ceci:

/etc/nginx/snippets/ssl-example.com.conf

ssl_certificate /etc/letsencrypt/live//fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live//privkey.pem;

Lorsque vous avez ajouté ces lignes, enregistrez et fermez le fichier.

Créer un extrait de configuration avec des paramètres de cryptage fort

Ensuite, nous allons créer un autre extrait qui définira certains paramètres SSL. Cela configurera Nginx avec une suite de chiffrement SSL puissante et activera certaines fonctionnalités avancées qui contribueront à maintenir la sécurité de notre serveur.

Les paramètres que nous définirons peuvent être réutilisés dans les futures configurations de Nginx. Nous allons donc donner au fichier un nom générique:

sudo nano /etc/nginx/snippets/ssl-params.conf

Pour configurer Nginx SSL en toute sécurité, nous allons utiliser les recommandations de Remy van Elst sur le site https://cipherli.st [Cipherli.st]. Ce site est conçu pour fournir des paramètres de chiffrement faciles à utiliser pour les logiciels courants. Vous pouvez en savoir plus sur ses décisions concernant les choix de Nginx here.

Pour nos besoins, nous pouvons copier les paramètres fournis dans leur intégralité. Nous avons juste besoin de faire quelques petites modifications.

Tout d’abord, nous allons ajouter notre résolveur DNS préféré pour les requêtes en amont. Nous utiliserons Google pour ce guide. Nous allons également définir le paramètre + ssl_dhparam + pour qu’il pointe vers le fichier Diffie-Hellman que nous avons généré précédemment.

Enfin, vous devriez prendre un moment pour lire HTTP Strict Transport Security, ou HSTS, et plus particulièrement à propos du https://hstspreload.appspot.com/ [ Fonctionnalité de «précharge»]. Le préchargement de HSTS offre une sécurité accrue, mais peut avoir de lourdes conséquences s’il est activé par inadvertance ou incorrectement. Dans ce guide, nous ne préchargerons pas les paramètres, mais vous pouvez le modifier si vous êtes certain de bien comprendre les implications:

/etc/nginx/snippets/ssl-params.conf

# from https://cipherli.st/
# and https://raymii.org/s/tutorials/Strong_SSL_Security_On_nginx.html

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH";
ssl_ecdh_curve secp384r1;
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off;
ssl_stapling on;
ssl_stapling_verify on;
resolver  valid=300s;
resolver_timeout 5s;


add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload";

add_header X-Frame-Options DENY;
add_header X-Content-Type-Options nosniff;

Enregistrez et fermez le fichier lorsque vous avez terminé.

Ajuster la configuration de Nginx pour utiliser SSL

Maintenant que nous avons nos extraits, nous pouvons ajuster notre configuration Nginx pour activer SSL.

Dans ce guide, nous supposerons que vous utilisez le fichier de blocage du serveur + default + dans le répertoire + / etc / nginx / sites-available +. Si vous utilisez un fichier de blocage de serveur différent, remplacez son nom par les commandes ci-dessous.

Avant d’aller plus loin, sauvegardons notre fichier de blocage de serveur actuel:

sudo cp /etc/nginx/sites-available/default /etc/nginx/sites-available/default.bak

Ouvrez maintenant le fichier de blocage du serveur pour effectuer les ajustements suivants:

sudo nano /etc/nginx/sites-available/default

A l’intérieur, votre bloc de serveur commence probablement comme ceci:

/ etc / nginx / sites-available / default

server {
   listen 80 default_server;
   listen [::]:80 default_server;

   # SSL configuration

   # listen 443 ssl default_server;
   # listen [::]:443 ssl default_server;

   . . .

Nous allons modifier cette configuration afin que les demandes HTTP non chiffrées soient automatiquement redirigées vers HTTPS chiffré. Cela offre la meilleure sécurité pour nos sites. Si vous souhaitez autoriser le trafic HTTP et HTTPS, utilisez la configuration alternative suivante.

Nous allons scinder la configuration en deux blocs distincts. Après les deux premières directives + listen +, nous ajouterons une directive + nom_serveur +, définie sur le nom de domaine de votre serveur. Nous établirons ensuite une redirection vers le deuxième bloc de serveur que nous allons créer. Ensuite, nous allons fermer ce court bloc:

/ etc / nginx / sites-available / default

server {
   listen 80 default_server;
   listen [::]:80 default_server;
   server_name  www.;



   # SSL configuration

   # listen 443 ssl default_server;
   # listen [::]:443 ssl default_server;

   . . .

Ensuite, nous devons démarrer un nouveau bloc de serveur directement ci-dessous pour contenir la configuration restante. Nous pouvons décommenter les deux directives + listen + qui utilisent le port 443. Ensuite, il suffit d’inclure les deux fichiers de code que nous avons configurés:

/ etc / nginx / sites-available / default

server {
   listen 80 default_server;
   listen [::]:80 default_server;
   server_name  www.;
   return 301 https://$server_name$request_uri;
}



   # SSL configuration






   . . .

Enregistrez et fermez le fichier lorsque vous avez terminé.

(Configuration alternative) Autoriser le trafic HTTP et HTTPS

Si vous souhaitez ou devez autoriser le contenu crypté et non crypté, vous devrez configurer Nginx un peu différemment. Ceci n’est généralement pas recommandé s’il peut être évité, mais dans certaines situations, cela peut être nécessaire. Fondamentalement, nous compressons simplement les deux blocs de serveur distincts en un bloc et supprimons la redirection:

/ etc / nginx / sites-available / default

server {
   listen 80 default_server;
   listen [::]:80 default_server;



   server_name  www.;



   . . .

Enregistrez et fermez le fichier lorsque vous avez terminé.

Étape 4: Ajustez le pare-feu

Si un pare-feu est activé, vous devez ajuster les paramètres pour autoriser le trafic SSL. La procédure requise dépend du logiciel de pare-feu que vous utilisez. Si vous n’avez pas de pare-feu configuré actuellement, n’hésitez pas à passer au suivant.

UFW

Si vous utilisez * ufw *, vous pouvez voir le paramètre actuel en tapant:

sudo ufw status

Cela ressemblera probablement à ceci, ce qui signifie que seul le trafic HTTP est autorisé vers le serveur Web:

OutputStatus: active

To                         Action      From
--                         ------      ----
SSH                        ALLOW       Anywhere
WWW                        ALLOW       Anywhere
SSH (v6)                   ALLOW       Anywhere (v6)
WWW (v6)                   ALLOW       Anywhere (v6)

Pour ajouter du trafic HTTPS, nous pouvons autoriser le profil «WWW complet», puis supprimer l’allocation redondante du profil «WWW»:

sudo ufw allow 'WWW Full'
sudo ufw delete allow 'WWW'

Votre statut devrait ressembler à ceci maintenant:

sudo ufw status
OutputStatus: active

To                         Action      From
--                         ------      ----
SSH                        ALLOW       Anywhere
WWW Full                   ALLOW       Anywhere
SSH (v6)                   ALLOW       Anywhere (v6)
WWW Full (v6)              ALLOW       Anywhere (v6)

Les requêtes HTTPS doivent maintenant être acceptées par votre serveur.

IPTables

Si vous utilisez + iptables +, vous pouvez voir les règles actuelles en tapant:

sudo iptables -S

Si des règles sont activées, elles seront affichées. Un exemple de configuration pourrait ressembler à ceci:

Output-P INPUT DROP
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT

Les commandes nécessaires pour ouvrir le trafic SSL dépendent de vos règles actuelles. Pour un ensemble de règles de base comme celui ci-dessus, vous pouvez ajouter un accès SSL en tapant:

sudo iptables -I INPUT -p tcp -m tcp --dport 443 -j ACCEPT

Si nous regardons à nouveau les règles du pare-feu, nous devrions voir la nouvelle règle:

sudo iptables -S
Output-P INPUT DROP
-P FORWARD ACCEPT
-P OUTPUT ACCEPT

-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT

Si vous utilisez un programme pour appliquer automatiquement les règles + iptables + au démarrage, assurez-vous de mettre à jour votre configuration avec la nouvelle règle.

Étape 5: activation des modifications dans Nginx

Maintenant que nous avons apporté nos modifications et ajusté notre pare-feu, nous pouvons redémarrer Nginx pour mettre en œuvre nos nouvelles modifications.

Tout d’abord, nous devons vérifier que nos fichiers ne contiennent pas d’erreurs de syntaxe. Nous pouvons le faire en tapant:

sudo nginx -t

Si tout réussit, vous obtiendrez un résultat qui ressemble à ceci:

Outputnginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Si votre sortie correspond à ce qui précède, votre fichier de configuration ne contient aucune erreur de syntaxe. Nous pouvons redémarrer Nginx en toute sécurité pour implémenter nos modifications:

sudo systemctl restart nginx

Le certificat Let’s Encrypt TLS / SSL est maintenant en place et le pare-feu autorise désormais le trafic sur les ports 80 et 443. À ce stade, vous devez vérifier que le certificat TLS / SSL fonctionne en visitant votre domaine via HTTPS dans un navigateur Web.

Vous pouvez utiliser le rapport Qualys SSL Labs pour voir les résultats de la configuration de votre serveur:

In a web browser:https://www.ssllabs.com/ssltest/analyze.html?d=

Cela peut prendre quelques minutes à compléter. La configuration SSL de ce guide doit indiquer au moins une note * A *.

Étape 6: Configuration du renouvellement automatique

Les certificats Let Encrypt sont valides pendant 90 jours, mais il est recommandé de les renouveler tous les 60 jours pour laisser une marge d’erreur. Au moment de la rédaction de ce document, le renouvellement automatique n’est toujours pas disponible en tant que fonction du client lui-même, mais vous pouvez renouveler manuellement vos certificats en exécutant le client Let’s Encrypt avec l’option `+ renew + '.

Pour déclencher le processus de renouvellement pour tous les domaines installés, exécutez cette commande:

sudo certbot renew

Comme nous avons récemment installé le certificat, la commande vérifie uniquement la date d’expiration et affiche un message l’informant que le certificat n’est pas encore en cours de renouvellement. La sortie devrait ressembler à ceci:

Output:Saving debug log to /var/log/letsencrypt/.log

-------------------------------------------------------------------------------
Processing /etc/letsencrypt/renewal/.conf
-------------------------------------------------------------------------------
Cert not yet due for renewal

The following certs are not due for renewal yet:
 /etc/letsencrypt/live//fullchain.pem (skipped)
No renewals were attempted.

Notez que si vous avez créé un certificat groupé avec plusieurs domaines, seul le nom du domaine de base sera affiché dans la sortie, mais le renouvellement devrait être valide pour tous les domaines inclus dans ce certificat.

Un moyen pratique de vous assurer que vos certificats ne seront pas périmés est de créer un travail cron qui exécutera périodiquement la commande de renouvellement automatique pour vous. Comme le renouvellement vérifie d’abord la date d’expiration et ne l’exécute que si le certificat a moins de 30 jours d’expiration, il est prudent de créer un travail cron qui s’exécute chaque semaine ou même tous les jours, par exemple.

Modifions la crontab pour créer un nouveau travail qui exécutera la commande de renouvellement chaque semaine. Pour éditer la crontab pour l’utilisateur root, exécutez:

sudo crontab -e

Si vous utilisez pour la première fois + crontab +, il vous sera peut-être demandé de sélectionner votre éditeur de texte préféré. Si vous n’avez pas de préférence forte, * nano * est un choix facile.

Ajoutez les lignes suivantes:

crontab entry30 2 * * * /usr/bin/certbot renew --noninteractive --renew-hook "/bin/systemctl reload nginx" >> /var/log/le-renew.log

Sauvegarder et quitter. Cela créera un nouveau travail cron qui exécutera la commande + certbot renew + tous les jours à 2 h 30, et rechargera Nginx si un certificat est renouvelé. La sortie générée par la commande sera dirigée vers un fichier journal situé dans + / var / log / le-renouvellement.log +.

Conclusion

C’est ça! Votre serveur Web utilise maintenant un certificat gratuit Let’s Encrypt TLS / SSL pour diffuser en toute sécurité le contenu HTTPS.

Related