Comment créer un certificat SSL auto-signé pour Nginx sur CentOS 7

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

[.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. Pour savoir comment configurer un certificat de confiance gratuit, suivez notre guide sursetting up Nginx with a Let’s Encrypt certificate on CentOS 7.

Conditions préalables

Tout d'abord, 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 CentOS 7.

Lorsque vous êtes prêt à commencer, connectez-vous à votre serveur en tant qu'utilisateursudo.

Étape 1: Installez Nginx et ajustez le pare-feu

Avant de commencer, nous devons nous assurer que le serveur Web Nginx est installé sur notre ordinateur.

Bien que Nginx ne soit pas disponible dans les référentiels par défaut de CentOS, il estisprésent dans le référentiel EPEL (packages supplémentaires pour Enterprise Linux). Nous pouvons permettre au référentiel EPEL de donner à notre serveur l'accès au package Nginx en tapant:

sudo yum install epel-release

Ensuite, nous pouvons installer Nginx en tapant:

sudo yum install nginx

Démarrez le service Nginx en tapant:

sudo systemctl start nginx

Vérifiez que le service est opérationnel en tapant:

systemctl status nginx
Output● nginx.service - The nginx HTTP and reverse proxy server
   Loaded: loaded (/usr/lib/systemd/system/nginx.service; disabled; vendor preset: disabled)
   Active: active (running) since Fri 2017-01-06 17:27:50 UTC; 28s ago

. . .

Jan 06 17:27:50 centos-512mb-nyc3-01 systemd[1]: Started The nginx HTTP and reverse proxy server.

Vous voudrez également activer Nginx pour qu'il démarre au démarrage de votre serveur:

sudo systemctl enable nginx
OutputCreated symlink from /etc/systemd/system/multi-user.target.wants/nginx.service to /usr/lib/systemd/system/nginx.service.

Ensuite, nous devons nous assurer que nous ne bloquons pas l'accès aux ports 80 et 443 avec un pare-feu. Si vous n'utilisez pas de pare-feu, vous pouvez passer à la section suivante.

Si vous avez un pare-feufirewalld en cours d’exécution, vous pouvez ouvrir ces ports en tapant:

sudo firewall-cmd --add-service=http
sudo firewall-cmd --add-service=https
sudo firewall-cmd --runtime-to-permanent

Si un pare-feuiptables est en cours d'exécution, les commandes que vous devez exécuter dépendent fortement de votre jeu de règles actuel. Pour un ensemble de règles de base, vous pouvez ajouter un accès HTTP et HTTPS en tapant:

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

Vous devriez maintenant pouvoir accéder à la page Nginx par défaut via un navigateur Web.

Étape 2: 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.

Le répertoire/etc/ssl/certs, qui peut être utilisé pour contenir le certificat public, doit déjà exister sur le serveur. Créons également un répertoire/etc/ssl/private pour contenir le fichier de clé privée. Le secret de cette clé étant essentiel pour la sécurité, nous allons verrouiller les autorisations pour empêcher tout accès non autorisé:

sudo mkdir /etc/ssl/private
sudo chmod 700 /etc/ssl/private

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

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 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 3: Configurez Nginx pour utiliser SSL

La configuration par défaut de Nginx dans CentOS est relativement non structurée, le bloc de serveur HTTP par défaut demeurant dans le fichier de configuration principal. Nginx recherchera les fichiers se terminant par.conf dans le répertoire/etc/nginx/conf.d pour une configuration supplémentaire.

Nous allons créer un nouveau fichier dans ce répertoire pour configurer un bloc de serveur servant du contenu à l'aide des fichiers de certificat générés. Nous pouvons ensuite éventuellement configurer le bloc de serveur par défaut pour rediriger les requêtes HTTP vers HTTPS.

Créer le bloc serveur TLS / SSL

Créez et ouvrez un fichier appeléssl.conf dans le répertoire/etc/nginx/conf.d:

sudo vi /etc/nginx/conf.d/ssl.conf

À l'intérieur, commencez par ouvrir un blocserver. Par défaut, les connexions TLS / SSL utilisent le port 443, donc cela devrait être notre portlisten. Lesserver_name doivent être définis sur le nom de domaine ou l'adresse IP du serveur que vous avez utilisé comme nom commun lors de la génération de votre certificat. Ensuite, utilisez les directivesssl_certificate,ssl_certificate_key etssl_dhparam pour définir l'emplacement des fichiers SSL que nous avons générés:

/etc/nginx/conf.d/ssl.conf

server {
    listen 443 http2 ssl;
    listen [::]:443 http2 ssl;

    server_name server_IP_address;

    ssl_certificate /etc/ssl/certs/nginx-selfsigned.crt;
    ssl_certificate_key /etc/ssl/private/nginx-selfsigned.key;
    ssl_dhparam /etc/ssl/certs/dhparam.pem;
}

Nous ajouterons ensuite quelques options SSL supplémentaires qui renforceront la sécurité de notre site. Les options que nous utiliserons sont des 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 Nginx en lisantStrong SSL Security on nginx.

[.Remarque]##

Note: Les paramètres suggérés par défaut surCipherli.st offrent une sécurité renforcé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 intitulé «Oui, donnez-moi une suite de chiffrement qui fonctionne avec les anciens / anciens logiciels».

La liste de compatibilité peut être utilisée à la place des suggestions par défaut dans la configuration ci-dessus entre les deux blocs de commentaires. Le choix de la configuration que vous utilisez dépendra en grande partie de ce que vous devez prendre en charge.

Vous voudrez peut-être modifier quelques éléments de la configuration. Tout d'abord, vous pouvez ajouter votre résolveur DNS préféré pour les requêtes en amont à la directiveresolver. Nous avons utilisé Google pour ce guide, mais vous pouvez le modifier si vous avez d’autres préférences.

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 bien comprendre les implications.

/etc/nginx/conf.d/ssl.conf

server {
    listen 443 http2 ssl;
    listen [::]:443 http2 ssl;

    server_name server_IP_address;

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

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

    ##################################
    # END https://cipherli.st/ BLOCK #
    ##################################
}

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.

Enfin, ajoutez le reste de la configuration Nginx pour votre site. Cela diffère en fonction de vos besoins. Nous allons simplement copier certaines des directives utilisées dans le bloc d'emplacement par défaut pour notre exemple, ce qui définira la racine du document et certaines pages d'erreur:

/etc/nginx/conf.d/ssl.conf

server {
    listen 443 http2 ssl;
    listen [::]:443 http2 ssl;

    server_name server_IP_address;

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

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

    . . .

    ##################################
    # END https://cipherli.st/ BLOCK #
    ##################################

    root /usr/share/nginx/html;

    location / {
    }

    error_page 404 /404.html;
    location = /404.html {
    }

    error_page 500 502 503 504 /50x.html;
    location = /50x.html {
    }
}

Lorsque vous avez terminé, enregistrez et quittez. Cela configure Nginx pour qu'il utilise notre certificat SSL généré pour chiffrer le trafic. Les options SSL spécifiées garantissent que seuls les protocoles et les chiffrements les plus sécurisés seront utilisés. Notez que cet exemple de configuration sert simplement la page Nginx par défaut, vous pouvez donc le modifier pour répondre à vos besoins.

(Facultatif) Créer une redirection de HTTP à HTTPS

Avec notre configuration actuelle, Nginx répond avec un contenu chiffré pour les demandes sur le port 443, mais avec un contenu non chiffré pour les demandes sur le port 80. Cela signifie que notre site offre un cryptage, mais ne force pas son utilisation. Cela peut convenir à certains cas d'utilisation, mais il est généralement préférable de recourir au cryptage. Ceci est particulièrement important lorsque des données confidentielles telles que des mots de passe peuvent être transférées entre le navigateur et le serveur.

Heureusement, le fichier de configuration par défaut de Nginx nous permet d'ajouter facilement des directives au bloc serveur par défaut du port 80 en ajoutant des fichiers dans le répertoire/etc/nginx/default.d. Créez un nouveau fichier appeléssl-redirect.conf et ouvrez-le pour le modifier avec cette commande:

sudo vi /etc/nginx/default.d/ssl-redirect.conf

Collez ensuite dans cette ligne:

/etc/nginx/default.d/ssl-redirect.conf

return 301 https://$host$request_uri/;

Enregistrez et fermez le fichier lorsque vous avez terminé. Ceci configure le bloc de serveur HTTP sur le port 80 (par défaut) pour rediriger les demandes entrantes vers le bloc de serveur HTTPS que nous avons configuré.

Étape 4: Activer les modifications dans Nginx

Maintenant que nous avons apporté nos modifications, nous pouvons redémarrer Nginx pour mettre en œuvre notre nouvelle configuration.

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

Le processus Nginx sera redémarré, en implémentant les paramètres SSL que nous avons configurés.

É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», puis sur le lien fourni pour accéder à votre hôte quand même:

Nginx self-signed override

Vous devriez être pris sur votre site. Si vous regardez dans la barre d'adresse du navigateur, vous verrez une indication de 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 pour rediriger les requêtes 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.

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