• Articles
• admin

Introduction

TLS, ou transport layer security, et son prédécesseur SSL, qui signifie secure sockets layer, sont des protocoles Web utilisés pour envelopper le trafic normal dans un wrapper protégé et crypté.

Grâce à cette technologie, les serveurs peuvent envoyer du trafic en toute sécurité entre le serveur et les clients sans possibilité que les messages soient interceptés par des tiers. Le système de certificat aide également les utilisateurs à vérifier l’identité des sites avec lesquels 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 un serveur Ubuntu 16.04.

Remarque : Un certificat auto-signé chiffrera 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 pour les cas où l’interface Web cryptée n’est pas orientée utilisateur. Si vous 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 Encrypt ici.

Prérequis

Avant de commencer, vous devez avoir un utilisateur non root configuré avec des privilèges sudo. Vous pouvez apprendre à configurer un tel compte utilisateur en suivant notre configuration initiale du serveur pour Ubuntu 16.04.

Vous devrez également installer le serveur web Apache. Si vous souhaitez installer une pile LAMP entière (Linux, Apache, MySQL, PHP) sur votre serveur, vous pouvez suivre notre guide de configuration de LAMP sur Ubuntu 16.04. Si vous voulez juste le serveur Web Apache, ignorez les étapes relatives à PHP et MySQL dans le guide.

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

Étape 1: Créer le certificat SSL

TLS/SSL fonctionne en utilisant une combinaison d’un certificat public et d’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és 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

Une série de questions vous sera posée. Avant de passer en revue cela, jetons un coup d’œil à 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 des certificats, des clés et d’autres fichiers OpenSSL.
• req : Cette sous-commande spécifie que nous voulons utiliser la gestion des demandes de signature de certificat (CSR) X.509. Le « X.509  » est une norme d’infrastructure à clé publique à laquelle SSL et TLS adhèrent pour sa gestion des clés et des 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.
• – nœuds : Cela indique à OpenSSL d’ignorer l’option pour sécuriser notre certificat avec une phrase secrète. Nous avons besoin d’Apache pour pouvoir lire le fichier, sans intervention de l’utilisateur, au démarrage du serveur. Une phrase secrète empêcherait cela de se produire car nous devions la saisir après chaque redémarrage.
• – jours 365: Cette option définit la durée pendant laquelle le certificat sera considéré comme valide. Nous l’avons fixé pour un an ici.
• – newkey rsa: 2048 : Cela 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 la créer avec le certificat. La partie rsa:2048 lui indique de créer une clé RSA longue de 2048 bits.
• – keyout: Cette ligne indique à OpenSSL où placer le fichier de clé privée généré que nous créons.
• – sortie: Cela 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. Quelques questions sur notre serveur nous seront posées 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 Common Name (e.g. server FQDN or YOUR name). Vous devez saisir le nom de domaine associé à votre serveur ou, plus probablement, l’adresse IP publique de votre serveur.

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

Output
Country Name (2 letter code) :USState or Province Name (full name) :New YorkLocality Name (eg, city) :New York CityOrganization Name (eg, company) :Bouncy Castles, Inc.Organizational Unit Name (eg, section) :Ministry of Water SlidesCommon Name (e.g. server FQDN or YOUR name) :server_IP_addressEmail 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é pour négocier un Secret parfait 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 solide à /etc/ssl/certs/dhparam.pem que nous pourrons utiliser dans notre configuration.

Étape 2 : Configurer Apache pour utiliser SSL

Nous avons créé nos fichiers de clés et de certificats sous le répertoire /etc/ssl. Maintenant, il nous suffit de modifier notre configuration Apache pour en tirer parti.

Nous allons apporter quelques ajustements à notre configuration:

1. Nous allons créer un extrait de configuration pour spécifier les paramètres SSL par défaut forts.
2. Nous modifierons le fichier d’hôte virtuel Apache SSL inclus pour pointer vers nos certificats SSL générés.
3. (Recommandé) Nous modifierons le fichier d’Hôte virtuel non chiffré pour rediriger automatiquement les demandes vers l’Hôte virtuel chiffré.

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

Créer un extrait de configuration Apache avec des paramètres de cryptage forts

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 aideront à sécuriser notre serveur. Les paramètres que nous allons définir peuvent être utilisés par tous les hôtes virtuels activant SSL.

Créez un nouvel extrait de code dans le répertoire /etc/apache2/conf-available. Nous nommerons le fichier ssl-params.conf pour que son but soit clair:

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

Pour configurer Apache SSL en toute sécurité, nous utiliserons les recommandations de Remy van Elst sur le Cipherli.st site. Ce site est conçu pour fournir des paramètres de cryptage faciles à utiliser pour les logiciels populaires. Vous pouvez en savoir plus sur ses décisions concernant les choix d’Apache ici.

