TOC

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

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 16.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 16.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 16.04.

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

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

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

Cela peut prendre quelques minutes, mais lorsque cela 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 la fonction de ce fichier, appelons-leself-signed.conf: 

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

Dans ce fichier, il suffit de 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é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 utiliserons les recommandations deRemy van Elst sur le siteCipherli.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 Nginxhere.

[.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. Nous allons également continuer et définir le paramètressl_dhparam pour qu'il pointe vers le fichier Diffie-Hellman que nous avons généré plus tôt.

Enfin, vous devriez prendre un moment pour lire surHTTP Strict Transport Security, or HSTS, et spécifiquement sur 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. Dans ce guide, nous ne préchargerons pas les paramètres, mais vous pouvez le modifier si vous êtes certain de 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 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;
# Disable preloading HSTS for now.  You can use the commented out header line that includes
# the "preload" directive if you understand the implications.
#add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload";
add_header Strict-Transport-Security "max-age=63072000; includeSubdomains";
add_header X-Frame-Options DENY;
add_header X-Content-Type-Options nosniff;

ssl_dhparam /etc/ssl/certs/dhparam.pem;

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.

Nous supposerons dans ce guide que vous utilisez le fichier de bloc serveurdefault dans le répertoire/etc/nginx/sites-available. Si vous utilisez un fichier de bloc de serveur différent, remplacez-le par le nom 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 diviser la configuration en deux blocs distincts. Après les deux premières directiveslisten, nous ajouterons une directiveserver_name, définie sur le nom de domaine de votre serveur ou, plus probablement, l'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:

[.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.
#

/etc/nginx/sites-available/default

server {
    listen 80 default_server;
    listen [::]:80 default_server;
    server_name server_domain_or_IP;
    return 302 https://$server_name$request_uri;
}

    # 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 directiveslisten qui utilisent le port 443. Nous pouvons ajouterhttp2 à ces lignes afin d'activer HTTP / 2 dans ce bloc. Ensuite, il suffit d’inclure les deux fichiers de code que nous avons configurés:

[.note] #Note: Vous ne pouvez avoir que la directiveonelisten qui inclut le modificateurdefault_server pour chaque version IP et combinaison de ports. Si d'autres blocs de serveur sont activés pour ces ports sur lesquelsdefault_server est défini, vous devez supprimer le modificateur de l'un des blocs.
#

/etc/nginx/sites-available/default

server {
    listen 80 default_server;
    listen [::]:80 default_server;
    server_name server_domain_or_IP;
    return 302 https://$server_name$request_uri;
}

server {

    # SSL configuration

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

    . . .

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;
    listen 443 ssl http2 default_server;
    listen [::]:443 ssl http2 default_server;

    server_name server_domain_or_IP;
    include snippets/self-signed.conf;
    include snippets/ssl-params.conf;

    . . .

Enregistrez et fermez le fichier lorsque vous avez terminé.

Étape 3: Ajustez le 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)

É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

Étape 5: Testez le 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.

É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 lereturn 302 et changez-le enreturn 301:

/etc/nginx/sites-available/default

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