Chapitre 12. Serveurs web


Un serveur web est un service réseau qui remet un contenu à un client à travers le web. Habituellement, cela signifie des pages web, mais tout autre document peut également être remis. Les serveurs web sont également appelés des serveurs HTTP , car ils utilisent le protocole de transport hypertexte (HTTP).

12.1. Serveur Apache HTTP

Le serveur web disponible sur Red Hat Enterprise Linux 7 est la version 2.4 du Serveur Apache HTTP, httpd, un serveur web open source développé par la Fondation Apache Software.
Si vous effectuez une mise à niveau à partir d'une version précédente de Red Hat Enterprise Linux, vous devrez mettre à jour la configuration du service httpd. Cette section traite de certaines nouvelles fonctionnalités ajoutées, souligne les changements importants entre les versions 2.2 et 2.4 du serveur Apache HTTP, et vous guide à travers la mise à jour des anciens fichiers de configuration.

12.1.1. Changements notables

Le serveur Apache HTTP sur Red Hat Enterprise Linux 7 propose les changements suivants comparé à Red Hat Enterprise Linux 6 :
Contrôle du service httpd
Avec la migration vers l'extérieur des scripts init SysV, les administrateurs de serveur devront se mettre à utiliser les commandes apachectl et systemctl pour contrôler le service, à la place de la commande service. Les exemples suivants sont spécifiques au service httpd.
La commande :
service httpd graceful
est remplacée par
apachectl graceful
. Le fichier unité systemd de httpd a un comportement différent du script init, comme suit :
  • Un redémarrage correct est utilisé par défaut lorsque le service est rechargé.
  • Un arrêt correct est utilisé par défaut lorsque le service est arrêté.
La commande :
service httpd configtest
est remplacée par
apachectl configtest
Répertoire /tmp privé
Pour améliorer la sécurité du système, le fichier unité systemd exécute le démon httpd en utilisant un répertoire privé /tmp, séparé du répertoire /tmp du système.
Structure de la configuration
Les fichiers de configuration qui chargent les modules sont désormais placés dans le répertoire /etc/httpd/conf.modules.d/. Les paquets fournissant des modules supplémentaires qui peuvent être chargés pour httpd, comme php, placeront un fichier dans ce répertoire. Une directive Include avant la section principale du fichier /etc/httpd/conf/httpd.conf est utilisée pour inclure les fichiers dans le répertoire /etc/httpd/conf.modules.d/. Cela signifie que tous les fichiers de configuration de conf.modules.d/ sont traités avant le corps principal de httpd.conf. Une directive IncludeOptional pour les fichiers dans le répertoire /etc/httpd/conf.d/ est placée à la fin du fichier httpd.conf. Cela signifie que les fichiers qui se trouvent dans /etc/httpd/conf.d/ sont désormais traités après le corps principal de httpd.conf.
Certains fichiers de configuration supplémentaires sont fournis par le paquet httpd :
  • /etc/httpd/conf.d/autoindex.conf — Permet de configurer l'indexation du répertoire mod_autoindex.
  • /etc/httpd/conf.d/userdir.conf — Permet de configurer l'accès aux répertoires utilisateurs. Par exemple, http://example.com/~username/ ; ce type d'accès est désactivé par défaut pour des raisons de sécurité.
  • /etc/httpd/conf.d/welcome.conf — Tout comme dans les versions précédentes, cela permet de configurer la page d'accueil affichée pour http://localhost/ lorsqu'aucun contenu n'est présent.
