TOC

Comment créer un certificat SSL auto-signé pour Nginx sur Debian 9

_Une version précédente de ce tutoriel a été écrite par Justin Ellingwood _

introduction

  • TLS *, ou sécurité de la couche de transport, et son prédécesseur * SSL *, qui correspond à Secure Sockets Layer, sont des protocoles Web utilisés pour envelopper le trafic normal dans un wrapper protégé et chiffré.

Grâce à cette technologie, les serveurs peuvent envoyer du trafic en toute sécurité entre le serveur et les clients sans que les messages puissent être interceptés par des tiers. Le système de certification aide également les utilisateurs à vérifier l’identité des sites auxquels ils se connectent.

Dans ce guide, nous allons vous montrer comment configurer un certificat SSL auto-signé pour une utilisation avec un serveur Web Nginx sur un serveur Debian 9.

Conditions préalables

Avant de commencer, vous devez avoir un utilisateur non root configuré avec les privilèges + sudo +. Vous pouvez apprendre à configurer un tel compte utilisateur en suivant notre initial initial server server for Debian 9.

Le serveur Web Nginx doit également être installé. Si vous souhaitez installer une pile LEMP complète (Linux, Nginx, MySQL, PHP) sur votre serveur, vous pouvez suivre notre guide sur https://www.digitalocean.com/community/tutorials/how-to-install-linux. -nginx-mysql-php-lemp-stack-debian-9 [configurer LEMP sur Debian 9].

Si vous voulez juste le serveur Web Nginx, vous pouvez plutôt suivre notre guide à l’adresse https://www.digitalocean.com/community/tutorials/how-to-install-nginx-on-debian-9] .

Lorsque vous avez terminé les conditions préalables, continuez ci-dessous.

Étape 1 - Création du certificat SSL

TLS / SSL fonctionne en combinant un certificat public et une clé privée. La clé SSL est gardée secrète sur le serveur. Il est utilisé pour chiffrer le contenu envoyé aux clients. Le certificat SSL est partagé publiquement avec toute personne demandant le contenu. Il peut être utilisé pour déchiffrer le contenu signé par la clé SSL associée.

Nous pouvons créer une paire de clés et de certificats auto-signée avec OpenSSL en une seule commande:

sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/ssl/private/nginx-selfsigned.key -out /etc/ssl/certs/nginx-selfsigned.crt

On vous posera une série de questions. Avant de commencer, examinons ce qui se passe dans la commande que nous émettons:

  • * openssl *: Il s’agit de l’outil de ligne de commande de base pour la création et la gestion de certificats OpenSSL, de clés et d’autres fichiers.

  • * req *: Cette sous-commande indique que nous souhaitons utiliser la gestion de la demande de signature de certificat X.509. «X.509» est une norme d’infrastructure à clé publique à laquelle SSL et TLS adhèrent pour la gestion de ses clés et de ses certificats. Nous voulons créer un nouveau certificat X.509, nous utilisons donc cette sous-commande.

  • * -x509 *: Ceci modifie encore la sous-commande précédente en indiquant à l’utilitaire que nous souhaitons créer un certificat auto-signé au lieu de générer une demande de signature de certificat, comme cela se produirait normalement.

  • * -nodes *: Ceci indique à OpenSSL de sauter l’option permettant de sécuriser notre certificat avec une phrase secrète. Nginx doit pouvoir lire le fichier, sans intervention de l’utilisateur, au démarrage du serveur. Un mot de passe empêcherait cela, car nous devions le saisir après chaque redémarrage.

  • * -days 365 *: Cette option définit la durée pendant laquelle le certificat sera considéré comme valide. Nous le fixons pour un an ici.

  • * -newkey rsa: 2048 *: Ceci spécifie que nous voulons générer un nouveau certificat et une nouvelle clé en même temps. Nous n’avons pas créé la clé requise pour signer le certificat lors d’une étape précédente. Nous devons donc le créer avec le certificat. La partie + rsa: 2048 + lui dit de créer une clé RSA de 2048 bits.

  • * -keyout *: Cette ligne indique à OpenSSL où placer le fichier de clé privée généré que nous sommes en train de créer.

  • * -out *: Ceci indique à OpenSSL où placer le certificat que nous créons.

Comme nous l’avons indiqué ci-dessus, ces options créeront à la fois un fichier de clé et un certificat. On nous posera quelques questions sur notre serveur afin d’intégrer correctement les informations dans le certificat.

Remplissez les invites de manière appropriée. * La ligne la plus importante est celle qui demande le nom commun `+ (p. Ex. nom de domaine complet du serveur ou VOTRE nom) + `. Vous devez entrer le nom de domaine associé à votre serveur ou, plus probablement, l’adresse IP publique de votre serveur. *

