]> granicus.if.org Git - apache/commitdiff
XML updates.
authorLucien Gentis <lgentis@apache.org>
Sun, 28 Aug 2016 13:57:59 +0000 (13:57 +0000)
committerLucien Gentis <lgentis@apache.org>
Sun, 28 Aug 2016 13:57:59 +0000 (13:57 +0000)
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1758114 13f79535-47bb-0310-9956-ffa450edef68

docs/manual/mod/core.xml.fr
docs/manual/mod/mod_rewrite.xml.fr
docs/manual/ssl/ssl_howto.xml.fr

index fadbddffd5530cc2d899ae17166d16ba3a70e469..2cdc3ed4ee894565dce96289c3a9ade7eb7d2738 100644 (file)
@@ -1,7 +1,7 @@
 <?xml version="1.0" encoding="UTF-8" ?>
 <!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
 <?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
-<!-- English Revision: 1756959:1757920 (outdated) -->
+<!-- English Revision: 1757920 -->
 <!-- French translation : Lucien GENTIS -->
 <!-- Reviewed by : Vincent Deffontaines -->
 
@@ -1358,9 +1358,9 @@ host</context>
 <name>HttpProtocolOptions</name>
 <description>Modifie les contraintes sur les messages des requêtes HTTP</description>
 <syntax>HttpProtocolOptions [Strict|Unsafe] [StrictURL|UnsafeURL]
- [StrictWhitespace|LenientWhitespace] [RegisteredMethods|LenientMethods]
+ [StrictWhitespace|UnsafeWhitespace] [RegisteredMethods|LenientMethods]
  [Allow0.9|Require1.0]</syntax>
-<default>HttpProtocolOptions Strict StrictURL LenientWhitespace 
+ <default>HttpProtocolOptions Strict StrictURL StrictWhitespace
 LenientMethods Allow0.9</default>
 <contextlist><context>server config</context>
 <context>virtual host</context></contextlist>
@@ -1395,7 +1395,7 @@ Apache</compatibility>
     règles de grammaire de la spécification doivent être respectées dans le mode
     d'opérations par défaut <code>Strict</code>.</p>
 
-    <p><a href="https://tools.ietf.org/html/rfc3986#section-2.2">RFC 7230
+    <p><a href="https://tools.ietf.org/html/rfc3986#section-2.2">RFC 3986
     &sect;2.2 and 2.3</a> définit les "Caractères réservés" ainsi que les
     "Caractères non réservés". Tous les autres caractères doivent être encodés
     sous la forme %XX selon la spécification, et la RFC7230 se conforme à ces
@@ -1404,21 +1404,7 @@ Apache</compatibility>
     contournée en utilisant l'option <code>UnsafeURI</code> qui permet de
     supporter les agents utilisateur mal conçus.</p>
     
-    <p>Il est fortement déconseillé aux utilisateurs d'utiliser les modes
-    d'opérations <code>Unsafe</code> et <code>UnsafeURI</code>, en particulier
-    pour les déploiements de serveurs ouverts sur l'extérieur et/ou accessibles
-    au public. Si un moniteur défectueux ou autre logiciel spécialisé ne
-    s'exécutant que sur un intranet nécessite une interface, les utilisateurs
-    ne doivent les utilisés qu'au sein d'un serveur virtuel bien spécifique et
-    sur un réseau privé.</p>
-
-    <p>La consultation des messages enregistrés dans le journal
-    <directive>ErrorLog</directive>, configuré via la directive
-    <directive>LogLevel</directive> avec un niveau <code>info</code>, pourra
-    vous aider à identifier de telles requêtes non conformes ainsi que leur
-    provenance. Les utilisateurs devront accorder une attention particulière aux
-    messages d'erreur de type 400 dans le journal access pour détecter les
-    requêtes apparemment valides mais rejetées.</p>
+    
 
     <p>La section de la <a
     href="https://tools.ietf.org/html/rfc7230#section-3.5">RFC 7230
@@ -1426,14 +1412,31 @@ Apache</compatibility>
     induits par l'interprétation de messages contenant des blancs représentés
     par un caractère autre que l'espace. Alors que les spécifications indiquent
     qu'un et un seul espace sépare l'URI de la méthode et le protocole de l'URI,
+    et que seuls les espaces et les tabulations horizontales sont autorisés
+    dans le contenu des en-têtes de requêtes,
     le serveur HTTP Apache a toujours toléré des blancs constitués d'un ou
     plusieurs espaces ou tabulations horizontales. L'option par défaut
-    <code>LenientWhitespace</code> continue d'accepter de telles requêtes en
-    provenance d'agents utilisateurs non conformes, mais l'administrateur est
-    encouragé à utiliser plutôt l'option <code>StrictWhitespace</code> pour
-    imposer la présence d'exactement deux espaces dans la ligne de requête.
-    D'autres types de blancs comme les tabulations verticales, form feed
-    ou retour chariot seront alors rejetés et ne seront plus supportés.</p>
+    <code>StrictWhitespace</code> permet maintenant de rejeter toute requête non
+    conforme. L'administrateur peut cependant utiliser l'option
+    <code>UnsafeWhitespace</code> pour continuer à accepter les requêtes non
+    conformes, avec un risque important d'interactions avec le mandataire.</p>
+
+    <p>Il est fortement déconseillé aux utilisateurs d'utiliser les modes
+    d'opérations <code>Unsafe</code> et <code>UnsafeURI</code>, ou
+    <code>UnsafeWhitespace</code>, en particulier pour les déploiements de
+    serveurs ouverts sur l'extérieur et/ou accessibles au public. Si un moniteur
+    défectueux ou autre logiciel spécialisé ne s'exécutant que sur un intranet
+    nécessite une interface, les utilisateurs ne doivent utiliser les options de
+    type UnSafe qu'en cas de nécessité et uniquement au sein d'un serveur
+    virtuel bien spécifique et sur un réseau privé.</p>
+
+    <p>La consultation des messages enregistrés dans le journal
+    <directive>ErrorLog</directive>, configuré via la directive
+    <directive>LogLevel</directive> avec un niveau <code>info</code>, pourra
+    vous aider à identifier de telles requêtes non conformes ainsi que leur
+    provenance. Les utilisateurs devront accorder une attention particulière aux
+    messages d'erreur de type 400 dans le journal access pour détecter les
+    requêtes apparemment valides mais rejetées.</p>
 
     <p>La section de la <a
     href="https://tools.ietf.org/html/rfc7231#section-4.1">RFC 7231