Configuration par défaut
Un fichier httpd.conf minimal est désormais fourni par défaut. De nombreux paramètres de configuration courants, comme Timeout ou KeepAlive, ne sont plus explicitement configurés dans la configuration par défaut ; au lieu de ceux-ci, les paramètres codés de manière irréversibles seront utilisés par défaut. Les paramètres codés de manière irréversible par défaut pour toutes les directives de configuration sont spécifiés dans le manuel. Veuillez consulter la section intitulée « Documentation installable » pour obtenir davantage d'informations.
Modifications incompatibles de la syntaxe
Lors de la migration d'une configuration existante de httpd 2.2 à httpd 2.4, un certain nombre de modifications incompatibles en arrière apportées à la syntaxe de la configuration httpd nécessiteront des changements. Veuillez consulter le document Apache suivant pour obtenir davantage d'informations concernant la mise à niveau de http://httpd.apache.org/docs/2.4/upgrading.html
Modèle de traitement
Dans les versions précédentes de Red Hat Enterprise Linux, différents modèles de multiples traitements (« multi-processing models », ou MPM) étaient disponibles aux différents binaires httpd : le modèle fourchu, « prefork », /usr/sbin/httpd ; et le modèle basé sur thread « worker », /usr/sbin/httpd.worker.
Sur Red Hat Enterprise Linux 7, seul un binaire httpd est utilisé, et trois MPM sont disponibles en tant que modules chargeables : « worker », « prefork » (par défaut), et « event ». Veuillez modifier le fichier de configuration /etc/httpd/conf.modules.d/00-mpm.conf comme requis, en ajoutant et supprimant le caractère dièse (#), afin qu'un seul des trois modules MPM soit chargé.
Modifications de paquets
Les modules d'authentification et d'autorisation LDAP sont désormais fournis dans un sous-paquet séparé, mod_ldap. Le nouveau module mod_session et les modules d'aide associés sont fournis dans un nouveau sous-paquet, mod_session. Les nouveaux modules mod_proxy_html et mod_xml2enc sont fournis dans un nouveau sous-paquet, mod_proxy_html. Ces paquets se trouvent tous dans le canal « Optional ».

Note

Avant de vous abonner aux canaux « Optional » et « Supplementary », veuillez consulter les Détails de l'étendue de la couverture. Si vous décidez d'installer des paquets à partir de ces canaux, veuillez suivre les étapes documentées dans l'article nommé Comment accéder aux canaux « Optional » et « Supplementary » et aux paquets -devel en utilisant Red Hat Subscription Manager (RHSM) ? sur le Portail Client Red Hat.
Empaquetage des structures de systèmes de fichiers
Le répertoire /var/cache/mod_proxy/ n'est plus fourni ; à la place, le répertoire /var/cache/httpd/ est empaqueté avec un sous-répertoire proxy et ssl.
Le contenu empaqueté avec httpd a été déplacé de /var/www/ à /usr/share/httpd/ :
  • /usr/share/httpd/icons/ — Le répertoire contenant un ensemble d'icônes avec des indices de répertoire, auparavant contenus dans /var/www/icons/, a été déplacé sur /usr/share/httpd/icons/. Disponible sur http://localhost/icons/ dans la configuration par défaut ; l'emplacement et la disponibilité des icônes est configurable dans le fichier /etc/httpd/conf.d/autoindex.conf.
  • /usr/share/httpd/manual//var/www/manual/ a été déplacé sur /usr/share/httpd/manual/. Ce répertoire, qui fait partie du paquet httpd-manual, contient la version HTML du manuel de httpd. Disponible sur http://localhost/manual/ si le paquet est installé, l'emplacement et la disponibilité du manuel sont configurables dans le fichier /etc/httpd/conf.d/manual.conf.
  • /usr/share/httpd/error//var/www/error/ a été déplacé sur /usr/share/httpd/error/. Pages d'erreurs HTTP de langues multiples personnalisées. Non configuré par défaut, le fichier de configuration exemple est fourni sur /usr/share/doc/httpd-VERSION/httpd-multilang-errordoc.conf.
Authentifications, autorisations et contrôle des accès
Les directives de configuration utilisées pour contrôler l'authentification, les autorisations et le contrôle des accès ont changé de manière significative. Les fichiers de configuration existants qui utilisent les directives Order, Deny et Allow doivent être adaptés afin de pouvoir utiliser la nouvelle syntaxe Require. Veuillez consulter le document Apache suivant pour obtenir davantage d'informations : http://httpd.apache.org/docs/2.4/howto/auth.html
suexec
Pour améliorer la sécurité du système, le binaire suexec n'est plus installé par l'équivalent de l'utilisateur root ; au lieu de cela, il possède une fonctionnalité  «bit Set» dans le système de fichiers, qui limite les restrictions. En conjonction avec ce changement, le binaire suexec n'utilise plus le fichier journal /var/log/httpd/suexec.log. Au lieu de cela, des messages de journalisation sont envoyés sur syslog. Par défaut, ceux-ci apparaîtront dans le fichier journal /var/log/secure.
Interface du module
Des modules binaires de tierce-partie créés avec httpd 2.2 ne sont pas compatibles avec httpd 2.4 à cause de changements apportés à l'interface du module httpd. De tels modules devront être ajustés comme nécessaire pour l'interface du module httpd 2.4, puis recréés. Une liste détaillée des changements d'API dans la version 2.4 sont disponibles ici : http://httpd.apache.org/docs/2.4/developer/new_api_2_4.html.
Le binaire apxs utilisé pour créer des modules source a été déplacé de /usr/sbin/apxs à /usr/bin/apxs.
Modules supprimés
Liste des modules httpd supprimés de Red Hat Enterprise Linux 7 :
mod_auth_mysql, mod_auth_pgsql
httpd 2.4 fournit la prise en charge de l'authentification de bases de données SQL de manière interne dans le module mod_authn_dbd.
mod_perl
mod_perl n'est pas officiellement pris en charge avec httpd 2.4 en amont.
mod_authz_ldap
httpd 2.4 offre la prise en charge LDAP dans le sous-paquet mod_ldap en utilisant mod_authnz_ldap.

12.1.2. Mettre à jour la configuration

Pour mettre à jour les fichiers de configuration à partir de la version 2.2 d'Apache HTTP Server, veuillez effectuer les étapes suivantes :
  1. Comme ils peuvent avoir été modifiés, assurez-vous que tous les noms de modules soient corrects. Ajustez la directive LoadModule pour chaque module dont le nom a changé.
  2. Compilez à nouveau tous les modules de tierce-partie avant de tenter de les charger. Typiquement, cela signifie des modules d'authentification et d'autorisation.
  3. Si vous utilisez le module mod_userdir, assurez-vous que la directive UserDir indiquant un nom de répertoire (habituellement public_html) soit effectivement fournie.
  4. Si vous utilisez Apache HTTP Secure Server, veuillez consulter la Section 12.1.8, « Activer le module mod_ssl » pour obtenir des informations importantes sur l'activation du protocole SSL (« Secure Sockets Layer »).
Remarquez qu'il est possible de vérifier les erreurs possibles de la configuration en utilisant la commande suivante :
~]# apachectl configtest
Syntax OK
Pour obtenir davantage d'informations sur la mise à niveau de la configuration d'Apache HTTP Server depuis la version 2.2 à la version 2.4, veuillez consulter http://httpd.apache.org/docs/2.4/upgrading.html.

12.1.3. Exécuter le service httpd

Cette section décrit comment lancer, arrêter, redémarrer, et vérifier le statut actuel du serveur Apache HTTP Server. Pour être en mesure d'utiliser le service httpd, assurez-vous que httpd soit effectivement installé. Cela peut être effectué en utilisant la commande suivante :
~]# yum install httpd
Pour obtenir davantage d'informations sur le concept des cibles et sur la manière de gérer les services système dans Red Hat Enterprise Linux, veuillez consulter le Chapitre 9, Gérer les services avec systemd.

12.1.3.1. Lancer le service

Pour exécuter le service httpd, veuillez saisir ce qui suit à l'invite de shell en tant qu'utilisateur root :
~]# systemctl start httpd.service
Si vous souhaitez que le service soit automatiquement lancé pendant le démarrage, veuillez utiliser la commande suivante :
~]# systemctl enable httpd.service
Created symlink from /etc/systemd/system/multi-user.target.wants/httpd.service to /usr/lib/systemd/system/httpd.service.

Note

Si Apache HTTP Server est exécuté en tant que serveur sécurisé, un mot de passe pourrait être requis après le démarrage de la machine si une clé SSL privée chiffrée est utilisée.

12.1.3.2. Arrêter le service

Pour arrêter le service en cours d'exécution httpd, veuillez saisir ce qui suit dans une invite de shell en tant qu'utilisateur root :
~]# systemctl stop httpd.service
Pour empêcher le service d'être lancé automatiquement pendant le démarrage, veuillez saisir :
~]# systemctl disable httpd.service
Removed symlink /etc/systemd/system/multi-user.target.wants/httpd.service.

12.1.3.3. Redémarrer le service

Il existe trois différentes manières de redémarrer un service httpd :
  1. Pour redémarrer le système entièrement, exécutez la commande suivante en tant qu'utilisateur root :
    ~]# systemctl restart httpd.service
    Ceci arrête le service en cours d'exécution httpd et le lance immédiatement après. Veuillez utiliser cette commande après avoir installé ou supprimé un module chargé dynamiquement, comme le module PHP.
  2. Pour uniquement recharger la configuration, veuillez saisir en tant qu'utilisateur root :
    ~]# systemctl reload httpd.service
    Ceci cause au service en cours d'exécution httpd de recharger son fichier de configuration. Toute requête actuellement en cours de traitement sera interrompue, ce qui pourrait causer à un navigateur client d'afficher un message d'erreur ou d'effectuer un rendu partiel de page.
  3. Pour recharger sa configuration sans affecter de requête active, veuillez saisir la commande suivante en tant qu'utilisateur root :
    ~]# apachectl graceful
    Ceci cause au service en cours d'exécution httpd de recharger son fichier de configuration. Toute requête actuellement en cours de traitement continuera d'utiliser l'ancienne configuration.
Pour obtenir davantage d'informations sur la manière de gérer les services système sur Red Hat Enterprise Linux 7, veuillez consulter le Chapitre 9, Gérer les services avec systemd.

12.1.3.4. Vérifier le statut du service

Pour vérifier que le service httpdest effectivement en cours d'exécution, veuillez saisir ce qui suit dans l'invite du shell :
~]# systemctl is-active httpd.service
active

12.1.4. Modifier les fichiers de configuration

