Tutoriel : Configurer SSL/TLS sur AL2023

Connectez-vous à votre instance et confirmez qu’Apache est en cours d’exécution. Pour plus d’informations, consultez Connexion à AL2 023 instances.

[ec2-user ~]$ sudo systemctl is-enabled httpd

Si la valeur renvoyée n’est pas « activé », démarrez Apache et configurez-le pour qu’il démarre à chaque amorçage du système.

[ec2-user ~]$ sudo systemctl start httpd && sudo systemctl enable httpd

Pour vous assurer que tous vos packages logiciels sont mis à jour, effectuez une mise à jour logicielle rapide sur votre instance. Ce processus peut prendre quelques minutes, mais il est important pour vous assurer que vous disposez des dernières mises à jour de sécurité et des nouveaux correctifs de bogues.

[ec2-user ~]$ sudo dnf install openssl mod_ssl

Une fois que vous avez saisi la commande suivante, vous êtes redirigé vers une invite où vous pouvez saisir des informations sur votre site.

[ec2-user ~]$ sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/pki/tls/private/apache-selfsigned.key -out /etc/pki/tls/certs/apache-selfsigned.crt

Cela génère un nouveau fichier apache-selfsigned.crt dans le répertoire /etc/pki/tls/certs/. Le nom de fichier spécifié correspond au nom par défaut attribué dans la directive SSLCertificateFile dans /etc/httpd/conf.d/ssl.conf.

Votre instance dispose désormais des fichiers suivants que vous utilisez pour configurer votre serveur sécurisé et créer un certificat pour les tests :

Ce fichier contient un certificat auto-signé et la clé privée du certificat. Apache exige que le certificat et la clé soient au format PEM qui est constitué de caractères ASCII codés en Base64, encadrés par des lignes « BEGIN » et « END », comme dans l’exemple abrégé ci-après.

-----BEGIN PRIVATE KEY-----
MIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQD2KKx/8Zk94m1q
3gQMZF9ZN66Ls19+3tHAgQ5Fpo9KJDhzLjOOCI8u1PTcGmAah5kEitCEc0wzmNeo
BCl0wYR6G0rGaKtK9Dn7CuIjvubtUysVyQoMVPQ97ldeakHWeRMiEJFXg6kZZ0vr
GvwnKoMh3DlK44D9dX7IDua2PlYx5+eroA+1Lqf32ZSaAO0bBIMIYTHigwbHMZoT
...
56tE7THvH7vOEf4/iUOsIrEzaMaJ0mqkmY1A70qQGQKBgBF3H1qNRNHuyMcPODFs
27hDzPDinrquSEvoZIggkDMlh2irTiipJ/GhkvTpoQlv0fK/VXw8vSgeaBuhwJvS
LXU9HvYq0U6O4FgD3nAyB9hI0BE13r1HjUvbjT7moH+RhnNz6eqqdscCS09VtRAo
4QQvAqOa8UheYeoXLdWcHaLP
-----END PRIVATE KEY-----                    

-----BEGIN CERTIFICATE-----
MIIEazCCA1OgAwIBAgICWxQwDQYJKoZIhvcNAQELBQAwgbExCzAJBgNVBAYTAi0t
MRIwEAYDVQQIDAlTb21lU3RhdGUxETAPBgNVBAcMCFNvbWVDaXR5MRkwFwYDVQQK
DBBTb21lT3JnYW5pemF0aW9uMR8wHQYDVQQLDBZTb21lT3JnYW5pemF0aW9uYWxV
bml0MRkwFwYDVQQDDBBpcC0xNzItMzEtMjAtMjM2MSQwIgYJKoZIhvcNAQkBFhVy
...
z5rRUE/XzxRLBZOoWZpNWTXJkQ3uFYH6s/sBwtHpKKZMzOvDedREjNKAvk4ws6F0
CuIjvubtUysVyQoMVPQ97ldeakHWeRMiEJFXg6kZZ0vrGvwnKoMh3DlK44D9dlU3
WanXWehT6FiSZvB4sTEXXJN2jdw8g+sHGnZ8zCOsclknYhHrCVD2vnBlZJKSZvak
3ZazhBxtQSukFMOnWPP2a0DMMFGYUHOd0BQE8sBJxg==
-----END CERTIFICATE-----

Les noms et extensions de fichiers sont fournis à titre indicatif et n’ont aucun effet sur la fonction. Par exemple, vous pouvez appeler un certificat cert.crt, cert.pem, ou tout autre nom de fichier dans la mesure où la directive associée dans le fichier ssl.conf utilise le même nom.

Redémarrez Apache.

[ec2-user ~]$ sudo systemctl restart httpd

Votre serveur web Apache devrait maintenant prendre en charge HTTPS (HTTP sécurisé) sur le port 443. Testez-le en saisissant l’adresse IP ou le nom de domaine complet de votre instance EC2 dans une barre URL du navigateur avec le préfixe https://.

Étant donné que vous vous connectez à un site avec un certificat d’hôte auto-signé non approuvé, il se peut que votre navigateur affiche une série d’avertissements de sécurité. Ignorez-les et poursuivez sur le site.