Les paramètres suggérés sur le site lié ci-dessus offrent une sécurité renforcée. Parfois, cela se fait au prix d’une plus grande compatibilité client. Si vous avez besoin de prendre en charge des clients plus anciens, il existe une liste alternative accessible en cliquant sur le lien sur la page intitulée « Oui, donnez-moi une suite de chiffrement qui fonctionne avec des logiciels hérités / anciens. »Cette liste peut être substituée aux éléments copiés ci-dessous.

Le choix de la configuration que vous utilisez 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 allons juste faire deux petits changements.

Définissez la directive SSLOpenSSLConfCmd DHParameters pour qu’elle pointe vers le fichier Diffie-Hellman que nous avons généré précédemment. Prenez également un moment pour lire sur la sécurité de transport stricte HTTP, ou HSTS, et plus précisément sur la fonctionnalité de « préchargement ». Le préchargement de HSTS offre une sécurité accrue, mais peut avoir des conséquences importantes s’il est activé accidentellement ou incorrectement. Dans ce guide, nous ne préchargerons pas les paramètres, mais vous pouvez les modifier si vous êtes sûr de comprendre les implications:

# from https://cipherli.st/# and https://raymii.org/s/tutorials/Strong_SSL_Security_On_Apache2.htmlSSLCipherSuite EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDHSSLProtocol All -SSLv2 -SSLv3SSLHonorCipherOrder On# Disable preloading HSTS for now. You can use the commented out header line that includes# the "preload" directive if you understand the implications.#Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains; preload"Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains"Header always set X-Frame-Options DENYHeader always set X-Content-Type-Options nosniff# Requires Apache >= 2.4SSLCompression off SSLSessionTickets OffSSLUseStapling on SSLStaplingCache "shmcb:logs/stapling-cache(150000)"SSLOpenSSLConfCmd DHParameters "/etc/ssl/certs/dhparam.pem"

Enregistrez et fermez le fichier lorsque vous avez terminé.

Modifier le 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 SSL Apache par défaut. Si vous utilisez un fichier de bloc de serveur différent, remplacez son nom dans les commandes ci-dessous.

Avant d’aller plus loin, sauvegardons le fichier d’hôte virtuel SSL d’origine:

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

Maintenant, ouvrez le fichier d’hôte virtuel SSL pour effectuer des ajustements:

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

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

<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> # BrowserMatch "MSIE " \ # nokeepalive ssl-unclean-shutdown \ # downgrade-1.0 force-response-1.0 </VirtualHost></IfModule>

Nous allons apporter quelques ajustements mineurs au fichier. Nous définirons les éléments normaux que nous souhaiterions ajuster dans un fichier hôte virtuel (adresse e-mail ServerAdmin, nom de serveur, etc.), ajustez les directives SSL pour pointer vers nos fichiers de certificats et de clés, et décommentez une section qui fournit la compatibilité pour les navigateurs plus anciens.

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

<IfModule mod_ssl.c> <VirtualHost _default_:443> ServerAdmin [email protected] ServerName server_domain_or_IP DocumentRoot /var/www/html ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined SSLEngine on SSLCertificateFile /etc/ssl/certs/apache-selfsigned.crt SSLCertificateKeyFile /etc/ssl/private/apache-selfsigned.key <FilesMatch "\.(cgi|shtml|phtml|php)$"> SSLOptions +StdEnvVars </FilesMatch> <Directory /usr/lib/cgi-bin> SSLOptions +StdEnvVars </Directory> BrowserMatch "MSIE " \ nokeepalive ssl-unclean-shutdown \ downgrade-1.0 force-response-1.0 </VirtualHost></IfModule>

Enregistrez et fermez le fichier lorsque vous avez terminé.

(Recommandé) Modifiez le fichier Hôte virtuel non chiffré pour rediriger vers HTTPS

Tel qu’il est actuellement, le serveur fournira à la fois du trafic HTTP non chiffré et du trafic HTTPS chiffré. Pour une meilleure sécurité, il est recommandé dans la plupart des cas de rediriger automatiquement HTTP vers HTTPS. Si vous ne voulez 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 crypté pour rediriger tout le trafic à crypter SSL, nous pouvons ouvrir 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, il suffit d’ajouter une directive Redirect, pointant tout le trafic vers la version SSL du site :

<VirtualHost *:80> . . . Redirect "/" "https://your_domain_or_IP/" . . .</VirtualHost>

Enregistrez et fermez le fichier lorsque vous avez terminé.