Lorsque le service httpd est lancé, par défaut, il lit la configuration à partir d'emplacements répertoriés dans la Tableau 12.1, « Fichiers de configuration du service httpd ».
Tableau 12.1. Fichiers de configuration du service httpd
CheminDescription
/etc/httpd/conf/httpd.conf Fichier de configuration principal.
/etc/httpd/conf.d/ Répertoire auxiliaire pour les fichiers de configuration inclus dans le fichier de configuration principal.
Même si la configuration par défaut est convenable dans la plupart des situations, il est préférable de se familiariser avec certaines des options de configuration plus importantes. Remarquez que pour que tout changement puisse entrer en vigueur, le serveur web doit d'abord être redémarré. Veuillez consulter la Section 12.1.3.3, « Redémarrer le service » pour obtenir davantage d'informations sur la manière de redémarrer le service httpd.
Pour vérifier que la configuration ne contienne pas d'erreurs possibles, veuillez saisir ce qui suit dans une invite de shell :
~]# apachectl configtest
Syntax OK
Pour faciliter la récupération après des erreurs, il est recommandé d'effectuer une copie du fichier d'origine avant de le modifier.

12.1.5. Utiliser des modules

Étant une application modulaire, le service httpd est distribué avec un certain nombre d'objets partagés dynamiques (« Dynamic Shared Objects », ou DSO), qui peuvent être chargés ou déchargés dynamiquement pendant le runtime, selon les besoins. Dans Red Hat Enterprise Linux 7, ces modules se trouvent dans /usr/lib64/httpd/modules/.

12.1.5.1. Charger un module

Pour charger un module DSO particulier, utilisez la directive LoadModule. Remarquez que les modules fournis par un paquet séparé possèdent souvent leur propre fichier de configuration dans le répertoire /etc/httpd/conf.d/.

Exemple 12.1. Charger mod_ssl DSO

LoadModule ssl_module modules/mod_ssl.so
Une fois que vous aurez terminé, redémarrez le serveur web pour recharger la configuration. Veuillez consulter la Section 12.1.3.3, « Redémarrer le service » pour obtenir davantage d'informations sur la manière de redémarrer le service httpd.

12.1.5.2. Écrire un module

Si vous comptez créer un nouveau module DSO, assurez-vous que le paquet httpd-devel soit installé. Pour faire cela, veuillez saisir la commande suivante en tant qu'utilisateur root :
~]# yum install httpd-devel
Ce paquet contient les fichiers « include », les fichiers d'en-tête « header », et l'utilitaire APache eXtenSion (apxs) requis pour compiler un module.
Une fois écrit, le module peut être créé par la commande suivante :
~]# apxs -i -a -c module_name.c
Si le build a été créé avec succès, vous devriez pouvoir charger le module de la même manière que tout autre module distribué avec le serveur Apache HTTP Server.

12.1.6. Paramétrer des hôtes virtuels

L'hébergement virtuel intégré d'Apache HTTP Server permet au serveur de fournir différentes informations basées sur l'adresse IP, le nom d'hôte, ou le port requis.
Pour créer un hôte virtuel basé nom, copiez l'exemple de fichier de configuration /usr/share/doc/httpd-VERSION/httpd-vhosts.conf dans le répertoire /etc/httpd/conf.d/, et remplacez les valeurs d'espaces réservés @@Port@@ et @@ServerRoot@@. Personnalisez les options selon vos besoins, comme affiché dans l'Exemple 12.2, « Exemple de configuration d'hôte virtuel ».

Exemple 12.2. Exemple de configuration d'hôte virtuel

<VirtualHost *:80>
    ServerAdmin webmaster@penguin.example.com
    DocumentRoot "/www/docs/penguin.example.com"
    ServerName penguin.example.com
    ServerAlias www.penguin.example.com
    ErrorLog "/var/log/httpd/dummy-host.example.com-error_log"
    CustomLog "/var/log/httpd/dummy-host.example.com-access_log" common
</VirtualHost>
Remarquez que ServerName doit être un nom DNS valide assigné à la machine. Le conteneur <VirtualHost> est hautement personnalisable, et accepte la plupart des directives disponibles dans la configuration du serveur principal. Les directives qui ne sont pas prises en charge dans ce conteneur incluent User et Group, remplacées par SuexecUserGroup.

Note

Si vous configurez un hôte virtuel pour qu'il écoute sur un port qui n'est pas un port par défaut, assurez-vous de mettre à jour la directive Listen dans la section des paramètres globaux du fichier /etc/httpd/conf/httpd.conf en conséquence.
Pour activer un nouvel hôte virtuel créé, le serveur web doit d'abord être redémarré. Veuillez consulter la Section 12.1.3.3, « Redémarrer le service » pour obtenir davantage d'informations sur la manière de redémarrer le service httpd.

12.1.7. Paramétrer un serveur SSL

Secure Sockets Layer (SSL) est un protocole de chiffrement permettant à un serveur et un client de communiquer de manière sécurisée. Avec sa version étendue et améliorée nommée Transport Layer Security (TLS), confidentialité et intégrité des données sont assurées. Le serveur Apache HTTP Server combiné à mod_ssl, un module qui utilise le kit de ressources OpenSSL pour fournir la prise en charge SSL/TLS, est couramment appelé un serveur SSL. Red Hat Enterprise Linux prend également en charge l'utilisation de Mozilla NSS comme implémentation TLS. La prise en charge de Mozilla NSS est fournie par le module mod_nss.
Contrairement à une connexion HTTP qui pourrait être lue et probablement modifiée par toute personne capable de l'intercepter, l'utilisation de SSL/TLS sur HTTP, également appelée HTTPS, empêche toute inspection ou modification du contenu transmis. Cette section fournit des informations de base sur la manière d'activer ce module dans la configuration du serveur Apache HTTP Server, et vous guide à travers le processus de génération de clés privées et de certificats auto-signés.

12.1.7.1. Vue d'ensemble des certificats et de la sécurité