@@ -1455,7 +1458,7 @@ Apache</compatibility>
     serveurs HTTP à supporter les anciennes requêtes HTTP/0.9. La RFC 7230 va
     cependant à son encontre via sa préconisation "Le souhait de supporter les
     requêtes HTTP/0.9 a été supprimé" et y adjoint des commentaires dans <a
-    href="https://tools.ietf.org/html/rfc7230#appendix-A">RFC 2616 Appendix
+    href="https://tools.ietf.org/html/rfc7230#appendix-A">RFC 7230 Appendix
     A</a>. A ce titre, l'option <code>Require1.0</code> permet à l'utilisateur
     d'inhiber le comportement induit par l'option par défaut
     <code>Allow0.9</code>.</p>
index c2d01fc787cfcfe8898329b997cec917861cbce8..afb578203f61ad42e6b238aff60f369261aee559 100644 (file)
@@ -1,7 +1,7 @@
 <?xml version="1.0" encoding="UTF-8" ?>
 <!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
 <?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
-<!-- English Revision: 1756567:1757838 (outdated) -->
+<!-- English Revision: 1757838 -->
 <!-- French translation : Lucien GENTIS -->
 <!-- Reviewed by : Vincent Deffontaines -->
 
@@ -483,7 +483,7 @@ AliasMatch "^/myapp" "/opt/myapp-1.2.3"
 la réécriture soit effectuée
 </description>
 <syntax> RewriteCond
-      <em>chaîne_de_test</em> <em>expression_de_comparaison</em></syntax>
+      <em>chaîne_de_test</em> <em>expression_de_comparaison</em> [<em>drapeaux</em>]</syntax>
 <contextlist><context>server config</context><context>virtual host</context>
 <context>directory</context><context>.htaccess</context></contextlist>
 <override>FileInfo</override>
@@ -1041,13 +1041,14 @@ RewriteRule ^(.+) /other/archive/$1 [R]
            RewriteRule "^/images" "-" [F]
            </highlight>
         </li>
+    </ol>
 
-       <li>Vous pouvez aussi définir certains drapeaux pour
+       <p>Vous pouvez aussi définir certains drapeaux pour
        l'<em>expression_de_comparaison</em> en ajoutant ces
        <strong><code>[</code><em>drapeaux</em><code>]</code></strong>
        comme troisième argument de la directive
        <code>RewriteCond</code>, où <em>drapeaux</em> est un
-       sous-ensemble séparé par des virgules des drapeaux suivants :
+       sous-ensemble séparé par des virgules des drapeaux suivants :</p>
 
       <ul>
         <li>'<strong><code>nocase|NC</code></strong>'
@@ -1089,8 +1090,7 @@ RewriteRule ...règles concernant tous ces hôtes...
        fonctionnement de l'en-tête Vary.
         </li>
       </ul>
-      </li>
-     </ol>
+      
 
       <p><strong>Exemple :</strong></p>
 
@@ -1137,46 +1137,47 @@ RewriteRule  "^/$"                 "/homepage.std.html"  [L]
 
       <p><a id="patterns" name="patterns"><em>Modèle</em></a> est une
       <a id="regexp" name="regexp">expression rationnelle</a>
-      compatible perl. Dans la première règle de réécriture,
-      l'expression est comparée au (%-decoded)
-      <a href="directive-dict.html#Syntax">chemin de l'URL</a> de la
-      requête, ou, dans un contexte de répertoire (voir
-      ci-dessous), au chemin de l'URL relativement à ce contexte de
-      répertoire. Les expressions suivantes sont comparées à la sortie de
-      la dernière règle de réécriture qui
-      correspondait.</p>
+      compatible perl. Ce avec quoi ce modèle est comparé dépend de l'endroit où
+      la directive <directive>RewriteRule</directive> est définie.</p>
 
 <note><title><a id="what_is_matched" name="what_is_matched">Qu'est-ce qui est comparé ?</a></title>
 