L’intégralité des invites ressemblera à ceci:

OutputCountry Name (2 letter code) [AU]:
State or Province Name (full name) [Some-State]:
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:
Email Address []:

Les deux fichiers que vous avez créés seront placés dans les sous-répertoires appropriés du répertoire + / etc / ssl +.

Lorsque nous utilisons OpenSSL, nous devrions également créer un groupe Diffie-Hellman fort, utilisé pour la négociation de Perfect Forward Secrecy avec les clients.

Nous pouvons le faire en tapant:

sudo openssl dhparam -out /etc/nginx/dhparam.pem 4096

Cela prendra un certain temps, mais quand ce sera fait, vous aurez un groupe DH fort à + ​​/ etc / nginx / dhparam.pem + que nous pourrons utiliser dans notre configuration.

Étape 2 - Configuration de Nginx pour utiliser SSL

Nous avons créé nos fichiers de clé et de certificat dans le répertoire + / etc / ssl +. Nous devons maintenant modifier notre configuration Nginx pour en tirer parti.

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 nos blocs de 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éation d’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 l’objet de ce fichier, appelons-le + self-signed.conf +:

sudo nano /etc/nginx/snippets/self-signed.conf

Dans ce fichier, nous devons 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/self-signed.conf

ssl_certificate /etc/ssl/certs/nginx-selfsigned.crt;
ssl_certificate_key /etc/ssl/private/nginx-selfsigned.key;

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

Création d’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.

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.

Deuxièmement, nous commenterons la ligne qui définit l’en-tête de sécurité de transport strict. Avant de commenter cette ligne, prenez un moment pour lire HTTP Strict Transport Security, ou HSTS, en particulier sur le https://hstspreload.appspot.com. / [Fonctionnalité de "préchargement"]. 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.

Copiez le texte suivant dans votre fichier d’extrait + ssl-params.conf +:

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

ssl_protocols TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_dhparam /etc/nginx/dhparam.pem;
ssl_ciphers ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384;
ssl_ecdh_curve secp384r1; # Requires nginx >= 1.1.0
ssl_session_timeout  10m;
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off; # Requires nginx >= 1.5.9
ssl_stapling on; # Requires nginx >= 1.3.7
ssl_stapling_verify on; # Requires nginx => 1.3.7
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;
# Disable strict transport security for now. You can uncomment the following
# line if you understand the implications.
# add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload";
add_header X-Frame-Options DENY;
add_header X-Content-Type-Options nosniff;
add_header X-XSS-Protection "1; mode=block";

Comme nous utilisons un certificat auto-signé, l’agrafage SSL ne sera pas utilisé. Nginx émettra un avertissement mais continuera à fonctionner correctement.

Enregistrez et fermez le fichier lorsque vous avez terminé.

Réglage de 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 un fichier de configuration de bloc de serveur personnalisé dans le répertoire + / etc / nginx / sites-available +. Nous allons utiliser + / etc / nginx / sites-available / example.com + pour cet exemple. Remplacez votre nom de fichier de configuration si nécessaire.

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

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

Maintenant, ouvrez le fichier de configuration pour faire les ajustements:

sudo nano /etc/nginx/sites-available/

A l’intérieur, votre bloc de serveur commence probablement de la même façon:

/etc/nginx/sites-available/example.com

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

   server_name ;

   root /var/www/example.com/html;
   index index.html index.htm index.nginx-debian.html;

   . . .
}

Votre fichier peut être dans un ordre différent, et au lieu des directives + racine + et + index +, vous pouvez avoir des instructions + location +, '+ + proxy_pass + `ou autres instructions de configuration personnalisées. Ce n’est pas grave, il suffit de mettre à jour les directives `+ listen + 'et d’inclure nos extraits SSL. Nous allons modifier ce bloc de serveur existant pour desservir le trafic SSL sur le port 443, puis créer un nouveau bloc de serveur pour répondre sur le port 80 et rediriger automatiquement le trafic vers le port 443.

Dans votre fichier de configuration existant, mettez à jour les deux instructions + listen + pour qu’elles utilisent le port 443 et SSL, puis incluez les deux fichiers d’extrait de code créés précédemment.

/etc/nginx/sites-available/example.com

server {
   listen ;
   listen [::]:;



   server_name ;

   root /var/www/example.com/html;
   index index.html index.htm index.nginx-debian.html;

   . . .
}

Ensuite, collez un second bloc serveur dans le fichier de configuration, après le crochet de fermeture (+} +) du premier bloc:

/etc/nginx/sites-available/example.com

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

   server_name ;

   return 302 https://$server_name$request_uri;
}