Les communications sécurisées sont basées sur l'usage de clés. Avec le chiffrement symétrique ou conventionel, les deux côtés de la transaction ont la même clé et peuvent l'utiliser pour décoder les transmissions de l'un ou de l'autre. D'autre part, avec le chiffrement asymétrique ou public, deux clés coexistent : une clé privée qui est gardée secrète, et une clé publique qui est habituellement partagée publiquement. Même si les données sont chiffrées avec la clé publique, elles peuvent uniquement être déchiffrées avec la clé privée, et les données chiffrées avec la clé privée peuvent uniquement être déchiffrées avec la clé publique.
Pour fournir des communications sécurisées en utilisant SSL, un serveur SSL doit utiliser un certificat digital signé par une Autorité de certification (AC). Le certificat répertorie les divers attributs du serveur (c'est-à-dire, le nom d'hôte du serveur, le nom de l'entreprise, son emplacement, etc.), et la signature est produite en utilisant la clé privée de l'autorité de certification. Cette signature assure qu'une autorité de certification particulière a signé le certificat, et que le certificat n'a été modifié d'aucune manière.
Lorsqu'un navigateur web établit une nouvelle connexion SSL, il vérifie le certificat fourni par le serveur web. Si le certificat ne possède pas de signature d'une autorité de certification (AC) de confiance, ou si le nom d'hôte répertorié dans le certificat ne correspond pas au nom d'hôte utilisé pour établir la connexion, il refusera de communiquer avec le serveur et présentera normalement un message d'erreur approprié à l'utilisateur.
Par défaut, la plupart des navigateurs web sont configurés pour faire confiance à un ensemble d'autorités de certification (AC) couramment utilisées. Par conséquent, une AC appropriée devrait être choisie lors du paramétrage d'un serveur sécurisé, afin que les utilisateurs cibles puissent fait confiance à la connexion, sinon ils recevront un message d'erreur et devront accepter le certificat manuellement. Comme encourager des utilisateurs à outrepasser des erreurs de certification peut permettre à une personne malveillante d'intercepter la connexion, une autorité de certification de confiance devrait être utilisée dans la mesure du possible. Pour obtenir davantage d'informations sur cela, veuillez consulter la Tableau 12.2, « Informations sur les listes d'AC utilisées par des navigateurs web communs ».
Tableau 12.2. Informations sur les listes d'AC utilisées par des navigateurs web communs
Navigateur WebLien
Mozilla FirefoxListe d'AC root Mozilla.
OperaInformations sur les certificats root utilisés par Opera.
Internet ExplorerInformations sur les certificats root utilisés par Microsoft Windows.
ChromiumInformations sur les certificats root utilisés par le projet Chromium.
Lors du paramétrage d'un serveur SSL, vous devrez générer une requête de certificat et une clé privée, puis envoyez la requête de certificat, la preuve de l'identité de l'entreprise, et le paiement à l'autorité de certification. Une fois que l'AC aura vérifié la requête du certificat et votre identité, elle vous enverra un certificat signé que vous pourrez utiliser avec votre serveur. Alternativement, il est possible de créer un certificat auto-signé qui ne contient pas de signature d'AC, et qui devrait être uniquement utilisé pour effectuer des tests.

12.1.8. Activer le module mod_ssl

Si vous souhaitez paramétrer un serveur SSL ou HTTPS en utilisant mod_ssl, il n'est pas possible qu'une autre application ou qu'un autre module, comme mod_nss, soit configuré pour utiliser le même port. Le port 443 est le port par défaut pour HTTPS.
Pour paramétrer un serveur SSL en utilisant le module mod_ssl et le kit de ressources OpenSSL toolkit, veuillez installer les paquets mod_ssl et openssl. Saisissez la commande suivante en tant qu'utilisateur root :
~]# yum install mod_ssl openssl
Cela créera le fichier de configuration mod_ssl sur /etc/httpd/conf.d/ssl.conf, qui est inclus dans le fichier de configuration principal du serveur Apache HTTP Server par défaut. Pour que le module soit chargé, veuillez redémarrer le service httpd comme décrit dans la Section 12.1.3.3, « Redémarrer le service ».

Important

À cause de la vulnérabilité décrite sur POODLE: SSLv3 vulnerability (CVE-2014-3566), Red Hat recommande de désactiver SSL et d'utiliser TLSv1.1 ou TLSv1.2 uniquement. Une rétrocompatibilité peut être effectuée en utilisant TLSv1.0. De nombreux produits pris en charge par Red Hat ont la capacité d'utiliser le protocole SSLv2 ou SSLv3, ou de les activer par défaut. Cependant, l'utilisation de SSLv2 ou de SSLv3 est désormais fortement déconseillée.

12.1.8.1. Activer et désactiver SSL et TLS sur mod_ssl

Pour activer et désactiver des versions particulières des protocoles SSL et TLS, veuillez le faire globalement en ajoutant la directive SSLProtocol dans la section « ## SSL Global Context » du fichier de configuration et en la supprimant partout ailleurs, ou modifiez l'entrée par défaut sous « # SSL Protocol support » dans toutes les sections « VirtualHost ». Si vous ne le spécifiez pas dans la section VirtualHost par domaine, les paramètres hérités proviendront de la section globale. Pour vous assurer qu'une version du protocole est en cours de désactivation, l'administrateur doit uniquement spécifier SSLProtocol dans la section « SSL Global Context », ou bien, le spécifier dans toutes les sections VirtualHost par domaine.

Procédure 12.1. Désactiver SSLv2 et SSLv3

Pour désactiver SSL version 2 et SSL version 3, ce qui implique de tout activer sauf SSL version 2 et SSL version 3 dans toutes les sections VirtualHost, veuillez procéder comme suit :
  1. En tant qu'utilisateur root, ouvrez le fichier /etc/httpd/conf.d/ssl.conf et recherchez toutes les instances de la directive SSLProtocol. Par défaut, le fichier de configuration contient une section qui ressemble à cela :
    ~]# vi /etc/httpd/conf.d/ssl.conf
    #   SSL Protocol support:
    # List the enable protocol levels with which clients will be able to
    # connect.  Disable SSLv2 access by default:
    SSLProtocol all -SSLv2
    Cette section se trouve dans la section VirtualHost.
  2. Modifiez la ligne SSLProtocol comme suit :
    #   SSL Protocol support:
    # List the enable protocol levels with which clients will be able to
    # connect.  Disable SSLv2 access by default:
    SSLProtocol all -SSLv2 -SSLv3
    Répétez cette action pour toutes les sections VirtualHost. Enregistrez et fermez le fichier.
  3. Vérifiez que toutes les occurrences de la directive SSLProtocol ont été modifiées comme suit :
    ~]# grep SSLProtocol /etc/httpd/conf.d/ssl.conf
    SSLProtocol all -SSLv2 -SSLv3
    Cette étape est particulièrement importante si vous avez plus d'une section VirtualHost par défaut.
  4. Redémarrez le démon Apache comme suit :
    ~]# systemctl restart httpd
    Remarquez que toutes les sessions seront interrompues.

Procédure 12.2. Désactiver tous les protocoles SSL et TLS sauf TLS 1 et ses versions supérieures

Pour désactiver toutes les versions des protocoles SSL et TLS sauf TLS version 1 et ses versions supérieures, veuillez procéder comme suit :
  1. En tant qu'utilisateur root, ouvrez le fichier /etc/httpd/conf.d/ssl.conf et recherchez toutes les instances de la directive SSLProtocol. Par défaut, le fichier contient une section qui ressemble à cela :
    ~]# vi /etc/httpd/conf.d/ssl.conf
    #   SSL Protocol support:
    # List the enable protocol levels with which clients will be able to
    # connect.  Disable SSLv2 access by default:
    SSLProtocol all -SSLv2
  2. Modifiez la ligne SSLProtocol comme suit :
    #   SSL Protocol support:
    # List the enable protocol levels with which clients will be able to
    # connect.  Disable SSLv2 access by default:
    SSLProtocol -all +TLSv1 +TLSv1.1 +TLSv1.2
    Enregistrer et fermer le fichier.
  3. Vérifiez le changement comme suit :
    ~]# grep SSLProtocol /etc/httpd/conf.d/ssl.conf 
    SSLProtocol -all +TLSv1 +TLSv1.1 +TLSv1.2
  4. Redémarrez le démon Apache comme suit :
    ~]# systemctl restart httpd
    Remarquez que toutes les sessions seront interrompues.

