TOC

Comment créer un certificat SSL auto-signé pour Apache dans Debian 9

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 les serveurs et les clients sans risque d’interception de messages 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 Apache sur 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 avec Debian 9.

Le serveur Web Apache devra également être installé. Si vous souhaitez installer une pile LAMP (Linux, Apache, MariaDB, PHP) complète sur votre serveur, vous pouvez suivre notre guide sur https://www.digitalocean.com/community/tutorials/how-to-install-linux. -apache-mariadb-php-lamp-stack-debian9 [configurer LAMP sous Debian 9]. Si vous souhaitez uniquement le serveur Web Apache, ignorez les étapes relatives à PHP et MariaDB.

Lorsque vous avez rempli ces 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/apache-selfsigned.key -out /etc/ssl/certs/apache-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. Apache 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 sous + / etc / ssl +.

Étape 2 - Configuration d’Apache pour utiliser SSL

Nous avons créé nos fichiers de clé et de certificat dans le répertoire + / etc / ssl +. Il ne nous reste plus qu’à modifier notre configuration Apache pour en tirer parti.

Nous allons faire quelques ajustements à notre configuration:

  1. Nous allons créer un extrait de configuration pour spécifier les paramètres SSL forts par défaut.

  2. Nous allons modifier le fichier d’hôte virtuel Apache SSL inclus pour qu’il pointe vers nos certificats SSL générés.

  3. (Recommandé) Nous allons modifier le fichier d’hôte virtuel non crypté pour rediriger automatiquement les demandes vers l’hôte virtuel crypté.

Lorsque nous aurons terminé, nous devrions avoir une configuration SSL sécurisée.

Création d’un extrait de configuration Apache avec des paramètres de cryptage fort

Tout d’abord, nous allons créer un extrait de configuration Apache pour définir certains paramètres SSL. Cela configurera Apache 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 utilisés par tous les hôtes virtuels activant SSL.

Créez un nouveau fragment de code dans le répertoire + / etc / apache2 / conf-available +. Nous nommerons le fichier + ssl-params.conf + pour préciser son objectif:

sudo nano /etc/apache2/conf-available/ssl-params.conf

Pour configurer de manière sécurisée Apache SSL, 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 allons juste apporter un petit changement à cela et désactiver l’en-tête + Strict-Transport-Security + (HSTS).

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 n’activerons pas les paramètres, mais vous pouvez le modifier si vous êtes certain de comprendre les implications.

Avant de vous décider, prenez un moment pour lire HTTP Strict Transport Security, ou HSTS, et plus particulièrement à propos de la https://hstspreload.appspot.com/ d’organisation. " Fonctionnalité].

Collez la configuration suivante dans le fichier + ssl-params.conf + que nous avons ouvert:

/etc/apache2/conf-available/ssl-params.conf

SSLCipherSuite EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH
SSLProtocol All -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
SSLHonorCipherOrder On


Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
Header always set X-Frame-Options DENY
Header always set X-Content-Type-Options nosniff
# Requires Apache >= 2.4
SSLCompression off
SSLUseStapling on
SSLStaplingCache "shmcb:logs/stapling-cache(150000)"
# Requires Apache >= 2.4.11
SSLSessionTickets Off

Enregistrez et fermez le fichier lorsque vous avez terminé.

Modification du fichier d’hôte virtuel SSL Apache par défaut

Ensuite, modifions + / etc / apache2 / sites-available / default-ssl.conf +, le fichier d’hôte virtuel Apache SSL par défaut. 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 le fichier d’hôte virtuel SSL original:

sudo cp /etc/apache2/sites-available/default-ssl.conf /etc/apache2/sites-available/default-ssl.conf.bak

Ouvrez maintenant le fichier SSL Virtual Host pour procéder aux ajustements suivants:

sudo nano /etc/apache2/sites-available/default-ssl.conf

A l’intérieur, avec la plupart des commentaires supprimés, le bloc de l’hôte virtuel devrait ressembler à ceci par défaut:

/etc/apache2/sites-available/default-ssl.conf

