Tutoriel : Configuration SSL/TLS sur l'AMI Amazon Linux

Connectez-vous à votre instance et confirmez qu’Apache est en cours d’exécution.

[ec2-user ~]$ sudo service httpd status

Si nécessaire, démarrez Apache.

[ec2-user ~]$ sudo service httpd start

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 yum update -y

Maintenant que votre instance est à jour, ajoutez la prise en charge de TLS en installant le module Apache mod_ssl:

[ec2-user ~]$ sudo yum install -y mod_ssl

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 :

Les fichiers .key et .crt sont au format PEM qui est constitué de caractères ASCII codés en Base64, encadrés par des lignes « BEGIN » et « END », comme dans cet exemple abrégé d’un certificat :

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

Les noms et extensions de fichier sont fournis à des fins de commodité et n’ont aucun effet sur la fonction ; 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 service httpd restart

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 EC2 instance dans la barre d'URL du navigateur avec le préfixehttps://. É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 en toute sécurité.

Pour éviter aux visiteurs du site d’avoir des avertissements, vous devez obtenir un certificat qui chiffre mais vous authentifie aussi publiquement comme le propriétaire du site.

Connectez-vous à votre instance et accédez à/etc/pki/tls/private/. Il s’agit du répertoire où la clé privée du serveur de SSL/TLS est stockée. Si vous préférez utiliser votre clé d’hôte existante pour générez la CSR, passez à l’étape 3.

(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 leur façon de mettre en œuvre la sécurité (et en ce qui concerne le niveau de sécurité assuré).

Assurez-vous que la propriété et les autorisations de la nouvelle clé privée sont très restrictives (owner=root, group=root, read/write pour le propriétaire uniquement). Les commandes seraient les suivantes :

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

Les commandes ci-dessus devraient générer 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 ci-dessous 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. À ce stade, il peut vous être demandé de fournir un ou plusieurs noms alternatifs de sujet (SANs) à 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 tape l’un de ces noms devrait bénéficier d’une connexion sans erreur. Si votre formulaire Web CA le permet, incluez le nom commun dans la liste des SANs. Certains l' CAs 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, 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 d'Amazon Linux (owner=root, group=root, pour le propriétaire uniquement). read/write

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

Les commandes ci-dessus 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). Les commandes seraient :

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

Les commandes ci-dessus devraient générer le résultat suivant :

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

Si vous avez utilisé une clé personnalisée pour créer votre CSR et le certificat d’hôte correspondant, supprimez ou renommez l’ancienne clé du répertoire /etc/pki/tls/private/, puis ajoutez-lui la nouvelle clé.

Depuis le /etc/pki/tls/private 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 d'Amazon Linux (owner=root, group=root, pour le propriétaire uniquement). read/write Les commandes seraient les suivantes :

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

Les commandes ci-dessus 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

   Certains CAs combinent le certificat hôte et les certificats intermédiaires dans un seul fichier, ce qui rend cette directive inutile. Consultez les instructions fournies par votre autorité de certification.

3. Fournissez le chemin et le nom de fichier de la clé privée 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 service httpd restart

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 les lignes qui suivent en saisissant « # » au début de chacune d’entre elles :

#SSLProtocol all -SSLv3
#SSLProxyProtocol all -SSLv3

Ajoutez les directives suivantes :

SSLProtocol -SSLv2 -SSLv3 -TLSv1 -TLSv1.1 +TLSv1.2
SSLProxyProtocol -SSLv2 -SSLv3 -TLSv1 -TLSv1.1 +TLSv1.2

Ces directives désactivent 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 communique plus clairement, à un lecteur humain, ce pour quoi le serveur est configuré.

Ouvrez le fichier de configuration /etc/httpd/conf.d/ssl.conf et trouvez la section avec les exemples mis en commentaire pour la configuration de SSLCipherSuite et SSLProxyCipherSuite.

#SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5
#SSLProxyCipherSuite HIGH:MEDIUM:!aNULL:!MD5

Laissez-les tels quels et ajoutez en dessous les directives suivants :

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:AES:!aNULL:!eNULL:!EXPORT:!DES:
!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA

SSLProxyCipherSuite 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:AES:!aNULL:!eNULL:!EXPORT:!DES:
!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA

Ces chiffrements constituent un sous-ensemble de la liste beaucoup plus longue des chiffrements pris en charge dans OpenSSL. Ils sont été sélectionnés et classés selon les critères suivants :

Notez que les noms des chiffrements de niveau élevé contiennent les lettres ECDHE, pour Elliptic Curve Diffie-Hellman Ephemeral. Expression dans laquelle Ephemeral (éphémère) indique la confidentialité persistante. En outre, RC4 il fait maintenant partie des chiffrements interdits vers la fin.

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. La liste des chiffrements affichée compte parmi les nombreuses listes possibles. Par exemple, il se peut que vous vouliez optimiser une liste pour la rapidité plutôt que la confidentialité persistante.

Si vous pensez avoir besoin de prendre en charge des clients plus âgés, vous pouvez autoriser la suite de chiffrement DES- CBC3 -SHA.

Enfin, chaque mise à jour de OpenSSL présente de nouveaux chiffrements qui rend les anciens obsolète. Maintenez votre instance EC2 Amazon Linux à jour, surveillez les annonces de sécurité d'OpenSSL et soyez attentif aux informations faisant état de nouveaux exploits de sécurité dans la presse technique.

Supprimez la mise en commentaire de la ligne suivante en retirant le « # » :

#SSLHonorCipherOrder on

Cette commande 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.

Redémarrez Apache. Si vous testez à nouveau le domaine sur Qualys SSL Labs, vous devriez constater que la RC4 vulnérabilité a disparu.