Procédure 12.3. Tester le statut des protocoles SSL et TLS

Pour vérifier quelles versions de SSL et TLS sont activées ou désactivées, assurez-vous d'utiliser la commande openssl s_client -connect. La commande se trouve sous le format suivant :
openssl s_client -connect hostname:port -protocol
, où port correspond au port pour effectuer le test et protocol est la version du protocole à tester. Pour tester le serveur SSL exécuté localement, veuillez utiliser localhost comme nom d'hôte. Par exemple, pour tester le port par défaut pour des connexion HTTPS sécurisées, pour voir si SSLv3 est activé sur le port 443, exécutez la commande suivante :
  1. ~]# openssl s_client -connect localhost:443 -ssl3
    CONNECTED(00000003)
    139809943877536:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1257:SSL alert number 40
    139809943877536:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:596:sortie omise
    New, (NONE), Cipher is (NONE)
    Secure Renegotiation IS NOT supported
    Compression: NONE
    Expansion: NONE
    SSL-Session:
        Protocol  : SSLv3
    sortie tronquée
    La sortie ci-dessus indique que la tentative de connexion a échoué et qu'aucun chiffrement n'a été négocié.
  2. ~]$ openssl s_client -connect localhost:443 -tls1_2
    CONNECTED(00000003)
    depth=0 C = --, ST = SomeState, L = SomeCity, O = SomeOrganization, OU = SomeOrganizationalUnit, CN = localhost.localdomain, emailAddress = root@localhost.localdomainsortie omise
    New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
    Server public key is 2048 bit
    Secure Renegotiation IS supported
    Compression: NONE
    Expansion: NONE
    SSL-Session:
        Protocol  : TLSv1.2sortie tronquée
    La sortie ci-dessus indique qu'aucun échec de tentative de connexion n'a eu lieu et qu'un ensemble de chiffrements a été négocié.
Les options de la commande openssl s_client sont documentées dans la page man de s_client(1).
Pour obtenir davantage d'informations sur la vulnérabilité SSLv3 et comment effectuer des tests pour la trouver, veuillez consulter l'article de la base de connaissances Red Hat POODLE: SSLv3 vulnerability (CVE-2014-3566).

12.1.9. Activer le module mod_nss

Si vous comptez paramétrer un serveur HTTPS en utilisant mod_nss, vous ne pourrez pas avoir le paquet mod_ssl installé avec ses paramètres par défaut car mod_ssl utilisera le port 443 par défaut, cependant ceci est le port HTTPS par défaut. Si possible, veuillez supprimer le paquet.
Pour supprimer mod_ssl, veuillez saisir la commande suivante en tant qu'utilisateur root :
~]# yum remove mod_ssl

Note

Si mod_ssl est requis à d'autres fins, veuillez modifier le fichier /etc/httpd/conf.d/ssl.conf afin qu'il utilise un autre port que le port 443 pour empêcher que mod_ssl entre en conflit avec mod_nss lorsque son port d'écoute est changé sur le port 443.
Un seul module peut posséder un port, ainsi mod_nss et mod_ssl peuvent uniquement coexister au même moment s'ils utilisent des ports uniques. Pour cette raison, mod_nss utilise par défaut le port 8443, mais le port HTTPS par défaut est le port 443. Le port est spécifié par la directive Listen ainsi que dans le nom ou l'adresse VirtualHost.
Tout dans NSS est associé à un jeton (ou « token »). Un jeton logiciel existe dans la base de données NSS mais vous pouvez également avoir une clé physique contenant des certificats. Avec OpenSSL, des certificats discrets et des clés privées se trouvent dans les fichiers PEM. Avec NSS, ces fichiers sont stockés dans une base de données. Chaque certificat et chaque clé est associé à un jeton, et chaque jeton peut avoir un mot de passe le protégeant. Ce mot de passe est optionnel, mais si un mot de passe est utilisé, alors le serveur HTTP Apache aura besoin d'en avoir une copie afin de pouvoir ouvrir la base de données sans intervention de l'utilisateur pendant le démarrage système.

