Amazon Elastic Compute Cloud
Guide de l'utilisateur pour les instances Linux

Didacticiel : Configurer SSL/TLS sur Amazon Linux 2

SSL/TLS (Secure Sockets Layer/Transport Layer Security) crée un canal chiffré entre un serveur web et un client web qui empêche les données en transit d'être écoutées. Ce didacticiel explique comment ajouter manuellement la prise en charge de SSL/TLS sur une instance EC2 avec Amazon Linux 2 et le serveur Web Apache. Si vous prévoyez de proposer des services de niveau commercial, AWS Certificate Manager, non présenté ici, est une bonne option.

Pour des raisons historiques, le chiffrement web est communément appelé SSL. Alors que les navigateurs web prennent toujours en charge SSL, son protocole successeur TLS est moins vulnérable en cas d'attaque. Amazon Linux 2 désactive la prise en charge côté serveur pour toutes les versions SSL par défaut. Les organismes de normes de sécurité considèrent TLS 1.0 comme peu sûr, et TLS 1.0 et TLS 1.1 sont sur le point d’être déclarés formellement obsolètes par l’IETF. Ce didacticiel contient des conseils pour l’activation de TLS 1.2 exclusivement. (Un protocole TLS 1.3 plus récent existe sous forme d’ébauche, mais il n’est pas encore pris en charge sur Amazon Linux 2.) Pour plus d'informations sur les normes de chiffrement mises à jour, consultez RFC 7568 et RFC 8446.

Ce didacticiel fait référence au chiffrement Web moderne simplement comme TLS.

Important

Ces procédures sont destinées à une utilisation avec Amazon Linux 2. Nous supposons également que vous commencez avec une nouvelle instance Amazon EC2. Si vous essayez de configurer un serveur web LAMP sur une instance avec une autre distribution ou si vous réaffectez une instance existante plus ancienne, certaines procédures de ce didacticiel peuvent ne pas fonctionner pour vous. Pour plus d'informations sur les serveurs web LAMP sur Ubuntu, consultez la rubrique ApacheMySQLPHP de la documentation proposée par la communauté Ubuntu. Pour plus d'informations sur Red Hat Enterprise Linux, consultez la rubrique Web Servers du portail client.

Prérequis

Avant de commencer ce didacticiel, suivez les étapes suivantes :

  • Lancez une instance Amazon Linux 2 basée sur les volumes EBS. Pour plus d'informations, consultez Étape 1 : Lancement d'une instance.

  • Configurez vos groupes de sécurité afin que votre instance puisse accepter des connexions sur les ports TCP suivants :

    • SSH (port 22)

    • HTTP (port 80)

    • HTTPS (port 443)

    Pour plus d'informations, consultez Autorisation du trafic entrant pour vos instances Linux.

  • Installez le serveur Web Apache. Pour des instructions pas à pas, consultez le Didacticiel : Installation d'un serveur web LAMP sur Amazon Linux 2. Seuls le package httpd et ses dépendances sont nécessaires. Par conséquent, vous pouvez ignorer les instructions impliquant PHP et MariaDB.

  • Pour identifier et authentifier les sites web, l'infrastructure à clés publiques (PKI) TLS repose sur le système de noms de domaine (DNS). Pour utiliser votre instance EC2 pour héberger un site web public, vous devez enregistrer un nom de domaine pour votre serveur web ou transférer un nom de domaine existant vers votre hôte Amazon EC2. Plusieurs services d'enregistrement de domaines tiers et d'hébergement DNS sont disponibles pour cela, ou vous pouvez utiliser Amazon Route 53.

Étape 1 : Activation de TLS sur le serveur

Cette procédure vous décrit le processus de paramétrage de TLS sur Amazon Linux 2 avec un certificat auto-signé numérique.

Note

Un certificat auto-signé est acceptable dans un environnement de test, mais pas pour les environnements de production. Si vous exposez votre certificat auto-signé sur Internet, les visiteurs de votre site verront s'afficher des messages d'avertissement de sécurité.