Étape 3 : Ajustez le pare-feu

Si le pare-feu ufw est activé, comme recommandé par les guides de prérequis, il peut être nécessaire d’ajuster les paramètres pour permettre le trafic SSL. Heureusement, Apache enregistre quelques profils avec ufw lors de l’installation.

Nous pouvons voir les profils disponibles en tapant:

sudo ufw app list

Vous devriez voir une liste comme celle-ci:

Output
Available applications: Apache Apache Full Apache Secure OpenSSH

Vous pouvez voir le paramètre actuel en tapant:

sudo ufw status

Si vous n’avez autorisé que le trafic HTTP régulier plus tôt, votre sortie pourrait ressembler à ceci:

Output
Status: activeTo Action From-- ------ ----OpenSSH ALLOW AnywhereApache ALLOW AnywhereOpenSSH (v6) ALLOW Anywhere (v6)Apache (v6) ALLOW Anywhere (v6)

Pour autoriser en outre le trafic HTTPS, nous pouvons autoriser le profil « Apache Full », puis supprimer l’allocation de profil « Apache » redondante:

 
sudo ufw allow 'Apache Full'
 
sudo ufw delete allow 'Apache'
 

Votre statut devrait ressembler à ceci maintenant:

sudo ufw status

Output
Status: activeTo Action From-- ------ ----OpenSSH ALLOW AnywhereApache Full ALLOW AnywhereOpenSSH (v6) ALLOW Anywhere (v6)Apache Full (v6) ALLOW Anywhere (v6)

Étape 4: Activer les modifications dans Apache

Maintenant que nous avons apporté nos modifications et ajusté notre pare-feu, nous pouvons activer les modules SSL et headers dans Apache, activer notre hôte virtuel compatible SSL et redémarrer Apache.

Nous pouvons activer mod_ssl, le module SSL Apache, et mod_headers, nécessaires à certains paramètres de notre extrait de code SSL, avec la commande a2enmod:

 
sudo a2enmod ssl
 
sudo a2enmod headers
 

Ensuite, nous pouvons activer notre hôte virtuel SSL avec la commande a2ensite:

sudo a2ensite default-ssl

Nous devrons également activer notre fichier ssl-params.conf, pour lire les valeurs que nous avons définies:

sudo a2enconf ssl-params

À ce stade, notre site et les modules nécessaires sont activés. Nous devons vérifier qu’il n’y a pas d’erreurs de syntaxe dans nos fichiers. Nous pouvons le faire en tapant:

sudo apache2ctl configtest

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

Output
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1. Set the 'ServerName' directive globally to suppress this messageSyntax OK

La première ligne est juste un message vous indiquant que la directive ServerName n’est pas définie globalement. Si vous souhaitez vous débarrasser de ce message, vous pouvez définir ServerName sur le nom de domaine ou l’adresse IP de votre serveur dans /etc/apache2/apache2.conf. Ceci est facultatif car le message ne fera aucun mal.

Si votre sortie contient Syntax OK, votre fichier de configuration ne contient aucune erreur de syntaxe. Nous pouvons redémarrer Apache en toute sécurité pour implémenter nos modifications:

sudo systemctl restart apache2

Étape 5: Testez le cryptage

Maintenant, nous sommes prêts à tester notre serveur SSL.

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

https://server_domain_or_IP

Étant donné que 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 effrayant comme celui ci-dessous:

Ceci est attendu et normal. Nous ne sommes intéressés que par l’aspect cryptage de notre certificat, pas par la validation par un tiers de l’authenticité de notre hôte. Cliquez sur « AVANCÉ » puis sur le lien fourni pour accéder à votre hôte de toute façon:

Vous devez être redirigé vers 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é Apache pour rediriger HTTP vers HTTPS, vous pouvez également vérifier si la redirection fonctionne correctement:

http://server_domain_or_IP

Si cela se traduit par la même icône, cela signifie que votre redirection a fonctionné correctement.

Étape 6: Passez à une Redirection permanente

Si votre redirection a fonctionné 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 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 à une redirection permanente 301 :

<VirtualHost *:80> . . . Redirect permanent "/" "https://your_domain_or_IP/" . . .</VirtualHost>

Enregistrez et fermez le fichier.

Vérifiez les erreurs de syntaxe de votre configuration:

sudo apache2ctl configtest

Lorsque vous êtes prêt, redémarrez Apache pour rendre la redirection permanente:

sudo systemctl restart apache2

Conclusion

Vous avez configuré votre serveur Apache pour qu’il utilise un cryptage fort pour les connexions client. Cela vous permettra de répondre aux demandes en toute sécurité et empêchera les tiers de lire votre trafic.