+SSL/TLS + + Chiffrement SSL/TLS fort: foire aux questions + +

+
Le sage n'apporte pas de bonnes réponses, il pose les bonnes questions
+
-- Claude Levi-Strauss
+ +

Ce chapitre propose une Foire Aux Questions (FAQ) et les réponses +correspondantes selon la tradition populaire USENET. La plupart des questions +ont été posés dans le Newsgroup +comp.infosystems.www.servers.unix ou dans la liste de diffusion du +support mod_ssl modssl-users@modssl.org. Elles ont été rassemblées ici afin +de ne pas avoir à répondre encore et encore aux mêmes questions.

+ +

Vous êtes prié de lire ce chapitre au moins une fois avant d'installer +mod_ssl, ou d'y rechercher la solution à votre problème avant de le soumettre +à l'auteur.

+ +

A propos de mod_ssl +

Quel est l'historique de mod_ssl ?
mod_ssl et l'arrangement Wassenaar

+ +

Quel est l'historique de mod_ssl ? +

Le paquet mod_ssl version 1 a été créé en avril 1998 par Ralf S. Engelschall par portage des + patches sources 1.17 du module Apache-SSL de Ben Laurie pour Apache 1.2.6 vers + Apache 1.3b6. Il fut ensuite entièrement réassemblé pour Apache 1.3.0 en + fusionnant l'ancien mod_ssl 1.x avec le nouveau Apache-SSL 1.18 pour cause + de conflits avec le cycle de développement du module de Ben Laurie. Depuis + lors, mod_ssl vole de ses propres ailes sous le nom de mod_ssl v2. La + première version distribuée au public fut mod_ssl 2.0.0 à partir du + 10 août 1998.

+ +

Quand les restrictions à l'exportation des US sur les logiciels de + cryptographie furent assouplis, mod_ssl devint partie + intégrante du serveur HTTP Apache à partir de la distribution de + Apache httpd 2.

+ +

mod_ssl est-il concerné par +l'arrangement Wassenaar ? +

Tout d'abord, examinons en quoi consiste Wassenaar et son +Arrangement sur le contrôle de l'exportation des armes conventionnelles +et le double usage des biens et des technologies : c'est un +règlement international, établi en 1995, qui contrôle le commerce des armes +conventionnelles et le double usage des biens et des technologies. Il +remplace le règlement précédent CoCom. Pour plus de détails sur +l'arrangement et ses signataires, se référer à http://www.wassenaar.org/.

+ +

En bref, l'Arrangement Wassenaar a pour but d'empêcher la constitution + de puissances militaires qui pourraient menacer la sécurité et la + stabilité régionales et internationales. L'Arrangement Wassenaar contrôle + l'exportation de logiciels de cryptographie comme biens à double usage, + c'est à dire ayant des applications à la fois militaires et civiles. + Cependant, l'Arrangement Wassenaar exempte les logiciels grand public et + les logiciels libres du contrôle à l'exportation.

+ +

Dans l'actuelle List of Dual Use Goods and Technologies And + Munitions, sous GENERAL SOFTWARE NOTE (GSN), il est écrit + La liste ne prend pas en compte les "logiciels" qui sont soit : + 1. [...] 2. "dans le domaine public". Et sous + DEFINITIONS OF TERMS USED IN THESE LISTS, In the public + domain est défini comme "technologie" ou "logiciel" qui a été + fourni sans restrictions à propos de sa redistribution ultérieure. Note: + les restrictions de Copyright ne privent pas la "technologie" ou le + "logiciel" de leur appartenance au "domaine public".

+ +

Ainsi, selon l'Arrangement Wassenaar et sa List of Dual Use Goods and + Technologies And Munitions List, mod_ssl et OpenSSL appartiennent au + domaine public, et ne sont donc pas concernés + par les dispositions de l'arrangement.

+ +

+ + +

Installation +

Pourquoi le démarrage d'Apache provoque-t-il des +erreurs de permission en rapport avec SSLMutex ?
Pourquoi mod_ssl s'arrête-t-il avec l'erreur +"Failed to generate temporary 512 bit RSA private key" au démarrage +d'Apache ?

+ +

Pourquoi le démarrage d'Apache provoque-t-il des +erreurs de permission en rapport avec SSLMutex ? +