Procédure 12.4. Configurer mod_nss

  1. Installez mod_nss en tant qu'utilisateur root :
    ~]# yum install mod_nss
    Cela créera le fichier de configuration mod_nss dans /etc/httpd/conf.d/nss.conf. Le répertoire /etc/httpd/conf.d/ est inclus dans le fichier de configuration principal du serveur Apache HTTP Server par défaut. Pour que le module soit chargé, veuillez redémarrer le service httpd comme décrit dans la Section 12.1.3.3, « Redémarrer le service ».
  2. En tant qu'utilisateur root, ouvrez le fichier /etc/httpd/conf.d/nss.conf et recherchez toutes les instances de la directive Listen.
    Modifiez la ligne Listen 8443 comme suit :
    Listen 443
    Le port 443 est le port par défaut pour HTTPS.
  3. Modifiez la ligne VirtualHost _default_:8443 par défaut comme suit :
    VirtualHost _default_:443
    Veuillez modifier toute autre section d'hôte virtuel qui n'est pas par défaut s'il en existe. Puis enregistrez et fermez le fichier.
  4. Mozilla NSS stocke les certificats dans une base de données de certificats de serveur indiquée par la directive NSSCertificateDatabase dans le fichier /etc/httpd/conf.d/nss.conf. Par défaut, le chemin est défini sur /etc/httpd/alias, la base de données NSS créée pendant l'installation.
    Pour afficher la base de données NSS par défaut, veuillez exécuter la commande suivante :
    ~]# certutil -L -d /etc/httpd/alias
    
    Certificate Nickname                                         Trust Attributes
                                                                 SSL,S/MIME,JAR/XPI
    
    cacert                                                       CTu,Cu,Cu
    Server-Cert                                                  u,u,u
    alpha                                                        u,pu,u
    Dans la sortie de commande ci-dessus, Server-Cert est le NSSNickname par défaut. L'option -L répertorie tous les certificats, ou affiche des informations sur un certificat nommé, dans une base de données de certificats. L'option -d spécifie le répertoire de la base de données contenant le certificat et les fichiers-clés de la base de données. Veuillez consulter la page man certutil(1) pour davantage d'options de ligne de commande.
  5. Pour configurer mod_nss de manière à utiliser une autre base de données, veuillez modifier la ligne NSSCertificateDatabase dans le fichier /etc/httpd/conf.d/nss.conf. Le fichier par défaut possède les lignes suivantes dans la section VirtualHost.
    #   Server Certificate Database:
    #   The NSS security database directory that holds the certificates and
    #   keys. The database consists of 3 files: cert8.db, key3.db and secmod.db.
    #   Provide the directory that these files exist.
    NSSCertificateDatabase /etc/httpd/alias
    Dans la sortie la commande ci-dessus, alias est le répertoire de la base de données NSS par défaut, /etc/httpd/alias/.
  6. Pour appliquer un mot de passe à la base de données des certificats NSS par défaut, veuillez utiliser la commande suivante en tant qu'utilisateur root :
    ~]# certutil -W -d /etc/httpd/alias
    Enter Password or Pin for "NSS Certificate DB":
    Enter a password which will be used to encrypt your keys.
    The password should be at least 8 characters long,
    and should contain at least one non-alphabetic character.
    
    Enter new password:
    Re-enter password:
    Password changed successfully.
  7. Avant de déployer le serveur HTTPS, veuillez créer une nouvelle base de données de certificats en utilisant un certificat signé par une autorité de certification (AC).

    Exemple 12.3. Ajouter un certificat à la base de données Mozilla NSS

    La commande certutil est utilisée pour ajouter un certificat AC aux fichiers de la base de données NSS :
    certutil -d /etc/httpd/nss-db-directory/ -A -n "CA_certificate" -t CT,, -a -i certificate.pem
    La commande ci-dessus ajoute un certificat AC stocké dans un fichier au format PEM nommé certificate.pem. L'option -d spécifie le répertoire de la base de données NSS contenant le certificat et les fichiers-clés de la base de données, l'option -n définit un nom pour le certificat, -t CT, signifie que le certificat est approuvé pour être utilisé dans les serveurs et clients TLS. L'option -A ajoute un certificat existant dans une base de données de certificats. Si la base de données n'existe pas, elle sera créée. L'option -a permet l'utilisation du format ASCII pour les entrées ou les sorties et l'option -i transmet le fichier d'entrée certificate.pem à la commande.
    Veuillez consulter la page man de certutil(1) pour obtenir davantage d'options de ligne de commande.
  8. La base de données NSS doit être protégée par un mot de passe afin de garantir la sécurité de la clé privée.

    Exemple 12.4. Définir un mot de passe pour la base de données Mozilla NSS

    L'outil certutil peut être utilisé pour définir un mot de passe pour une base de données NSS comme suit :
    certutil -W -d /etc/httpd/nss-db-directory/
    Par exemple, pour la base de données par défaut, veuillez exécuter une commande en tant qu'utilisateur root, comme suit :
    ~]# certutil -W -d /etc/httpd/alias
    Enter Password or Pin for "NSS Certificate DB":
    Enter a password which will be used to encrypt your keys.
    The password should be at least 8 characters long,
    and should contain at least one non-alphabetic character.
    
    Enter new password: 
    Re-enter password: 
    Password changed successfully.
  9. Configurez mod_nss de manière à utiliser le jeton logiciel NSS interne en modifiant la ligne avec la directive NSSPassPhraseDialog, comme suit :
    ~]# vi /etc/httpd/conf.d/nss.conf
    NSSPassPhraseDialog file:/etc/httpd/password.conf
    Ceci sert à éviter la saisie manuelle de mots de passe pendant le démarrage système. Le jeton logiciel existe dans la base de données NSS, mais vous pouvez également posséder une clé physique contenant les certificats.
  10. Si le certificat du serveur SSL situé dans la base de données NSS est un certificat RSA, assurez-vous que le paramètre NSSNickname ne soit pas mis en commentaire et qu'il corresponde bien au nom affiché dans l'étape 4 ci-dessus :
    ~]# vi /etc/httpd/conf.d/nss.conf
    NSSNickname Server-Cert
    Si le certificat du serveur SSL situé dans la base de données NSS est un certificat ECC, assurez-vous que le paramètre NSSECCNickname ne soit pas mis en commentaire et qu'il corresponde bien au surnom affiché dans l'étape 4 ci-dessus :
    ~]# vi /etc/httpd/conf.d/nss.conf
    NSSECCNickname Server-Cert
    Assurez-vous que le paramètre NSSCertificateDatabase ne soit pas mis en commentaire et qu'il pointe vers le répertoire de la base de données NSS affiché dans l'étape 4 ou configuré dans l'étape 5 ci-dessus :
    ~]# vi /etc/httpd/conf.d/nss.conf
    NSSCertificateDatabase /etc/httpd/alias
    Remplacez /etc/httpd/alias par le chemin vers la base de données de certificats à utiliser.
  11. Créez le fichier /etc/httpd/password.conf en tant qu'utilisateur root :
    ~]# vi /etc/httpd/password.conf
    Ajoutez une ligne sous le format suivant :
    internal:password
    en remplaçant password par le mot de passe appliqué aux bases de données de sécurité NSS dans l'étape 6 ci-dessus.
  12. Veuillez appliquer l'appartenance et les permissions appopriées au fichier /etc/httpd/password.conf :
    ~]# chgrp apache /etc/httpd/password.conf
    ~]# chmod 640 /etc/httpd/password.conf
    ~]# ls -l /etc/httpd/password.conf
    -rw-r-----. 1 root apache 10 Dec  4 17:13 /etc/httpd/password.conf
  13. Pour configurer mod_nss de manière à utiliser le jeton logiciel NSS dans /etc/httpd/password.conf, veuillez modifier /etc/httpd/conf.d/nss.conf comme suit :
    ~]# vi /etc/httpd/conf.d/nss.conf
  14. Redémarrez le serveur Apache pour que les changements entrent en vigueur, comme décrit dans la Section 12.1.3.3, « Redémarrer le service »

Important

À cause de la vulnérabilité décrite sur POODLE: SSLv3 vulnerability (CVE-2014-3566), Red Hat recommande de désactiver SSL et d'utiliser TLSv1.1 ou TLSv1.2 uniquement. Une rétrocompatibilité peut être effectuée en utilisant TLSv1.0. De nombreux produits pris en charge par Red Hat ont la capacité d'utiliser le protocole SSLv2 ou SSLv3, ou de les activer par défaut. Cependant, l'utilisation de SSLv2 ou de SSLv3 est désormais fortement déconseillée.

12.1.9.1. Activer et désactiver SSL et TLS sur mod_nss

Pour activer et désactiver des versions particulières des protocoles SSL et TLS, veuillez le faire globalement en ajoutant la directive NSSProtocol dans la section « ## SSL Global Context » du fichier de configuration et en la supprimant partout ailleurs, ou modifiez l'entrée par défaut sous « # SSL Protocol » dans toutes les sections « VirtualHost ». Si vous ne le spécifiez pas dans la section VirtualHost par domaine, les paramètres hérités proviendront de la section globale. Pour vous assurer qu'une version du protocole est en cours de désactivation, l'administrateur doit uniquement spécifier NSSProtocol dans la section « SSL Global Context », ou bien dans toutes les sections VirtualHost par domaine.

Procédure 12.5. Désactiver tous les protocoles SSL et TLS sauf TLS 1 et ses versions supérieures dans mod_nss

