Added: httpd/httpd/trunk/docs/manual/ssl/ssl_faq.xml.fr
URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/ssl/ssl_faq.xml.fr?rev=795191&view=auto
==============================================================================
--- httpd/httpd/trunk/docs/manual/ssl/ssl_faq.xml.fr (added)
+++ httpd/httpd/trunk/docs/manual/ssl/ssl_faq.xml.fr Fri Jul 17 18:46:11 2009
@@ -0,0 +1,1133 @@
+<?xml version="1.0" encoding="ISO-8859-1" ?>
+<!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
+<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
+<!-- English revision : 734692 -->
+<!-- French translation : Lucien GENTIS -->
+<!-- Reviewed by : Vincent Deffontaines -->
+
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+<manualpage metafile="ssl_faq.xml.meta">
+<parentdocument href="./">SSL/TLS</parentdocument>
+
+ <title>Chiffrement SSL/TLS fort: foire aux questions</title>
+
+<summary>
+<blockquote>
+<p>Le sage n'apporte pas de bonnes réponses, il pose les bonnes questions</p>
+<p class="cite">-- <cite>Claude Levi-Strauss</cite></p>
+
+</blockquote>
+<p>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
+<code><a href="news:comp.infosystems.www.servers.unix"
+>comp.infosystems.www.servers.unix</a></code> ou dans la liste de diffusion du
+support mod_ssl <code><a href="mailto:modssl-users@modssl.org"
+>modssl-users@modssl.org</a></code>. Elles ont été rassemblées ici afin
+de ne pas avoir à répondre encore et encore aux mêmes questions.</p>
+
+<p>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.</p>
+</summary>
+
+<section id="about"><title>A propos de mod_ssl</title>
+<ul>
+<li><a href="#history">Quel est l'historique de mod_ssl ?</a></li>
+<li><a href="#wassenaar">mod_ssl et l'arrangement Wassenaar</a></li>
+</ul>
+
+<section id="history"><title>Quel est l'historique de mod_ssl ?</title>
+<p>Le paquet mod_ssl version 1 a été créé en avril 1998 par <a
+ href="mailto:rse@engelschall.com">Ralf S. Engelschall</a> par portage des
+ patches sources 1.17 du module <a
+ href="http://www.apache-ssl.org/">Apache-SSL</a> de <a
+ href="mailto:ben@algroup.co.uk">Ben Laurie</a> 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. </p>
+
+ <p>Quand les restrictions à l'exportation des US sur les logiciels de
+ cryptographie furent assouplis, <module>mod_ssl</module> devint partie
+ intégrante du serveur HTTP Apache à partir de la distribution de
+ Apache httpd 2.</p>
+</section>
+
+<section id="wassenaar"><title>mod_ssl est-il concerné par
+l'arrangement Wassenaar ?</title>
+<p>Tout d'abord, examinons en quoi consiste <dfn>Wassenaar</dfn> et son
+<dfn>Arrangement sur le contrôle de l'exportation des armes conventionnelles
+et le double usage des biens et des technologies</dfn> : 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 <dfn>CoCom</dfn>. Pour plus de détails sur
+l'arrangement et ses signataires, se référer à <a
+ href="http://www.wassenaar.org/">http://www.wassenaar.org/</a>.</p>
+
+ <p>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.</p>
+
+ <p>Dans l'actuelle <cite>List of Dual Use Goods and Technologies And
+ Munitions</cite>, sous <q>GENERAL SOFTWARE NOTE (GSN)</q>, il est écrit
+ <q>La liste ne prend pas en compte les "logiciels" qui sont soit :
+ 1. [...] 2. "dans le domaine public".</q> Et sous
+ <q>DEFINITIONS OF TERMS USED IN THESE LISTS</q>, <q>In the public
+ domain</q> est défini comme <q>"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".</q></p>
+
+ <p>Ainsi, selon l'Arrangement Wassenaar et sa <q>List of Dual Use Goods and
+ Technologies And Munitions List</q>, mod_ssl et OpenSSL appartiennent au
+ <q>domaine public</q>, et ne sont donc pas concernés
+ par les dispositions de l'arrangement.</p>
+
+</section>
+</section>
+<!-- /about -->
+
+<section id="installation"><title>Installation</title>
+<ul>
+<li><a href="#mutex">Pourquoi le démarrage d'Apache provoque-t-il des
+erreurs de permission en rapport avec SSLMutex ?</a></li>
+<li><a href="#entropy">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 ?</a></li>
+</ul>
+
+<section id="mutex"><title>Pourquoi le démarrage d'Apache provoque-t-il des
+erreurs de permission en rapport avec SSLMutex ?</title>
+ <p>Des erreurs telles que ``<code>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)</code>''
+ sont souvent provoquées par des permissions trop restrictives sur les
+ répertoires <em>parents</em>. Assurez-vous que tous les répertoires
+ parents (ici <code>/opt</code>, <code>/opt/apache</code> et
+ <code>/opt/apache/logs</code>) ont le bit x positionné au moins pour
+ l'UID sous lequel les processus enfants d'Apache s'exécutent (voir la
+ directive <directive module="mpm_common">User</directive>).</p>
+</section>
+
+<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 ?</title>
+ <p>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
+ <code>/dev/random</code>). 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.</p>
+ <p>Pour éviter cette erreur, <module>mod_ssl</module> doit fournir
+ suffisamment d'entropie au PRNG pour lui permettre de fonctionner
+ correctement. Ce niveau d'entropie est défini par la directive
+ <directive module="mod_ssl">SSLRandomSeed</directive>.</p>
+</section>
+</section>
+<!-- /installation -->
+
+<section id="aboutconfig"><title>Configuration</title>
+<ul>
+<li><a href="#parallel">Peut-on faire cohabiter HTTP et HTTPS sur le même
+serveur ?</a></li>
+<li><a href="#ports">Quel port HTTPS utilise-t-il ?</a></li>
+<li><a href="#httpstest">Comment s'exprimer en langage HTTPS à des fins
+de test ?</a></li>
+<li><a href="#hang">Pourquoi la communication se bloque-t-elle lorsque je
+me connecte à mon serveur Apache configuré pour SSL ?</a></li>
+<li><a href="#refused">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 ?</a></li>
+<li><a href="#envvars">Pourquoi les variables <code>SSL_XXX</code>
+ne sont-elles pas disponibles dans mes scripts CGI et SSI ?</a></li>
+<li><a href="#relative">Comment puis-je basculer entre les protocoles HTTP et
+HTTPS dans les hyperliens relatifs ?</a></li>
+</ul>
+
+<section id="parallel"><title>Peut-on faire cohabiter HTTP et HTTPS sur le même
+serveur ?</title>
+ <p>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.</p>
+</section>
+
+<section id="ports"><title>Quel port HTTPS utilise-t-il ?</title>
+<p>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 <code>https://example.com:8080/</code>.</p>
+</section>
+
+<section id="httpstest"><title>Comment s'exprimer en langage HTTPS à des fins
+de test ?</title>
+ <p>Alors que vous utilisez simplement</p>
+
+ <example>$ telnet localhost 80<br />
+ GET / HTTP/1.0</example>
+
+ <p>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 <code>s_client</code> vous permet cependant
+ d'effectuer un test similaire via HTTPS :</p>
+
+ <example>$ openssl s_client -connect localhost:443 -state -debug<br />
+ GET / HTTP/1.0</example>
+
+ <p>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 <a href="http://curl.haxx.se/">cURL</a>. Grâce à lui,
+ vous pouvez vérifier si Apache répond correctement aux requêtes via
+ HTTP et HTTPS comme suit :</p>
+
+ <example>$ curl http://localhost/<br />
+ $ curl https://localhost/</example>
+</section>
+
+<section id="hang"><title>Pourquoi la communication se bloque-t-elle lorsque je
+me connecte à mon serveur Apache configuré pour SSL ?</title>
+<p>Ceci peut arriver si vous vous connectez à un serveur HTTPS (ou à
+un serveur virtuel) via HTTP (par exemple, en utilisant
+<code>http://example.com/</code> au lieu de <code>https://example.com</code>).
+Cela peut aussi arriver en essayant de vous connecter via HTTPS à un
+serveur HTTP (par exemple, en utilisant <code>https://example.com/</code>
+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.</p>
+</section>
+
+<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 ?</title>
+<p>Une configuration incorrecte peut provoquer ce type d'erreur.
+Assurez-vous que vos directives <directive module="mpm_common"
+ >Listen</directive> s'accordent avec vos directives
+ <directive type="section" module="core">VirtualHost</directive>. Si
+ l'erreur persiste, recommencez depuis le début en restaurant la
+ configuration par défaut fournie par<module>mod_ssl</module>.</p>
+</section>
+
+<section id="envvars"><title>Pourquoi les variables <code>SSL_XXX</code>
+ne sont-elles pas disponibles dans mes scripts CGI et SSI ?</title>
+<p>Assurez-vous que la directive ``<code>SSLOptions +StdEnvVars</code>'' est
+bien présente dans le contexte de vos requêtes CGI/SSI.</p>
+</section>
+
+<section id="relative">
+<title>Comment puis-je basculer entre les protocoles HTTP et
+HTTPS dans les hyperliens relatifs ?</title>
+<p>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 <module>mod_rewrite</module>, vous pouvez
+manipuler des hyperliens relatifs, pour obtenir le même effet.</p>
+ <example>
+ RewriteEngine on<br />
+ RewriteRule ^/(.*):SSL$ https://%{SERVER_NAME}/$1 [R,L]<br />
+ RewriteRule ^/(.*):NOSSL$ http://%{SERVER_NAME}/$1 [R,L]
+ </example>
+
+ <p>Ce jeu de règles rewrite vous permet d'utiliser des hyperliens de la
+ forme <code><a href="document.html:SSL"></code> pour passer en HTTPS
+ dans les liens relatifs. (Remplacez SSL par NOSSL pour passer en HTTP.)</p>
+</section>
+</section>
+<!-- configuration -->
+
+<section id="aboutcerts"><title>Certificats</title>
+<ul>
+<li><a href="#keyscerts">Qu'est-ce qu'un clé privée RSA, un certificat,
+une demande de signature de certificat (CSR) ?</a></li>
+<li><a href="#startup">Y a-t-il une différence au démarrage entre un serveur
+Apache non SSL et un serveur Apache supportant SSL ?</a></li>
+<li><a href="#selfcert">Comment créer un certificat auto-signé SSL à des
+fins de test ?</a></li>
+<li><a href="#realcert">Comment créer un vrai certificat SSL ?</a></li>
+<li><a href="#ownca">Comment créer et utiliser sa propre Autorité de
+certification (CA) ?</a></li>
+<li><a href="#passphrase">Comment modifier le mot de passe
+de ma clé privée ?</a></li>
+<li><a href="#removepassphrase">Comment démarrer Apache sans avoir à entrer de
+mot de passe ?</a></li>
+<li><a href="#verify">Comment vérifier si une clé privée correspond bien
+à son certificat ?</a></li>
+<li><a href="#badcert">Pour quelle raison une connexion échoue-t-elle avec
+l'erreur "alert bad certificate" ?</a></li>
+<li><a href="#keysize">Pourquoi ma clé privée de 2048 bits ne
+fonctionne-t-elle pas ?</a></li>
+<li><a href="#hashsymlinks">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 ?</a></li>
+<li><a href="#pemder">Comment convertir un certificat du format PEM
+au format DER ?</a></li>
+<li><a href="#verisign">Pourquoi ne trouve-t-on pas les programmes
+<code>getca</code> ou <code>getverisign</code> mentionnés par Verisign
+pour installer un certificat Verisign ?</a></li>
+<li><a href="#sgc">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 ?</a></li>
+<li><a href="#gid">Pourquoi les navigateurs se plaignent-ils de ne pas pouvoir
+vérifier mon certificat de serveur Verisign Global ID ?</a></li>
+</ul>
+
+<section id="keyscerts"><title>Qu'est-ce qu'un clé privée RSA, un certificat,
+une demande de signature de certificat (CSR) ?</title>
+<p>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.</p>
+ <p>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.</p>
+ <p>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.</p>
+ <p>Se référer au chapitre <a href="ssl_intro.html">Introduction</a>
+ pour une description générale du protocole SSL.</p>
+</section>
+
+<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 ?</title>
+<p>Oui. En général, avec ou sans <module>mod_ssl</module> 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.</p>
+
+ <p>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 <a href="#removepassphrase">ci-dessous</a> 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 !</p>
+</section>
+
+<section id="selfcert"><title>Comment créer un certificat auto-signé SSL à des
+fins de test ?</title>
+ <ol>
+ <li>Vérifiez qu'OpenSSL est installé et l'exécutable openssl dans votre
+ <code>PATH</code>.<br />
+ <br />
+ </li>
+ <li>Exécuter la commande suivante pour créer les fichiers
+ <code>server.key</code> et <code>server.crt</code> :<br />
+ <code><strong>$ openssl req -new -x509 -nodes -out server.crt
+ -keyout server.key</strong></code><br />
+ Ces fichiers seront utilisés comme suit dans votre
+ <code>httpd.conf</code> :
+ <pre>
+ SSLCertificateFile /chemin/vers/server.crt
+ SSLCertificateKeyFile /chemin/vers/server.key
+ </pre>
+ </li>
+ <li>Il est important de savoir que le fichier <code>server.key</code> n'a
+ <em>pas</em> 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é.<br />
+ <p><code><strong>$ openssl rsa -des3 -in server.key -out
+ server.key.new</strong></code><br />
+ <code><strong>$ mv server.key.new server.key</strong></code><br /></p>
+ Sauvegardez le fichier <code>server.key</code> ainsi que son mot de
+ passe en lieu sûr.
+ </li>
+ </ol>
+</section>
+
+<section id="realcert"><title>Comment créer un vrai certificat SSL ?</title>
+<p>Voici la marche à suivre pas à pas :</p>
+ <ol>
+ <li>Assurez-vous qu'OpenSSL est bien installé et dans votre <code>PATH</code>.
+ <br />
+ <br />
+ </li>
+ <li>Créez une clé privée RSA pour votre serveur Apache
+ (elle sera au format PEM et chiffrée en Triple-DES):<br />
+ <br />
+ <code><strong>$ openssl genrsa -des3 -out server.key 1024</strong></code><br />
+ <br />
+ Enregistrez le fichier <code>server.key</code> 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 :<br />
+
+ <br />
+ <code><strong>$ openssl rsa -noout -text -in server.key</strong></code><br />
+ <br />
+ Si nécessaire, vous pouvez aussi créer une version PEM non chiffrée
+ (non recommandé) de clé privée RSA avec :<br />
+ <br />
+ <code><strong>$ openssl rsa -in server.key -out server.key.unsecure</strong></code><br />
+ <br />
+
+ </li>
+ <li>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):<br />
+ <br />
+ <code><strong>$ openssl req -new -key server.key -out server.csr</strong></code><br />
+ <br />
+ 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
+ <code>https://www.foo.dom/</code>, le FQDN sera "www.foo.dom". Vous
+ pouvez afficher les détails de ce CSR avec :<br />
+
+ <br />
+ <code><strong>$ openssl req -noout -text -in server.csr</strong></code><br />
+ <br />
+ </li>
+ <li>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.<br />
+ 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 <a href="#ownca">ci-dessous</a>.<br />
+
+ Une fois la CSR signée, vous pouvez afficher les détails du certificat
+ comme suit :<br />
+ <br />
+ <code><strong>$ openssl x509 -noout -text -in server.crt</strong></code><br />
+
+ </li>
+ <li>Vous devez maintenant disposer de deux fichiers :
+ <code>server.key</code> et <code>server.crt</code>. Ils sont précisés dans
+ votre fichier <code>httpd.conf</code> comme suit :
+ <pre>
+ SSLCertificateFile /chemin/vers/server.crt
+ SSLCertificateKeyFile /chemin vers/server.key
+ </pre>
+ Le fichier <code>server.csr</code> n'est plus nécessaire.
+ </li>
+
+ </ol>
+</section>
+
+<section id="ownca"><title>Comment créer et utiliser sa propre Autorité de
+certification (CA) ?</title>
+ <p>La solution la plus simple consiste à utiliser les scripts
+ <code>CA.sh</code> ou <code>CA.pl</code> 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 :</p>
+
+ <ol>
+ <li>Créez une clé privée RSA pour votre serveur
+ (elle sera au format PEM et chiffrée en Triple-DES) :<br />
+ <br />
+ <code><strong>$ openssl genrsa -des3 -out server.key 1024</strong></code><br />
+ <br />
+ Sauvegardez le fichier <code>host.key</code> 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 :<br />
+ <code><strong>$ openssl rsa -noout -text -in server.key</strong></code><br />
+ <br />
+ Si nécessaire, vous pouvez aussi créer une version PEM non chiffrée
+ (non recommandé) de cette clé privée RSA avec :<br />
+ <br />
+ <code><strong>$ openssl rsa -in server.key -out server.key.unsecure</strong></code><br />
+ <br />
+ </li>
+ <li>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) :<br />
+ <br />
+ <code><strong>$ openssl req -new -x509 -nodes -sha1 -days 365
+ -key server.key -out server.crt</strong></code><br />
+ <br />
+ Cette commande signe le certificat du serveur et produit un fichier
+ <code>server.crt</code>. Vous pouvez afficher les détails de ce
+ certificat avec :<br />
+ <br />
+ <code><strong>$ openssl x509 -noout -text -in server.crt</strong></code><br />
+ <br />
+ </li>
+ </ol>
+</section>
+
+<section id="passphrase"><title>Comment modifier le mot de passe
+de ma clé privée ?</title>
+<p>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 :</p>
+
+
+ <p><code><strong>$ openssl rsa -des3 -in server.key -out server.key.new</strong></code><br />
+ <code><strong>$ mv server.key.new server.key</strong></code><br /></p>
+
+ <p>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.</p>
+</section>
+
+<section id="removepassphrase"><title>Comment démarrer Apache sans avoir à entrer de
+mot de passe ?</title>
+<p>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 !</p>
+ <ol>
+ <li>Supprimer le chiffrement de la clé privée RSA (tout en conservant une
+ copie de sauvegarde du fichier original) :<br />
+ <br />
+ <code><strong>$ cp server.key server.key.org</strong></code><br />
+ <code><strong>$ openssl rsa -in server.key.org -out server.key</strong></code><br />
+
+ <br />
+ </li>
+ <li>Assurez-vous que le fichier server.key n'est lisible que par root :<br />
+ <br />
+ <code><strong>$ chmod 400 server.key</strong></code><br />
+ <br />
+ </li>
+ </ol>
+
+ <p>Maintenant, <code>server.key</code> 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).</p>
+
+ <p>Une autre alternative consiste à utiliser la directive
+ ``<code>SSLPassPhraseDialog exec:/chemin/vers/programme</code>''. Gardez
+ cependant à l'esprit que ce n'est bien entendu ni plus ni moins
+ sécurisé.</p>
+</section>
+
+<section id="verify"><title>Comment vérifier si une clé privée correspond bien
+à son certificat ?</title>
+<p>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é.</p>
+ <p>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 :</p>
+
+ <p><code><strong>$ openssl x509 -noout -text -in server.crt</strong></code><br />
+ <code><strong>$ openssl rsa -noout -text -in server.key</strong></code></p>
+
+ <p>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 :</p>
+
+ <p><code><strong>$ openssl x509 -noout -modulus -in server.crt | openssl md5</strong></code><br />
+ <code><strong>$ openssl rsa -noout -modulus -in server.key | openssl md5</strong></code></p>
+
+ <p>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.</p>
+ <p>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 :</p>
+
+ <p><code><strong>$ openssl req -noout -modulus -in server.csr | openssl md5</strong></code></p>
+</section>
+
+<section id="badcert"><title>>Pour quelle raison une connexion échoue-t-elle avec
+l'erreur "alert bad certificate" ?</title>
+<p>Les erreurs du type <code>OpenSSL: error:14094412: SSL
+ routines:SSL3_READ_BYTES:sslv3 alert bad certificate</code> 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.</p>
+</section>
+
+<section id="keysize"><title>Pourquoi ma clé privée de 2048 bits ne
+fonctionne-t-elle pas ?</title>
+<p>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.</p>
+</section>
+
+<section id="hashsymlinks"><title>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 ?</title>
+<p>Les certificats de CA situés dans le chemin que vous avez
+défini à l'aide de <code>SSLCACertificatePath</code> 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
+`<code>openssl x509 -noout -hash</code>'. 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 <code>Makefile</code> fourni par
+<module>mod_ssl</module>.</p>
+</section>
+
+<section id="pemder"><title>Comment convertir un certificat du format PEM
+au format DER ?</title>
+<p>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 <code>cert.pem</code> en son équivalent
+au format DER <code>cert.der</code> à l'aide de la commande suivante :
+<code><strong>$ openssl x509 -in cert.pem -out cert.der
+-outform DER</strong></code></p>
+</section>
+
+<section id="verisign"><title>Pourquoi ne trouve-t-on pas les programmes
+<code>getca</code> ou <code>getverisign</code> mentionnés par Verisign
+pour installer un certificat Verisign ?</title>
+<p>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).</p>
+<p>Pour installer votre certificat, il vous suffit d'enregistrer le
+certificat dans un fichier, et de fournir le nom de ce fichier à la directive
+<directive module="mod_ssl">SSLCertificateFile</directive>. Vous devez aussi
+fournir le nom du fichier contenant la clé privée. Pour plus de détails, voir
+la directive <directive module="mod_ssl">SSLCertificateKeyFile</directive>.</p>
+</section>
+
+<section id="sgc"><title>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 ?</title>
+<p>Oui. <module>mod_ssl</module> 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 <em>mise à niveau</em> des clients
+est gérée automatiquement par <module>mod_ssl</module> à l'exécution.</p>
+</section>
+
+<section id="gid"><title>Pourquoi les navigateurs se plaignent-ils de ne pas pouvoir
+vérifier mon certificat de serveur Verisign Global ID ?</title>
+<p>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
+<directive module="mod_ssl">SSLCertificateChainFile</directive>. 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.</p>
+</section>
+</section>
+<!-- /certs -->
+
+<section id="aboutssl"><title>Le protocole SSL</title>
+<ul>
+<li><a href="#random">Pourquoi de nombreuses et aléatoires erreurs de
+protocole SSL apparaissent-elles en cas de forte charge du serveur ?</a></li>
+<li><a href="#load">Pourquoi la charge de mon serveur est-elle plus
+importante depuis qu'il sert des ressources chiffrées en SSL ?</a></li>
+<li><a href="#establishing">Pourquoi les connexions en HTTPS à mon serveur
+prennent-elles parfois jusqu'à 30 secondes pour s'établir ?</a></li>
+<li><a href="#ciphers">Quels sont les algorithmes de chiffrement
+supportés par mod_ssl ?</a></li>
+<li><a href="#adh">Pourquoi une erreur ``no shared cipher'' apparaît-elle
+quand j'essaie d'utiliser un algorithme de chiffrement
+Diffie-Hellman anonyme (ADH) ?</a></li>
+<li><a href="#sharedciphers">Pourquoi une erreur ``no shared cipher''
+apparaît-elle lorsqu'on se connecte à mon serveur
+fraîchement installé ?</a></li>
+<li><a href="#vhosts">Pourquoi ne peut-on pas utiliser SSL avec des hôtes
+virtuels identifiés par un nom et non par une adresse IP ?</a></li>
+<li><a href="#vhosts2">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 ?</a></li>
+<li><a href="#comp">Comment mettre en oeuvre la compression SSL ?</a></li>
+<li><a href="#lockicon">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 ?</a></li>
+<li><a href="#msie">Pourquoi des erreurs d'entrée/sortie apparaissent-elles
+lorsqu'on se connecte à un serveur Apache+mod_ssl avec
+Microsoft Internet Explorer (MSIE) ?</a></li>
+<li><a href="#nn">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 ?</a></li>
+</ul>
+
+<section id="random"><title>Pourquoi de nombreuses et aléatoires erreurs de
+protocole SSL apparaissent-elles en cas de forte charge du serveur ?</title>
+<p>Ce problème peut avoir plusieurs causes, mais la principale réside dans le
+cache de session SSL défini par la directive
+<directive module="mod_ssl">SSLSessionCache</directive>. 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).</p>
+</section>
+
+<section id="load"><title>Pourquoi la charge de mon serveur est-elle plus
+importante depuis qu'il sert des ressources chiffrées en SSL ?</title>
+<p>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.</p>
+</section>
+
+<section id="establishing"><title>Pourquoi les connexions en HTTPS à mon serveur
+prennent-elles parfois jusqu'à 30 secondes pour s'établir ?</title>
+<p>Ce problème provient en général d'un périphérique <code>/dev/random</code>
+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
+<directive module="mod_ssl">SSLRandomSeed</directive>.</p>
+</section>
+
+<section id="ciphers"><title>Quels sont les algorithmes de chiffrement
+supportés par mod_ssl ?</title>
+<p>En général, tous les algorithmes de chiffrement supportés par la version
+d'OpenSSL installée, le sont aussi par <module>mod_ssl</module>. 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 :</p>
+
+ <ol>
+ <li>RC4 avec MD5</li>
+ <li>RC4 avec MD5 (version d'exportation limitée à une clé de 40 bits)</li>
+ <li>RC2 avec MD5</li>
+ <li>RC2 avec MD5 (version d'exportation limitée à une clé de 40 bits)</li>
+ <li>IDEA avec MD5</li>
+ <li>DES avec MD5</li>
+ <li>Triple-DES avec MD5</li>
+ </ol>
+
+ <p>Pour déterminer la liste réelle des algorithmes disponibles, vous
+ pouvez utiliser la commande suivante :</p>
+ <example>$ openssl ciphers -v</example>
+</section>
+
+<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) ?</title>
+<p>Par défaut et pour des raisons de sécurité, OpenSSl ne permet <em>pas</em>
+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.</p>
+<p>Pour pouvoir utiliser les algorithmes de chiffrements Diffie-Hellman
+anonymes (ADH), vous devez compiler OpenSSL avec
+``<code>-DSSL_ALLOW_ADH</code>'', puis ajouter ``<code>ADH</code>'' à votre
+directive <directive module="mod_ssl">SSLCipherSuite</directive>.</p>
+</section>
+
+<section id="sharedciphers"><title>Pourquoi une erreur ``no shared cipher''
+apparaît-elle lorsqu'on se connecte à mon serveur
+fraîchement installé ?</title>
+<p>Soit vous avez fait une erreur en définissant votre directive
+<directive module="mod_ssl">SSLCipherSuite</directive> (comparez-la avec
+l'exemple préconfiguré dans <code>httpd.conf-dist</code>), 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.</p>
+</section>
+
+<section id="vhosts"><title>Pourquoi ne peut-on pas utiliser SSL avec des hôtes
+virtuels identifiés par un nom et non par une adresse IP ?</title>
+<p>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 <code>Host</code>. 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 !</p>
+</section>
+
+<section id="vhosts2"><title>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 ?</title>
+ <p>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.</p>
+
+ <p>Et là, on reçoit un choc en apprenant que ce n'est pas possible.</p>
+
+ <p>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.</p>
+
+ <p>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 :</p>
+
+ <example>
+ NameVirtualHost 192.168.1.1:80
+ </example>
+
+ <p>il existe d'autres solutions alternatives comme :</p>
+
+ <p>Utiliser des adresses IP différentes pour chaque hôte SSL.
+ Utiliser des numéros de port différents pour chaque hôte SSL.</p>
+</section>
+
+<section id="comp"><title>Comment mettre en oeuvre la compression SSL ?</title>
+<p>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.
+</p>
+<p>Depuis la version 0.9.8, OpenSSL supporte cette compression par défaut
+lorsqu'il est compilé avec l'option <code>zlib</code>. 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 <code>%{SSL_COMPRESS_METHOD}x</code>.
+</p>
+</section>
+
+<section id="lockicon"><title>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 ?</title>
+<p>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.</p>
+</section>
+
+<section id="msie"><title>Pourquoi des erreurs d'entrée/sortie apparaissent-elles
+lorsqu'on se connecte à un serveur Apache+mod_ssl avec
+Microsoft Internet Explorer (MSIE) ?</title>
+<p>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 :</p>
+ <example>
+ SetEnvIf User-Agent ".*MSIE.*" \<br />
+ nokeepalive ssl-unclean-shutdown \<br />
+ downgrade-1.0 force-response-1.0
+ </example>
+ <p>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
+ <directive module="mod_setenvif">SetEnvIf</directive> 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 <em>tous</em> vos clients, ceux utilisant MSIE,
+ mais aussi les autres.</p>
+
+ <p>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 :</p>
+ <example>SSLProtocol all -SSLv3</example>
+ <p>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.</p>
+ <example><p><code>SSLCipherSuite
+ ALL:!ADH:<strong>!EXPORT56</strong>:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP</code>
+ </p></example>
+
+ <p>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.</p>
+
+ <p>Autre problème avec les clients MSIE 5.x : ils refusent de se
+ connecter à des URLs de la forme <code>https://12.34.56.78/</code>
+ (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.</p>
+
+ <p>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
+ <directive module="mod_ssl">SSLSessionCache</directive>).</p>
+</section>
+
+<section id="nn"><title>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 ?</title>
+<p>
+ 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.</p>
+</section>
+</section>
+<!-- /aboutssl -->
+
+<section id="support"><title>Support de mod_ssl</title>
+<ul>
+<li><a href="#resources">Quelles sont les sources d'informations
+disponibles en cas de problème avec mod_ssl ?</a></li>
+<li><a href="#contact">Qui peut-on contacter pour un support en cas de
+problème avec mod_ssl ?</a></li>
+<li><a href="#reportdetails">Quelles informations dois-je fournir lors
+de l'écriture d'un rapport de bogue ?</a></li>
+<li><a href="#coredumphelp">Un vidage mémoire s'est produit,
+pouvez-vous m'aider ?</a></li>
+<li><a href="#backtrace">Comment puis-je obtenir une journalisation de
+ce qui s'est passé, pour m'aider à trouver la raison de ce vidage
+mémoire ?</a></li>
+</ul>
+
+<section id="resources"><title>Quelles sont les sources d'informations
+disponibles en cas de problème avec mod_ssl ?</title>
+<p>Voici les sources d'informations disponibles ; vous devez chercher
+ici en cas de problème.</p>
+
+ <dl>
+ <dt>Vous trouverez des réponses dans la Foire Aux Questions du
+ manuel utilisateur (ce document)</dt>
+ <dd><a href="http://httpd.apache.org/docs/&httpd.docs;/ssl/ssl_faq.html">
+ http://httpd.apache.org/docs/&httpd.docs;/ssl/ssl_faq.html</a><br />
+ 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.
+ </dd>
+ <dt>Les archives de la liste de diffusion de support modssl-users
+ <a href="http://www.modssl.org/support/"
+ >http://www.modssl.org/support/</a></dt>
+ <dd>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 !
+ </dd>
+ </dl>
+</section>
+
+<section id="contact"><title>Qui peut-on contacter pour un support en cas de
+problème avec mod_ssl ?</title>
+ <p>Voici toutes les possibilités de support pour mod_ssl, par ordre
+ de préférence. Merci d'utiliser ces possibilités
+ <em>dans cet ordre</em> - ne vous précipitez pas sur celle qui vous
+ paraît la plus alléchante. </p>
+ <ol>
+ <li><em>Envoyez un rapport de problème à la liste de diffusion de
+ support modssl-users</em><br />
+ <a href="mailto:modssl-users@modssl.org">
+ modssl-users@modssl.org</a><br />
+ 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.
+ </li>
+
+ <li><em>Envoyez un rapport de problème à la liste de diffusion de
+ support des utilisateurs d'Apache httpd</em><br />
+ <a href="mailto:users@httpd.apache.org">
+ users@httpd.apache.org</a><br />
+ 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.
+ </li>
+
+ <li><em>Ecrire un rapport de problème dans la base de données des
+ bogues</em><br />
+ <a href="http://httpd.apache.org/bug_report.html">
+ http://httpd.apache.org/bug_report.html</a><br />
+ 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 <em>avec soin</em>.
+ </li>
+ </ol>
+</section>
+
+<section id="reportdetails"><title>Quelles informations dois-je fournir lors
+de l'écriture d'un rapport de bogue ?</title>
+<p>Vous devez toujours fournir au moins les informations
+suivantes :</p>
+
+ <dl>
+ <dt>Les versions d'Apache et OpenSSL installées</dt>
+ <dd>La version d'Apache peut être déterminée en exécutant
+ <code>httpd -v</code>. La version d'OpenSSL peut être déterminée
+ en exécutant <code>openssl version</code>. Si Lynx est installé,
+ vous pouvez aussi exécuter la commande<code>lynx -mime_header
+ http://localhost/ | grep Server</code> et ainsi obtenir ces
+ informations en une seule fois.
+ </dd>
+
+ <dt>Les détails de votre installation d'Apache+mod_ssl+OpenSSL</dt>
+ <dd>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 <program>configure</program> que
+ vous avez utilisée.
+ </dd>
+
+ <dt>En cas de vidage mémoire, inclure une trace de ce qui s'est
+ passé</dt>
+ <dd>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
+ <a href="#backtrace">ci-dessous</a> 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.
+ </dd>
+
+ <dt>Une description détaillée de votre problème</dt>
+
+ <dd>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.
+ </dd>
+ </dl>
+</section>
+
+<section id="coredumphelp"><title>Un vidage mémoire s'est produit,
+pouvez-vous m'aider ?</title>
+<p>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.</p>
+</section>
+
+<section id="backtrace"><title>Comment puis-je obtenir une journalisation de
+ce qui s'est passé, pour m'aider à trouver la raison de ce vidage
+mémoire ?</title>
+<p>Vous trouverez ci-dessous les différentes étapes permettant
+d'obtenir une journalisation des évènements (backtrace) :</p>
+ <ol>
+ <li>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
+ ``<code>OPTIM="-g -ggdb3"</code>''. Sur les autres plates-formes,
+ l'option ``<code>OPTIM="-g"</code>'' est un minimum.
+ </li>
+
+ <li>Démarrez le serveur et essayez de reproduire le vidage mémoire.
+ A cet effet, vous pouvez utiliser une directive du style
+ ``<code>CoreDumpDirectory /tmp</code>'' pour être sûr que le
+ fichier de vidage mémoire puisse bien être écrit. Vous devriez
+ obtenir un fichier <code>/tmp/core</code> ou
+ <code>/tmp/httpd.core</code>. 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 <code>setuid()</code> (à moins
+ qu'il effectue un <code>exec()</code>) car des informations d'un
+ niveau privilégié pourraient être transmises en mémoire. Si
+ nécessaire, vous pouvez exécuter <code>/chemin/vers/httpd -X</code>
+ manuellement afin de ne pas permettre à Apache de se clôner (fork).
+ </li>
+
+ <li>Analysez le vidage mémoire. Pour cela, exécutez
+ <code>gdb /path/to/httpd /tmp/httpd.core</code> ou une commande
+ similaire. Dans GDB, tout ce que vous avez à faire est d'entrer
+ <code>bt</code>, et voila, vous obtenez la backtrace. Pour les
+ débogueurs autres que GDB consulter le manuel correspondant.
+ </li>
+ </ol>
+</section>
+</section>
+</manualpage>
Modified: httpd/httpd/trunk/docs/manual/ssl/ssl_faq.xml.meta
URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/ssl/ssl_faq.xml.meta?rev=795191&r1=795190&r2=795191&view=diff
==============================================================================
--- httpd/httpd/trunk/docs/manual/ssl/ssl_faq.xml.meta (original)
+++ httpd/httpd/trunk/docs/manual/ssl/ssl_faq.xml.meta Fri Jul 17 18:46:11 2009
@@ -8,5 +8,6 @@
<variants>
<variant>en</variant>
+ <variant>fr</variant>
</variants>
</metafile>
Modified: httpd/httpd/trunk/docs/manual/ssl/ssl_howto.html
URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/ssl/ssl_howto.html?rev=795191&r1=795190&r2=795191&view=diff
==============================================================================
--- httpd/httpd/trunk/docs/manual/ssl/ssl_howto.html (original)
+++ httpd/httpd/trunk/docs/manual/ssl/ssl_howto.html Fri Jul 17 18:46:11 2009
@@ -3,3 +3,7 @@
URI: ssl_howto.html.en
Content-Language: en
Content-type: text/html; charset=ISO-8859-1
+
+URI: ssl_howto.html.fr
+Content-Language: fr
+Content-type: text/html; charset=ISO-8859-1
Modified: httpd/httpd/trunk/docs/manual/ssl/ssl_howto.html.en
URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/ssl/ssl_howto.html.en?rev=795191&r1=795190&r2=795191&view=diff
==============================================================================
--- httpd/httpd/trunk/docs/manual/ssl/ssl_howto.html.en (original)
+++ httpd/httpd/trunk/docs/manual/ssl/ssl_howto.html.en Fri Jul 17 18:46:11 2009
@@ -18,7 +18,8 @@
<div id="path">
<a href="http://www.apache.org/">Apache</a> > <a href="http://httpd.apache.org/">HTTP Server</a> > <a href="http://httpd.apache.org/docs/">Documentation</a> > <a href="../">Version 2.3</a> > <a href="./">SSL/TLS</a></div><div id="page-content"><div id="preamble"><h1>SSL/TLS Strong Encryption: How-To</h1>
<div class="toplang">
-<p><span>Available Languages: </span><a href="../en/ssl/ssl_howto.html" title="English"> en </a></p>
+<p><span>Available Languages: </span><a href="../en/ssl/ssl_howto.html" title="English"> en </a> |
+<a href="../fr/ssl/ssl_howto.html" hreflang="fr" rel="alternate" title="Français"> fr </a></p>
</div>
<blockquote>
@@ -292,7 +293,8 @@
</div></div>
<div class="bottomlang">
-<p><span>Available Languages: </span><a href="../en/ssl/ssl_howto.html" title="English"> en </a></p>
+<p><span>Available Languages: </span><a href="../en/ssl/ssl_howto.html" title="English"> en </a> |
+<a href="../fr/ssl/ssl_howto.html" hreflang="fr" rel="alternate" title="Français"> fr </a></p>
</div><div id="footer">
<p class="apache">Copyright 2009 The Apache Software Foundation.<br />Licensed under the <a href="http://www.apache.org/licenses/LICENSE-2.0">Apache License, Version 2.0</a>.</p>
<p class="menu"><a href="../mod/">Modules</a> | <a href="../mod/directives.html">Directives</a> | <a href="../faq/">FAQ</a> | <a href="../glossary.html">Glossary</a> | <a href="../sitemap.html">Sitemap</a></p></div>
Added: httpd/httpd/trunk/docs/manual/ssl/ssl_howto.html.fr
URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/ssl/ssl_howto.html.fr?rev=795191&view=auto
==============================================================================
--- httpd/httpd/trunk/docs/manual/ssl/ssl_howto.html.fr (added)
+++ httpd/httpd/trunk/docs/manual/ssl/ssl_howto.html.fr Fri Jul 17 18:46:11 2009
@@ -0,0 +1,341 @@
+<?xml version="1.0" encoding="ISO-8859-1"?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" lang="fr" xml:lang="fr"><head><!--
+ XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+ This file is generated from xml source: DO NOT EDIT
+ XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+ -->
+<title>Chiffrement fort SSL/TLS : Mode d'emploi - Serveur Apache HTTP</title>
+<link href="../style/css/manual.css" rel="stylesheet" media="all" type="text/css" title="Main stylesheet" />
+<link href="../style/css/manual-loose-100pc.css" rel="alternate stylesheet" media="all" type="text/css" title="No Sidebar - Default font size" />
+<link href="../style/css/manual-print.css" rel="stylesheet" media="print" type="text/css" />
+<link href="../images/favicon.ico" rel="shortcut icon" /></head>
+<body id="manual-page"><div id="page-header">
+<p class="menu"><a href="../mod/">Modules</a> | <a href="../mod/directives.html">Directives</a> | <a href="../faq/">FAQ</a> | <a href="../glossary.html">Glossaire</a> | <a href="../sitemap.html">Plan du site</a></p>
+<p class="apache">Serveur Apache HTTP Version 2.3</p>
+<img alt="" src="../images/feather.gif" /></div>
+<div class="up"><a href="./"><img title="<-" alt="<-" src="../images/left.gif" /></a></div>
+<div id="path">
+<a href="http://www.apache.org/">Apache</a> > <a href="http://httpd.apache.org/">Serveur HTTP</a> > <a href="http://httpd.apache.org/docs/">Documentation</a> > <a href="../">Version 2.3</a> > <a href="./">SSL/TLS</a></div><div id="page-content"><div id="preamble"><h1>Chiffrement fort SSL/TLS : Mode d'emploi</h1>
+<div class="toplang">
+<p><span>Langues Disponibles: </span><a href="../en/ssl/ssl_howto.html" hreflang="en" rel="alternate" title="English"> en </a> |
+<a href="../fr/ssl/ssl_howto.html" title="Français"> fr </a></p>
+</div>
+
+<blockquote>
+<p>La solution à ce problème est évidente et le lecteur la recherchera
+à titre d'exercice</p>
+
+<p class="cite">-- <cite>Phrase standard des manuels</cite></p>
+</blockquote>
+
+<p>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.</p>
+</div>
+<div id="quickview"><ul id="toc"><li><img alt="" src="../images/down.gif" /> <a href="#ciphersuites">Suites de chiffrement et mise en application de la sécurité
+de haut niveau</a></li>
+<li><img alt="" src="../images/down.gif" /> <a href="#accesscontrol">Authentification du client et contrôle d'accès</a></li>
+</ul></div>
+<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
+<div class="section">
+<h2><a name="ciphersuites" id="ciphersuites">Suites de chiffrement et mise en application de la sécurité
+de haut niveau</a></h2>
+
+<ul>
+<li><a href="#realssl">Comment créer un véritable serveur
+SSLv2 seulement ?</a></li>
+<li><a href="#onlystrong">Comment créer un serveur SSL
+qui n'accepte que le chiffrement fort ?</a></li>
+<li><a href="#upgradeenc">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 ?</a></li>
+<li><a href="#strongurl">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 ?</a></li>
+</ul>
+
+<h3><a name="realssl" id="realssl">Comment créer un véritable serveur SSLv2 seulement ?</a></h3>
+
+ <p>Les directives suivantes créent un serveur SSL qui ne communique que
+ selon le protocole SSLv2 et ses modes de chiffrement.</p>
+
+ <div class="example"><h3>httpd.conf</h3><p><code>
+ SSLProtocol -all +SSLv2<br />
+ SSLCipherSuite SSLv2:+HIGH:+MEDIUM:+LOW:+EXP<br />
+ </code></p></div>
+
+
+<h3><a name="onlystrong" id="onlystrong">Comment créer un serveur SSL qui n'accepte
+que le chiffrement fort ?</a></h3>
+
+ <p>Les directives suivantes ne permettent que les
+ chiffrements de plus haut niveau :</p>
+ <div class="example"><h3>httpd.conf</h3><p><code>
+ SSLProtocol all<br />
+ SSLCipherSuite HIGH:MEDIUM<br />
+ </code></p></div>
+
+
+<h3><a name="upgradeenc" id="upgradeenc">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 ?</a></h3>
+
+ <p>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).</p>
+ <p>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.</p>
+ <p>Il est possible de parvenir à ceci de cette façon:</p>
+ <div class="example"><h3>httpd.conf</h3><p><code>
+ # autorise tout mode de chiffrement pour l'échange de données
+ initial,<br />
+ # les navigateurs non US peuvent ainsi se mettre à jour
+ via la fonctionnalité SGC<br />
+ SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL<br />
+ <br />
+ <Directory /usr/local/apache2/htdocs><br />
+ # et enfin interdit l'accès à tous les navigateurs qui n'ont pas fait
+ évoluer leur suite de chiffrement<br />
+ SSLRequire %{SSL_CIPHER_USEKEYSIZE} >= 128<br />
+ </Directory>
+ </code></p></div>
+
+
+<h3><a name="strongurl" id="strongurl">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 ?</a></h3>
+
+ <p>Dans ce cas bien évidemment, une directive <code class="directive"><a href="../mod/mod_ssl.html#sslciphersuite">SSLCipherSuite</a></code> au niveau du serveur principal
+ qui restreint le choix des suites de chiffrement aux versions les plus
+ fortes ne conviendra pas. <code class="module"><a href="../mod/mod_ssl.html">mod_ssl</a></code> peut cependant être
+ reconfiguré au sein de blocs <code>Location</code> qui permettent
+ d'adapter la configuration générale à un répertoire spécifique ;
+ <code class="module"><a href="../mod/mod_ssl.html">mod_ssl</a></code> peut alors forcer automatiquement une
+ renégociation des paramètres SSL pour parvenir au but recherché.
+ Cette configuration peut se présenter comme suit :</p>
+ <div class="example"><p><code>
+ # soyons très tolérant a priori<br />
+ SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL<br />
+ <br />
+ <Location /strong/area><br />
+ # sauf pour https://hostname/strong/area/ et ses sous-répertoires<br />
+ # qui exigent des chiffrements forts<br />
+ SSLCipherSuite HIGH:MEDIUM<br />
+ </Location>
+ </code></p></div>
+
+</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
+<div class="section">
+<h2><a name="accesscontrol" id="accesscontrol">Authentification du client et contrôle d'accès</a></h2>
+
+<ul>
+<li><a href="#allclients">Comment forcer les clients
+à s'authentifier à l'aide de certificats ?</a></li>
+<li><a href="#arbitraryclients">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 ?</a></li>
+<li><a href="#certauthenticate">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 ?</a></li>
+<li><a href="#intranet">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 ?</a></li>
+</ul>
+
+<h3><a name="allclients" id="allclients">Comment forcer les clients
+à s'authentifier à l'aide de certificats ?
+</a></h3>
+
+
+ <p>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
+ (<code>ca.crt</code>), et d'authentifier les clients à l'aide de ces
+ certificats.</p>
+ <div class="example"><h3>httpd.conf</h3><p><code>
+ # exige un certificat client signé par le certificat de votre CA<br />
+ # contenu dans ca.crt<br />
+ SSLVerifyClient require<br />
+ SSLVerifyDepth 1<br />
+ SSLCACertificateFile conf/ssl.crt/ca.crt
+ </code></p></div>
+
+
+<h3><a name="arbitraryclients" id="arbitraryclients">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 ?</a></h3>
+
+
+<p>Pour forcer les clients à s'authentifier à l'aide de certificats pour une
+URL particulière, vous pouvez utiliser les fonctionnalités de reconfiguration
+de <code class="module"><a href="../mod/mod_ssl.html">mod_ssl</a></code> en fonction du répertoire :</p>
+
+ <div class="example"><h3>httpd.conf</h3><p><code>
+ SSLVerifyClient none<br />
+ SSLCACertificateFile conf/ssl.crt/ca.crt<br />
+ <br />
+ <Location /secure/area><br />
+ SSLVerifyClient require<br />
+ SSLVerifyDepth 1<br />
+ </Location><br />
+ </code></p></div>
+
+
+<h3><a name="certauthenticate" id="certauthenticate">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 ?</a></h3>
+
+
+ <p>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 <code class="module"><a href="../mod/mod_auth_basic.html">mod_auth_basic</a></code>, soit la
+ directive <code class="directive"><a href="../mod/mod_ssl.html#sslrequire">SSLRequire</a></code>.</p>
+
+ <p>La méthode du module <code class="module"><a href="../mod/mod_auth_basic.html">mod_auth_basic</a></code> 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 <em>tous</em> les clients
+ autorisés, comme suit :</p>
+
+ <div class="example"><h3>httpd.conf</h3><pre>
+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></pre></div>
+
+ <p>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 <code class="directive"><a href="../mod/mod_ssl.html#ssloptions">SSLOptions</a></code> pour
+ plus de détails.</p>
+
+ <div class="example"><h3>httpd.passwd</h3><pre>
+/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</pre></div>
+
+ <p>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 <code class="directive"><a href="../mod/mod_ssl.html#sslrequire">SSLRequire</a></code>, comme suit :</p>
+
+
+ <div class="example"><h3>httpd.conf</h3><pre>
+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></pre></div>
+
+
+<h3><a name="intranet" id="intranet">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.</a></h3>
+
+
+ <p>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
+ <code>/usr/local/apache2/htdocs/subarea</code>. 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.</p>
+
+ <div class="example"><h3>httpd.conf</h3><pre>
+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></pre></div>
+
+</div></div>
+<div class="bottomlang">
+<p><span>Langues Disponibles: </span><a href="../en/ssl/ssl_howto.html" hreflang="en" rel="alternate" title="English"> en </a> |
+<a href="../fr/ssl/ssl_howto.html" title="Français"> fr </a></p>
+</div><div id="footer">
+<p class="apache">Copyright 2009 The Apache Software Foundation.<br />Autorisé sous <a href="http://www.apache.org/licenses/LICENSE-2.0">Apache License, Version 2.0</a>.</p>
+<p class="menu"><a href="../mod/">Modules</a> | <a href="../mod/directives.html">Directives</a> | <a href="../faq/">FAQ</a> | <a href="../glossary.html">Glossaire</a> | <a href="../sitemap.html">Plan du site</a></p></div>
+</body></html>
\ No newline at end of file
|