26.6. Configuration d'un serveur Web sécurisé avec SSL

Lorsque des données sensibles, telles que des informations relatives aux cartes bancaires, sont transférées entre un serveur Web et un client, il est souhaitable d'utiliser une connexion sécurisée, codée avec authentification. mod_ssl fournit un codage renforcé en utilisant les protocoles SSL (secure sockets layer) et TLS (transport layer security) pour la communication HTTP entre un client et le serveur Web. Grâce à SSL/TSL, une connexion privée entre le serveur Web et le client est établie. L'intégrité des données est assurée, et le client et le serveur sont en mesure de s'authentifier mutuellement.

À cette fin, le serveur envoie un certificat SSL contenant des informations prouvant l'identité valide du serveur avant la réponse à toute requête vers une adresse URL. Cela garantit à son tour que le serveur est le seul point terminal correct pour la communication. De plus, le certificat génère une connexion codée entre client et serveur, capable de transporter des informations sans risque d'exposer du contenu sensible en texte brut.

mod_ssl n'implémente pas directement les protocoles SSL/TSL, mais agit comme interface entre Apache et une bibliothèque SSL. Dans SUSE Linux, la bibliothèque OpenSSL est utilisée. OpenSSL est installée automatiquement avec Apache.

L'effet le plus visible de l'utilisation de mod_ssl avec Apache est que les adresses URL portent le préfixe https:// et non http://.

26.6.1. Création d'un certificat SSL

Pour utiliser SSL/TSL avec le serveur Web, vous devez créer un certificat SSL. Ce certificat est nécessaire pour l'autorisation entre le serveur Web et le client, afin que chaque partie puisse identifier l'autre. Pour assurer l'intégrité du certificat, il doit être signé par une partie approuvée par chaque utilisateur.

Vous pouvez créer trois types de certificats : un certificat « fictif » à des fins de test uniquement, un certificat auto-signé pour un cercle défini d'utilisateurs qui vous font confiance, et un certificat signé par une autorité de certification indépendante et réputée.

La création d'un certificat s'effectue essentiellement en deux étapes. D'abord, une clé privée de l'autorité de certification est générée, puis le certificat du serveur est signé avec cette clé.

[Tip]pour plus d'informations

Pour en savoir plus sur les concepts et les définitions de SSL/TSL, reportez-vous à http://httpd.apache.org/docs/2.2/ssl/ssl_intro.html.

26.6.1.1. Création d'un certificat « fictif »

La génération d'un certificat fictif est simple. Il suffit d'appeler le script /usr/bin/gensslcert. Il crée ou remplace les fichiers suivants :

  • /etc/apache2/ssl.crt/ca.crt

  • /etc/apache2/ssl.crt/server.crt

  • /etc/apache2/ssl.key/server.key

  • /etc/apache2/ssl.csr/server.csr

Une copie de ca.crt est également placée dans /srv/www/htdocs/CA.crt pour le téléchargement.

[Important]Important

Un certificat fictif ne doit jamais être utilisé sur un système de production. Ne l'utilisez qu'à des fins de test.

26.6.1.2. Création d'un certificat signé automatiquement

Si vous configurez un serveur Web sécurisé pour un Intranet ou pour un cercle défini d'utilisateur, il peut être suffisant de signer un certificat avec votre propre autorité de certification.

La création d'un certificat auto-signé est un processus interactif en neuf étapes. Accédez au répertoire /usr/share/doc/packages/apache2 et exécutez la commande suivante : ./mkcert.sh make --no-print-directory /usr/bin/openssl /usr/sbin/ custom. Ne tentez pas d'exécuter cette commande à l'extérieur de ce répertoire. Le programme envoie une série d'invites, parmi lesquelles vous devez répondre à certaines.

