From: Lucien Gentis Date: Sun, 14 Nov 2010 17:06:11 +0000 (+0000) Subject: Updates. X-Git-Tag: 2.3.9~47 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=c288060731004db6d1bdbe3cc250646d6d4214ca;p=apache Updates. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1035023 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/docs/manual/bind.xml.fr b/docs/manual/bind.xml.fr index 6f10846518..e47bc7ad6a 100644 --- a/docs/manual/bind.xml.fr +++ b/docs/manual/bind.xml.fr @@ -3,7 +3,7 @@ - + + @@ -34,8 +34,8 @@ DNS pour interpréter les fichiers de configuration, votre serveur pourra présenter des problèmes de fiabilité (en d'autres termes, il est possible qu'il refuse de démarrer), ou d'attaques par déni ou - usurpation de service (y compris le détournement d'informations - utilisateurs).

+ usurpation de service (y compris l'attribution de requêtes à un + serveur virtuel autre que le serveur virtuel voulu).

@@ -44,9 +44,9 @@ # Cet exemple de configuration est invalide, ne l'utilisez pas comme base # de configuration - <VirtualHost www.abc.dom>
- ServerAdmin webgirl@abc.dom
- DocumentRoot /www/abc
+ <VirtualHost www.example.dom>
+ ServerAdmin webgirl@example.dom
+ DocumentRoot /www/example
</VirtualHost> @@ -56,24 +56,22 @@ module="core">ServerName, et au moins une adresse IP à laquelle le serveur va se rattacher et répondre. L'exemple ci-dessus ne comporte pas d'adresse IP, si bien que httpd devra utiliser le - DNS pour trouver l'adresse IP de www.abc.dom. Si pour + DNS pour trouver l'adresse IP de www.example.dom. Si pour une raison quelconque, le DNS n'est pas disponible au moment où votre serveur interprète son fichier de configuration, ce serveur virtuel ne sera pas pris en compte dans la configuration. Il sera incapable de - répondre à toute requête pour ce serveur virtuel (avec les versions - de httpd antérieures à 1.2, le serveur ne démarrera tout simplement - pas).

+ répondre à toute requête pour ce serveur virtuel.

-

Supposons que l'adresse de www.abc.dom soit +

Supposons que l'adresse de www.example.dom soit 192.0.2.1, et examinons cet extrait de configuration :

# Cet exemple de configuration est invalide, ne l'utilisez pas comme base # de configuration <VirtualHost 192.0.2.1>
- ServerAdmin webgirl@abc.dom
- DocumentRoot /www/abc
+ ServerAdmin webgirl@example.dom
+ DocumentRoot /www/example
</VirtualHost> @@ -84,16 +82,17 @@ virtuel est à base de nom, il sera en fait totalement désactivé, mais s'il est à base d'adresse IP, il fonctionnera probablement. Cependant, httpd échouera s'il doit générer une URL complète pour - le serveur qui inclut ce nom de serveur.

+ le serveur qui inclut ce nom de serveur (comme dans le cas d'une + redirection).

Voici un extrait de configuration qui permet d'éviter ces deux types de problèmes :

<VirtualHost 192.0.2.1>
- ServerName www.abc.dom
- ServerAdmin webgirl@abc.dom
- DocumentRoot /www/abc
+ ServerName www.example.dom
+ ServerAdmin webgirl@example.dom
+ DocumentRoot /www/example
</VirtualHost>
@@ -101,49 +100,38 @@
Déni de service -

Il existe (au moins) deux formes possibles de déni de service. Si - vous utilisez une version de httpd antérieure à 1.2, votre serveur - ne démarrera pas si une des deux recherches DNS mentionnées - ci-dessus échoue pour au moins un de vos serveurs virtuels. Dans - certains cas, cette recherche DNS ne sera même pas sous votre - contrôle ; par exemple, si abc.dom est un de vos - clients et s'il gère son propre DNS, il peut empêcher votre - serveur (pre-1.2) de démarrer, simplement en supprimant - l'enregistrement www.abc.dom.

- -

La deuxième forme de déni de service est beaucoup plus subtile. - Examinons cet extrait de configuration :

+

Considérons cet extrait de configuration :

- <VirtualHost www.abc.dom>
+ <VirtualHost www.example1.dom>
- ServerAdmin webgirl@abc.dom
- DocumentRoot /www/abc
+ ServerAdmin webgirl@example1.dom
+ DocumentRoot /www/example1
 </VirtualHost>

- <VirtualHost www.def.dom>
+ <VirtualHost www.example2.dom>
- ServerAdmin webguy@def.dom
- DocumentRoot /www/def
+ ServerAdmin webguy@example2.dom
+ DocumentRoot /www/example2
 </VirtualHost>

Supposons que vous avez assigné 192.0.2.1 à - www.abc.dom et 192.0.2.2 à www.def.dom. En - outre, supposons que def.dom gère son propre DNS. Avec - cette configuration, def.dom sera en mesure de - détourner tout trafic destiné à abc.dom. Pour y + www.example1.dom et 192.0.2.2 à www.example2.dom. En + outre, supposons que example2.dom gère son propre DNS. Avec + cette configuration, example2.dom sera en mesure de + détourner tout trafic destiné à example1.dom. Pour y parvenir, tout ce qu'ils ont à faire consiste à assigner 192.0.2.1 à - www.def.dom. Comme ils gèrent leur propre DNS, vous ne + www.example2.dom. Comme ils gèrent leur propre DNS, vous ne pouvez pas les empêcher de faire pointer l'enregistrement - www.def.dom vers l'adresse qu'ils veulent.

+ www.example2.dom vers l'adresse qu'ils veulent.

Les requêtes à destination de 192.0.2.1 (y compris toutes celles où l'utilisateur à tapé une URL de la forme - http://www.abc.dom/quelquepart), seront toutes servies - par le serveur virtuel def.dom. Une meilleur + http://www.example1.dom/quelquepart), seront toutes servies + par le serveur virtuel example2.dom. Une meilleur compréhension de la raison pour laquelle ceci peut se produire nécessite une discussion plus approfondie à propos de la manière dont httpd associe les requêtes entrantes aux différents serveurs @@ -209,42 +197,5 @@ _default_:*> qui n'a aucune page à servir

- -
- Appendice : orientations pour le futur - -

La situation concernant le DNS apparaît clairement comme non - souhaitable. Bien que nous ayons fait en sorte que le - serveur puisse au moins démarrer en cas d'échec de recherche DNS, - ce n'est pas ce que nous pouvons faire de mieux. En tout état - de cause, le fait de devoir spécifier des adresses IP explicites - dans les fichiers de configuration est fortement non souhaitable - avec l'Internet d'aujourd'hui où les changements de numérotation - sont une nécessité.

- -

Il est possible d'éviter les attaques par usurpation de service - décrites ci-dessus en effectuant une recherche DNS inverse sur - l'adresse IP renvoyée par la recherche DNS directe et en comparant - les deux noms -- en cas de non correspondance, le serveur virtuel - serait désactivé. Ceci nécessite cependant une configuration - correcte du DNS inverse (ce avec quoi les administrateurs sont - familiers à cause de l'utilisation courante des doubles recherches - DNS inverses par les serveurs FTP et les TCP wrappers).

- -

En tout état de cause, il ne semble pas envisageable de démarrer - de manière fiable un serveur web avec serveurs virtuels losqu'une - recherche DNS a échoué, sauf si l'on utilise des adresses IP. Les - solutions partielles consistant à désactiver des portions de - configuration pourraient s'avérer pires que ne pas démarrer du tout - ; tout dépend de ce que le serveur est supposé faire.

- -

Au fur et à mesure du déploiement de HTTP/1.1, et comme les - navigateurs et les mandataires commencent à générer l'en-tête - Host, il devient possible d'envisager de se passer - complètement des serveurs virtuels à base d'adresses IP. Dans ce - cas, un serveur web n'a besoin d'aucune recherche DNS pendant - l'interprétation de ses fichiers de configuration. Cependant, au - mois de mars 1997, ces fonctionnalités n'ont pas été assez largement - déployées pour être utilisées sur des serveurs web critiques.

-
+ diff --git a/docs/manual/mod/core.xml.fr b/docs/manual/mod/core.xml.fr index cc32985c67..c007b076b8 100644 --- a/docs/manual/mod/core.xml.fr +++ b/docs/manual/mod/core.xml.fr @@ -1,7 +1,7 @@ - + @@ -57,6 +57,12 @@ sur les autres plates-formes. premier, comme ftp: ou nntp:

AcceptFilter nntp none +

Les noms de protocoles par défaut sont https pour le + port 443 et http pour tous les autres ports. Pour + spécifier un autre protocole à utiliser avec un port en écoute, + ajoutez l'argument protocol à la directive Listen.

+

Sous FreeBSD, les valeurs par défaut sont :

AcceptFilter http httpready
@@ -113,6 +119,7 @@ sur les autres plates-formes. anti-spyware.

+Protocol @@ -326,7 +333,8 @@ supérieures .htaccess AllowOverride All|None|type directive [type directive] ... -AllowOverride All +AllowOverride None à partir de la version 2.3.9, AllowOverride +All pour les versions antérieures directory @@ -970,6 +978,46 @@ supérieures. Par défaut à Off depuis la version 2.3.9. + +Error +Interrompt la lecture de la configuration avec un message +d'erreur personnalisé +Error message +server configvirtual host +directory.htaccess + +à partir de la version 2.3.9 + + +

Si une erreur peut être détectée dans la configuration, souvent + un module manquant, cette + directive peut être utilisée pour générer un message d'erreur + personnalisé, et interrompre la lecture de la configuration.

+ + Exemple + # vérification du chargement de mod_include
+ <IfModule !include_module>
+ Error mod_foo nécessite mod_include. Chargez-le via LoadModule.
+ </IfModule>
+
+ # vérification de la définition de SSL ou (exclusif) NOSSL
+ <IfDefine SSL>
+ <IfDefine NOSSL>
+ Error SSL et NOSSL sont définies. Vous devez définir soit l'une, + soit l'autre.
+ </IfDefine>
+ </IfDefine>
+ <IfDefine !SSL>
+ <IfDefine !NOSSL>
+ Error Vous devez définir une et une seule des deux variables SSL + ou NOSSL.
+ </IfDefine>
+ </IfDefine>
+ + + + + ErrorDocument Document que le serveur renvoie au client en cas @@ -1128,7 +1176,9 @@ host mais vous pouvez le modifier à l'aide de la syntaxe syslog:facility, où facility peut être remplacé par un des noms habituellement documentés dans la page - de man syslog(1).

+ de man syslog(1). Le dispositif syslog local7 est + global, et si il est modifié dans un serveur virtuel, le dispositif + final spécifié affecte l'ensemble du serveur

Exemple ErrorLog syslog:user @@ -1608,6 +1658,26 @@ HTTP Content-Type pour les fichiers correspondants + +GprofDir +Répertoire dans lequel écrire les données de profiling +gmon.out. +GprofDir /tmp/gprof/|/tmp/gprof/% +server configvirtual host + + + +

Lorsque le serveur a été compilé avec le support du profiling + gprof, la directive GprofDir permet de + spécifier dans quel répertoire les fichiers gmon.out + doivent être écrits lorsque le processus s'arrête. Si l'argument se + termine par un caractère pourcentage ('%'), des sous-répertoires + sont créés pour chaque identifiant de processus.

+ +

Cette directive ne fonctionne actuellement qu'avec le MPM + prefork.

+ + HostnameLookups @@ -2209,7 +2279,8 @@ host

Cette directive spécifie la taille maximale autorisée pour le corps d'une requête ; la valeur de l'argument octets va - de 0 (pour une taille illimitée), à 2147483647 (2Go).

+ de 0 (pour une taille illimitée), à 2147483647 (2Go). Voir la note + ci-dessous pour la limite d'applicabilité aux requêtes mandatées.

La directive LimitRequestBody permet de définir une limite pour la taille maximale autorisée du corps d'une @@ -2240,6 +2311,11 @@ host LimitRequestBody 102400 +

Pour une description détaillée de la manière dont cette + directive est interprétée par les requêtes mandatées, voir la + documentation du module mod_proxy.

+ + @@ -2501,9 +2577,7 @@ host <Location /status>
SetHandler server-status
- Order Deny,Allow
- Deny from all
- Allow from .example.com
+ Require host example.com
 </Location> @@ -3236,7 +3310,14 @@ host
Les vues multiples ("multiviews") à contenu négocié à l'aide du - module mod_negotiation sont autorisées.
+ module mod_negotiation sont autorisées. + Note

Cette option est ignorée si elle est + définie en tout autre endroit qu'une section Directory, car + mod_negotiation a besoin de ressources réelles + pour effectuer ses comparaisons et ses évaluations.

 + +
SymLinksIfOwnerMatch
@@ -3326,6 +3407,42 @@ host + +Protocol +Protocole pour une socket d'écoute +Protocol protocole +server configvirtual host +Disponible depuis la version 2.1.5 d'Apache, mais +seulement depuis la version 2.3.3 sous Windows. + + +

Cette directive permet de spécifier le protocole utilisé pour une + socket d'écoute particulière. Le protocole sert à déterminer quel + module doit traiter une requête, et d'appliquer les optimisations + spécifiques au protocole via la directive + AcceptFilter.

+ +

Vous ne devez définir le protocole que si vous travaillez avec + des ports non standards ; dans le cas général, le protocole + http est associé au port 80 et le protocole + https au port 443.

+ +

Par exemple, si vous travaillez avec le protocole + https sur un port non standard, spécifiez le protocole + de manière explicite :

+ + + Protocol https + + +

Vous pouvez aussi spécifier le protocole via la directive + Listen.

+ +AcceptFilter +Listen + + + RLimitCPU Limite le temps CPU alloué aux processus initiés par les diff --git a/docs/manual/mod/mod_info.xml.fr b/docs/manual/mod/mod_info.xml.fr index fd49bd0a49..ccf7205f6b 100644 --- a/docs/manual/mod/mod_info.xml.fr +++ b/docs/manual/mod/mod_info.xml.fr @@ -1,7 +1,7 @@ - + @@ -52,9 +52,7 @@ serveur <Location /infos-serveur>
SetHandler server-info
- Order deny,allow
- Deny from all
- Allow from votre-entreprise.com
+ Require host votre-entreprise.com
 </Location> diff --git a/docs/manual/rewrite/intro.xml.fr b/docs/manual/rewrite/intro.xml.fr index 7adcc79192..c91ead8f24 100644 --- a/docs/manual/rewrite/intro.xml.fr +++ b/docs/manual/rewrite/intro.xml.fr @@ -1,7 +1,7 @@ - + @@ -348,8 +348,8 @@ alors %1 contiendrait example.com et

La directive RewriteMap permet en quelque sorte de faire appel à une fonction externe pour effectuer la réécriture à votre place. Tout ceci est décrit plus en -détails dans la Documentation supplémentaire sur RewriteMap.

+détails dans la Documentation +supplémentaire sur RewriteMap.

Fichiers .htaccess diff --git a/docs/manual/ssl/ssl_faq.xml.fr b/docs/manual/ssl/ssl_faq.xml.fr index 545e12f19d..b9094a500c 100644 --- a/docs/manual/ssl/ssl_faq.xml.fr +++ b/docs/manual/ssl/ssl_faq.xml.fr @@ -1,7 +1,7 @@ - + - + @@ -29,127 +29,52 @@
-

Le sage n'apporte pas de bonnes réponses, il pose les bonnes 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 ? -

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 +<section id="mutex"><title>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 + 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 + /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 +<section id="entropy"><title>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 + 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 + 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 + correctement. Ce niveau d'entropie est défini par la directive SSLRandomSeed.

@@ -157,15 +82,15 @@ d'Apache ?
Configuration -
Peut-on faire cohabiter HTTP et HTTPS sur le même +<section id="parallel"><title>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 +

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

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 +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 +<section id="httpstest"><title>Comment s'exprimer en langage HTTPS à des fins de test ?

Alors que vous utilisez simplement

@@ -203,21 +128,21 @@ de test ? 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. + 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 +

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 + 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/
@@ -225,49 +150,49 @@ de test ?
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 à +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 +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 +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'' +<section id="refused"><title>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.

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

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

+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] + 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 +

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

@@ -275,87 +200,76 @@ manipuler des hyperliens relatifs, pour obtenir le même effet.

Certificats -
Qu'est-ce qu'un clé privée RSA, un certificat, +<section id="keyscerts"><title>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 +

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 +

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.

+

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 +<section id="startup"><title>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 +

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 !

+

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 +<section id="selfcert"><title>Comment créer un certificat auto-signé SSL à des fins de test ?
    -
  1. Vérifiez qu'OpenSSL est installé et l'exécutable openssl dans votre +
  2. Vérifiez qu'OpenSSL est installé et l'exécutable openssl dans votre PATH.

    3. -
  3. Exécuter la commande suivante pour créer les fichiers +
  4. 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 + Ces fichiers seront utilisés comme suit dans votre httpd.conf : 
                  SSLCertificateFile    /chemin/vers/server.crt
@@ -363,127 +277,127 @@ fins de test ?
  5. 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é.
    + 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. + passe en lieu sûr.
-
Comment créer un vrai certificat SSL ? -

Voici la marche à suivre pas à pas :

+
Comment créer un vrai certificat SSL ? +

Voici la marche à suivre pas à pas :

    -
  1. Assurez-vous qu'OpenSSL est bien installé et dans votre PATH. +
  2. Assurez-vous qu'OpenSSL est bien installé et dans votre PATH.

    3. -
  3. Créez une clé privée RSA pour votre serveur Apache - (elle sera au format PEM et chiffrée en Triple-DES):
    +
  4. 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
    + $ openssl genrsa -des3 -out server.key 2048

    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 + é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 :
    + 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

    5. -
  5. 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):
    +
  6. 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é + 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 + 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 :
    + pouvez afficher les détails de ce CSR avec :

    $ openssl req -noout -text -in server.csr

    7. -
  7. 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 +
  8. 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 + 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 + 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 + Une fois la CSR signée, vous pouvez afficher les détails du certificat comme suit :

    $ openssl x509 -noout -text -in server.crt
  9. Vous devez maintenant disposer de deux fichiers : - server.key et server.crt. Ils sont précisés dans + 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. + Le fichier server.csr n'est plus nécessaire.
-
Comment créer et utiliser sa propre Autorité de +<section id="ownca"><title>Comment créer et utiliser sa propre Autorité de certification (CA) ? -

La solution la plus simple consiste à utiliser les scripts +

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 :

+ 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 :

    -
  1. Créez une clé privée RSA pour votre serveur - (elle sera au format PEM et chiffrée en Triple-DES) :
    +
  2. 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
    + $ openssl genrsa -des3 -out server.key 2048

    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 + é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 :
    + 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

    3. -
  3. 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) :
    +
  4. 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 + server.crt. Vous pouvez afficher les détails de ce certificat avec :

    $ openssl x509 -noout -text -in server.crt
    @@ -493,32 +407,32 @@ certification (CA) ?
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 +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 +

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 + 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 +<section id="removepassphrase"><title>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 !

+

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 !

    -
  1. Supprimer le chiffrement de la clé privée RSA (tout en conservant une +
  2. 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
    @@ -533,293 +447,244 @@ sécurité du serveur - agissez avec précautions !

-

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

+

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 +

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é, + 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 +

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 +

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 +

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.

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

Le format des certificats par défaut pour 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 : +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 +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.

+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 +<section id="random"><title>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 +

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

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 :

+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 :

    -
  1. RC4 avec MD5
    2. -
  2. RC4 avec MD5 (version d'exportation limitée à une clé de 40 bits)
    3. -
  3. RC2 avec MD5
    4. -
  4. RC2 avec MD5 (version d'exportation limitée à une clé de 40 bits)
    5. -
  5. IDEA avec MD5
    6. -
  6. DES avec MD5
    7. -
  7. Triple-DES avec MD5
    8. +
  8. RC4 avec SHA1
    9. +
  9. AES avec SHA1
    10. +
  10. Triple-DES avec SHA1
-

Pour déterminer la liste réelle des algorithmes disponibles, vous +

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 +<section id="adh"><title>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 +

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 +``-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 +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 +l'exemple préconfiguré dans extra/httpd-ssl.conf), 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 +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 +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 +"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 +

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 +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 +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 :

+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. Voir la question suivante pour +contourner ce problème.

+
+ +
Est-il 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.

+ +

C'est possible, mais seulement si on utilise une version 2.2.12 + ou supérieure du serveur web compilée avec OpenSSL + version 0.9.8j ou supérieure. Ceci est du au fait que + l'utilisation de l'hébergement virtuel à base de nom + avec SSL nécessite une fonctionnalité appelée + Indication du Nom de Serveur (Server Name Indication - SNI) que + seules les révisions les plus récentes de la + spécification SSL supportent.

+ +

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 contenait aucun + en-tête Host:, le serveur n'avait aucun moyen de déterminer quel hôte virtuel SSL il + devait utiliser. En général, il utilisait le premier + qu'il trouvait et qui + correspondait à l'adresse IP et au port spécifiés.

+ +

Par contre, si vous utilisez des versions du serveur web et + d'OpenSSL qui supportent SNI, et si le navigateur du client le + supporte aussi, alors le nom d'hôte sera inclus dans la + requête SSL originale, et le serveur web pourra + sélectionner le bon serveur virtuel SSL.

+ +

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 @@ -827,305 +692,235 @@ pour différencier plusieurs hôtes virtuels ?

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.

+

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

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 +

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

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 +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 :

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

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 ? +disponibles en cas de problème avec mod_ssl ?

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

+ici en cas de problème.

-
Vous trouverez des réponses dans la Foire Aux Questions du +
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 + (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.

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

    -
  1. 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. -
    2. - -
  2. Envoyez un rapport de problème à la liste de diffusion de +
  3. 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 + 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 + problème avec l'ensemble de la communauté d'utilisateurs d'Apache httpd.
    4. -
  4. Ecrire un rapport de problème dans la base de données des +
  5. 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é + 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. + mentionnée ci-dessus avec soin.
Quelles informations dois-je fournir lors -de l'écriture d'un rapport de bogue ? +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 +
Les versions d'Apache httpd 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
+
Les détails de votre installation d'Apache httpd et 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 + 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. + 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. +
En cas de vidage mémoire, inclure une trace de ce qui s'est + passé
+
Si votre serveur Apache httpd 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
+
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. +
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, +<section id="coredumphelp"><title>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.

+

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) :

+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) :

    -
  1. 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 +
  2. 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.
    3. -
  3. Démarrez le serveur et essayez de reproduire le vidage mémoire. +
  4. 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 + ``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 + 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). + 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).
    5. -
  5. Analysez le vidage mémoire. Pour cela, exécutez +
  6. 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 + 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. + débogueurs autres que GDB consulter le manuel correspondant.
diff --git a/docs/manual/ssl/ssl_howto.xml.fr b/docs/manual/ssl/ssl_howto.xml.fr index 484e50c571..11e84a1cfe 100644 --- a/docs/manual/ssl/ssl_howto.xml.fr +++ b/docs/manual/ssl/ssl_howto.xml.fr @@ -1,7 +1,7 @@ - + @@ -46,6 +46,24 @@ solution de sécurité sans connaître ses restrictions et la m interagit avec les autres systèmes.

+
+Exemple de configuration basique + +

Votre configuration SSL doit comporter au moins les directives +suivantes :

+ + + Listen 443 + <VirtualHost _default_:443>
+ ServerName www.domain.com
+ SSLEngine on
+ SSLCertificateFile /chemin/vers/www.comain.com.cert
+ SSLCertificateKeyFile /chemin/vers/www.domain.com.key
+ </VirtualHost> + + +
+
Suites de chiffrement et mise en application de la sécurité de haut niveau