TOC

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

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 8.

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 for Debian 8.

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-on-debian-8 [configuration de LEMP sur Debian 8].

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-8] .

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

Étape 1: Créer le 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/ssl/certs/dhparam.pem 2048

Cela peut prendre quelques minutes, mais quand ce sera fait, vous aurez un groupe DH fort à + ​​/ etc / ssl / certs / dhparam.pem + que nous pourrons utiliser dans notre configuration.

Étape 2: Configurez 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é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 l’objet de ce fichier, appelons-le + self-signed.conf +:

sudo nano /etc/nginx/snippets/self-signed.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/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é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/ [ 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. 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;

Parce que nous utilisons un certificat auto-signé, l’agrafage SSL ne sera pas utilisé. Nginx émet simplement un avertissement, désactive l’agrafage de notre certificat auto-signé et continue de fonctionner correctement.

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 pour que les demandes HTTP non chiffrées soient automatiquement redirigées vers le protocole 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 ou, plus probablement, sur une adresse IP. 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;




   # 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 ;
   return 302 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 ;



   . . .

Enregistrez et fermez le fichier lorsque vous avez terminé.

Étape 3: 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 4: Activer les 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

Notre serveur devrait maintenant être accessible via HTTPS.

Étape 5: Testez le cryptage

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://

Comme le certificat que nous avons créé n’est pas signé par l’une des autorités de certification de confiance de votre navigateur, vous verrez probablement un avertissement inquiétant, comme celui ci-dessous:

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 une indication d’une sécurité partielle. Cela peut être un verrou avec un «x» dessus ou un triangle avec un point d’exclamation. 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/default

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

/ etc / nginx / sites-available / default

server {
   listen 80 default_server;
   listen [::]:80 default_server;
   server_name ;
   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

Votre site devrait maintenant émettre une redirection permanente en cas d’accès via HTTP.

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