Pour désactiver toutes les versions des protocoles SSL et TLS sauf TLS version 1 et ses versions supérieures, veuillez procéder comme suit :
  1. En tant qu'utilisateur root, ouvrez le fichier /etc/httpd/conf.d/nss.conf et recherchez toutes les instances de la directive NSSProtocol. Par défaut, le fichier de configuration contient une section qui ressemble à cela :
    ~]# vi /etc/httpd/conf.d/nss.conf
    #   SSL Protocol:sortie omise
    #   Since all protocol ranges are completely inclusive, and no protocol in the
    #   middle of a range may be excluded, the entry "NSSProtocol SSLv3,TLSv1.1"
    #   is identical to the entry "NSSProtocol SSLv3,TLSv1.0,TLSv1.1".
    NSSProtocol SSLv3,TLSv1.0,TLSv1.1
    Cette section se trouve dans la section VirtualHost.
  2. Modifiez la ligne NSSProtocol comme suit :
    #   SSL Protocol:
    NSSProtocol TLSv1.0,TLSv1.1
    Répétez cette action pour toutes les sections VirtualHost.
  3. Modifiez la ligne Listen 8443 comme suit :
    Listen 443
  4. Modifiez la ligne VirtualHost _default_:8443 par défaut comme suit :
    VirtualHost _default_:443
    Veuillez modifier toute autre section d'hôte virtuel qui n'est pas par défaut s'il en existe. Puis enregistrez et fermez le fichier.
  5. Vérifiez que toutes les occurrences de la directive NSSProtocol ont été modifiées comme suit :
    ~]# grep NSSProtocol /etc/httpd/conf.d/nss.conf
    #   middle of a range may be excluded, the entry "NSSProtocol SSLv3,TLSv1.1"
    #   is identical to the entry "NSSProtocol SSLv3,TLSv1.0,TLSv1.1".
    NSSProtocol TLSv1.0,TLSv1.1
    Cette étape est particulièrement importante si vous possédez plus d'une section VirtualHost.
  6. Redémarrez le démon Apache comme suit :
    ~]# service httpd restart
    Remarquez que toutes les sessions seront interrompues.

Procédure 12.6. Tester le statut des protocoles SSL et TLS dans mod_nss

Pour vérifier quelles versions de SSL et TLS sont activées ou désactivées dans mod_nss, veuillez utiliser la commande openssl s_client -connect. Installez le paquet openssl en tant qu'utilisateur root :
~]# yum install openssl
La commande openssl s_client -connect se trouve sous le format suivant :
openssl s_client -connect hostname:port -protocol
, où port correspond au port pour effectuer le test et protocol est la version du protocole à tester. Pour tester le serveur SSL exécuté localement, veuillez utiliser localhost comme nom d'hôte. Par exemple, pour tester le port par défaut pour des connexions HTTPS sécurisées, pour voir si SSLv3 est activé sur le port 443, exécutez la commande suivante :
  1. ~]# openssl s_client -connect localhost:443 -ssl3
    CONNECTED(00000003)
    3077773036:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:337:sortie omise
    New, (NONE), Cipher is (NONE)
    Secure Renegotiation IS NOT supported
    Compression: NONE
    Expansion: NONE
    SSL-Session:
        Protocol  : SSLv3
    sortie tronquée
    La sortie ci-dessus indique que la tentative de connexion a échoué et qu'aucun chiffrement n'a été négocié.
  2. ~]$ openssl s_client -connect localhost:443 -tls1
    CONNECTED(00000003)
    depth=1 C = US, O = example.com, CN = Certificate Shacksortie omise
    New, TLSv1/SSLv3, Cipher is AES128-SHA
    Server public key is 1024 bit
    Secure Renegotiation IS supported
    Compression: NONE
    Expansion: NONE
    SSL-Session:
        Protocol  : TLSv1sortie tronquée
    La sortie ci-dessus indique qu'aucun échec de tentative de connexion n'a eu lieu et qu'un ensemble de chiffrements a été négocié.
Les options de la commande openssl s_client sont documentées dans la page man de s_client(1).
Pour obtenir davantage d'informations sur la vulnérabilité SSLv3 et comment effectuer des tests pour la trouver, veuillez consulter l'article de la base de connaissances Red Hat POODLE: SSLv3 vulnerability (CVE-2014-3566).

12.1.10. Utiliser une clé existante et un certificat

Si vous avez créé au préalable une clé et un certificat, vous pouvez configurer le serveur SSL pour utiliser ces fichiers au lieu d'en générer de nouveaux. Il existe uniquement deux situations dans lesquelles cela n'est pas possible :
  1. Vous modifiez l'adresse IP ou le nom du domaine.
    Des certificats sont créés pour une paire adresse IP et nom de domaine particuliers. Si l'une de ces valeurs change, le certificat est invalide.
  2. Vous avez un certificat de VeriSign, et vous changez le logiciel du serveur.
    VeriSign, une autorité de certification largement utilisée, octroit des certificats pour un produit logiciel, une adresse IP, et un nom de domaine particulier. Modifier le produit logiciel rend le certificat invalide.
Dans les deux cas ci-dessus, vous devrez obtenir un nouveau certificat. Pour obtenir davantage d'informations sur ce sujet, veuillez consulter la Section 12.1.11, « Générer une nouvelle clé et un nouveau certificat ».
Si vous souhaitez utiliser une clé et un certificat existants, déplacez les fichiers correspondants sur les répertoires /etc/pki/tls/private/ et /etc/pki/tls/certs/, respectivement. Vous pouvez faire cela exécutant les commandes suivantes en tant qu'utilisateur root :
~]# mv key_file.key /etc/pki/tls/private/hostname.key
~]# mv certificate.crt /etc/pki/tls/certs/hostname.crt
Puis ajoutez les lignes suivante au fichier de configuration /etc/httpd/conf.d/ssl.conf :
SSLCertificateFile /etc/pki/tls/certs/hostname.crt
SSLCertificateKeyFile /etc/pki/tls/private/hostname.key
Pour charger la configuration mise à jour, redémarrez le service httpd comme décrit dans la Section 12.1.3.3, « Redémarrer le service ».

Exemple 12.5. Utiliser une clé et un certificat du serveur web sécurisé « Red Hat Secure Web Server »

~]# mv /etc/httpd/conf/httpsd.key /etc/pki/tls/private/penguin.example.com.key
~]# mv /etc/httpd/conf/httpsd.crt /etc/pki/tls/certs/penguin.example.com.crt

12.1.11. Générer une nouvelle clé et un nouveau certificat

Pour générer une nouvelle paire clé-certificat, le paquet crypto-utils doit être installé sur le système. Pour l'installer, veuillez saisir la commande suivante en tant qu'utilisateur root :
~]# yum install crypto-utils
Ce paquet fournit un ensemble d'outils pour générer et gérer des certificats SSL et des clés privées, et inclut genkey, l'utilitaire de génération de paires de clés « Red Hat Keypair Generation », qui vous guidera à travers le processus de génération de clés.

Important

Si le serveur possède déjà un certificat valide et que vous le remplacez par un nouveau certificat, veuillez spécifier un numéro de série différent. Ceci permet de vous assurer que les navigateurs clients soient notifiés de ce changement, mis à jour au sujet de ce nouveau certificat comme prévu, et qu'ils réussissent à accéder à la page. Pour créer un nouveau certificat avec un numéro de série personnalisé, en tant qu'utilisateur root, veuillez utiliser la commande suivante au lieu de genkey :
~]# openssl req -x509 -new -set_serial number -key hostname.key -out hostname.crt

Note