Procédure 26.1. Création d'un certificat signé automatiquement avec mkcert.sh

  1. Choix de l'algorithme de signature utilisé pour les certificats

    Choisissez RSA (R, par défaut), car certains anciens navigateurs ont des problèmes avec DSA.

  2. Génération de la clé privée RSA pour l'autorité de certification (1 024 bits)

    Aucune interaction nécessaire.

  3. Génération de la demande de signature du certificat X.509 pour l'autorité de certification

    Créez ici le nom distinctif de l'autorité de certification. Vous devez répondre à quelques questions, et indiquer par exemple votre pays ou votre entreprise. Entrez des données valides, car tout ce que vous entrez ici s'affiche ensuite dans le certificat. Vous n'avez pas besoin de répondre à toutes les questions. Si l'une d'entres elles ne s'applique pas à vous ou si vous ne voulez pas répondre, utilisez « . ». Le nom commun est le nom CA. Choisissez un nom significatif, par exemple Mon entreprise CA.

  4. Génération du certificat X.509 pour l'autorité de certification signée automatiquement

    Choisissez la version de certificat 3 (par défaut).

  5. Génération de la clé privée RSA pour le SERVEUR (1 024 bits)

    Aucune interaction nécessaire.

  6. Génération de la demande de signature du certificat X.509 pour le SERVEUR

    Créez ici le nom distinctif de la clé du serveur. Les questions sont presque identiques à celles portant sur le nom distinctif de l'autorité de certification. Les données entrées ici s'appliquent au serveur Web et ne doivent pas nécessairement être identiques à celles de l'autorité de certification (par exemple, si le serveur se trouve ailleurs).

    [Important]sélection d'un nom commun

    Le nom commun que vous entrez ici doit être le nom d'hôte complet de votre serveur sécurisé (par exemple, www.exemple.com). Sinon, le navigateur émet un avertissement indiquant que le certificat ne correspond pas au serveur lors de l'accès au serveur Web.

  7. Génération du certificat X.509 signé par la propre autorité de certification

    Choisissez la version de certificat 3 (par défaut).

  8. Codage de la clé privée RSA de l'autorité de certification avec une phrase secrète pour la sécurité

    Il est vivement recommandé de coder la clé privée de l'autorité de certification avec un mot de passe. Vous devez donc choisir Y et entrer un mot de passe.

  9. Codage de la clé privée RSA du SERVEUR avec une phrase secrète pour la sécurité

    Le codage de la clé du serveur avec un mot de passe nécessite que vous entriez ce mot de passe chaque fois que vous démarrez le serveur Web. Il rend difficile le démarrage automatique du serveur à l'amorçage ou le redémarrage du serveur Web. Il est donc judicieux de répondre N à cette question. N'oubliez pas que votre clé n'est pas protégée lorsqu'elle n'est pas codée par mot de passe et vérifiez que seules les personnes autorisées ont accès à la clé.

    [Important]codage de la clé du serveur

    Si vous choisissez de coder la clé du serveur avec un mot de passe, augmentez la valeur de APACHE_TIMEOUT dans /etc/sysconfig/apache2. Sinon, vous n'avez pas assez de temps pour entrer la phrase secrète avant que la tentative de démarrage du serveur ne soit arrêtée.

La page de résultats du script présente la liste de certificats et des clés générés. Contrairement aux sorties du script, les fichiers n'ont pas été générés dans le répertoire local conf, mais dans les emplacements corrects sous /etc/apache2/.

La dernière étape consiste à copier le fichier de certificat de l'autorité de certification de /etc/apache2/ssl.crt/ca.crt vers un emplacement auquel vos utilisateurs peuvent accéder pour l'intégrer à la liste des autorités de certification connues et approuvées de leurs navigateurs Web. Sinon, un navigateur se plaint de ce qu'un certificat a été émis par une autorité inconnue. Le certificat est valide pendant un an.

[Important]certificats signés automatiquement

N'utilisez qu'un certificat auto-signé sur un serveur Web auquel accèdent des utilisateurs qui vous connaissent et vous font confiance en tant qu'autorité de certification. Il n'est pas recommandé d'utiliser ce type de certificat dans une boutique publique, par exemple.

26.6.1.3. Obtention d'un certificat signé officiel