Il s’agit d’une configuration simple qui écoute sur le port 80 et effectue la redirection vers HTTPS. Enregistrez et fermez le fichier lorsque vous avez fini de le modifier.

Étape 3 - Réglage du pare-feu

Si le pare-feu + ufw + est activé, comme recommandé par les guides de prérequis, vous devrez ajuster les paramètres pour autoriser le trafic SSL. Heureusement, Nginx enregistre quelques profils avec + ufw + lors de l’installation.

Nous pouvons voir les profils disponibles en tapant:

sudo ufw app list

Vous devriez voir une liste comme celle-ci:

OutputAvailable applications:
. . .
 Nginx Full
 Nginx HTTP
 Nginx HTTPS
. . .

Vous pouvez voir le réglage 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
--                         ------      ----
OpenSSH                    ALLOW       Anywhere
Nginx HTTP                 ALLOW       Anywhere
OpenSSH (v6)               ALLOW       Anywhere (v6)
Nginx HTTP (v6)            ALLOW       Anywhere (v6)

Pour ajouter du trafic HTTPS, nous pouvons autoriser le profil «Nginx Full», puis supprimer le profil redondant «Nginx HTTP»:

sudo ufw allow 'Nginx Full'
sudo ufw delete allow 'Nginx HTTP'

Votre statut devrait ressembler à ceci maintenant:

sudo ufw status
OutputStatus: active

To                         Action      From
--                         ------      ----
OpenSSH                    ALLOW       Anywhere
Nginx Full                 ALLOW       Anywhere
OpenSSH (v6)               ALLOW       Anywhere (v6)
Nginx Full (v6)            ALLOW       Anywhere (v6)

Étape 4 - 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: [warn] "ssl_stapling" ignored, issuer certificate not found
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Remarquez l’avertissement au début. Comme indiqué précédemment, ce paramètre génère un avertissement, car notre certificat auto-signé ne peut pas utiliser l’agrafage SSL. Cela est prévu et notre serveur peut toujours chiffrer les connexions correctement.

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

Étape 5 - Test du chiffrement

Nous sommes maintenant prêts à tester votre serveur SSL.

Ouvrez votre navigateur Web et tapez + https: // + suivi du nom de domaine ou de l’IP de votre serveur dans la barre d’adresse:

https://

Le certificat que nous avons créé n’étant pas signé par l’une des autorités de certification de confiance de votre navigateur, vous verrez probablement un avertissement épouvantable, comme celui ci-dessous (ce qui suit apparaît lorsque vous utilisez Google Chrome):

image: https: //assets.digitalocean.com/articles/nginx_ssl_1604/self_signed_warning.png [Avertissement de certificat auto-signé de Nginx]

Ceci est prévu et normal. Nous ne sommes intéressés que par l’aspect cryptage de notre certificat, et non par la validation par un tiers de l’authenticité de notre hôte. Cliquez sur «ADVANCED» (Avancé), puis sur le lien fourni pour tout de même accéder à votre hôte:

image: https: //assets.digitalocean.com/articles/nginx_ssl_1604/warning_override.png [Remplacement auto-signé par Nginx]

Vous devriez être pris sur votre site. Si vous regardez dans la barre d’adresse du navigateur, vous verrez un verrou avec un «x» dessus. Dans ce cas, cela signifie simplement que le certificat ne peut pas être validé. Il crypte toujours votre connexion.

Si vous avez configuré Nginx avec deux blocs de serveur, redirigeant automatiquement le contenu HTTP vers HTTPS, vous pouvez également vérifier si la redirection fonctionne correctement:

http://

Si cela entraîne la même icône, cela signifie que votre redirection a fonctionné correctement.

Étape 6 - Passage à une redirection permanente

Si votre redirection fonctionne correctement et que vous êtes sûr de vouloir autoriser uniquement le trafic chiffré, vous devez modifier la configuration de Nginx pour rendre la redirection permanente.

Ouvrez à nouveau votre fichier de configuration de bloc de serveur:

sudo nano /etc/nginx/sites-available/

Trouvez le + return 302 + et changez le en + return 301 +:

/etc/nginx/sites-available/example.com

   return  https://$server_name$request_uri;

Enregistrez et fermez le fichier.

Vérifiez votre configuration pour les erreurs de syntaxe:

sudo nginx -t

Lorsque vous êtes prêt, redémarrez Nginx pour rendre la redirection permanente:

sudo systemctl restart nginx

Conclusion

Vous avez configuré votre serveur Nginx pour utiliser un cryptage fort pour les connexions client. Cela vous permettra de répondre aux demandes en toute sécurité et empêchera des tiers de lire votre trafic.

Related