-      <p>Dans un contexte de serveur virtuel <directive
+<ul>
+      <li><p>Dans un contexte de serveur virtuel <directive
       module="core">VirtualHost</directive>, le <em>modèle</em> est tout
       d'abord comparé à la portion de l'URL située entre le nom d'hôte
       éventuellement accompagné du port, et la chaîne de paramètres (par
-      exemple "/app1/index.html").</p>
-
-      <p>Dans les contextes de répertoire <directive
-      module="core">Directory</directive> et htaccess, le
-      <em>modèle</em> est tout d'abord comparé au chemin du <em>système
-      de fichiers</em>, après suppression du préfixe ou chemin de base
-      ayant conduit le serveur vers la règle <directive>RewriteRule</directive> (par
-      exemple "app1/index.html" ou
-      "index.html" selon l'endroit où les directives sont définies).</p>
+      exemple "/app1/index.html"). Il s'agit du <a
+      href="directive-dict.html#Syntax">URL-path</a> décodé de sa valeur "%xx".</p></li>
+
+      <li><p>Dans un contexte de répertoire (sections <directive
+      module="core">Directory</directive> et fichiers .htaccess), le
+      <em>Modèle</em> est comparé avec une partie de chemin ; par exemple une
+      requête pour "/app1/index.html" entraînera une comparaison avec
+      "app1/index.html" ou "index.html" selon l'endroit où la directive
+      <directive>RewriteRule</directive> est définie.</p>
+
+      <p>Le chemin où la règle est défini est supprimé du chemin correspondant
+      du système de fichiers avant comparaison (jusqu'au slash final compris).
+      En conséquence de cette suppression, les règles définies dans
+      ce contexte n'effectuent des comparaisons qu'avec la portion du chemin
+      du système de fichiers "en dessous" de l'endroit où la règle est définie.</p>
+
+      <p>Le chemin correspondant actuel du système de fichiers est déterminé par
+      des directives telles que <directive>DocumentRoot</directive> et
+      <directive>Alias</directive>, ou même le résultat de substitutions dans
+      des règles <directive>RewriteRule</directive> précédentes.  
+      </p>
+      </li>
 
-      <p>Si vous souhaitez faire une comparaison sur le nom
+      <li><p>Si vous souhaitez faire une comparaison sur le nom
       d'hôte, le port, ou la chaîne de requête, utilisez une
       directive <directive module="mod_rewrite">RewriteCond</directive>
       comportant respectivement les variables
       <code>%{HTTP_HOST}</code>, <code>%{SERVER_PORT}</code>, ou
-      <code>%{QUERY_STRING}</code>.</p>
-
-      <p>Dans tous les cas, il faut garder à l'esprit que les expressions
-      rationnelles permettent de rechercher des correspondances de sous-chaînes.
-      En d'autres termes, l'expression rationnelle n'a pas besoin de correspondre à
-      l'ensemble de la chaîne, mais seulement à la partie que vous souhaitez
-      voir correspondre. Ainsi, l'utilisation de l'expression <code>.</code> est
-      souvent suffisante et préférable à <code>.*</code>, et l'expression
-      <code>abc</code> <strong>n'est pas</strong> identique à l'expression
-      <code>^abc$</code>.</p>
+      <code>%{QUERY_STRING}</code>.</p></li>
+</ul>
+      
 </note>
 
 <note><title>Réécritures dans un contexte de répertoire</title>
@@ -1195,13 +1196,7 @@ niveau du répertoire d'un utilisateur, vous ne pouvez pas utiliser le
 moteur de réécriture. Cette restriction a été instaurée à des fins de
 sécurité.</li>
 
-<li>Lorsqu'on utilise le moteur de réécriture dans un fichier
-<code>.htaccess</code>, le chemin de base du répertoire courant (autrement dit
-le chemin URI qui représente le répertoire contenant ce fichier
-<code>.htaccess</code>) est <em>supprimé</em> au cours de la
-comparaison avec le modèle de la règle de réécriture, et
-<em>ajouté</em> lorsqu'une substitution relative (ne débutant pas par un slash
-ou un nom de protocole) arrive à la fin d'un jeu de règles. Voir la directive
+<li>Voir la directive
 <directive module="mod_rewrite">RewriteBase</directive> pour plus de détails à
 propos de l'ajout du préfixe après les substitutions relatives.</li>
 
index 8f42d7d1e2d45172b0acbf5d0a578f58f27eede9..4bac8497039d7333c176c891f7ca3eeb3b762d37 100644 (file)
@@ -1,7 +1,7 @@
-<?xml version="1.0" encoding="ISO-8859-1" ?>
+<?xml version="1.0" encoding="UTF-8" ?>
 <!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
 <?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
-<!-- English Revision: 1689468:1757280 (outdated) -->
+<!-- English Revision: 1757280 -->
 <!-- French translation : Lucien GENTIS -->
 <!-- Reviewed by : Vincent Deffontaines -->
 
 
 <summary>
 
-<p>Ce document doit vous permettre de d&eacute;marrer et de faire fonctionner
+<p>Ce document doit vous permettre de démarrer et de faire fonctionner
 une configuration de base. Avant de vous lancer dans l'application de
-techniques avanc&eacute;es, il est fortement recommand&eacute; de lire le reste
+techniques avancées, il est fortement recommandé de lire le reste
 de la documentation SSL afin d'en comprendre le fonctionnement de
-mani&egrave;re plus approfondie.</p>
+manière plus approfondie.</p>
 </summary>
 
 <section id="configexample">
@@ -55,58 +55,125 @@ Listen 443
 </section>
 
 <section id="ciphersuites">
-<title>Suites de chiffrement et mise en application de la s&eacute;curit&eacute;
-de haut niveau</title>
+<title>Suites d'algorithmes de chiffrement et mise en oeuvre du chiffrement fort</title>
+
+<note type="warning">
+<p>Le "chiffrement fort est et a toujours été une cible mouvante. En outre, la
+définition du terme "fort" dépend de l'utilisation que vous allez faire de votre
+chiffrement, de vos modèles de menaces, et du niveau de risque que vous
+considérez comme acceptable. L'équipe du serveur HTTP Apache ne peut donc pas
+définir ce chiffrement fort à votre place.</p>
+<p>Dans ce document dont la dernière mise à jour remonte à la mi-2016, une
+"chiffrement fort" fait référence à une implémentation TLS qui fournit, en plus
+d'une protection basique de la confidentialité, de l'intégrité et de
+l'authenticité que tout utilisateur s'attend à trouver, toutes les
+fonctionnalités suivantes :</p>
 <ul>
-<li><a href="#onlystrong">Comment cr&eacute;er un serveur SSL
+<li>Une confidentialité persistante (Forward Secrecy) parfaite qui garantie que
+la découverte de la clé privée d'un serveur ne compromettra pas la
+condidentialité des communications TLS passées.</li>
+<li>Une protection contre les types d'attaque connus contre les anciennes
+implémentations SSL et TLS comme <a
+href="https://en.wikipedia.org/wiki/POODLE">POODLE</a> et <a
+href="https://en.wikipedia.org/wiki/Transport_Layer_Security#BEAST_attack">BEAST</a>.</li>
+<li>Le support des algorithmes de chiffrement les plus efficaces disponibles sur
+les navigateurs web modernes (et à jour), ainsi que sur les autres clients HTTP.</li>
+<li>Le <strong>Rejet</strong> des clients qui ne sont pas en mesure de respecter
+ces prérequis. En d'autres termes, un "chiffrement fort" implique que les
+clients obsolètes ne doivent pas avoir la possibilité de se connecter au serveur
+afin de les empêcher de mettre en danger leurs utilisateurs. Vous seul(e) êtes
+alors à même de décider si ce comportement est approprié à votre situation.</li>
+</ul>
+<p>Notez cependant qu'un <em>chiffrement fort</em> ne suffit pas à lui seul pour
+assurer un niveau de <em>securité</em> fort (A titre d'exemple, les attaques
+oracle sur la compression HTTP comme <a
+href="https://en.wikipedia.org/wiki/BREACH_(security_exploit)">BREACH</a>
+peuvent nécessiter des actions supplémentaires pour être éradiquées).</p>
+</note>
+
+<ul>
+<li><a href="#onlystrong">Comment créer un serveur SSL
 qui n'accepte que le chiffrement fort ?</a></li>