Il existe plusieurs autorités de certification officielles qui signent vos certificats. Le certificat est signé par un tiers digne de confiance, qui peut être entièrement approuvé. Les serveurs Web sécurisés qui fonctionnent de façon publique ont généralement un certificat signé officiellement.

Les autorités de certification officielles les plus connues sont Thawte (http://www.thawte.com/) ou Verisign (www.verisign.com). Ces autorités de certification et d'autres sont déjà compilées dans tous les navigateurs, de sorte que les certificats signés par ces autorités de certification sont acceptés automatiquement par les navigateurs.

Lorsque vous demandez un certificat signé officiellement, vous n'envoyez pas de certificat à l'autorité de certification. À la place, vous envoyez une requête de signature de certificat (CSR). Pour créer une CSR, appelez le script /usr/share/ssl/misc/CA.sh -newreq.

Tout d'abord, le script demande un mot de passe avec lequel la CSR doit être codée. Vous devez ensuite entrer un nom distinctif. Vous devez répondre à quelques questions, et indiquer par exemple votre pays ou votre entreprise. Entrez des données ; tout ce que vous entrez ici s'affiche ensuite dans le certificat et est vérifié. Vous n'avez pas besoin de répondre à toutes les questions. Si l'une d'entres elles ne s'applique pas à vous ou si vous ne voulez pas répondre, utilisez « . ». Le nom commun est le nom CA. Choisissez un nom significatif, par exemple Mon entreprise CA. Enfin, un mot de passe de vérification et un autre nom de société doivent être entrés.

Vous trouverez la CSR dans le répertoire à partir duquel vous avez appelé le script. Le fichier s'appelle newreq.pem.

26.6.2. Configuration d'Apache avec SSL

Le port par défaut pour les requêtes SSL et TLS du côté du serveur Web est 443. Il n'y a pas de conflit entre une écoute « normale » Apache sur le port 80 et une écoute Apache de type SSL/TLS sur le port 443. En fait, HTTP et HTTPS peuvent être exécutés avec la même instance Apache. Des hôtes virtuels distincts sont généralement utilisés pour envoyer les requêtes vers le port 80 et le port 443 afin de séparer les serveurs virtuels.

[Important]configuration du pare-feu

N'oubliez pas d'ouvrir le pare-feu pour Apache avec SSL sur le port 443. Cela peut s'effectuer avec YaST comme indiqué à Section 4.1.4.1, « Configuration avec YaST ».

Pour utiliser SSL, il doit être activé dans la configuration globale du serveur. Ouvrez /etc/sysconfig/apache2 dans un éditeur et recherchez APACHE_MODULES. Ajoutez « ssl » à la liste des modules s'il n'est pas encore présent (mod_ssl est activé par défaut). Recherchez ensuite APACHE_SERVER_FLAGS et ajoutez « SSL ». Si vous avez choisi de coder votre certificat de serveur par un mot de passe, vous devez également augmenter la valeur de APACHE_TIMEOUT, afin d'avoir assez de temps pour entrer la phrase secrète lorsque Apache démarre. Redémarrez le serveur pour activer ces changements. Le rechargement n'est pas suffisant.

Le répertoire de configuration de l'hôte virtuel contient un modèle /etc/apache2/vhosts.d/vhost-ssl.template avec des directives SSl spécifiques qui sont documentées de façon complète. Reportez-vous à Section 26.2.1.2, « Configuration de l'hôte virtuel » pour la configuration générale de l'hôte virtuel.

Pour commencer, il doit être suffisant de régler les valeurs des directives suivantes :

  • DocumentRoot

  • ServerName

  • ServerAdmin

  • ErrorLog

  • TransferLog

[Important]hôtes virtuels à base de nom et SSL

Il n'est pas possible d'exécuter plusieurs hôtes virtuels de type SSL sur un serveur avec une seule adresse IP. Les utilisateurs qui se connectent à ce type de configuration reçoivent un message d'avertissement indiquant que le certificat ne correspond pas au nom du serveur chaque fois qu'ils visitent l'adresse URL. Une adresse IP ou un port séparés sont nécessaires pour chaque domaine SSL afin de réaliser la communication basée sur un certificat SSL valide.