TOC

Comment créer un certificat SSL auto-signé pour Nginx dans Ubuntu 18.04

Une version précédente de ce tutoriel a été écrite parJustin Ellingwood

introduction

TLS, ou sécurité de la couche de transport, et son prédécesseurSSL, qui signifie couche de sockets sécurisés, 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 Ubuntu 18.04.

[.Remarque]##

Note: Un certificat auto-signé cryptera la communication entre votre serveur et tous les clients. Cependant, comme il n'est signé par aucune des autorités de certification de confiance incluses dans les navigateurs Web, les utilisateurs ne peuvent pas utiliser le certificat pour valider automatiquement l'identité de votre serveur.

Un certificat auto-signé peut être approprié si vous n'avez pas de nom de domaine associé à votre serveur et dans les cas où l'interface Web chiffrée n'est pas accessible à l'utilisateur. Si vousdo avez un nom de domaine, dans de nombreux cas, il est préférable d'utiliser un certificat signé par une autorité de certification. Vous pouvez découvrir comment configurer un certificat de confiance gratuit avec le projet Let’s Encrypthere.

Conditions préalables

Avant de commencer, vous devez avoir un utilisateur non root configuré avec les privilègessudo. Vous pouvez apprendre comment configurer un tel compte utilisateur en suivant nosinitial server setup for Ubuntu 18.04.

Le serveur Web Nginx doit également être installé. Si vous souhaitez installer une pile LEMP (Linux, Nginx, MySQL, PHP) entière sur votre serveur, vous pouvez suivre notre guide sursetting up LEMP on Ubuntu 18.04.

Si vous voulez juste le serveur Web Nginx, vous pouvez plutôt suivre notre guide surinstalling Nginx on Ubuntu 18.04.

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

[[step-1 -–- creation-the-ssl-certificate]] == Étape 1 - Création du certificat SSL

TLS/SSL works by using a combination of a public certificate and a private key. 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 créer et gérer les certificats, clés et autres fichiers OpenSSL.

  • req: cette sous-commande spécifie que nous voulons utiliser la gestion des demandes de signature de certificat (CSR) 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: Cela modifie encore la sous-commande précédente en indiquant à l'utilitaire que nous voulons 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 d'ignorer l'option pour sécuriser notre certificat avec une phrase de passe. 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 partiersa:2048 lui dit de créer une clé RSA d'une longueur de 2048 bits.

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

  • -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. The most important line is the one that requests the Common Name (e.g. server FQDN or YOUR name). You need to enter the domain name associated with your server or, more likely, your server’s public IP address.

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

OutputCountry Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:New York
Locality Name (eg, city) []:New York City
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Bouncy Castles, Inc.
Organizational Unit Name (eg, section) []:Ministry of Water Slides
Common Name (e.g. server FQDN or YOUR name) []:server_IP_address
Email Address []:admin@your_domain.com

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

Pendant que nous utilisons OpenSSL, nous devrions également créer un groupe Diffie-Hellman fort, qui est utilisé dans la négociation dePerfect 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 lorsque cela sera fait, vous aurez un groupe DH fort à/etc/nginx/dhparam.pem que nous pouvons utiliser dans notre configuration.

[[step-2 -–- configuring-nginx-to-use-ssl]] == É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 la fonction de ce fichier, appelons-leself-signed.conf: 

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

Dans ce fichier, nous devons définir la directivessl_certificate sur notre fichier de certificat et lesssl_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 utiliserons les recommandations de Remy van Elst sur le siteCipherli.st. Ce site est conçu pour fournir des paramètres de chiffrement faciles à utiliser pour les logiciels courants.

[.Remarque]##

Les paramètres suggérés sur le site lié à ci-dessus offrent une sécurité élevée. Parfois, cela se fait au détriment d'une meilleure compatibilité client. Si vous devez prendre en charge des clients plus âgés, il existe une autre liste accessible en cliquant sur le lien de la page intitulée «Oui, donnez-moi une suite de chiffrement qui fonctionne avec les anciens / anciens logiciels». Cette liste peut être remplacée par les éléments copiés au dessous de.

Le choix de la configuration que vous utiliserez dépendra en grande partie de ce que vous devez prendre en charge. Ils offriront tous les deux une grande sécurité.

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 décommenter cette ligne, vous devriez prendre un moment pour lire lesHTTP Strict Transport Security, or HSTS, et plus particulièrement les“preload” functionality. 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 ce qui suit dans votre fichier d'extrait de codessl-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";

Parce que nous utilisons un certificat auto-signé, l'agrafage SSL ne sera pas utilisé. Nginx émettra un avertissement, désactivera l'agrafage pour notre certificat auto-signé et 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.

Nous supposerons dans ce guide que vous utilisez un fichier de configuration de bloc de serveur personnalisé dans le répertoire/etc/nginx/sites-available. Nous utiliserons/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/example.com /etc/nginx/sites-available/example.com.bak

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

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

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 example.com www.example.com;

    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 directivesroot etindex, vous pouvez avoir deslocation,proxy_pass ou d'autres instructions de configuration personnalisées. C'est correct, car nous n'avons besoin que de mettre à jour les directiveslisten et d'inclure nos extraits de code 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.

[.note] #Note: Nous utiliserons une redirection 302 jusqu'à ce que nous ayons vérifié que tout fonctionne correctement. Ensuite, nous pouvons changer cela en une redirection 301.
#

Dans votre fichier de configuration existant, mettez à jour les deux instructionslisten pour utiliser le port 443 et ssl, puis incluez les deux fichiers d'extraits que nous avons créés lors des étapes précédentes:

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

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    include snippets/self-signed.conf;
    include snippets/ssl-params.conf;

    server_name example.com www.example.com;

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

    . . .
}

Ensuite, collez un deuxième bloc serveur dans le fichier de configuration, après le crochet fermant (}) du premier bloc:

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

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

    server_name example.com www.example.com;

    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.

[[step-3 -–- Adjusting-the-firewall]] == Étape 3 - Réglage du pare-feu

Si le pare-feu deufw est activé, comme recommandé par les guides des prérequis, vous devrez ajuster les paramètres pour autoriser le trafic SSL. Heureusement, Nginx enregistre quelques profils avecufw 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
  OpenSSH

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)

[[step-4 -–- enabled-the-changes-in-nginx]] == É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

[[step-5 -–- testing-encryption]] == Étape 5 - Test du cryptage

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

Ouvrez votre navigateur Web et saisissezhttps:// suivi du nom de domaine ou de l'adresse IP de votre serveur dans la barre d'adresse: 

https://server_domain_or_IP

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:

Nginx self-signed cert warning

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:

Nginx self-signed override

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

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

[[step-6 -–- changer-en-une-redirection permanente]] == Étape 6 - Changer en 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/example.com

Trouvez lereturn 302 et changez-le enreturn 301:

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

    return 301 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