-<li><a href="#strongurl">Comment cr&eacute;er un serveur qui accepte tous les types de
-chiffrement en g&eacute;n&eacute;ral, mais exige un chiffrement fort pour pouvoir
-acc&eacute;der &agrave; une URL particuli&egrave;re ?</a></li>
+<li><a href="#strongurl">Comment créer un serveur qui accepte de nombreux types de
+chiffrement en général, mais exige un chiffrement fort pour pouvoir
+accéder à une URL particulière ?</a></li>
 </ul>
 
 
 <section id="onlystrong">
-<title>Comment cr&eacute;er un serveur SSL qui n'accepte
+<title>Comment créer un serveur SSL qui n'accepte
 que le chiffrement fort ?</title>
-    <p>Les directives suivantes ne permettent que les
-    chiffrements de plus haut niveau :</p>
-    <highlight language="config">
-      SSLCipherSuite HIGH:!aNULL:!MD5
-    </highlight>
-
- <p>Avec la configuration qui suit, vous indiquez une pr&eacute;f&eacute;rence pour
- des algorityhmes de chiffrement sp&eacute;cifiques optimis&eacute;s en mati&egrave;re de
- rapidit&eacute; (le choix final sera op&eacute;r&eacute; par mod_ssl, dans la mesure ou le
- client les supporte) :</p>
+    <p>La configuration suivante active le "chiffrement fort" telle qu'il est
+    défini ci-dessus, et s'inspire du document de la Fondation Mozilla sur les
+    prérequis de <a
+    href="https://wiki.mozilla.org/Security/Server_Side_TLS">Server Side
+    TLS</a> :</p>
 
     <highlight language="config">
-SSLCipherSuite RC4-SHA:AES128-SHA:HIGH:!aNULL:!MD5
+# Configuration "moderne" définie en août 2016 par le générateur de
+# configuration SSL de la Fondation Mozilla. Ce dernier est disponible à
+# https://mozilla.github.io/server-side-tls/ssl-config-generator/
+SSLProtocol         all -SSLv3 -TLSv1 -TLSv1.1
+# De nombreux algorithmes de chiffrement définis ici nécessitent une version
+# récente (1.0.1 ou plus) d'OpenSSL. Certains nécessitent même OpenSSL 1.1.0
+# qui, à l'heure où ces lignes sont écrites, était encore en pre-release.
+SSLCipherSuite      ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
 SSLHonorCipherOrder on
+SSLCompression      off
+SSLSessionTickets   off
     </highlight>
+
+    <ul>
+    <li>SSL 3.0 et TLS 1.0 étant vulnérables à certaines attaques connues contre
+    le protocole, ils ont été entièrement retirés.</li>
+    <li>Actuellement (en août 2016), la désactivation de TLS 1.1 est facultative
+    ; TLS 1.2 fournit des options de chiffrement plus évoluées, mais la version
+    1.1 n'est pas encore considérée comme obsolète. La désactivation de TLS 1.1
+    peut cependant juguler des attaques contre certaines implémentations
+    dépassées de TLS.</li>
+    <li>La directive <directive module="mod_ssl">SSLHonorCipherOrder</directive>
+    permet de s'assurer que ce sont les préférences de chiffrement du serveur
+    qui seront suivies, et non celles du client.</li>
+    <li>La désactivation de <directive
+    module="mod_ssl">SSLCompression</directive> permet de prévenir les attaques
+    oracle sur la compression TLS (en autres <a
+    href="https://en.wikipedia.org/wiki/CRIME">CRIME</a>).</li>
+    <li>La désactivation de <directive
+    module="mod_ssl">SSLSessionTickets</directive> permet de s'assurer que la
+    qualité de la confidentialité persistante (Forward Secrecy) ne sera pas
+    compromise, même si le serveur n'est pas redémarré régulièrement.</li>
+    </ul>
+
+    <p>C'est votre version d'OpenSSL installée qui détermine la liste des
+    algorithmes de chiffrement supportés par la directive <directive
+    module="mod_ssl">SSLCipherSuite</directive>, et non le serveur. Pour pouvoir
+    utiliser certains d'entre eux, vous devrez peut-être mettre à jour votre
+    version d'OpenSSL.</p>
 </section>
 
 <section id="strongurl">
-<title>Comment cr&eacute;er un serveur qui accepte tous les types de
-chiffrement en g&eacute;n&eacute;ral, mais exige un chiffrement fort pour pouvoir
-acc&eacute;der &agrave; une URL particuli&egrave;re ?</title>
-    <p>Dans ce cas bien &eacute;videmment, une directive <directive
+<title>Comment créer un serveur qui accepte de nombreux types de
+chiffrement en général, mais exige un chiffrement fort pour pouvoir
+accéder à une URL particulière ?</title>
+    <p>Dans ce cas bien évidemment, une directive <directive
     module="mod_ssl">SSLCipherSuite</directive> au niveau du serveur principal
     qui restreint le choix des suites de chiffrement aux versions les plus
-    fortes ne conviendra pas. <module>mod_ssl</module> peut cependant &ecirc;tre
-    reconfigur&eacute; au sein de blocs <code>Location</code> qui permettent
-    d'adapter la configuration g&eacute;n&eacute;rale &agrave; un r&eacute;pertoire sp&eacute;cifique ;
+    fortes ne conviendra pas. <module>mod_ssl</module> 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 ;
     <module>mod_ssl</module> peut alors forcer automatiquement une