S'il existe déjà un fichier clé pour un nom d'hôte particulier dans votre système, genkey refusera de démarrer. Dans ce cas, veuillez supprimer le fichier existant en utilisant la commande suivante en tant qu'utilisateur root :
~]# rm /etc/pki/tls/private/hostname.key
Pour exécuter l'utilitaire, veuillez saisir la commande genkey en tant qu'utilisateur root, suivie du nom d'hôte approprié (par exemple, penguin.example.com) :
~]# genkey hostname
Pour terminer la création de la clé et du certificat, veuillez procéder aux étapes suivantes :
  1. Examinez les emplacements cibles dans lesquels la clé et le certificat seront stockés.
    Exécuter l'utilitaire genkey

    Figure 12.1. Exécuter l'utilitaire genkey

    Veuillez utiliser la touche Tab pour sélectionner le bouton Suivant, et appuyez sur Entrée pour passer à l'écran suivant.
  2. En utilisant les touches de flèches haut et bas, sélectionnez une taille de clé convenable. Remarquez que malgré qu'une clé de plus grande taille améliore la sécurité, celle-ci augmentera également le temps de réponse de votre serveur. L'organisme NIST recommande d'utiliser 2048 bits. Veuillez consulter le document NIST Special Publication 800-131A.
    Sélectionner la taille de la clé

    Figure 12.2. Sélectionner la taille de la clé

    Une fois terminé, veuillez utiliser la touche Tab pour sélectionner le bouton Suivant, et appuyez sur Entrée pour initier le processus de génération de bits aléatoire. Selon la taille de clé sélectionnée, ceci peut prendre longtemps.
  3. Décidez si vous souhaitez envoyer une requête de certificat à une autorité de certification.
    Générer une requête de certificat

    Figure 12.3. Générer une requête de certificat

    Utilisez la touche Tab pour sélectionner Oui afin de composer une requête de certificat, ou Non pour générer un certificat auto-signé. Puis appuyez sur Entrée pour confirmer votre choix.
  4. À l'aide de la barre d'espace, activez ([*]) ou désactivez ([ ]) le chiffrement de la clé privée.
    Chiffrer la clé privée

    Figure 12.4. Chiffrer la clé privée

    Veuillez utiliser la touche Tab pour sélectionner le bouton Suivant, et appuyez sur Entrée pour passer à l'écran suivant.
  5. Si vous avez activé le chiffrement de clé privée, veuillez saisir une phrase de passe convenable. Remarquez que pour des raisons de sécurité, celle-ci n'est pas affichée lorsque vous la saisissez, et doit faire 5 caractères au minimum.
    Saisir une phrase de passe

    Figure 12.5. Saisir une phrase de passe

    Veuillez utiliser la touche Tab pour sélectionner le bouton Suivant, et appuyez sur Entrée pour passer à l'écran suivant.

    Important

    Saisir la phrase de passe correctement est requis pour que le serveur démarre. Si vous la perdez, vous devrez générer une nouvelle clé et un nouveau certificat.
  6. Personnaliser les détails du certificat.
    Spécifier les informations du certificat

    Figure 12.6. Spécifier les informations du certificat

    Veuillez utiliser la touche Tab pour sélectionner le bouton Suivant, et appuyez sur Entrée pour terminer avec la génération de clé.
  7. Si vous avez activé la génération de requête de certificat, il vous sera demandé de l'envoyer à une autorité de certification.
    Instructions sur la manière d'envoyer une requête de certificat

    Figure 12.7. Instructions sur la manière d'envoyer une requête de certificat

    Appuyez sur Entrée pour retourner dans une invite shell.
Une fois généré, ajoutez les emplacements de la clé et du certificat au fichier de configuration /etc/httpd/conf.d/ssl.conf :
SSLCertificateFile /etc/pki/tls/certs/hostname.crt
SSLCertificateKeyFile /etc/pki/tls/private/hostname.key
Finalement, redémarrez le service httpd comme décrit dans la Section 12.1.3.3, « Redémarrer le service » afin que la configuration mise à jour soit chargée.

12.1.12. Configurez le pare-feu pour HTTP et HTTPS en utilisant la ligne de commande

Par défaut, Red Hat Enterprise Linux n'autorise pas le trafic HTTP et HTTPS. Pour autoriser le système à agir en tant que serveur web, veuillez utiliser les services firewalld pris en charge pour que le trafic HTTP et que le trafic HTTPS soient autorisés à passer à travers le pare-feu comme requis.
Pour autoriser HTTP en utilisant la ligne de commande, veuillez exécuter la commande suivante en tant qu'utilisateur root :
~]# firewall-cmd --add-service http
 success
Pour autoriser HTTPS en utilisant la ligne de commande, veuillez exécuter la commande suivante en tant qu'utilisateur root :
~]# firewall-cmd --add-service https
 success
Remarquez que ces changements ne persisteront pas après le prochain démarrage système. Pour rendre ces changements permanents sur le pare-feu, veuillez répéter les commandes en ajoutant l'option --permanent.

12.1.12.1. Vérifier l'accès réseau de HTTPS et de HTTPS entrant en utilisant la ligne de commande

Pour vérifier quels services le pare-feu est configuré à autoriser, veuillez exécuter la commande suivante sur la ligne de commande en tant qu'utilisateur root :
~]# firewall-cmd --list-all
public (default, active)
  interfaces: em1
  sources: 
  services: dhcpv6-client sshsortie tronquée
Dans cet exemple extrait d'une installation par défaut, le pare-feu est activé mais HTTP et HTTPS n'ont pas été autorisés à passer à travers.
Une fois les services de pare-feu HTTP et HTTP activés, la ligne services apparaîtra et sera similaire à ceci :
services: dhcpv6-client http https ssh
Pour obtenir des informations supplémentaires sur l'activation des services de pare-feu, ou sur l'ouverture et la fermeture de ports sur firewalld, veuillez consulter le Guide de sécurité Red Hat Enterprise Linux 7 .

12.1.13. Ressources supplémentaires

Pour en savoir plus sur le serveur Apache HTTP, veuillez consulter les ressources suivantes.

Documentation installée

  • httpd(8) — la page du manuel du service httpd contenant la liste complète de ses options de ligne de commande.
  • genkey(1) — la page du manuel de l'utilitaire genkey, fournie par le paquet crypto-utils.
  • apachectl(8) — la page du manuel de l'interface de contrôle du serveur HTTP Apache.

Documentation installable

  • http://localhost/manual/ — documentation officielle du serveur HTTP Apache avec la description complète de ses directives et modules disponibles. Remarquez que pour accéder à cette documentation, le paquet httpd-manual doit être installé, et le serveur web doit être en cours d'exécution.
    Avant d'accéder à la documentation, veuillez exécuter la commande suivante en tant qu'utilisateur root :
    ~]# yum install httpd-manual
    ~]# apachectl graceful

Documentation en ligne

  • http://httpd.apache.org/ — site web officiel du serveur HTTP Apache avec la documentation sur toutes les directives et tous les modules par défaut.
  • http://www.openssl.org/ — page d'accueil d'OpenSSL contenant davantage de documentation, une foire aux questions, des liens de listes de diffusion, ainsi que d'autres ressources utiles.
Red Hat logoGithubRedditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez leBlog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

© 2024 Red Hat, Inc.