Si la page de test Apache par défaut s’ouvre, cela signifie que vous avez configuré correctement TLS sur votre serveur. Toutes les données transmises entre le navigateur et le serveur sont maintenant chiffrées.

Connectez-vous à votre instance et accédez à /etc/pki/tls/private/. Il s’agit du répertoire où vous stockez la clé privée du serveur pour TLS. Si vous préférez utiliser une clé d’hôte existante pour générez la CSR, passez à l’étape 3. Pour plus d'informations sur la connexion à votre instance, voir Connexion à AL2 023 instances

(Facultatif) Générez une nouvelle clé privée. Voici quelques exemples de configurations de clés. Toutes les clés obtenues fonctionnent avec votre serveur web, mais elles diffèrent dans le degré et le type de sécurité qu’elles mettent en œuvre.

Assurez-vous que la nouvelle clé privée possède un critère de propriété et d’autorisations très restrictif (propriétaire=racine, groupe=racine, lecture/écriture pour propriétaire uniquement). Les commandes seraient similaires à celles illustrées dans l’exemple suivant.

[ec2-user ~]$ sudo chown root:root custom.key
[ec2-user ~]$ sudo chmod 600 custom.key
[ec2-user ~]$ ls -al custom.key

Les commandes ci-avant produisent le résultat suivant.

-rw------- root root custom.key

Une fois que vous avez créé et configuré une clé satisfaisante, vous pouvez créer une CSR.

Créez une CSR à l’aide de votre clé préférée. L’exemple suivant utilise custom.key.

[ec2-user ~]$ sudo openssl req -new -key custom.key -out csr.pem

OpenSSL ouvre une boîte de dialogue et vous invite à compléter les informations affichées dans le tableau ci-dessous. Tous les champs à l’exception de Common Name sont facultatifs pour un certificat d’hôte basique avec validation de domaine.

Au final, OpenSSL vous invite à donner un mot de passe de stimulation facultatif. Ce mot de passe s’applique uniquement à la CSR et aux transactions entre vous et votre autorité de certification, donc suivez les recommandations de l’autorité de certification sur cela, l’autre champ facultatif et le nom de l’entreprise facultatif. Le mot de passe de stimulation de la CSR n’a aucun effet sur le fonctionnement du serveur.

Le fichier obtenu csr.pem contient votre clé publique, la signature numérique de votre clé publique et les métadonnées que vous avez saisies.

Envoyez la CSR à une autorité de certification. Elle consiste généralement en l’ouverture de votre fichier CSR dans un éditeur de texte et la reproduction du contenu dans un formulaire web. A ce moment-là, il se peut que l’on vous demande de fournir un SAN (subject alternate name) ou plus à placer sur le certificat. Si www.example.com est le nom commun, example.com serait un bon SAN, et vice versa. Un visiteur de votre site qui saisit l’un de ces noms devrait bénéficier d’une connexion sans erreur. Si le formulaire web de votre autorité de certification le permet, incluez le nom commun dans la liste des SAN. Certaines autorités de certification l’incluent automatiquement.

Une fois que votre demande a été approuvée, vous recevrez un nouveau certificat d’hôte signé par l’autorité de certification. Il se peut que l’on vous demande également de télécharger un fichier de certificat intermédiaire qui contient des certificats supplémentaires nécessaires pour compléter la chaîne de confiance de l’autorité de certification.

- - - - -BEGIN CERTIFICATE - - - - - 

- - - -END CERTIFICATE - - - - -

[ec2-user certs]$ openssl x509 -in certificate.crt -text

Placez le nouveau certificat signé par une CA et les certificats intermédiaires dans le répertoire /etc/pki/tls/certs.

Depuis le /etc/pki/tls/certs répertoire, vérifiez que les paramètres de propriété, de groupe et d'autorisation du fichier correspondent aux valeurs par défaut très restrictives de la norme AL2023 (owner=root, group=root, read/write pour le propriétaire uniquement). L’exemple suivant illustre les commandes à utiliser.

[ec2-user certs]$ sudo chown root:root custom.crt
[ec2-user certs]$ sudo chmod 600 custom.crt
[ec2-user certs]$ ls -al custom.crt

Ces commandes devraient générer le résultat suivant.

-rw------- root root custom.crt

Les autorisations pour le fichier de certificat intermédiaire sont moins contraignantes (propriétaire=racine, groupe=racine, le propriétaire peut écrire, le groupe peut lire, tout le monde peut lire). L’exemple suivant illustre les commandes à utiliser.

[ec2-user certs]$ sudo chown root:root intermediate.crt
[ec2-user certs]$ sudo chmod 644 intermediate.crt
[ec2-user certs]$ ls -al intermediate.crt

Ces commandes devraient générer le résultat suivant.

-rw-r--r-- root root intermediate.crt

Placez la clé privée que vous avez utilisée pour créer la CSR dans le répertoire /etc/pki/tls/private/.