-    ren&eacute;gociation des param&egrave;tres SSL pour parvenir au but recherch&eacute;.
-    Cette configuration peut se pr&eacute;senter comme suit :</p>
+    renégociation des paramètres SSL pour parvenir au but recherché.
+    Cette configuration peut se présenter comme suit :</p>
     <highlight language="config">
-# soyons tr&egrave;s tol&eacute;rant a priori
-SSLCipherSuite ALL:!aNULL:RC4+RSA:+HIGH:+MEDIUM:+LOW:+EXP:+eNULL
+# soyons très tolérant a priori -- utilisons la suite d'algorithmes de
+# chiffrement "intermédiaire" de Mozilla (des suites plus légères peuvent aussi
+# être utilisées mais ne seront pas documentées ici)
+SSLCipherSuite ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS
 
 &lt;Location "/strong/area"&gt;
-# sauf pour https://hostname/strong/area/ et ses sous-r&eacute;pertoires
-# qui exigent des chiffrements forts
-SSLCipherSuite HIGH:!aNULL:!MD5
+# sauf pour https://hostname/strong/area/ et ses sous-répertoires qui exigent
+# des chiffrements forts
+SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
 &lt;/Location&gt;
     </highlight>
 </section>
@@ -116,34 +183,34 @@ SSLCipherSuite HIGH:!aNULL:!MD5
 <section id="ocspstapling">
 <title>Agrafage OCSP</title>
 
-<p>Le protocole de contr&ocirc;le du statut des certificats en ligne (Online
-Certificate Status Protocol - OCSP) est un m&eacute;canisme permettant de
-d&eacute;terminer si un certificat a &eacute;t&eacute; r&eacute;voqu&eacute; ou non, et l'agrafage OCSP en
-est une fonctionnalit&eacute; particuli&egrave;re par laquelle le serveur, par exemple
-httpd et mod_ssl, maintient une liste des r&eacute;ponses OCSP actuelles pour
+<p>Le protocole de contrôle du statut des certificats en ligne (Online
+Certificate Status Protocol - OCSP) est un mécanisme permettant de
+déterminer si un certificat a été révoqué ou non, et l'agrafage OCSP en
+est une fonctionnalité particulière par laquelle le serveur, par exemple
+httpd et mod_ssl, maintient une liste des réponses OCSP actuelles pour
 ses certificats et l'envoie aux clients qui communiquent avec lui. La
-plupart des certificats contiennent l'adresse d'un r&eacute;pondeur OCSP maintenu
-par l'Autorit&eacute; de Certification (CA) sp&eacute;cifi&eacute;e, et mod_ssl peut requ&eacute;rir
-ce r&eacute;pondeur pour obtenir une r&eacute;ponse sign&eacute;e qui peut &ecirc;tre envoy&eacute;e aux
+plupart des certificats contiennent l'adresse d'un répondeur OCSP maintenu
+par l'Autorité de Certification (CA) spécifiée, et mod_ssl peut requérir
+ce répondeur pour obtenir une réponse signée qui peut être envoyée aux
 clients qui communiquent avec le serveur.</p>
 
-<p>L'agrafage OCSP est la m&eacute;thode la plus performante pour obtenir le
+<p>L'agrafage OCSP est la méthode la plus performante pour obtenir le
 statut d'un certificat car il est disponible au niveau du serveur, et le
 client n'a donc pas besoin d'ouvrir une nouvelle connexion vers
-l'autorit&eacute; de certification. Autres avantages de l'absence de
-communication entre le client et l'autorit&eacute; de certification :
-l'autorit&eacute; de certification n'a pas acc&egrave;s &agrave; l'historique de navigation
+l'autorité de certification. Autres avantages de l'absence de
+communication entre le client et l'autorité de certification :
+l'autorité de certification n'a pas accès à l'historique de navigation
 du client, et l'obtention du statut du certificat est plus efficace car
-elle n'est plus assujettie &agrave; une surcharge &eacute;ventuelle des serveurs de
-l'autorit&eacute; de certification.</p>
+elle n'est plus assujettie à une surcharge éventuelle des serveurs de
+l'autorité de certification.</p>
 
-<p>La charge du serveur est moindre car la r&eacute;ponse qu'il a obtenu du
-r&eacute;pondeur OCSP peut &ecirc;tre r&eacute;utilis&eacute;e par tous les clients qui utilisent
-le m&ecirc;me certificat dans la limite du temps de validit&eacute; de la r&eacute;ponse.</p>
+<p>La charge du serveur est moindre car la réponse qu'il a obtenu du
+répondeur OCSP peut être réutilisée par tous les clients qui utilisent
+le même certificat dans la limite du temps de validité de la réponse.</p>
 
-<p>Une fois le support g&eacute;n&eacute;ral SSL correctement configur&eacute;, l'activation
+<p>Une fois le support général SSL correctement configuré, l'activation
 de l'agrafage OCSP ne requiert que des modifications mineures
-&agrave; la configuration de httpd et il suffit en g&eacute;n&eacute;ral de l'ajout de ces
+à la configuration de httpd et il suffit en général de l'ajout de ces
 deux directives :</p>
 
     <highlight language="config">
@@ -151,22 +218,22 @@ SSLUseStapling On
 SSLStaplingCache "shmcb:ssl_stapling(32768)"
     </highlight>
 
-<p>Ces directives sont plac&eacute;es de fa&ccedil;on &agrave; ce qu'elles aient une port&eacute;e
-globale (et particuli&egrave;rement en dehors de toute section VirtualHost), le
-plus souvent o&ugrave; sont plac&eacute;es les autres directives de configuration
+<p>Ces directives sont placées de façon à ce qu'elles aient une portée
+globale (et particulièrement en dehors de toute section VirtualHost), le
+plus souvent où sont placées les autres directives de configuration
 globales SSL, comme <code>conf/extra/httpd-ssl.conf</code> pour les
-installations de httpd &agrave; partir des sources, ou
+installations de httpd à partir des sources, ou
 <code>/etc/apache2/mods-enabled/ssl.conf</code> pour Ubuntu ou Debian,
 etc...</p>
 