Pour activer TLS sur un serveur

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

    [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
  2. 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.

    Note

    L'option -y installe les mises à jour sans demander de confirmation. Si vous souhaitez examiner les mises à jour avant l'installation, vous pouvez omettre cette option.

    [ec2-user ~]$ sudo yum update -y
  3. 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 :

    • /etc/httpd/conf.d/ssl.conf

      Le fichier de configuration de mod_ssl. Il contient des directives indiquant à Apache où trouver les clés et les certificats de chiffrement, les versions de protocoles TLS à autoriser et les algorithmes de chiffrement à accepter.

    • /etc/pki/tls/certs/make-dummy-cert

      Script pour générer un certificat X.509 auto-signé et une clé privée pour votre hôte serveur. Ce certificat est utile pour vérifier qu'Apache est correctement paramétré pour utiliser TLS. Comme il n’offre aucune preuve d’identité, il ne doit pas être utilisé en production. S’il est utilisé en production, il déclenche des avertissements dans les navigateurs web.

  4. Exécutez le script pour générer un certificat factice auto-signé et une clé pour les tests.

    [ec2-user ~]$ cd /etc/pki/tls/certs sudo ./make-dummy-cert localhost.crt

    Cela génère un nouveau fichier localhost.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.

    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.

    Note

    Lorsque vous remplacez les fichiers TLS par défaut par vos propres fichiers personnalisés, veillez à ce qu'ils soient au format PEM.

  5. Ouvrez le fichier /etc/httpd/conf.d/ssl.conf et supprimez le commentaire sur la ligne suivante, car le certificat fictif signé automatiquement contient aussi la clé. Si vous ne le faites pas avant d'exécuter l'étape suivante, le service Apache ne peut pas démarrer.

    SSLCertificateKeyFile /etc/pki/tls/private/localhost.key
  6. Redémarrez Apache.

    [ec2-user ~]$ sudo systemctl restart httpd

    Note

    Assurez-vous que le port TCP 443 est accessible sur votre instance EC2, tel que décrit précédemment.

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

    Note

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

Étape 2 : Obtention d'un certificat signé par une CA

Vous pouvez utiliser le processus suivant pour obtenir un certificat signé par une CA :

  • Générez une demande de signature de certificat (CSR) à partir d’une clé privée

  • Envoyez la demande de signature de certificat (CSR) à une autorité de certification (CA)

  • Obtenez un certificat d’hôte signé

  • Configurez Apache pour utiliser le certificat

Le chiffrement d'un certificat X.509 TLS auto-signé est identique à celui d'un certificat signé par une autorité de certification. La différence est sociale, pas mathématique. Une autorité de certification promet, au minimum, de valider la propriété d'un domaine avant de générer un certificat pour un demandeur. Chaque navigateur web contient une liste d'autorités de certification approuvées par le fournisseur de navigateur pour faire cela. Un certificat X.509 se compose surtout d'une clé publique qui correspond à votre clé de serveur privée et d'une signature de l'autorité de certification qui est cryptographiquement reliée à la clé publique. Lorsqu'un navigateur se connecte à un serveur web sur HTTPS, le serveur présente un certificat que le navigateur doit vérifier par rapport à sa liste d'autorités de certification approuvées. Si le signataire est sur la liste ou s'il est accessible via une chaîne de confiance composée d'autres utilisateurs de confiance, le navigateur négocie un canal de données chiffrées rapide avec le serveur et charge la page.

Les certificats coûtent généralement de l'argent à cause travail impliqué dans la validation des requêtes, donc il est intéressant de comparer les prix. Une liste d'autorités de certification connues est proposée sur dmoztools.net. Quelques autorités de certification offrent des certificats basiques gratuits. La plus importante autorité de certification est le projet Let's Encrypt, qui prend également en charge l'automatisation du processus de création et de renouvellement des certificats. Pour de plus amples informations sur l'utilisation de Let's Encrypt comme autorité de certification, consultez Automatisation de certificat : Utilisation de Let's Encrypt avec Certbot sur Amazon Linux 2.

La clé est l'élément sous-jacent du certificat d'hôte. Depuis 2019, des groupes gouvernementaux et industriels recommandent l'utilisation d'une taille de clé minimale (module) de 2048 bits pour les clés RSA conçues pour protéger des documents, jusqu'en 2030. La taille de module par défaut générée par OpenSSL dans Amazon Linux 2 est de 2048 bits qui convient à l'utilisation d'un certificat signé par une CA. Dans la procédure suivante, étape facultative pour ceux qui souhaitent une clé personnalisée, par exemple, une clé avec un module plus important ou utilisant un algorithme de chiffrement différent.

Ces instructions pour l’acquisition de certificats d'hôte signés par l'autorité de certification (CA) ne fonctionnent pas à moins que vous possédiez un domaine DNS enregistré et hébergé.

Pour obtenir un certificat signé par une CA

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

  2. (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.

    • Exemple 1 : création d’une clé d’hôte RSA par défaut. Le fichier obtenu, custom.key, est une clé privée RSA 2048 bits.

      [ec2-user ~]$ sudo openssl genrsa -out custom.key
    • Exemple 2 : création d’une clé RSA plus forte avec un modulus plus grand. Le fichier obtenu, custom.key, est une clé privée RSA 4096 bits.

      [ec2-user ~]$ sudo openssl genrsa -out custom.key 4096
    • Exemple 3 : création d’une clé RSA chiffrée 4096 bits avec protection par mot de passe. Le fichier obtenu, custom.key, est une clé privée RSA 4096 bits chiffrée avec le chiffrement AES-128.

      Important

      Le chiffrement de la clé offre une plus grande sécurité, mais comme une clé chiffrée nécessite un mot de passe, les services qui en dépendent ne peuvent pas démarrer automatiquement. A chaque fois que vous utilisez cette clé, vous devez fournir le mot de passe (« abcde12345 » dans l’exemple précédent) sur une connexion SSH.

      [ec2-user ~]$ sudo openssl genrsa -aes128 -passout pass:abcde12345 -out custom.key 4096
    • Exemple 4 : création d’une clé avec un chiffrement non RSA. La cryptographie RSA peut être relativement lente en raison de la taille de ses clés publiques, lesquelles sont basées sur le produit de deux grands nombres premiers. Cependant, il est possible de créer des clés pour TLS qui utilisent des chiffrements non RSA. Les clés basées sur les mathématiques des courbes elliptiques sont plus petites et plus rapides en termes de calcul, tout en offrant un niveau de sécurité équivalent.

      [ec2-user ~]$ sudo openssl ecparam -name prime256v1 -out custom.key -genkey

      Le résultat est une clé privée 256 bits à courbes elliptiques utilisant prime256v1, une « courbe nommée » que OpenSSL prend en charge. Sa qualité cryptographique est légèrement plus importante qu'une clé RSA 2048 bits, selon NIST.

      Note

      Les autorités de certification ne fournissent pas toutes le même niveau de support pour les clés basées sur les courbes elliptiques que pour les clés RSA.

    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.

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

    Nom Description Exemple
    Nom du pays Abréviation ISO de deux lettres de votre pays. US (=Etats-Unis)
    Nom de l'état ou de la province Nom de l'état ou de la province où votre organisation se situe. Ce nom ne peut pas être abrégé. Washington
    Nom de la localité L'emplacement de votre organisation, comme une ville. Seattle
    Nom de l'organisation Nom légal complet de votre organisation. N'abrégez pas le nom de votre organisation. Exemple d'entreprise
    Nom de l'unité d'organisation Informations supplémentaires sur l'organisation, s'il y en a. Exemple de service
    Nom commun

    Cette valeur doit correspondre exactement à l'adresse web que les utilisateurs saisiront dans un navigateur, selon vous. Il s'agit généralement d'un nom de domaine avec un nom d'hôte ou un alias préfixé sous la forme www.example.com. Dans les essais avec un certificat auto-signé et aucune résolution DNS, le nom commun peut se composer uniquement du nom d'hôte. Les autorités de certification proposent aussi des certificats onéreux qui acceptent les noms inconnus comme *.example.com.

    www.exemple.com
    Adresse e-mail L'adresse e-mail de l'administrateur du serveur. quelquun@exemple.com

    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.

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

    Note

    Votre autorité de certification peut vous envoyer des fichiers sous différents formats en fonction des finalités recherchées. Dans ce didacticiel, vous devez utiliser uniquement un fichier de certificat au format PEM, qui comporte habituellement (mais pas toujours) une extension de fichier .pem ou .crt. Si vous ne savez pas quel fichier utiliser, ouvrez les fichiers dans un éditeur de texte et recherchez celui qui contient un ou plusieurs blocs commençant par la ligne suivante.

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

    Le fichier doit également se terminer par la ligne suivante.

    - - - -END CERTIFICATE - - - - -

    Vous pouvez également tester le fichier dans la ligne de commande, comme suit.

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

    Vérifiez que ces lignes apparaissent dans le fichier. N'utilisez pas de fichiers se terminant par .p7b, .p7c ou autres extensions similaires.

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

    Note

    Il existe plusieurs méthodes pour charger votre nouveau certificat dans votre instance EC2, mais le moyen le plus simple et informatif consiste à ouvrir un éditeur de texte (vi, nano, Bloc-notes, etc.) sur votre ordinateur local et votre instance, puis à copier et coller le contenu du fichier. Pour effectuer ces opérations sur l'instance EC2, vous devez disposer de privilèges racine [sudo]. Vous voyez ainsi immédiatement s'il existe des problèmes d'autorisation ou de chemin d'accès. Veillez toutefois à ne pas d'ajouter des lignes supplémentaires lors de la copie du contenu, ou à les modifier de quelque façon.

    À partir du répertoire /etc/pki/tls/certs, vérifiez que les paramètres de propriété du fichier, de groupe et d'autorisation correspondent aux valeurs par défaut Amazon Linux 2 très restrictives (propriétaire=racine, groupe=racine, lecture/écriture pour 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
  6. Placez la clé privée que vous avez utilisée pour créer la CSR dans le répertoire /etc/pki/tls/private/.

    Note

    Il existe plusieurs méthodes pour charger votre clé personnalisée dans votre instance EC2, mais le moyen le plus simple et informatif consiste à ouvrir un éditeur de texte (vi, nano, Bloc-notes, etc.) sur votre ordinateur local et votre instance, puis à copier et coller le contenu du fichier. Pour effectuer ces opérations sur l'instance EC2, vous devez disposer de privilèges racine [sudo]. Vous voyez ainsi immédiatement s'il existe des problèmes d'autorisation ou de chemin d'accès. Veillez toutefois à ne pas d'ajouter des lignes supplémentaires lors de la copie du contenu, ou à les modifier de quelque façon.

    À partir du répertoire /etc/pki/tls/private, utilisez les commandes suivantes pour vérifier que les paramètres de propriété du fichier, de groupe et d'autorisation correspondent aux valeurs par défaut Amazon Linux 2 très restrictives (propriétaire=racine, groupe=racine, lecture/écriture pour 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
  7. 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
  8. Enregistrez /etc/httpd/conf.d/ssl.conf et redémarrez Apache.

    [ec2-user ~]$ sudo systemctl restart httpd
  9. 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.

Étape 3 : Test et renforcement de la configuration de sécurité

Une fois que votre TLS est opérationnel et exposé au public, vous devriez tester son niveau de sécurité. Il est facile de le faire avec des services en ligne comme Qualys SSL Labs qui effectue une analyse gratuite et complète de votre configuration de sécurité. En fonction des résultats, vous pouvez décider de renforcer la configuration de sécurité par défaut en contrôlant les protocoles que vous acceptez, les chiffrements que vous préférez et que vous excluez. Pour plus d'informations, consultez comment Qualys formule ses scores.

Important

Le test concret est essentiel pour la sécurité de votre serveur. Les petites erreurs de configuration peuvent entraîner des failles de sécurité et des pertes de données. Comme les pratiques de sécurité recommandées changent constamment en réponse à la recherche et aux menaces émergentes, des audits de sécurité périodiques sont essentiels pour la bonne administration du serveur.

Sur le site Qualys SSL Labs, saisissez le nom de domaine complet de votre serveur dans le formulaire www.example.com. Après environ deux minutes, vous recevrez une note (de A à F) pour votre site et une analyse détaillée des résultats. Le tableau suivant présente le rapport pour un domaine avec des paramètres identiques à la configuration Apache par défaut sur Amazon Linux 2 et avec un certificat Certbot par défaut.

Score général B
Certificat 100 %
Support du protocole 95 %
Échange de clés 70 %
Force du chiffrement 90 %

Même si l’aperçu montre que la configuration est principalement sûre, le rapport détaillé indique plusieurs problèmes potentiels, répertoriés ici dans l’ordre de gravité :

Le chiffrement RC4 est pris en charge pour être utilisé par certains navigateurs plus anciens. Un chiffrement est le noyau mathématique d'un algorithme de chiffrement. RC4, un chiffrement rapide utilisé pour chiffrer les flux de données TLS, est connu pour avoir plusieurs failles importantes. À moins que vous ayez une très bonne raison de prendre en charge des navigateurs existants, vous devez désactiver cette option.

Les anciennes versions de TLS sont prises en charge. La configuration prend en charge TLS 1.0 (déjà obsolète) et TLS 1.1 (bientôt obsolète). Seul TLS 1.2 est recommandé depuis 2018.

La confidentialité persistante n’est pas entièrement prise en charge. La confidentialité persistante est une fonction des algorithmes qui chiffrent à l'aide de clés de session temporaires (éphémères) issues de la clé privée. Ceci signifie en pratique que les pirates informatiques ne peuvent pas déchiffrer les données HTTPS même s'ils possèdent la clé privée à long terme d'un serveur web.

Pour corriger et prévenir les erreurs de configuration TLS

  1. 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
  2. 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é.

    Note

    La désactivation des versions TLS 1.0 et 1.1 de cette manière empêche un faible pourcentage de navigateurs web obsolètes d'accéder à votre site.

Pour modifier la liste des chiffrements autorisés

  1. 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
  2. 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.

    Note

    Même si la directive est affichée ici sur plusieurs lignes afin d'être plus lisible, elle doit être sur une seule ligne lorsqu’elle est copiée dans /etc/httpd/conf.d/ssl.conf avec un point (pas d'espace) entre les noms des chiffrements.

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

Après avoir terminé ces deux procédures, enregistrez les modifications dans /etc/httpd/conf.d/ssl.conf et redémarrez Apache.

Si vous testez de nouveau le domaine sur Qualys SSL Labs, vous devriez voir que la vulnérabilité RC4 et les autres avertissements ont été supprimés et que le résumé ressemble à ce qui suit.

Score général A
Certificat 100 %
Support du protocole 100 %
Échange de clés 90 %
Force du chiffrement 90 %

Important

Chaque mise à jour d'OpenSSL présente de nouveaux chiffrements et supprime le support des anciens. Gardez à jour votre instance EC2 Amazon Linux 2, surveillez les annonces de sécurité d'OpenSSL et restez attentif aux rapports de nouvelles attaques de la sécurité dans la presse technique. Pour plus d'informations, consultez la section Predefined SSL Security Policies for Elastic Load Balancing du manuel Guide de l'utilisateur pour les Equilibreurs de charge classiques.

Dépannage

  • Mon serveur web Apache ne démarre pas si je ne fournis pas un mot de passe

    Il s'agit du comportement attendu si vous avez installé une clé de serveur privée chiffrée et protégée par mot de passe.

    Vous pouvez supprimer l’obligation de chiffrement et de mot de passe de la clé. En supposant que vous disposez d'une clé RSA privée chiffrée nommée custom.key dans le répertoire par défaut et que le mot de passe de celle-ci est abcde12345, exécutez les commandes suivantes sur votre instance EC2 pour générer une version non chiffrée de la clé.

    [ec2-user ~]$ cd /etc/pki/tls/private/ [ec2-user private]$ sudo cp custom.key custom.key.bak [ec2-user private]$ sudo openssl rsa -in custom.key -passin pass:abcde12345 -out custom.key.nocrypt [ec2-user private]$ sudo mv custom.key.nocrypt custom.key [ec2-user private]$ sudo chown root:root custom.key [ec2-user private]$ sudo chmod 600 custom.key [ec2-user private]$ sudo systemctl restart httpd

    Apache devrait maintenant démarrer sans vous demander de fournir un mot de passe.

  • J'obtiens des erreurs lors de l'exécution sudo yum install -y mod_ssl.

    Lorsque vous installez les packages requis pour SSL, vous pouvez voir des erreurs similaires à ce qui suit.

    Error: httpd24-tools conflicts with httpd-tools-2.2.34-1.16.amzn1.x86_64 Error: httpd24 conflicts with httpd-2.2.34-1.16.amzn1.x86_64

    Cela signifie généralement que votre instance EC2 n'exécute pas Amazon Linux 2. Ce didacticiel prend uniquement en charge les instances récemment créées à partir d'une AMI Amazon Linux 2 officielle.

Automatisation de certificat : Utilisation de Let's Encrypt avec Certbot sur Amazon Linux 2

L'autorité de certification Let's Encrypt est la pièce maîtresse de l'effort réalisé par l'organisation Electronic Frontier Foundation (EFF) pour chiffrer Internet à 100 %. Conformément à cet objectif, les certificats d'hôte Let's Encrypt sont conçus pour être créés, validés, installés et tenus à jour avec une intervention humaine limitée. Les aspects automatisés de la gestion de certificats sont effectués par un agent logiciel exécuté sur votre serveur web. Après avoir installé et configuré l'agent, il communique de façon sécurisée avec Let's Encrypt et effectue des tâches administratives sur Apache et sur le système de gestion des clés. Ce didacticiel utilise un agent Certbot gratuit, car il vous permet soit de fournir une clé de chiffrement personnalisée comme base pour vos certificats, soit d'autoriser l'agent lui-même à créer une clé basée sur ses valeurs par défaut. Vous pouvez également configurer Certbot pour renouveler vos certificats de façon régulière sans intervention humaine, comme décrit dans Pour automatiser Certbot. Pour plus d'informations, consultez le guide de l'utilisateur Certbot et la documentation Man.

Même si Certbot n'est pas officiellement pris en charge sur Amazon Linux 2, il est disponible en téléchargement et fonctionne correctement une fois installé. Nous vous recommandons d'effectuer les sauvegardes suivantes pour protéger vos données et éviter tout incident :

  • Avant de commencer, prenez un instantané de votre volume racine Amazon EBS. Vous pouvez ainsi restaurer l'état d'origine de votre instance EC2. Pour plus d'informations sur la création d'instantanés EBS, consultez Création d'instantanés Amazon EBS.

  • La procédure ci-dessous nécessite la modification du fichier httpd.conf, qui contrôle le fonctionnement d'Apache. Certbot lui apporte automatiquement ses propres modifications, ainsi qu'à d'autres fichiers de configuration. Effectuez une copie de sauvegarde de l'ensemble de votre répertoire /etc/httpd au cas où vous auriez besoin de le restaurer.

Préparation de l'installation

Exécutez les procédures suivantes avant d'installer Certbot.

  1. Téléchargez les packages de référentiels EPEL (Extra Packages for Enterprise Linux) 7. Ils sont requis pour fournir les dépendances requises par Certbot.

    1. Accédez à votre répertoire de base (/home/ec2-user). Téléchargez le kit EPEL avec la commande suivante.

      [ec2-user ~]$ sudo wget -r --no-parent -A 'epel-release-*.rpm' http://dl.fedoraproject.org/pub/epel/7/x86_64/Packages/e/
    2. Installez les packages de référentiel comme illustré dans la commande suivante.

      [ec2-user ~]$ sudo rpm -Uvh dl.fedoraproject.org/pub/epel/7/x86_64/Packages/e/epel-release-*.rpm
    3. Activez EPEL comme dans la commande suivante.

      [ec2-user ~]$ sudo yum-config-manager --enable epel*

      Vous pouvez vérifier qu'EPEL est activé avec la commande suivante. Les informations renvoyées devraient être semblables à ce qui suit.

      [ec2-user ~]$ sudo yum repolist all ... epel/x86_64 Extra Packages for Enterprise Linux 7 - x86_64 enabled: 12949+175 epel-debuginfo/x86_64 Extra Packages for Enterprise Linux 7 - x86_64 - Debug enabled: 2890 epel-source/x86_64 Extra Packages for Enterprise Linux 7 - x86_64 - Source enabled: 0 epel-testing/x86_64 Extra Packages for Enterprise Linux 7 - Testing - x86_64 enabled: 778+12 epel-testing-debuginfo/x86_64 Extra Packages for Enterprise Linux 7 - Testing - x86_64 - Debug enabled: 107 epel-testing-source/x86_64 Extra Packages for Enterprise Linux 7 - Testing - x86_64 - Source enabled: 0 ...
  2. Modifiez le fichier de configuration principal Apache, /etc/httpd/conf/httpd.conf. Localisez la directive « listen 80 » et ajoutez les lignes suivantes après cette dernière, en remplaçant les exemples de noms de domaine par le nom commun et le nom SAN (Subject Alternative Name) réels.

    <VirtualHost *:80> DocumentRoot "/var/www/html" ServerName "example.com" ServerAlias "www.example.com" </VirtualHost>

    Enregistrez le fichier et redémarrez Apache.

    [ec2-user ~]$ sudo systemctl restart httpd

Installation et exécution de Certbot

Cette procédure est basée sur la documentation d'EFF pour installer Certbot sur Fedora et RHEL 7. Elle décrit l'utilisation par défaut de Certbot, générant un certificat basé sur une clé RSA 2 048 bits. Si vous voulez utiliser des clés personnalisées, commencez par consulter la page Using ECDSA certificates with Let's Encrypt.

  1. Installez les dépendances et les packages Certbot à l'aide de la commande suivante.

    [ec2-user ~]$ sudo yum install -y certbot python2-certbot-apache
  2. Exécutez Certbot.

    [ec2-user ~]$ sudo certbot
  3. A l'invite « Enter email address (used for urgent renewal and security notices) », saisissez l'adresse d'un contact et appuyez sur Entrée.

  4. A l'invite, acceptez les conditions de service Let's Encrypt. Saisissez « A » et appuyez sur Entrée pour poursuivre.

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Please read the Terms of Service at https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf. You must agree in order to register with the ACME server at https://acme-v02.api.letsencrypt.org/directory - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - (A)gree/(C)ancel: A
  5. À l'autorisation EFF vous permettant de vous ajouter à la liste de diffusion, saisissez « Y » ou « N », puis appuyez sur Entrée.

  6. Certbot affiche le nom commun et le nom SAN (Subject Alternative Name) que vous avez fournis dans le bloc VirtualHost.

    Which names would you like to activate HTTPS for? - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1: example.com 2: www.example.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Select the appropriate numbers separated by commas and/or spaces, or leave input blank to select all options shown (Enter 'c' to cancel):

    Laissez le champ vide et appuyez sur Entrée.

  7. Certbot affiche le résultat suivant lorsqu'il crée des certificats et configure Apache. Il vous invite ensuite à réacheminer les requêtes HTTP vers HTTPS.

    Obtaining a new certificate Performing the following challenges: http-01 challenge for example.com http-01 challenge for www.example.com Waiting for verification... Cleaning up challenges Created an SSL vhost at /etc/httpd/conf/httpd-le-ssl.conf Deploying Certificate for example.com to VirtualHost /etc/httpd/conf/httpd-le-ssl.conf Enabling site /etc/httpd/conf/httpd-le-ssl.conf by adding Include to root configuration Deploying Certificate for www.example.com to VirtualHost /etc/httpd/conf/httpd-le-ssl.conf Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1: No redirect - Make no further changes to the webserver configuration. 2: Redirect - Make all requests redirect to secure HTTPS access. Choose this for new sites, or if you're confident your site works on HTTPS. You can undo this change by editing your web server's configuration. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Select the appropriate number [1-2] then [enter] (press 'c' to cancel):

    Si vous souhaitez autoriser les visiteurs à se connecter à votre serveur via un protocole HTTP non chiffré, saisissez « 1 ». Si vous souhaitez accepter uniquement les connexions chiffrées via HTTPS, saisissez « 2 ». Appuyez sur Entrée pour soumettre votre choix.

  8. Certbot termine la configuration d'Apache et signale un succès et d'autres informations.

    Congratulations! You have successfully enabled https://example.com and https://www.example.com You should test your configuration at: https://www.ssllabs.com/ssltest/analyze.html?d=example.com https://www.ssllabs.com/ssltest/analyze.html?d=www.example.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - IMPORTANT NOTES: - Congratulations! Your certificate and chain have been saved at: /etc/letsencrypt/live/certbot.oneeyedman.net/fullchain.pem Your key file has been saved at: /etc/letsencrypt/live/certbot.oneeyedman.net/privkey.pem Your cert will expire on 2019-08-01. To obtain a new or tweaked version of this certificate in the future, simply run certbot again with the "certonly" option. To non-interactively renew *all* of your certificates, run "certbot renew" - Your account credentials have been saved in your Certbot configuration directory at /etc/letsencrypt. You should make a secure backup of this folder now. This configuration directory will also contain certificates and private keys obtained by Certbot so making regular backups of this folder is ideal.
  9. Une fois que vous avez terminé l'installation, testez et optimisez la sécurité de votre serveur comme décrit dans Étape 3 : Test et renforcement de la configuration de sécurité.

Configuration du renouvellement automatique de certificats

Certbot est conçu pour devenir une partie de votre système de serveur invisible et sans erreur. Par défaut, il génère des certificats d'hôte avec un court délai d'expiration de 90 jours. Si vous n'avez pas configuré votre système pour appeler la commande automatiquement, vous devez réexécuter la commande certbot manuellement avant l'expiration. Cette procédure indique comment automatiser Certbot en configurant une tâche cron.

Pour automatiser Certbot

  1. Ouvrez le fichier /etc/crontab dans un éditeur de texte et ajoutez une ligne semblable à la suivante.

    39 1,13 * * * root certbot renew --no-self-upgrade

    Enregistrez le fichier lorsque c'est terminé. Voici un descriptif de chaque composant de la commande.

    39 1,13 * * *

    Planifie l'exécution d'une commande à 1 h 39 et 13 h 39 chaque jour. Les valeurs sélectionnées sont arbitraires, mais les développeurs Certbot suggèrent d'exécuter la commande au moins deux fois par jour. Cela garantit la révocation et le remplacement rapides de tous les certificats compromis.

    root

    Des autorisations racine sont nécessaires pour exécuter la commande.

    certbot renew --no-self-upgrade

    La commande à exécuter. La sous-commande renew provoque la vérification des certificats obtenus et le renouvellement de ceux qui s'approchent de la date d'expiration par Certbot. L'indicateur --no-self-upgrade empêche la mise à niveau de Certbot sans votre intervention.

  2. Redémarrez le processus cron.

    [ec2-user ~]$ sudo systemctl restart crond