Depuis le /etc/pki/tls/private répertoire, utilisez les commandes suivantes pour vérifier que les paramètres de propriété, de groupe et d'autorisation du fichier correspondent aux valeurs par défaut très restrictives de la norme AL2023 (owner=root, group=root, read/write pour le propriétaire uniquement).

[ec2-user private]$ sudo chown root:root custom.key
[ec2-user private]$ sudo chmod 600 custom.key
[ec2-user private]$ ls -al custom.key

Ces commandes devraient générer le résultat suivant.

-rw------- root root custom.key

Modifiez /etc/httpd/conf.d/ssl.conf pour refléter les nouveaux fichiers de certificat et de clé.

1. Fournissez le chemin et le nom de fichier du certificat d’hôte signé par une CA dans la directive SSLCertificateFile d’Apache :

   SSLCertificateFile /etc/pki/tls/certs/custom.crt

2. Si vous avez reçu un fichier de certificat intermédiaire (intermediate.crt dans cet exemple), indiquez son nom correct de chemin et de fichier à l’aide de la directive SSLCACertificateFile d’Apache :

   SSLCACertificateFile /etc/pki/tls/certs/intermediate.crt

   Note

   Certaines autorités de certification combinent le certificat d’hôte et les certificats intermédiaires dans un seul fichier ; la directive SSLCACertificateFile devient alors inutile. Consultez les instructions fournies par votre autorité de certification.

3. Fournissez le chemin et le nom de fichier de la clé privée (custom.key dans cet exemple) dans la directive SSLCertificateKeyFile d’Apache :

   SSLCertificateKeyFile /etc/pki/tls/private/custom.key

Enregistrez /etc/httpd/conf.d/ssl.conf et redémarrez Apache.

[ec2-user ~]$ sudo systemctl restart httpd

Testez votre serveur en saisissant votre nom de domaine dans la barre d’URL de navigateur avec le préfixe https://. Votre navigateur doit charger la page de test via HTTPS sans générer d’erreurs.

Ouvrez le fichier de configuration /etc/httpd/conf.d/ssl.conf dans un éditeur de texte et mettez en commentaire la ligne suivante en saisissant « # » au début de la ligne.

#SSLProtocol all -SSLv3

Ajoutez la directive suivante :

#SSLProtocol all -SSLv3
SSLProtocol -SSLv2 -SSLv3 -TLSv1 -TLSv1.1 +TLSv1.2

Cette directive désactive explicitement les versions SSL 2 et 3, ainsi que les versions TLS 1.0 et 1.1. Le serveur refuse désormais d’accepter les connexions chiffrées avec des clients utilisant tout sauf TLS 1.2. La formulation des commentaires dans la directive indique plus clairement, à un lecteur humain, ce pour quoi le serveur est configuré.

Dans le fichier de configuration /etc/httpd/conf.d/ssl.conf, recherchez la section avec la directive SSLCipherSuite et mettez en commentaire la ligne existante en saisissant « # » au début de la ligne.

#SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5

Spécifiez explicitement des suites de chiffrement et un ordre de chiffrement qui donnent la priorité à la confidentialité persistante et évitent les chiffrements peu sûrs. La directive SSLCipherSuite utilisée ici est basée sur la sortie du Mozilla SSL Configuration Generator, qui adapte une configuration TLS au logiciel spécifique s’exécutant sur votre serveur. (Pour plus d’informations, consultez la ressource utile de Mozilla Security/Server Side TLS.) Déterminez d’abord vos versions d’Apache et OpenSSL en utilisant la sortie des commandes suivantes.

[ec2-user ~]$ yum list installed | grep httpd

[ec2-user ~]$ yum list installed | grep openssl

Par exemple, si l’information renvoyée est Apache 2.4.34 et OpenSSL 1.0.2, nous saisissons cela dans le générateur. Si vous choisissez le modèle de compatibilité « moderne », il crée une directive SSLCipherSuite qui applique la sécurité de façon stricte, tout en étant compatible avec la plupart des navigateurs. Si votre logiciel ne prend pas en charge la configuration moderne, vous pouvez mettre à jour le logiciel ou choisir la configuration « intermédiaire ».

SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:
ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:
ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256

Les chiffrements sélectionnés contiennent ECDHE (une abréviation pour Elliptic Curve Diffie-Hellman Ephemeral) dans leur nom. Le terme ephemeral indique la confidentialité persistante. Comme corollaire, ces chiffrements ne prennent pas en charge RC4.

Nous vous recommandons d’utiliser une liste explicite de chiffrements au lieu de compter sur les valeurs par défaut ou les directives succinctes dont le contenu n’est pas visible.

Copiez la directive générée dans /etc/httpd/conf.d/ssl.conf.

En dernier lieu, supprimez la mise en commentaire de la ligne suivante en retirant le « # » au début de la ligne.

#SSLHonorCipherOrder on

Cette directive force le serveur à préférer les chiffrements de niveau élevé notamment (dans ce cas) ceux qui prennent en charge la confidentialité persistante. Avec cette directive activée, le serveur essaie d’établir une connexion très sécurisée avant d’avoir recours aux chiffrements autorisés dotés d’une sécurité moindre.