-<p>Cette directive <directive>SSLStaplingCache</directive> particuli&egrave;re
-n&eacute;cessite le chargement du module <module>mod_socache_shmcb</module> (&agrave;
-cause du pr&eacute;fixe <code>shmcb</code> de son argument). Ce module est en
-g&eacute;n&eacute;ral d&eacute;j&agrave; activ&eacute; pour la directive
+<p>Cette directive <directive>SSLStaplingCache</directive> particulière
+nécessite le chargement du module <module>mod_socache_shmcb</module> (à
+cause du préfixe <code>shmcb</code> de son argument). Ce module est en
+général déjà activé pour la directive
 <directive>SSLSessionCache</directive>, ou pour des modules autres que
 <module>mod_ssl</module>. Si vous activez un cache de session SSL
-utilisant un m&eacute;canisme autre que <module>mod_socache_shmcb</module>,
-utilisez aussi ce m&eacute;canisme alternatif pour la directive
+utilisant un mécanisme autre que <module>mod_socache_shmcb</module>,
+utilisez aussi ce mécanisme alternatif pour la directive
 <directive>SSLStaplingCache</directive>. Par exemple :</p>
 
     <highlight language="config">
@@ -174,8 +241,8 @@ SSLSessionCache "dbm:ssl_scache"
 SSLStaplingCache "dbm:ssl_stapling"
     </highlight>
 
-<p>Vous pouvez utiliser la commande openssl pour v&eacute;rifier que votre
-serveur envoie bien une r&eacute;ponse OCSP :</p>
+<p>Vous pouvez utiliser la commande openssl pour vérifier que votre
+serveur envoie bien une réponse OCSP :</p>
 
 <pre>
 $ openssl s_client -connect www.example.com:443 -status -servername www.example.com
@@ -191,28 +258,28 @@ OCSP Response Data:
 </pre>
 
 <p>Les sections suivantes explicitent les situations courantes qui
-requi&egrave;rent des modifications suppl&eacute;mentaires de la configuration. Vous
-pouvez aussi vous r&eacute;f&eacute;rer au manuel de r&eacute;f&eacute;rence de
+requièrent des modifications supplémentaires de la configuration. Vous
+pouvez aussi vous référer au manuel de référence de
 <module>mod_ssl</module>.</p>
 
 <section>
 <title>Si l'on utilise plus que quelques certificats SSL pour le serveur</title>