Des erreurs telles que ``mod_ssl: Child could not open + SSLMutex lockfile /opt/apache/logs/ssl_mutex.18332 (avec l'erreur + système qui suit) [...] System: Permission denied (errno: 13)'' + sont souvent provoquées par des permissions trop restrictives sur les + répertoires parents. Assurez-vous que tous les répertoires + parents (ici /opt, /opt/apache et + /opt/apache/logs) ont le bit x positionné au moins pour + l'UID sous lequel les processus enfants d'Apache s'exécutent (voir la + directive User).

+ +

Pourquoi mod_ssl s'arrête-t-il avec l'erreur +"Failed to generate temporary 512 bit RSA private key" au démarrage +d'Apache ? +

Pour fonctionner correctement, les logiciels de cryptographie ont + besoin d'une source de données aléatoires. De nombreux systèmes + d'exploitation libres proposent un "périphérique source d'entropie" + qui fournit ce service (il se nomme en général + /dev/random). Sur d'autres systèmes, les applications + doivent amorcer manuellement + le Générateur de Nombres Pseudo-Aléatoires d'OpenSSL + (Pseudo Random Number Generator -PRNG) à l'aide de données appropriées + avant de générer des clés ou d'effectuer un chiffrement à clé + publique. Depuis la version 0.9.5, les fonctions d'OpenSSL qui nécessitent + des données aléatoires provoquent une erreur si le PRNG n'a pas été amorcé + avec une source de données aléatoires d'au moins 128 bits.

Pour éviter cette erreur, mod_ssl doit fournir + suffisamment d'entropie au PRNG pour lui permettre de fonctionner + correctement. Ce niveau d'entropie est défini par la directive + SSLRandomSeed.

+ + +

Configuration +

Peut-on faire cohabiter HTTP et HTTPS sur le même +serveur ?
Quel port HTTPS utilise-t-il ?
Comment s'exprimer en langage HTTPS à des fins +de test ?
Pourquoi la communication se bloque-t-elle lorsque je +me connecte à mon serveur Apache configuré pour SSL ?
Pourquoi, lorsque je tente d'accéder en HTTPS à mon +serveur Apache+mod_ssl fraîchement installé, l'erreur ``Connection Refused'' +s'affiche-t-elle ?
Pourquoi les variables SSL_XXX +ne sont-elles pas disponibles dans mes scripts CGI et SSI ?
Comment puis-je basculer entre les protocoles HTTP et +HTTPS dans les hyperliens relatifs ?

+ +

Peut-on faire cohabiter HTTP et HTTPS sur le même +serveur ? +

Oui. HTTP et HTTPS utilisent des ports différents (HTTP écoute le port + 80 et HTTPS le port 443), si bien qu'il n'y a pas de conflit direct entre + les deux. Vous pouvez soit exécuter deux instances séparées du serveur, + chacune d'entre elles écoutant l'un de ces ports, soit utiliser l'élégante + fonctionnalité d'Apache que constituent les hôtes virtuels pour créer + deux serveurs virtuels gérés par la même instance d'Apache - le + premier serveur répondant en HTTP aux requêtes sur le port 80, + le second répondant en HTTPS aux requêtes sur le port + 443.

+ +

Quel port HTTPS utilise-t-il ? +

Vous pouvez associer le protocole HTTPS à n'importe quel port, mais le port +standard est le port 443, que tout navigateur compatible HTTPS va utiliser par +défaut. Vous pouvez forcer votre navigateur à utiliser un port différent en le +précisant dans l'URL. Par exemple, si votre serveur est configuré pour +servir des pages en HTTPS sur le port 8080, vous pourrez y accéder par +l'adresse https://example.com:8080/.

+ +

Comment s'exprimer en langage HTTPS à des fins +de test ? +

Alors que vous utilisez simplement

+ + $ telnet localhost 80
+ GET / HTTP/1.0 + +

pour tester facilement Apache via HTTP, les choses ne sont pas si + simples pour HTTPS à cause du protocole SSL situé entre TCP et HTTP. + La commande OpenSSL s_client vous permet cependant + d'effectuer un test similaire via HTTPS :

+ + $ openssl s_client -connect localhost:443 -state -debug
+ GET / HTTP/1.0 + +

Avant la véritable réponse HTTP, vous recevrez des informations + détaillées à propos de l'établissement de la connexion SSL. Si vous + recherchez un client en ligne de commande à usage plus général qui comprend + directement HTTP et HTTPS, qui peut effectuer des opérations GET et POST, + peut utiliser un mandataire, supporte les requêtes portant sur une partie + d'un fichier (byte-range), etc..., vous devriez vous tourner vers + l'excellent outil cURL. Grâce à lui, + vous pouvez vérifier si Apache répond correctement aux requêtes via + HTTP et HTTPS comme suit :

+ + $ curl http://localhost/
+ $ curl https://localhost/ +

+ +

Pourquoi la communication se bloque-t-elle lorsque je +me connecte à mon serveur Apache configuré pour SSL ? +

Ceci peut arriver si vous vous connectez à un serveur HTTPS (ou à +un serveur virtuel) via HTTP (par exemple, en utilisant +http://example.com/ au lieu de https://example.com). +Cela peut aussi arriver en essayant de vous connecter via HTTPS à un +serveur HTTP (par exemple, en utilisant https://example.com/ +avec un serveur qui ne supporte pas HTTPS, ou le supporte, mais sur un +port non standard). Assurez-vous que vous vous connectez bien à un +serveur (virtuel) qui supporte SSL.

+ +

Pourquoi, lorsque je tente d'accéder en HTTPS à mon +serveur Apache+mod_ssl fraîchement installé, l'erreur ``Connection Refused'' +s'affiche-t-elle ? +

Une configuration incorrecte peut provoquer ce type d'erreur. +Assurez-vous que vos directives Listen s'accordent avec vos directives + VirtualHost. Si + l'erreur persiste, recommencez depuis le début en restaurant la + configuration par défaut fournie parmod_ssl.

+ +

Pourquoi les variables <code>SSL_XXX</code> +ne sont-elles pas disponibles dans mes scripts CGI et SSI ? +

Assurez-vous que la directive ``SSLOptions +StdEnvVars'' est +bien présente dans le contexte de vos requêtes CGI/SSI.

+ +

+Comment puis-je basculer entre les protocoles HTTP et +HTTPS dans les hyperliens relatifs ? +

Normalement, pour basculer entre HTTP et HTTPS, vous devez utiliser des +hyperliens pleinement qualifiés (car vous devez modifier le schéma de l'URL). +Cependant, à l'aide du module mod_rewrite, vous pouvez +manipuler des hyperliens relatifs, pour obtenir le même effet.

+ + RewriteEngine on
+ RewriteRule ^/(.*):SSL$ https://%{SERVER_NAME}/$1 [R,L]
+ RewriteRule ^/(.*):NOSSL$ http://%{SERVER_NAME}/$1 [R,L] + + +

Ce jeu de règles rewrite vous permet d'utiliser des hyperliens de la + forme <a href="document.html:SSL"> pour passer en HTTPS + dans les liens relatifs. (Remplacez SSL par NOSSL pour passer en HTTP.)

+ + +

Certificats +

Qu'est-ce qu'un clé privée RSA, un certificat, +une demande de signature de certificat (CSR) ?
Y a-t-il une différence au démarrage entre un serveur +Apache non SSL et un serveur Apache supportant SSL ?
Comment créer un certificat auto-signé SSL à des +fins de test ?
Comment créer un vrai certificat SSL ?
Comment créer et utiliser sa propre Autorité de +certification (CA) ?
Comment modifier le mot de passe +de ma clé privée ?
Comment démarrer Apache sans avoir à entrer de +mot de passe ?
Comment vérifier si une clé privée correspond bien +à son certificat ?
Pour quelle raison une connexion échoue-t-elle avec +l'erreur "alert bad certificate" ?
Pourquoi ma clé privée de 2048 bits ne +fonctionne-t-elle pas ?
Pourquoi l'authentification des clients ne +fonctionne-t-elle plus après une mise à jour de SSLeay version 0.8 +vers la version 0.9 ?
Comment convertir un certificat du format PEM +au format DER ?
Pourquoi ne trouve-t-on pas les programmes +getca ou getverisign mentionnés par Verisign +pour installer un certificat Verisign ?
Puis-je utiliser la fonctionnalité "Cryptographie Transmise +par Serveur" (Server Gated Cryptography - SGC), aussi connue sous le nom +d'Identifiant Global Verisign (Verisign Global ID) avec mod_ssl ?
Pourquoi les navigateurs se plaignent-ils de ne pas pouvoir +vérifier mon certificat de serveur Verisign Global ID ?

+ +

Qu'est-ce qu'un clé privée RSA, un certificat, +une demande de signature de certificat (CSR) ? +

Un fichier de clé privée RSA est un fichier numérique que vous pouvez +utiliser pour déchiffrer des messages que l'on vous a envoyés. Il a son +pendant à caractère public que vous pouvez distribuer (par le biais de votre +certificat), ce qui permet aux utilisateurs de chiffrer les messages qu'ils +vous envoient.

Une Demande de Signature de Certificat (CSR) est un fichier numérique + qui contient votre clé publique et votre nom. La CSR doit être envoyée à + une Autorité de Certification (CA), qui va la convertir en vrai certificat + en la signant.

Un certificat contient votre clé publique RSA, votre nom, le nom + de la CA, et est signé numériquement par cette dernière. Les navigateurs + qui reconnaissent la CA peuvent vérifier la signature du certificat, et + ainsi en extraire votre clé publique RSA. Ceci leur permet de vous envoyer + des messages chiffrés que vous seul pourrez déchiffrer.

Se référer au chapitre Introduction + pour une description générale du protocole SSL.

+ +

Y a-t-il une différence au démarrage entre un serveur +Apache non SSL et un serveur Apache supportant SSL ? +

Oui. En général, avec ou sans mod_ssl intégré, le démarrage +d'Apache ne présente pas de différences. Cependant, si votre fichier de clé +privée SSL possède un mot de passe, vous devrez le taper au démarrage +d'Apache.

+ +

Devoir entrer manuellement le mot de passe au démarrage du serveur peut + poser quelques problèmes - par exemple, quand le serveur est démarré au + moyen de scripts au lancement du système. Dans ce cas, vous pouvez suivre + les étapes ci-dessous pour supprimer le + mot de passe de votre clé privée. Gardez à l'esprit qu'agir ainsi augmente + les risques de sécurité - agissez avec précaution !

+ +

Comment créer un certificat auto-signé SSL à des +fins de test ? +

Vérifiez qu'OpenSSL est installé et l'exécutable openssl dans votre + PATH.
+
+
Exécuter la commande suivante pour créer les fichiers + server.key et server.crt :
+ $ openssl req -new -x509 -nodes -out server.crt + -keyout server.key
+ Ces fichiers seront utilisés comme suit dans votre + httpd.conf : +
```
+             SSLCertificateFile    /chemin/vers/server.crt
+             SSLCertificateKeyFile /chemin/vers/server.key
+	
```
+
Il est important de savoir que le fichier server.key n'a + pas de mot de passe. Pour ajouter un mot de passe à la clé, vous + devez exécuter la commande suivante et confirmer le mot de passe comme + demandé.
+
$ openssl rsa -des3 -in server.key -out + server.key.new
+ $ mv server.key.new server.key
+ Sauvegardez le fichier server.key ainsi que son mot de + passe en lieu sûr. +

+ +

Comment créer un vrai certificat SSL ? +

Voici la marche à suivre pas à pas :

Assurez-vous qu'OpenSSL est bien installé et dans votre PATH. +
+
+
Créez une clé privée RSA pour votre serveur Apache + (elle sera au format PEM et chiffrée en Triple-DES):
+
+ $ openssl genrsa -des3 -out server.key 1024
+
+ Enregistrez le fichier server.key et le mot de passe + éventuellement défini en lieu sûr. + Vous pouvez afficher les détails de cette clé privée RSA à l'aide de la + commande :
+ +
+ $ openssl rsa -noout -text -in server.key
+
+ Si nécessaire, vous pouvez aussi créer une version PEM non chiffrée + (non recommandé) de clé privée RSA avec :
+
+ $ openssl rsa -in server.key -out server.key.unsecure
+
+ +
Créez une Demande de signature de Certificat (CSR) à l'aide de la + clé privée précédemment générée (la sortie sera au format PEM):
+
+ $ openssl req -new -key server.key -out server.csr
+
+ Vous devez entrer le Nom de Domaine Pleinement Qualifié + ("Fully Qualified Domain Name" ou FQDN) de votre serveur lorsqu'OpenSSL + vous demande le "CommonName", c'est à dire que si vous générez une CSR + pour un site web auquel on accèdera par l'URL + https://www.foo.dom/, le FQDN sera "www.foo.dom". Vous + pouvez afficher les détails de ce CSR avec :
+ +
+ $ openssl req -noout -text -in server.csr
+
+
Vous devez maintenant envoyer la CSR à une Autorité de Certification + (CA), afin que cette dernière puisse la signer. Une fois la CSR signée, + vous disposerez d'un véritable certificat que vous pourrez utiliser avec + Apache. Vous pouvez faire signer votre CSR par une CA commerciale ou par + votre propre CA.
+ Les CAs commerciales vous demandent en général de leur envoyer la CSR + par l'intermédiaire d'un formulaire web, de régler le montant de la + signature, puis vous envoient un certificat signé que vous pouvez + enregistrer dans un fichier server.crt. + + Pour plus de détails sur la manière de créer sa propre CA, et de + l'utiliser pour signer une CSR, voir ci-dessous.
+ + Une fois la CSR signée, vous pouvez afficher les détails du certificat + comme suit :
+
+ $ openssl x509 -noout -text -in server.crt
+ +
Vous devez maintenant disposer de deux fichiers : + server.key et server.crt. Ils sont précisés dans + votre fichier httpd.conf comme suit : +
```
+       SSLCertificateFile    /chemin/vers/server.crt
+       SSLCertificateKeyFile /chemin vers/server.key
+       
```
+ Le fichier server.csr n'est plus nécessaire. +

+ +

Comment créer et utiliser sa propre Autorité de +certification (CA) ? +

La solution la plus simple consiste à utiliser les scripts + CA.sh ou CA.pl fournis avec OpenSSL. De + préférence, utilisez cette solution, à moins que vous ayez de bonnes + raisons de ne pas le faire. Dans ce dernier cas, vous pouvez créer un + certificat auto-signé comme suit :

+ +

Créez une clé privée RSA pour votre serveur + (elle sera au format PEM et chiffrée en Triple-DES) :
+
+ $ openssl genrsa -des3 -out server.key 1024
+
+ Sauvegardez le fichier host.key et le mot de passe + éventuellement défini en lieu sûr. + Vous pouvez afficher les détails de cette clé privée RSA à l'aide de la + commande :
+ $ openssl rsa -noout -text -in server.key
+
+ Si nécessaire, vous pouvez aussi créer une version PEM non chiffrée + (non recommandé) de cette clé privée RSA avec :
+
+ $ openssl rsa -in server.key -out server.key.unsecure
+
+
Créez un certificat auto-signé (structure X509) à l'aide de la clé RSA + que vous venez de générer (la sortie sera au format PEM) :
+
+ $ openssl req -new -x509 -nodes -sha1 -days 365 + -key server.key -out server.crt
+
+ Cette commande signe le certificat du serveur et produit un fichier + server.crt. Vous pouvez afficher les détails de ce + certificat avec :
+
+ $ openssl x509 -noout -text -in server.crt
+
+

+ +

Comment modifier le mot de passe +de ma clé privée ? +

Vous devez simplement lire la clé avec l'ancien mot de passe et la +réécrire en spécifiant le nouveau mot de passe. Pour cela, vous pouvez +utiliser les commandes suivantes :

+ + +

$ openssl rsa -des3 -in server.key -out server.key.new
+ $ mv server.key.new server.key

+ +

La première fois qu'il vous est demandé un mot de passe PEM, vous + devez entrer l'ancien mot de passe. Ensuite, on vous demandera d'entrer + encore un mot de passe - cette fois, entrez le nouveau mot de passe. Si on + vous demande de vérifier le mot de passe, vous devrez entrer le nouveau + mot de passe une seconde fois.

+ +

Comment démarrer Apache sans avoir à entrer de +mot de passe ? +

L'apparition de ce dialogue au démarrage et à chaque redémarrage provient +du fait que la clé privée RSA contenue dans votre fichier server.key est +enregistrée sous forme chiffrée pour des raisons de sécurité. Le +déchiffrement de ce fichier nécessite un mot de passe, afin de pouvoir être +lu et interprété. Cependant, La suppression du mot de passe diminue le niveau de +sécurité du serveur - agissez avec précautions !

Supprimer le chiffrement de la clé privée RSA (tout en conservant une + copie de sauvegarde du fichier original) :
+
+ $ cp server.key server.key.org
+ $ openssl rsa -in server.key.org -out server.key
+ +
+
Assurez-vous que le fichier server.key n'est lisible que par root :
+
+ $ chmod 400 server.key
+
+

+ +

Maintenant, server.key contient une copie non chiffrée de + la clé. Si vous utilisez ce fichier pour votre serveur, il ne vous + demandera plus de mot de passe. CEPENDANT, si quelqu'un arrive à obtenir + cette clé, il sera en mesure d'usurper votre identité sur le réseau. + Vous DEVEZ par conséquent vous assurer que seuls root ou le serveur web + peuvent lire ce fichier (de préférence, démarrez le serveur web sous + root et faites le s'exécuter sous un autre utilisateur, en n'autorisant + la lecture de la clé que par root).

+ +

Une autre alternative consiste à utiliser la directive + ``SSLPassPhraseDialog exec:/chemin/vers/programme''. Gardez + cependant à l'esprit que ce n'est bien entendu ni plus ni moins + sécurisé.

+ +

Comment vérifier si une clé privée correspond bien +à son certificat ? +

Une clé privée contient une série de nombres. Deux de ces nombres forment la +"clé publique", les autres appartiennent à la "clé privée". Les bits de la +"clé publique" sont inclus quand vous générez une CSR, et font par +conséquent partie du certificat associé.

Pour vérifier que la clé publique contenue dans votre certificat + correspond bien à la partie publique de votre clé privée, il vous suffit + de comparer ces nombres. Pour afficher le certificat et la clé, + utilisez cette commande :

+ +

$ openssl x509 -noout -text -in server.crt
+ $ openssl rsa -noout -text -in server.key

+ +

Les parties `modulus' et `public exponent' doivent être identiques dans + la clé et le certificat. Comme le `public exponent' est habituellement + 65537, et comme il est difficile de vérifier visuellement que les nombreux + nombres du `modulus' sont identiques, vous pouvez utiliser l'approche + suivante :

+ +

$ openssl x509 -noout -modulus -in server.crt | openssl md5
+ $ openssl rsa -noout -modulus -in server.key | openssl md5

+ +

Il ne vous reste ainsi que deux nombres relativement courts à comparer. + Il est possible, en théorie que ces deux nombres soient les mêmes, sans que + les nombres du modulus soient identiques, mais les chances en sont infimes.

Si vous souhaitez vérifier à quelle clé ou certificat appartient une CSR + particulière, vous pouvez effectuer le même calcul + sur la CSR comme suit :

+ +

$ openssl req -noout -modulus -in server.csr | openssl md5

+ +

>Pour quelle raison une connexion échoue-t-elle avec +l'erreur "alert bad certificate" ? +

Les erreurs du type OpenSSL: error:14094412: SSL + routines:SSL3_READ_BYTES:sslv3 alert bad certificate dans le fichier + journal de SSL sont souvent causées par un navigateur qui ne sait pas + manipuler le certificat ou la clé privée du serveur. Par exemple, + Netscape Navigator 3.x ne reconnaît pas une clé RSA dont la longueur + est différente de 1024 bits.

+ +

Pourquoi ma clé privée de 2048 bits ne +fonctionne-t-elle pas ? +

La longueur des clés privées pour SSL doit être de 512 ou 1024 bits, pour +des raison de compatibilité avec certains navigateurs. Une longueur de 1024 +bits est recommandée car des clés d'une longueur supérieure sont incompatibles +avec certaines versions de Netscape Navigator et Microsoft Internet Explorer, +ainsi qu'avec d'autres navigateurs qui utilisent le kit de chiffrement +BSAFE de RSA.

+ +

Pourquoi l'authentification des clients ne +fonctionne-t-elle plus après une mise à jour de SSLeay version 0.8 +vers la version 0.9 ? +

Les certificats de CA situés dans le chemin que vous avez +défini à l'aide de SSLCACertificatePath sont localisés par +SSLeay au moyen de liens symboliques représentant l'empreinte du certificat +(hash symlinks). Ces empreintes sont générées à l'aide de la commande +`openssl x509 -noout -hash'. Cependant, SSLeay 0.8 et 0.9 +utilisent des algorithmes différents pour calculer l'empreinte d'un +certificat. Vous devrez supprimer les anciens liens symboliques et en créer +de nouveau après la mise à jour. Utilisez le Makefile fourni par +mod_ssl.

+ +

Comment convertir un certificat du format PEM +au format DER ? +

Le format des certificats par défaut pour SSLeay/OpenSSL est le format PEM, +qui est tout simplement un format DER codé en Base64, avec des lignes +d'en-têtes et des annotations. Certaines applications, comme +Microsoft Internet Explorer, ont besoin d'un certificat au format DER de base. +Vous pouvez convertir un fichier PEM cert.pem en son équivalent +au format DER cert.der à l'aide de la commande suivante : +$ openssl x509 -in cert.pem -out cert.der +-outform DER

+ +

Pourquoi ne trouve-t-on pas les programmes +<code>getca</code> ou <code>getverisign</code> mentionnés par Verisign +pour installer un certificat Verisign ? +

Verisign n'a jamais fourni d'instructions spécifiques à Apache+mod_ssl. +Les instructions fournies concernent Stronghold de C2Net (un serveur +commercial basé sur Apache avec support SSL).

Pour installer votre certificat, il vous suffit d'enregistrer le +certificat dans un fichier, et de fournir le nom de ce fichier à la directive +SSLCertificateFile. Vous devez aussi +fournir le nom du fichier contenant la clé privée. Pour plus de détails, voir +la directive SSLCertificateKeyFile.

+ +

Puis-je utiliser la fonctionnalité "Cryptographie Transmise +par Serveur" (Server Gated Cryptography - SGC), aussi connue sous le nom +d'Identifiant Global Verisign (Verisign Global ID) avec mod_ssl ? +

Oui. mod_ssl supporte SGC depuis la version 2.1. Aucune +configuration spécifique n'est nécessaire - utilisez simplement le +Global ID comme certificat de serveur. La mise à niveau des clients +est gérée automatiquement par mod_ssl à l'exécution.

+ +

Pourquoi les navigateurs se plaignent-ils de ne pas pouvoir +vérifier mon certificat de serveur Verisign Global ID ? +

Verisign utilise un certificat de CA intermédiaire entre le certificat +de CA racine (installé dans les navigateurs) et le certificat du serveur (que +vous avez installé sur le serveur). Verisign a dû vous envoyer ce certificat +de CA additionnel. Dans la négative, réclamez-le. Ensuite, installez ce +certificat à l'aide de la directive +SSLCertificateChainFile. Ceci assure +que le certificat de CA intermédiaire est bien envoyé au navigateur, ce qui +comble le vide dans la chaîne de certification.

+ + +

Le protocole SSL +

Pourquoi de nombreuses et aléatoires erreurs de +protocole SSL apparaissent-elles en cas de forte charge du serveur ?
Pourquoi la charge de mon serveur est-elle plus +importante depuis qu'il sert des ressources chiffrées en SSL ?
Pourquoi les connexions en HTTPS à mon serveur +prennent-elles parfois jusqu'à 30 secondes pour s'établir ?
Quels sont les algorithmes de chiffrement +supportés par mod_ssl ?
Pourquoi une erreur ``no shared cipher'' apparaît-elle +quand j'essaie d'utiliser un algorithme de chiffrement +Diffie-Hellman anonyme (ADH) ?
Pourquoi une erreur ``no shared cipher'' +apparaît-elle lorsqu'on se connecte à mon serveur +fraîchement installé ?
Pourquoi ne peut-on pas utiliser SSL avec des hôtes +virtuels identifiés par un nom et non par une adresse IP ?
Pourquoi n'est-il pas possible d'utiliser +l'hébergement virtuel basé sur le nom d'hôte +pour différencier plusieurs hôtes virtuels ?
Comment mettre en oeuvre la compression SSL ?
Lorsque j'utilise l'authentification de base sur HTTPS, +l'icône de verrouillage des navigateurs Netscape reste ouverte quand la boîte +de dialogue d'authentification apparaît. Cela signifie-t-il que les utilisateur +et mot de passe sont envoyés en clair ?
Pourquoi des erreurs d'entrée/sortie apparaissent-elles +lorsqu'on se connecte à un serveur Apache+mod_ssl avec +Microsoft Internet Explorer (MSIE) ?
Pourquoi des erreurs d'entrée/sortie apparaissent-elles, ou +le message "Netscape a reçu des données erronées du serveur" s'affiche-t-il, +lorsqu'on se connecte à un serveur Apache+mod_ssl +avec Netscape Navigator ?

+ +

Pourquoi de nombreuses et aléatoires erreurs de +protocole SSL apparaissent-elles en cas de forte charge du serveur ? +

Ce problème peut avoir plusieurs causes, mais la principale réside dans le +cache de session SSL défini par la directive +SSLSessionCache. Le cache de session +DBM est souvent à la source du problème qui peut être résolu en utilisant le +cache de session SHM (ou en n'utilisant tout simplement pas de cache).

+ +

Pourquoi la charge de mon serveur est-elle plus +importante depuis qu'il sert des ressources chiffrées en SSL ? +

SSL utilise un procédé de chiffrement fort qui nécessite la manipulation +d'une quantité très importante de nombres. Lorsque vous effectuez une requête +pour une page web via HTTPS, tout (même les images) est chiffré avant d'être +transmis. C'est pourquoi un accroissement du traffic HTTPS entraîne une +augmentation de la charge.

+ +

Pourquoi les connexions en HTTPS à mon serveur +prennent-elles parfois jusqu'à 30 secondes pour s'établir ? +

Ce problème provient en général d'un périphérique /dev/random +qui bloque l'appel système read(2) jusqu'à ce que suffisamment d'entropie +soit disponible pour servir la requête. Pour plus d'information, se référer au +manuel de référence de la directive +SSLRandomSeed.

+ +

Quels sont les algorithmes de chiffrement +supportés par mod_ssl ? +

En général, tous les algorithmes de chiffrement supportés par la version +d'OpenSSL installée, le sont aussi par mod_ssl. La liste des +algorithmes disponibles peut dépendre de la manière dont vous avez installé +OpenSSL. Typiquement, au moins les algorithmes suivants sont supportés :

+ +

RC4 avec MD5
RC4 avec MD5 (version d'exportation limitée à une clé de 40 bits)
RC2 avec MD5
RC2 avec MD5 (version d'exportation limitée à une clé de 40 bits)
IDEA avec MD5
DES avec MD5
Triple-DES avec MD5

+ +

Pour déterminer la liste réelle des algorithmes disponibles, vous + pouvez utiliser la commande suivante :

+ $ openssl ciphers -v +

+ +

Pourquoi une erreur ``no shared cipher'' apparaît-elle +quand j'essaie d'utiliser un algorithme de chiffrement +Diffie-Hellman anonyme (ADH) ? +

Par défaut et pour des raisons de sécurité, OpenSSl ne permet pas +l'utilisation des algorithmes de chiffrements ADH. Veuillez vous informer +sur les effets pervers potentiels si vous choisissez d'activer le support +de ces algorithmes de chiffrements.

Pour pouvoir utiliser les algorithmes de chiffrements Diffie-Hellman +anonymes (ADH), vous devez compiler OpenSSL avec +``-DSSL_ALLOW_ADH'', puis ajouter ``ADH'' à votre +directive SSLCipherSuite.

+ +

Pourquoi une erreur ``no shared cipher'' +apparaît-elle lorsqu'on se connecte à mon serveur +fraîchement installé ? +

Soit vous avez fait une erreur en définissant votre directive +SSLCipherSuite (comparez-la avec +l'exemple préconfiguré dans httpd.conf-dist), soit vous avez +choisi d'utiliser des algorithmes DSA/DH au lieu de RSA lorsque vous avez +généré votre clé privée, et avez ignoré ou êtes passé outre les +avertissements. Si vous avez choisi DSA/DH, votre serveur est incapable de +communiquer en utilisant des algorithmes de chiffrements SSL basés sur RSA +(du moins tant que vous n'aurez pas configuré une paire clé/certificat RSA +additionnelle). Les navigateurs modernes tels que NS ou IE ne peuvent +communiquer par SSL qu'avec des algorithmes RSA. C'est ce qui provoque l'erreur +"no shared ciphers". Pour la corriger, générez une nouvelle paire +clé/certificat pour le serveur en utilisant un algorithme de chiffrement +RSA.

+ +

Pourquoi ne peut-on pas utiliser SSL avec des hôtes +virtuels identifiés par un nom et non par une adresse IP ? +

La raison est très technique, et s'apparente au problème de la primauté de +l'oeuf ou de la poule. La couche du protocole SSL se trouve en dessous de la +couche de protocole HTTP qu'elle encapsule. Lors de l'établissement d'une +connexion SSL (HTTPS), Apache/mod_ssl doit négocier les paramètres du +protocole SSL avec le client. Pour cela, mod_ssl doit consulter la +configuration du serveur virtuel (par exemple, il doit accéder à la la suite +d'algorithmes de chiffrement, au certificat du serveur, etc...). Mais afin de +sélectionner le bon serveur virtuel, Apache doit connaître le contenu du champ +d'en-tête HTTP Host. Pour cela, il doit lire l'en-tête de la +requête HTTP. Mais il ne peut le faire tant que la négociation SSL n'est pas +terminée, or, la phase de négociation SSL a besoin du nom d'hôte contenu +dans l'en-tête de la requête. Bingo !

+ +

Pourquoi n'est-il pas possible d'utiliser +l'hébergement virtuel basé sur le nom d'hôte +pour différencier plusieurs hôtes virtuels ? +

L'hébergement virtuel basé sur le nom est une méthode très populaire + d'identification des différents hôtes virtuels. Il permet d'utiliser la + même adresse IP et le même numéro de port pour de nombreux sites + différents. Lorsqu'on se tourne vers SSL, il semble tout naturel de penser + que l'on peut appliquer la même méthode pour gérer plusieurs hôtes + virtuels SSL sur le même serveur.

+ +

Et là, on reçoit un choc en apprenant que ce n'est pas possible.

+ +

La raison en est que le protocole SSL constitue une couche séparée qui + encapsule le protocole HTTP. Aini, la session SSL nécessite une + transaction séparée qui prend place avant que la session HTTP n'ait débuté. + Le serveur reçoit une requête SSL sur l'adresse IP X et le port Y + (habituellement 443). Comme la requête SSL ne contient aucun champ relatif + à l'hôte, le serveur n'a aucun moyen de déterminer quel hôte virtuel SSL il + doit utiliser. En général, il utilisera le premier qu'il trouve et qui + correspond à l'adresse IP et au port spécifiés.

+ +

Bien entendu, vous pouvez utiliser l'hébergement virtuel basé sur le nom + pour identifier de nombreux hôtes virtuels non-SSL + (tous sur le port 80 par exemple), et ne gérer qu'un seul hôte virtuel SSL + (sur le port 443). Mais dans ce cas, vous devez définir le numéro de port + non-SSL à l'aide de la directive NameVirtualHost dans ce style :

+ + + NameVirtualHost 192.168.1.1:80 + + +

il existe d'autres solutions alternatives comme :

+ +

Utiliser des adresses IP différentes pour chaque hôte SSL. + Utiliser des numéros de port différents pour chaque hôte SSL.

+ +

Comment mettre en oeuvre la compression SSL ? +

Bien que la négociation pour la compression SSL ait été définie dans la +spécification de SSLv2 et TLS, ce n'est qu'en mai 2004 que la RFC 3749 a +défini DEFLATE comme une méthode de compression standard négociable. +

Depuis la version 0.9.8, OpenSSL supporte cette compression par défaut +lorsqu'il est compilé avec l'option zlib. Si le client et le +serveur supportent la compression, elle sera utilisée. Cependant, la +plupart des clients essaient encore de se connecter avec un Hello SSLv2. +Comme SSLv2 ne comportait pas de table des algorithmes de compression préférés +dans sa négociation, la compression ne peut pas être négociée avec ces clients. +Si le client désactive le support SSLv2, un Hello SSLv3 ou TLS peut être +envoyé, selon la bibliothèque SSL utilisée, et la compression peut être mise +en oeuvre. Vous pouvez vérifier si un client utilise la compression SSL en +journalisant la variable %{SSL_COMPRESS_METHOD}x. +

+ +

Lorsque j'utilise l'authentification de base sur HTTPS, +l'icône de verrouillage des navigateurs Netscape reste ouverte quand la boîte +de dialogue d'authentification apparaît. Cela signifie-t-il que les utilisateur +et mot de passe sont envoyés en clair ? +

Non, le couple utilisateur/mot de passe est transmis sous forme chiffrée. + L'icône de chiffrement dans les navigateurs Netscape n'est pas vraiment + synchronisé avec la couche SSL/TLS. Il ne passe à l'état verrouillé + qu'au moment où la première partie des données relatives à la page web + proprement dite sont transférées, ce qui peut prêter à confusion. Le + dispositif d'authentification de base appartient à la couche HTTP, qui + est située au dessus de la couche SSL/TLS dans HTTPS. Avant tout + transfert de données HTTP sous HTTPS, la couche SSL/TLS a déjà achevé + sa phase de négociation et basculé dans le mode de communication + chiffrée. Ne vous laissez donc pas abuser par l'état de cet icône.

+ +

Pourquoi des erreurs d'entrée/sortie apparaissent-elles +lorsqu'on se connecte à un serveur Apache+mod_ssl avec +Microsoft Internet Explorer (MSIE) ? +

La première raison en est la présence dans l'implémentation SSL de +certaines versions de MSIE de bogues subtils en rapport avec le +dispositif de "maintien en vie" (keep-alive) HTTP, et les alertes de +notification de fermeture de session SSL en cas de coupure de la +connexion au point d'entrée (socket). De plus, l'interaction entre +SSL et les fonctionnalités HTTP/1.1 pose problème avec certaines +versions de MSIE. Vous pouvez contourner ces problèmes en interdisant +à Apache l'utilisation de HTTP/1.1, les connexions avec maintien en vie +ou l'envoi de messages de notification de fermeture de session SSL aux +clients MSIE. Pour cela, vous pouvez utiliser la directive suivante +dans votre section d'hôte virtuel avec support SSL :

+ + SetEnvIf User-Agent ".*MSIE.*" \
+ nokeepalive ssl-unclean-shutdown \
+ downgrade-1.0 force-response-1.0 + +

En outre, certaines versions de MSIE ont des problèmes avec des + algorithmes de chiffrement particuliers. Hélas, il n'est pas + possible d'apporter une solution spécifique à MSIE pour ces + problèmes, car les algorithmes de chiffrement sont utilisés dès la + phase de négociation SSL. Ainsi, une directive + SetEnvIf spécifique + à MSIE ne peut être d'aucun secours. Par contre, vous devrez + ajuster les paramètres généraux de manière drastique. Avant de + vous décider, soyez sûr que vos clients rencontrent vraiment des + problèmes. Dans la négative, n'effectuez pas ces ajustements car + ils affecteront tous vos clients, ceux utilisant MSIE, + mais aussi les autres.

+ +

Un autre problème vient du fait que les versions d'exportation + 56 bits de MSIE 5.x présentent une mauvaise implémentation de + SSLv3, qui interagit de manière inappropriée avec les versions + d'OpenSSL supérieures à 0.9.4. Vous pouvez ignorer ce problème et + demander à vos clients de mettre à jour leurs navigateurs, vous + pouvez revenir à OpenSSL 0.9.4 (non recommandé), ou vous pouvez + contourner le problème, en sachant que vos modifications + affecteront tous les types de navigateurs :

+ SSLProtocol all -SSLv3 +

va désactiver complètement le protocole SSLv3 et ainsi permettre + aux navigateurs concernés de fonctionner. Une meilleure solution + consiste à ne désactiver que les algorithmes de chiffrement qui + posent problème.

SSLCipherSuite + ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP +

+ +

Ceci permet aussi aux versions de MSIE incriminées de + fonctionner, mais n'enlève que le support des derniers algorithmes + de chiffrement TLS 56 bits.

+ +

Autre problème avec les clients MSIE 5.x : ils refusent de se + connecter à des URLs de la forme https://12.34.56.78/ + (où une adresse IP est utilisée à la place d'un nom d'hôte), si le + serveur utilise le dispositif de cryptographie transmise par le + serveur (SGC). Le problème ne peut être contourné qu'en utilisant + le nom de domaine pleinement qualifié (FQDN) du site web dans les + hyperliens à la place de l'adresse IP, car MSIE 5.x gère la + négociation SGC de manière inappropriée.

+ +

Enfin, pour certaines versions de MSIE, il semble nécessaire + qu'une session SSL puisse être réutilisée (un comportement tout à + fait non conforme aux standard, bien entendu). Les connections avec + ces versions de MSIE ne fonctionnent que si un cache de session SSL + est mis en oeuvre. Ainsi, pour contourner le problème, assurez-vous + d'utiliser un cache de session (voir la directive + SSLSessionCache).

+ +

Pourquoi des erreurs d'entrée/sortie apparaissent-elles, ou +le message "Netscape a reçu des données erronées du serveur" s'affiche-t-il, +lorsqu'on se connecte à un serveur Apache+mod_ssl +avec Netscape Navigator ? +

+ Ceci arrive en général quand vous avez créé un nouveau certificat + de serveur pour un domaine donné, mais aviez auparavant configuré + votre navigateur pour toujours accepter l'ancien certificat du + serveur. Si vous supprimez de votre navigateur l'entrée + correspondant à l'ancien certificat, tout devrait rentrer dans + l'ordre. L'implémentation de SSL dans Netscape étant correcte, les + erreurs d'entrées/sorties avec Netscape Navigator sont en général + causées par les certificats installés.

+ + +

Support de mod_ssl +

Quelles sont les sources d'informations +disponibles en cas de problème avec mod_ssl ?
Qui peut-on contacter pour un support en cas de +problème avec mod_ssl ?
Quelles informations dois-je fournir lors +de l'écriture d'un rapport de bogue ?
Un vidage mémoire s'est produit, +pouvez-vous m'aider ?
Comment puis-je obtenir une journalisation de +ce qui s'est passé, pour m'aider à trouver la raison de ce vidage +mémoire ?

+ +

Quelles sont les sources d'informations +disponibles en cas de problème avec mod_ssl ? +

Voici les sources d'informations disponibles ; vous devez chercher +ici en cas de problème.

+ +

Vous trouverez des réponses dans la Foire Aux Questions du + manuel utilisateur (ce document): + http://httpd.apache.org/docs/&httpd.docs;/ssl/ssl_faq.html
+ Cherchez tout d'abord dans la foire aux questions + (ce document). Si votre question est courante, on a déjà dû y + répondre de nombreuses fois, et elle fait probablement partie + de ce document. +
Les archives de la liste de diffusion de support modssl-users + http://www.modssl.org/support/: Vous pouvez chercher la solution à votre problème dans les + archives de la liste de diffusion modssl-users. Vous n'êtes + probablement pas la première personne à rencontrer ce problème ! +

+ +

Qui peut-on contacter pour un support en cas de +problème avec mod_ssl ? +

Voici toutes les possibilités de support pour mod_ssl, par ordre + de préférence. Merci d'utiliser ces possibilités + dans cet ordre - ne vous précipitez pas sur celle qui vous + paraît la plus alléchante.

Envoyez un rapport de problème à la liste de diffusion de + support modssl-users
+ + modssl-users@modssl.org
+ C'est la manière la plus efficace de soumettre votre rapport de + problème, car ainsi, les autres en sont informés, et pourront + bénéficier des réponses apportées. Vous devez tout d'abord vous + abonner à la liste, mais vous pourrez ensuite discuter + facilement de votre problème avec l'auteur et l'ensemble de la + communauté d'utilisateurs de mod_ssl. +
Envoyez un rapport de problème à la liste de diffusion de + support des utilisateurs d'Apache httpd
+ + users@httpd.apache.org
+ C'est la deuxième manière de soumettre votre rapport de + problème. Ici aussi, vous devez d'abord vous abonner à la + liste, mais vous pourrez ensuite discuter facilement de votre + problème avec l'ensemble de la communauté d'utilisateurs + d'Apache httpd. +
Ecrire un rapport de problème dans la base de données des + bogues
+ + http://httpd.apache.org/bug_report.html
+ C'est la dernière manière de soumettre votre rapport de + problème. Vous ne devez utiliser cette solution que si vous + avez déjà écrit aux listes de diffusion, et n'avez pas trouvé + de solution. Merci de suivre les instructions de la page + mentionnée ci-dessus avec soin. +

+ +

Quelles informations dois-je fournir lors +de l'écriture d'un rapport de bogue ? +

Vous devez toujours fournir au moins les informations +suivantes :

+ +

Les versions d'Apache et OpenSSL installées: La version d'Apache peut être déterminée en exécutant + httpd -v. La version d'OpenSSL peut être déterminée + en exécutant openssl version. Si Lynx est installé, + vous pouvez aussi exécuter la commandelynx -mime_header + http://localhost/ | grep Server et ainsi obtenir ces + informations en une seule fois. +
Les détails de votre installation d'Apache+mod_ssl+OpenSSL: A cet effet, vous pouvez fournir un fichier journal de votre + session de terminal qui montre les étapes de la configuration et + de l'installation. En cas d'impossibilité, vous devez au moins + fournir la ligne de commande configure que + vous avez utilisée. +
En cas de vidage mémoire, inclure une trace de ce qui s'est + passé: Si votre serveur Apache+mod_ssl+OpenSSL fait un vidage de sa + mémoire, merci de fournir en pièce jointe un fichier contenant + une trace de la zone dédiée à la pile (voir + ci-dessous pour des informations sur la manière + de l'obtenir). Il est nécessaire de disposer de ces informations + afin de pouvoir déterminer la raison de votre vidage mémoire. +
Une description détaillée de votre problème: Ne riez pas, nous sommes sérieux ! De nombreux rapports + n'incluent pas de description de la véritable nature du problème. + Sans ces informations, il est très difficile pour quiconque de + vous aider. Donc, et c'est votre propre intérêt (vous souhaitez + que le problème soit résolu, n'est-ce pas ?), fournissez, s'il vous + plait, le maximum de détails possible. Bien entendu, vous devez + aussi inclure tout ce qui a été dit précédemment. +

+ +

Un vidage mémoire s'est produit, +pouvez-vous m'aider ? +

En général non, du moins tant que vous n'aurez pas fourni plus de +détails à propos de la localisation dans le code où Apache a effectué +son vidage mémoire. Ce dont nous avons en général besoin pour vous +aider est une trace de ce qui s'est passé (voir la question suivante). +Sans cette information, il est pratiquement impossible de déterminer +la nature du problème et de vous aider à le résoudre.

+ +

Comment puis-je obtenir une journalisation de +ce qui s'est passé, pour m'aider à trouver la raison de ce vidage +mémoire ? +

Vous trouverez ci-dessous les différentes étapes permettant +d'obtenir une journalisation des évènements (backtrace) :

Assurez-vous que les symboles de débogage sont disponibles, au + moins pour Apache. Pour cela, sur les plates-formes où GCC/GDB est + utilisé, vous devez compiler Apache+mod_ssl avec l'option + ``OPTIM="-g -ggdb3"''. Sur les autres plates-formes, + l'option ``OPTIM="-g"'' est un minimum. +
Démarrez le serveur et essayez de reproduire le vidage mémoire. + A cet effet, vous pouvez utiliser une directive du style + ``CoreDumpDirectory /tmp'' pour être sûr que le + fichier de vidage mémoire puisse bien être écrit. Vous devriez + obtenir un fichier /tmp/core ou + /tmp/httpd.core. Si ce n'est pas le cas, essayez de + lancer votre serveur sous un UID autre que root. + Pour des raisons de sécurité, de nombreux + noyaux modernes de permettent pas à un processus de vider sa + mémoire une fois qu'il a accompli un setuid() (à moins + qu'il effectue un exec()) car des informations d'un + niveau privilégié pourraient être transmises en mémoire. Si + nécessaire, vous pouvez exécuter /chemin/vers/httpd -X + manuellement afin de ne pas permettre à Apache de se clôner (fork). +
Analysez le vidage mémoire. Pour cela, exécutez + gdb /path/to/httpd /tmp/httpd.core ou une commande + similaire. Dans GDB, tout ce que vous avez à faire est d'entrer + bt, et voila, vous obtenez la backtrace. Pour les + débogueurs autres que GDB consulter le manuel correspondant. +

Chiffrement fort SSL/TLS : Mode d'emploi

Langues Disponibles: en | + fr

+ +

+
La solution à ce problème est évidente et le lecteur la recherchera +à titre d'exercice
+ +
-- Phrase standard des manuels
+

+ +

Résoudre des problèmes de sécurité particuliers pour un serveur web +utilisant SSL n'est pas toujours évident à cause des interactions entre SSL, +HTTP et la manière dont Apache traite les requêtes. Ce chapitre donne des +instructions pour résoudre certaines situations typiques. Considérez-le +comme une première étape sur le chemin de la solution définitive, mais +efforcez-vous toujours de comprendre ce que vous faites pour résoudre le +problème avant d'utiliser la solution. Rien n'est pire que d'utiliser une +solution de sécurité sans connaître ses restrictions et la manière dont elle +interagit avec les autres systèmes.

Suites de chiffrement et mise en application de la sécurité +de haut niveau
Authentification du client et contrôle d'accès

Suites de chiffrement et mise en application de la sécurité +de haut niveau

+ +

Comment créer un véritable serveur +SSLv2 seulement ?
Comment créer un serveur SSL +qui n'accepte que le chiffrement fort ?
Comment créer un serveur SSL qui n'accepte que le +chiffrement fort, mais permet aux navigateurs importés des USA +d'évoluer vers un chiffrement plus fort ?
Comment créer un serveur qui accepte tous les types de +chiffrement en général, mais exige un chiffrement fort pour pouvoir +accéder à une URL particulière ?

+ +

Comment créer un véritable serveur SSLv2 seulement ?

+ +

Les directives suivantes créent un serveur SSL qui ne communique que + selon le protocole SSLv2 et ses modes de chiffrement.

+ +

httpd.conf

+ SSLProtocol -all +SSLv2 + SSLCipherSuite SSLv2:+HIGH:+MEDIUM:+LOW:+EXP +

+ + +

Comment créer un serveur SSL qui n'accepte +que le chiffrement fort ?

+ +

Les directives suivantes ne permettent que les + chiffrements de plus haut niveau :

httpd.conf

+ SSLProtocol all + SSLCipherSuite HIGH:MEDIUM +

+ + +

Comment créer un serveur SSL qui n'accepte que le +chiffrement fort, mais permet aux navigateurs importés des USA +d'évoluer vers un chiffrement plus fort ?

+ +

Cette fonctionnalité se nomme Cryptographie Transférée par Serveur + (Server Gated Cryptography - SGC) et nécessite un certificat de serveur + à identifiant global, signé par un certificat de CA spécial de chez + Verisign. Ceci permet d'activer le chiffrement fort dans les versions des + navigateurs importés des US, qui n'en avaient habituellement pas la + possibilité (à cause des restrictions à l'exportation imposées par les + US).

Quand un navigateur se connecte avec un mode de chiffrement importé + des US, le serveur présente son certificat à identifiant global. le + navigateur le vérifie, et peut ensuite faire évoluer sa suite de + chiffrement avant que la communication HTTP ne se mette en place. Le + problème consiste à permettre au navigateur de se mettre à jour de cette + façon, mais de nécessiter encore un chiffrement fort. En d'autres termes, + nous voulons que les navigateurs démarrent une connexion soit avec + chiffrement fort, soit avec une version export du chiffrement mais que + dans ce dernier cas, le navigateur fasse évoluer sa suite de chiffrement + vers un chiffrement fort avant de démarrer la communication HTTP.

Il est possible de parvenir à ceci de cette façon:

httpd.conf

+ # autorise tout mode de chiffrement pour l'échange de données + initial, + # les navigateurs non US peuvent ainsi se mettre à jour + via la fonctionnalité SGC + SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL + + <Directory /usr/local/apache2/htdocs> + # et enfin interdit l'accès à tous les navigateurs qui n'ont pas fait + évoluer leur suite de chiffrement + SSLRequire %{SSL_CIPHER_USEKEYSIZE} >= 128 + </Directory> +

+ + +

Comment créer un serveur qui accepte tous les types de +chiffrement en général, mais exige un chiffrement fort pour pouvoir +accéder à une URL particulière ?

+ +

Dans ce cas bien évidemment, une directive SSLCipherSuite au niveau du serveur principal + qui restreint le choix des suites de chiffrement aux versions les plus + fortes ne conviendra pas. mod_ssl peut cependant être + reconfiguré au sein de blocs Location qui permettent + d'adapter la configuration générale à un répertoire spécifique ; + mod_ssl peut alors forcer automatiquement une + renégociation des paramètres SSL pour parvenir au but recherché. + Cette configuration peut se présenter comme suit :

+ # soyons très tolérant a priori + SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL + + <Location /strong/area> + # sauf pour https://hostname/strong/area/ et ses sous-répertoires + # qui exigent des chiffrements forts + SSLCipherSuite HIGH:MEDIUM + </Location> +

+ +

Authentification du client et contrôle d'accès

+ +

Comment forcer les clients +à s'authentifier à l'aide de certificats ?
Comment forcer les clients +à s'authentifier à l'aide de certificats pour une URL particulière, +mais autoriser quand-même tout client anonyme +à accéder au reste du serveur ?
Comment n'autoriser l'accès à une URL +particulière qu'aux clients qui possèdent des certificats, mais autoriser +l'accès au reste du serveur à tous les clients ?
Comment imposer HTTPS avec chiffrements forts, +et soit authentification de base, soit possession de certificats clients, +pour l'accès à une partie de l'Intranet, pour les clients en +provenance de l'Internet ?

+ +

Comment forcer les clients +à s'authentifier à l'aide de certificats ? +

+ + +

Lorsque vous connaissez tous vos clients (comme c'est en général le cas + au sein d'un intranet d'entreprise), vous pouvez imposer une + authentification basée uniquement sur les certificats. Tout ce dont vous + avez besoin pour y parvenir est de créer des certificats clients signés par + le certificat de votre propre autorité de certification + (ca.crt), et d'authentifier les clients à l'aide de ces + certificats.

httpd.conf

+ # exige un certificat client signé par le certificat de votre CA + # contenu dans ca.crt + SSLVerifyClient require + SSLVerifyDepth 1 + SSLCACertificateFile conf/ssl.crt/ca.crt +

+ + +

Comment forcer les clients +à s'authentifier à l'aide de certificats pour une URL particulière, +mais autoriser quand-même tout client anonyme +à accéder au reste du serveur ?

+ + +

Pour forcer les clients à s'authentifier à l'aide de certificats pour une +URL particulière, vous pouvez utiliser les fonctionnalités de reconfiguration +de mod_ssl en fonction du répertoire :

+ +

httpd.conf

+ SSLVerifyClient none + SSLCACertificateFile conf/ssl.crt/ca.crt + + <Location /secure/area> + SSLVerifyClient require + SSLVerifyDepth 1 + </Location> +

+ + +

Comment n'autoriser l'accès à une URL +particulière qu'aux clients qui possèdent des certificats, mais autoriser +l'accès au reste du serveur à tous les clients ?

+ + +

La clé du problème consiste à vérifier si une partie du certificat + client correspond à ce que vous attendez. Cela signifie en général + consulter tout ou partie du nom distinctif (DN), afin de vérifier s'il + contient une chaîne connue. Il existe deux méthodes pour y parvenir ; + on utilise soit le module mod_auth_basic, soit la + directive SSLRequire.

+ +

La méthode du module mod_auth_basic est en général + incontournable lorsque les certificats ont un contenu arbitraire, ou + lorsque leur DN ne contient aucun champ connu + (comme l'organisation, etc...). Dans ce cas, vous devez construire une base + de données de mots de passe contenant tous les clients + autorisés, comme suit :

+ +

httpd.conf

+SSLVerifyClient      none
+<Directory /usr/local/apache2/htdocs/secure/area>
+
+SSLVerifyClient      require
+SSLVerifyDepth       5
+SSLCACertificateFile conf/ssl.crt/ca.crt
+SSLCACertificatePath conf/ssl.crt
+SSLOptions           +FakeBasicAuth
+SSLRequireSSL
+AuthName             "Snake Oil Authentication"
+AuthType             Basic
+AuthBasicProvider    file
+AuthUserFile         /usr/local/apache2/conf/httpd.passwd
+Require              valid-user
+</Directory>

+ +

Le mot de passe utilisé dans cet exemple correspond à la chaîne de + caractères "password" chiffrée en DES. Voir la documentation de la + directive SSLOptions pour + plus de détails.

+ +

httpd.passwd

+/C=DE/L=Munich/O=Snake Oil, Ltd./OU=Staff/CN=Foo:xxj31ZMTZzkVA
+/C=US/L=S.F./O=Snake Oil, Ltd./OU=CA/CN=Bar:xxj31ZMTZzkVA
+/C=US/L=L.A./O=Snake Oil, Ltd./OU=Dev/CN=Quux:xxj31ZMTZzkVA

+ +

Lorsque vos clients font tous partie d'une même hiérarchie, ce qui + apparaît dans le DN, vous pouvez les authentifier plus facilement en + utilisant la directive SSLRequire, comme suit :

+ + +

httpd.conf

+SSLVerifyClient      none
+<Directory /usr/local/apache2/htdocs/secure/area>
+
+  SSLVerifyClient      require
+  SSLVerifyDepth       5
+  SSLCACertificateFile conf/ssl.crt/ca.crt
+  SSLCACertificatePath conf/ssl.crt
+  SSLOptions           +FakeBasicAuth
+  SSLRequireSSL
+  SSLRequire       %{SSL_CLIENT_S_DN_O}  eq "Snake Oil, Ltd." \
+               and %{SSL_CLIENT_S_DN_OU} in {"Staff", "CA", "Dev"}
+</Directory>

+ + +

Comment imposer HTTPS avec chiffrements forts, +et soit authentification de base, soit possession de certificats clients, +pour l'accès à une partie de l'Intranet, pour les clients en +provenance de l'Internet ? Je souhaite quand-même autoriser l'accès en HTTP +aux clients de l'intranet.

+ + +

On suppose dans ces exemples que les clients de l'intranet ont des + adresses IP dans la gamme 192.168.1.0/24, et que la partie de l'intranet + à laquelle vous voulez autoriser l'accès depuis l'Internet est + /usr/local/apache2/htdocs/subarea. Ces lignes de configuration + doivent se trouver en dehors de votre hôte virtuel HTTPS, afin qu'elles + s'appliquent à la fois à HTTP et HTTPS.

+ +

httpd.conf

+SSLCACertificateFile conf/ssl.crt/company-ca.crt
+
+<Directory /usr/local/apache2/htdocs>
+#   En dehors de subarea, seul l'accès depuis l'intranet est autorisé
+Order                deny,allow
+Deny                 from all
+Allow                from 192.168.1.0/24
+</Directory>
+
+<Directory /usr/local/apache2/htdocs/subarea>
+#   Dans subarea, tout accès depuis l'intranet est autorisé
+#   mais depuis l'Internet, seul l'accès par HTTPS + chiffrement fort
+ + Mot de passe
+#   ou HTTPS + chiffrement fort + certificat client n'est autorisé.
+
+#   Si HTTPS est utilisé, on s'assure que le niveau de chiffrement est fort.
+#   Autorise en plus les certificats clients comme une alternative à
+#   l'authentification basique.
+SSLVerifyClient      optional
+SSLVerifyDepth       1
+SSLOptions           +FakeBasicAuth +StrictRequire
+SSLRequire           %{SSL_CIPHER_USEKEYSIZE} >= 128
+
+#   ON oblige les clients venant d'Internet à utiliser HTTPS
+RewriteEngine        on
+RewriteCond          %{REMOTE_ADDR} !^192\.168\.1\.[0-9]+$
+RewriteCond          %{HTTPS} !=on
+RewriteRule          .* - [F]
+
+#   On permet l'accès soit sur les critères réseaux, soit par authentification Basique
+Satisfy              any
+
+#   Contrôle d'accès réseau
+Order                deny,allow
+Deny                 from all
+Allow                192.168.1.0/24
+
+#   Configuration de l'authentification HTTP Basique
+AuthType             basic
+AuthName             "Protected Intranet Area"
+AuthBasicProvider    file
+AuthUserFile         conf/protected.passwd
+Require              valid-user
+</Directory>

+ +

SSL/TLS Strong Encryption: How-To

Chiffrement fort SSL/TLS : Mode d'emploi

httpd.conf

httpd.conf

httpd.conf

httpd.conf

httpd.conf

httpd.conf

httpd.passwd

httpd.conf

httpd.conf