<IfModule mod_ssl.c>
       <VirtualHost _default_:443>
               ServerAdmin webmaster@localhost

               DocumentRoot /var/www/html

               ErrorLog ${APACHE_LOG_DIR}/error.log
               CustomLog ${APACHE_LOG_DIR}/access.log combined

               SSLEngine on

               SSLCertificateFile      /etc/ssl/certs/ssl-cert-snakeoil.pem
               SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key

               <FilesMatch "\.(cgi|shtml|phtml|php)$">
                               SSLOptions +StdEnvVars
               </FilesMatch>
               <Directory /usr/lib/cgi-bin>
                               SSLOptions +StdEnvVars
               </Directory>

       </VirtualHost>
</IfModule>

Nous apporterons quelques ajustements mineurs au dossier. Nous allons définir les éléments normaux que nous ne souhaitons pas modifier dans un fichier d’hôte virtuel (adresse électronique ServerAdmin, NomServeur, etc.) et ajuster les directives SSL pour qu’elles pointent vers nos fichiers de certificat et de clé. Encore une fois, si vous utilisez une racine de document différente, veillez à mettre à jour la directive + DocumentRoot +.

Après avoir apporté ces modifications, votre bloc serveur devrait ressembler à ceci:

/etc/apache2/sites-available/default-ssl.conf

<IfModule mod_ssl.c>
       <VirtualHost _default_:443>
               ServerAdmin


               DocumentRoot /var/www/html

               ErrorLog ${APACHE_LOG_DIR}/error.log
               CustomLog ${APACHE_LOG_DIR}/access.log combined

               SSLEngine on

               SSLCertificateFile      /etc/ssl/certs/
               SSLCertificateKeyFile /etc/ssl/private/

               <FilesMatch "\.(cgi|shtml|phtml|php)$">
                               SSLOptions +StdEnvVars
               </FilesMatch>
               <Directory /usr/lib/cgi-bin>
                               SSLOptions +StdEnvVars
               </Directory>

       </VirtualHost>
</IfModule>

Enregistrez et fermez le fichier lorsque vous avez terminé.

(Recommandé) Modification du fichier d’hôte HTTP pour une redirection vers HTTPS

Dans l’état actuel des choses, le serveur fournira à la fois le trafic HTTP non crypté et le trafic HTTPS crypté. Pour une meilleure sécurité, il est recommandé dans la plupart des cas de rediriger automatiquement HTTP vers HTTPS. Si vous ne souhaitez pas ou n’avez pas besoin de cette fonctionnalité, vous pouvez ignorer cette section en toute sécurité.

Pour ajuster le fichier d’hôte virtuel non chiffré afin de rediriger tout le trafic sur SSL, ouvrez le fichier + / etc / apache2 / sites-available / 000-default.conf +:

sudo nano /etc/apache2/sites-available/000-default.conf

À l’intérieur, dans les blocs de configuration + VirtualHost +, ajoutez une directive + Redirect +, pointant tout le trafic vers la version SSL du site:

/etc/apache2/sites-available/000-default.conf

<VirtualHost *:80>
       . . .

       Redirect "/" "https:///"

       . . .
</VirtualHost>

Enregistrez et fermez le fichier lorsque vous avez terminé.

C’est tous les changements de configuration que vous devez apporter à Apache. Nous verrons ensuite comment mettre à jour les règles de pare-feu avec + ufw + pour autoriser le trafic HTTPS chiffré sur votre serveur.

Étape 3 - Réglage du pare-feu

Si le pare-feu + ufw + est activé, comme recommandé par les guides de prérequis, vous devrez peut-être ajuster les paramètres pour autoriser le trafic SSL. Heureusement, une fois installé sur Debian 9, + ufw + est fourni avec des profils d’application que vous pouvez utiliser pour modifier les paramètres de votre pare-feu.

Nous pouvons voir les profils disponibles en tapant:

sudo ufw app list

Vous devriez voir une liste comme celle-ci, avec les quatre profils suivants situés au bas de la sortie:

OutputAvailable applications:
. . .
 WWW
 WWW Cache
 WWW Full
 WWW Secure
. . .

Vous pouvez voir le réglage actuel en tapant:

sudo ufw status