-<p>Les r&eacute;ponses OCSP sont stock&eacute;es dans le cache d'agrafage SSL. Alors
-que les r&eacute;ponses ont une taille de quelques centaines &agrave; quelques
-milliers d'octets, mod_ssl supporte des r&eacute;ponses d'une taille jusqu'&agrave;
-environ 10 ko. Dans notre cas, le nombre de certificats est cons&eacute;quent
-et la taille du cache (32768 octets dans l'exemple ci-dessus) doit &ecirc;tre
-augment&eacute;e. En cas d'erreur lors du stockage d'une r&eacute;ponse, le
-message AH01929 sera enregistr&eacute; dans le journal.</p>
+<p>Les réponses OCSP sont stockées dans le cache d'agrafage SSL. Alors
+que les réponses ont une taille de quelques centaines à quelques
+milliers d'octets, mod_ssl supporte des réponses d'une taille jusqu'à
+environ 10 ko. Dans notre cas, le nombre de certificats est conséquent
+et la taille du cache (32768 octets dans l'exemple ci-dessus) doit être
+augmentée. En cas d'erreur lors du stockage d'une réponse, le
+message AH01929 sera enregistré dans le journal.</p>
 </section>
 
 <section>
-<title>Si le certificat ne sp&eacute;cifie pas de r&eacute;pondeur OCSP, ou si une
-adresse diff&eacute;rente doit &ecirc;tre utilis&eacute;e</title>
-<p>Veuillez vous r&eacute;f&eacute;rer &agrave; la documentation de la directive <directive
+<title>Si le certificat ne spécifie pas de répondeur OCSP, ou si une
+adresse différente doit être utilisée</title>
+<p>Veuillez vous référer à la documentation de la directive <directive
 module="mod_ssl">SSLStaplingForceURL</directive>.</p>
 
-<p>Vous pouvez v&eacute;rifier si un certificat sp&eacute;cifie un r&eacute;pondeur OCSP en
+<p>Vous pouvez vérifier si un certificat spécifie un répondeur OCSP en
 utilisant la commande openssl comme suit :</p>
 
 <pre>
@@ -222,30 +289,30 @@ OCSP - URI:http://ocsp.example.com
 
 <p>Si un URI OCSP est fourni et si le serveur web peut communiquer
 directement avec lui sans passer par un mandataire, aucune modification
-suppl&eacute;mentaire de la configuration n'est requise. Notez que les r&egrave;gles
-du pare-feu qui contr&ocirc;lent les connexions sortantes en provenance du
-serveur web devront peut-&ecirc;tre subir quelques ajustements.</p>
+supplémentaire de la configuration n'est requise. Notez que les règles
+du pare-feu qui contrôlent les connexions sortantes en provenance du
+serveur web devront peut-être subir quelques ajustements.</p>
 
-<p>Si aucun URI OCSP n'est fourni, contactez votre autorit&eacute; de
+<p>Si aucun URI OCSP n'est fourni, contactez votre autorité de
 certification pour savoir s'il en existe une ; si c'est le
 cas, utilisez la directive <directive
-module="mod_ssl">SSLStaplingForceURL</directive> pour la sp&eacute;cifier dans
+module="mod_ssl">SSLStaplingForceURL</directive> pour la spécifier dans
 la configuration du serveur virtuel qui utilise le certificat.</p>
 </section>
 
 <section>
-<title>Si plusieurs serveurs virtuels sont configur&eacute;s pour utiliser SSL
-et si l'agrafage OCSP doit &ecirc;tre d&eacute;sactiv&eacute; pour certains d'entre eux</title>
+<title>Si plusieurs serveurs virtuels sont configurés pour utiliser SSL
+et si l'agrafage OCSP doit être désactivé pour certains d'entre eux</title>
 
-<p>Ajoutez la directive <code>SSLUseStapling Off</code> &agrave; la
+<p>Ajoutez la directive <code>SSLUseStapling Off</code> à la
 configuration des serveurs virtuels pour lesquels l'agrafage OCSP doit
-&ecirc;tre d&eacute;sactiv&eacute;.</p>
+être désactivé.</p>
 </section>
 
 <section>
-<title>Si le r&eacute;pondeur OCSP est lent ou instable</title>
-<p>De nombreuses directives permettent de g&eacute;rer les temps de r&eacute;ponse et
-les erreurs. R&eacute;f&eacute;rez-vous &agrave; la documentation de <directive
+<title>Si le répondeur OCSP est lent ou instable</title>
+<p>De nombreuses directives permettent de gérer les temps de réponse et
+les erreurs. Référez-vous à la documentation de <directive
 module="mod_ssl">SSLStaplingFakeTryLater</directive>, <directive
 module="mod_ssl">SSLStaplingResponderTimeout</directive>, et <directive
 module="mod_ssl">SSLStaplingReturnResponderErrors</directive>.</p>
@@ -257,16 +324,16 @@ module="mod_ssl">SSLStaplingReturnResponderErrors</directive>.</p>
 AH02217: ssl_stapling_init_cert: Can't retrieve issuer certificate!
 </pre>
 <p>Afin de pouvoir supporter l'agrafage OCSP lorsqu'un certificat de
-serveur particulier est utilis&eacute;, une cha&icirc;ne de certification pour ce
-certificat doit &ecirc;tre sp&eacute;cifi&eacute;e. Si cela n'a pas &eacute;t&eacute; fait lors de
-l'activation de SSL, l'erreur AH02217 sera enregistr&eacute;e lorsque
-l'agrafage OCSP sera activ&eacute;, et les clients qui utilisent le certificat
-consid&eacute;r&eacute; ne recevront pas de r&eacute;ponse OCSP.</p>
+serveur particulier est utilisé, une chaîne de certification pour ce
+certificat doit être spécifiée. Si cela n'a pas été fait lors de
+l'activation de SSL, l'erreur AH02217 sera enregistrée lorsque
+l'agrafage OCSP sera activé, et les clients qui utilisent le certificat
+considéré ne recevront pas de réponse OCSP.</p>
 
-<p>Veuillez vous r&eacute;f&eacute;rer &agrave; la documentation des directives <directive
+<p>Veuillez vous référer à la documentation des directives <directive
 module="mod_ssl">SSLCertificateChainFile</directive> et <directive
-module="mod_ssl">SSLCertificateFile</directive> pour sp&eacute;cifier une
-cha&icirc;ne de certification.</p>
+module="mod_ssl">SSLCertificateFile</directive> pour spécifier une
+chaîne de certification.</p>
 </section>
 
 </section>
@@ -274,37 +341,37 @@ cha&icirc;ne de certification.</p>
 
 
 <section id="accesscontrol">
-<title>Authentification du client et contr&ocirc;le d'acc&egrave;s</title>
+<title>Authentification du client et contrôle d'accès</title>
 <ul>
 <li><a href="#allclients">Comment forcer les clients
-&agrave; s'authentifier &agrave; l'aide de certificats ?</a></li>
+à s'authentifier à l'aide de certificats ?</a></li>
 <li><a href="#arbitraryclients">Comment forcer les clients
-&agrave; s'authentifier &agrave; l'aide de certificats pour une URL particuli&egrave;re,
-mais autoriser quand-m&ecirc;me tout client anonyme
-&agrave; acc&eacute;der au reste du serveur ?</a></li>
-<li><a href="#certauthenticate">Comment n'autoriser l'acc&egrave;s &agrave; une URL
-particuli&egrave;re qu'aux clients qui poss&egrave;dent des certificats, mais autoriser
-l'acc&egrave;s au reste du serveur &agrave; tous les clients ?</a></li>
+à 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&egrave;s &agrave; une partie de l'Intranet, pour les clients en
+pour l'accès à une partie de l'Intranet, pour les clients en
 provenance de l'Internet ?</a></li>
 </ul>
 
 <section id="allclients">
 <title>Comment forcer les clients
-&agrave; s'authentifier &agrave; l'aide de certificats ?
+à s'authentifier à l'aide de certificats ?
 </title>
 
-    <p>Lorsque vous connaissez tous vos clients (comme c'est en g&eacute;n&eacute;ral le cas
+    <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&eacute;e uniquement sur les certificats. Tout ce dont vous
-    avez besoin pour y parvenir est de cr&eacute;er des certificats clients sign&eacute;s par
-    le certificat de votre propre autorit&eacute; de certification
-    (<code>ca.crt</code>), et d'authentifier les clients &agrave; l'aide de ces
+    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>
     <highlight language="config">
-# exige un certificat client sign&eacute; par le certificat de votre CA
+# exige un certificat client signé par le certificat de votre CA
 # contenu dans ca.crt
 SSLVerifyClient require
 SSLVerifyDepth 1
@@ -314,13 +381,13 @@ SSLCACertificateFile "conf/ssl.crt/ca.crt"
 
 <section id="arbitraryclients">
 <title>Comment forcer les clients
-&agrave; s'authentifier &agrave; l'aide de certificats pour une URL particuli&egrave;re,
-mais autoriser quand-m&ecirc;me tout client anonyme
-&agrave; acc&eacute;der au reste du serveur ?</title>
+à 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 ?</title>
 
-<p>Pour forcer les clients &agrave; s'authentifier &agrave; l'aide de certificats pour une
-URL particuli&egrave;re, vous pouvez utiliser les fonctionnalit&eacute;s de reconfiguration
-de <module>mod_ssl</module> en fonction du r&eacute;pertoire :</p>
+<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 <module>mod_ssl</module> en fonction du répertoire :</p>
 
     <highlight language="config">
 SSLVerifyClient none
@@ -334,23 +401,23 @@ SSLVerifyDepth 1
 </section>
 
 <section id="certauthenticate">
-<title>Comment n'autoriser l'acc&egrave;s &agrave; une URL
-particuli&egrave;re qu'aux clients qui poss&egrave;dent des certificats, mais autoriser
-l'acc&egrave;s au reste du serveur &agrave; tous les clients ?</title>
-
-    <p>La cl&eacute; du probl&egrave;me consiste &agrave; v&eacute;rifier si une partie du certificat
-    client correspond &agrave; ce que vous attendez. Cela signifie en g&eacute;n&eacute;ral
-    consulter tout ou partie du nom distinctif (DN), afin de v&eacute;rifier s'il
-    contient une cha&icirc;ne connue. Il existe deux m&eacute;thodes pour y parvenir ;
+<title>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 ?</title>
+
+    <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 <module>mod_auth_basic</module>, soit la
     directive <directive module="mod_ssl">SSLRequire</directive>.</p>
 
-    <p>La m&eacute;thode du module <module>mod_auth_basic</module> est en g&eacute;n&eacute;ral
+    <p>La méthode du module <module>mod_auth_basic</module> 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&eacute;es de mots de passe contenant <em>tous</em> les clients
-    autoris&eacute;s, comme suit :</p>
+    de données de mots de passe contenant <em>tous</em> les clients
+    autorisés, comme suit :</p>
 
     <highlight language="config">
 SSLVerifyClient      none
@@ -371,10 +438,10 @@ SSLVerifyClient      require
     </highlight>
     
 
-    <p>Le mot de passe utilis&eacute; dans cet exemple correspond &agrave; la cha&icirc;ne de
-    caract&egrave;res "password" chiffr&eacute;e en DES. Voir la documentation de la
+    <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 <directive module="mod_ssl">SSLOptions</directive> pour
-    plus de d&eacute;tails.</p>
+    plus de détails.</p>
 
     <example><title>httpd.passwd</title><pre>
 /C=DE/L=Munich/O=Snake Oil, Ltd./OU=Staff/CN=Foo:xxj31ZMTZzkVA
@@ -382,8 +449,8 @@ SSLVerifyClient      require
 /C=US/L=L.A./O=Snake Oil, Ltd./OU=Dev/CN=Quux:xxj31ZMTZzkVA</pre>
     </example>
 
-    <p>Lorsque vos clients font tous partie d'une m&ecirc;me hi&eacute;rarchie, ce qui
-    appara&icirc;t dans le DN, vous pouvez les authentifier plus facilement en
+    <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 <directive module="mod_ssl"
     >SSLRequire</directive>, comme suit :</p>
 
@@ -407,49 +474,49 @@ SSLCACertificatePath "conf/ssl.crt"
 <section id="intranet">
 <title>Comment imposer HTTPS avec chiffrements forts,
 et soit authentification de base, soit possession de certificats clients,
-pour l'acc&egrave;s &agrave; une partie de l'Intranet, pour les clients en
-provenance de l'Internet ? Je souhaite quand-m&ecirc;me autoriser l'acc&egrave;s en HTTP
+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.</title>
 
    <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
-   &agrave; laquelle vous voulez autoriser l'acc&egrave;s depuis l'Internet est
+   à 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&ocirc;te virtuel HTTPS, afin qu'elles
-   s'appliquent &agrave; la fois &agrave; HTTP et HTTPS.</p>
+   doivent se trouver en dehors de votre hôte virtuel HTTPS, afin qu'elles
+   s'appliquent à la fois à HTTP et HTTPS.</p>
 
     <highlight language="config">
 SSLCACertificateFile "conf/ssl.crt/company-ca.crt"
 
 &lt;Directory "/usr/local/apache2/htdocs"&gt;
-#   En dehors de subarea, seul l'acc&egrave;s depuis l'intranet est
-#   autoris&eacute;
+#   En dehors de subarea, seul l'accès depuis l'intranet est
+#   autorisé
     Require              ip 192.168.1.0/24
 &lt;/Directory&gt;
 
 &lt;Directory "/usr/local/apache2/htdocs/subarea"&gt;
-#   Dans subarea, tout acc&egrave;s depuis l'intranet est autoris&eacute;
-#   mais depuis l'Internet, seul l'acc&egrave;s par HTTPS + chiffrement fort + Mot de passe
-#   ou HTTPS + chiffrement fort + certificat client n'est autoris&eacute;.
+#   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&eacute;, on s'assure que le niveau de chiffrement est fort.
-#   Autorise en plus les certificats clients comme une alternative &agrave;
+#   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} &gt;= 128
     
-    #   ON oblige les clients venant d'Internet &agrave; utiliser HTTPS
+    #   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&egrave;s soit sur les crit&egrave;res r&eacute;seaux, soit par authentification Basique
+    #   On permet l'accès soit sur les critères réseaux, soit par authentification Basique
     Satisfy              any
     
-    #   Contr&ocirc;le d'acc&egrave;s r&eacute;seau
+    #   Contrôle d'accès réseau
     Require              ip 192.168.1.0/24
     
     #   Configuration de l'authentification HTTP Basique
@@ -468,13 +535,13 @@ SSLCACertificateFile "conf/ssl.crt/company-ca.crt"
     <title>Journalisation</title>
 
     <p><module>mod_ssl</module> peut enregistrer des informations de
-    d&eacute;bogage tr&egrave;s verbeuses dans le journal des erreurs, lorsque sa
-    directive <directive module="core">LogLevel</directive> est d&eacute;finie
-    &agrave; des niveaux de trace &eacute;lev&eacute;s. Par contre, sur un serveur tr&egrave;s
-    sollicit&eacute;, le niveau <code>info</code> sera probablement d&eacute;j&agrave; trop
-    &eacute;lev&eacute;. Souvenez-vous que vous pouvez configurer la directive
+    débogage très verbeuses dans le journal des erreurs, lorsque sa
+    directive <directive module="core">LogLevel</directive> est définie
+    à des niveaux de trace élevés. Par contre, sur un serveur très
+    sollicité, le niveau <code>info</code> sera probablement déjà trop
+    élevé. Souvenez-vous que vous pouvez configurer la directive
     <directive module="core">LogLevel</directive> par module afin de
-    pourvoir &agrave; vos besoins.</p>
+    pourvoir à vos besoins.</p>
 </section>
 
 </manualpage>