Si vous avez autorisé uniquement le trafic HTTP normal auparavant, votre sortie pourrait ressembler à ceci:

OutputStatus: active

To                         Action      From
--                         ------      ----
OpenSSH                    ALLOW       Anywhere
WWW                        ALLOW       Anywhere
OpenSSH (v6)               ALLOW       Anywhere (v6)
WWW (v6)                   ALLOW       Anywhere (v6)

Pour ajouter du trafic HTTPS, autorisez le profil «WWW complet», puis supprimez le profil redondant 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
--                         ------      ----
OpenSSH                    ALLOW       Anywhere
WWW Full                   ALLOW       Anywhere
OpenSSH (v6)               ALLOW       Anywhere (v6)
WWW Full (v6)              ALLOW       Anywhere (v6)

Votre pare-feu étant configuré pour autoriser le trafic HTTPS, vous pouvez passer à l’étape suivante. Nous verrons ensuite comment activer quelques modules et fichiers de configuration pour permettre à SSL de fonctionner correctement.

Étape 4 - Activation des modifications dans Apache

Maintenant que nous avons apporté nos modifications et ajusté notre pare-feu, nous pouvons activer les modules SSL et les en-têtes dans Apache, activer notre hôte virtuel compatible SSL, puis redémarrer Apache pour appliquer ces modifications.

Activez + mod_ssl +, le module SSL Apache et + mod_headers +, requis par certains des paramètres de notre extrait de code SSL, à l’aide de la commande + a2enmod +:

sudo a2enmod ssl
sudo a2enmod headers

Ensuite, activez votre hôte virtuel SSL avec la commande + a2ensite +:

sudo a2ensite default-ssl

Vous devrez également activer votre fichier + ssl-params.conf +, pour lire les valeurs que vous avez définies:

sudo a2enconf ssl-params

À ce stade, le site et les modules nécessaires sont activés. Nous devrions vérifier que nos fichiers ne contiennent aucune erreur de syntaxe. Faites ceci en tapant:

sudo apache2ctl configtest

Si tout réussit, vous obtiendrez un résultat qui ressemble à ceci:

OutputSyntax OK

Tant que votre sortie contient + Syntax OK +, votre fichier de configuration ne contient aucune erreur de syntaxe et vous pouvez redémarrer Apache en toute sécurité pour implémenter les modifications:

sudo systemctl restart apache2

Avec cela, votre certificat SSL auto-signé est tout défini. Vous pouvez maintenant vérifier que votre serveur chiffre correctement son trafic.

Étape 5 - Test du chiffrement

Vous êtes maintenant prêt à 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 vous avez 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/apache_ssl_1604/self_signed_warning.png [Avertissement de certif Apache auto-signé]

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 continuer à accéder à votre hôte:

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

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 ou un autre avis similaire «non sécurisé». Dans ce cas, cela signifie simplement que le certificat ne peut pas être validé. Il crypte toujours votre connexion.

Si vous avez configuré Apache pour rediriger 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. Toutefois, la redirection que vous avez créée précédemment n’est qu’une redirection temporaire. Si vous souhaitez rendre la redirection permanente vers HTTPS, passez à la dernière étape.

É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 à nouveau l’hôte virtuel Apache non chiffré pour rendre la redirection permanente.

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

sudo nano /etc/apache2/sites-available/000-default.conf

Trouvez la ligne + Redirect + que nous avons ajoutée plus tôt. Ajoutez + permanent + à cette ligne, ce qui change la redirection d’une redirection temporaire 302 en une redirection permanente 301:

/etc/apache2/sites-available/000-default.conf

<VirtualHost *:80>
       . . .

       Redirect  "/" "https:///"

       . . .
</VirtualHost>

Enregistrez et fermez le fichier.

Vérifiez votre configuration pour les erreurs de syntaxe:

sudo apache2ctl configtest

Si cette commande ne rapporte aucune erreur de syntaxe, redémarrez Apache:

sudo systemctl restart apache2

Cela rendra la redirection permanente et votre site ne servira que du trafic sur HTTPS.

Conclusion

Vous avez configuré votre serveur Apache 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