Rebuild.

[apache] / docs / manual / ssl / ssl_howto.xml.fr

<?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: 1757280 -->
<!-- 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_howto.xml.meta">
<parentdocument href="./">SSL/TLS</parentdocument>

  <title>Chiffrement fort SSL/TLS : Mode d'emploi</title>

<summary>

<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ées, il est fortement recommandé de lire le reste
de la documentation SSL afin d'en comprendre le fonctionnement de
manière plus approfondie.</p>
</summary>

<section id="configexample">
<title>Exemple de configuration basique</title>

<p>Votre configuration SSL doit comporter au moins les directives
suivantes :</p>

<highlight language="config">
Listen 443
&lt;VirtualHost *:443&gt;
    ServerName www.example.com
    SSLEngine on
    SSLCertificateFile "/path/to/www.example.com.cert"
    SSLCertificateKeyFile "/path/to/www.example.com.key"
&lt;/VirtualHost&gt;
</highlight>

</section>

<section id="ciphersuites">
<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>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é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éer un serveur SSL qui n'accepte
que le chiffrement fort ?</title>
    <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">
# 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é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 ê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égociation des paramètres SSL pour parvenir au but recherché.
    Cette configuration peut se présenter comme suit :</p>
    <highlight language="config">
# 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é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>
</section>
<!-- /ciphersuites -->

<section id="ocspstapling">
<title>Agrafage OCSP</title>

<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é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é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é 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 à une surcharge éventuelle des serveurs de
l'autorité de certification.</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énéral SSL correctement configuré, l'activation
de l'agrafage OCSP ne requiert que des modifications mineures
à la configuration de httpd et il suffit en général de l'ajout de ces
deux directives :</p>

    <highlight language="config">
SSLUseStapling On
SSLStaplingCache "shmcb:ssl_stapling(32768)"
    </highlight>

<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 à 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è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é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">
SSLSessionCache "dbm:ssl_scache"
SSLStaplingCache "dbm:ssl_stapling"
    </highlight>

<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
...
OCSP response: 
======================================
OCSP Response Data:
    OCSP Response Status: successful (0x0)
    Response Type: Basic OCSP Response
...
    Cert Status: Good
...
</pre>

<p>Les sections suivantes explicitent les situations courantes qui
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é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é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érifier si un certificat spécifie un répondeur OCSP en
utilisant la commande openssl comme suit :</p>

<pre>
$ openssl x509 -in ./www.example.com.crt -text | grep 'OCSP.*http'
OCSP - URI:http://ocsp.example.com
</pre>

<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é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é 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écifier dans
la configuration du serveur virtuel qui utilise le certificat.</p>
</section>

<section>
<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> à la
configuration des serveurs virtuels pour lesquels l'agrafage OCSP doit
être désactivé.</p>
</section>

<section>
<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>
</section>

<section>
<title>Si mod_ssl enregistre l'erreur AH02217 dans le journal</title>
<pre>
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é, 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éférer à la documentation des directives <directive
module="mod_ssl">SSLCertificateChainFile</directive> et <directive
module="mod_ssl">SSLCertificateFile</directive> pour spécifier une
chaîne de certification.</p>
</section>

</section>
<!-- /ocspstapling -->


<section id="accesscontrol">
<title>Authentification du client et contrôle d'accès</title>
<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>

<section id="allclients">
<title>Comment forcer les clients
à s'authentifier à l'aide de certificats ?
</title>

    <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>
    <highlight language="config">
# exige un certificat client signé par le certificat de votre CA
# contenu dans ca.crt
SSLVerifyClient require
SSLVerifyDepth 1
SSLCACertificateFile "conf/ssl.crt/ca.crt"
    </highlight>
</section>

<section id="arbitraryclients">
<title>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 ?</title>

<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
SSLCACertificateFile "conf/ssl.crt/ca.crt"

&lt;Location "/secure/area"&gt;
SSLVerifyClient require
SSLVerifyDepth 1
&lt;/Location&gt;
    </highlight>
</section>

<section id="certauthenticate">
<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é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ées de mots de passe contenant <em>tous</em> les clients
    autorisés, comme suit :</p>

    <highlight language="config">
SSLVerifyClient      none
SSLCACertificateFile "conf/ssl.crt/ca.crt"
SSLCACertificatePath "conf/ssl.crt"

&lt;Directory "/usr/local/apache2/htdocs/secure/area"&gt;
SSLVerifyClient      require
    SSLVerifyDepth       5
    SSLOptions           +FakeBasicAuth
    SSLRequireSSL
    AuthName             "Snake Oil Authentication"
    AuthType             Basic
    AuthBasicProvider    file
    AuthUserFile         "/usr/local/apache2/conf/httpd.passwd"
    Require              valid-user
&lt;/Directory&gt;
    </highlight>
    

    <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étails.</p>

    <example><title>httpd.passwd</title><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>
    </example>

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


    <highlight language="config">
SSLVerifyClient      none
SSLCACertificateFile "conf/ssl.crt/ca.crt"
SSLCACertificatePath "conf/ssl.crt"

&lt;Directory "/usr/local/apache2/htdocs/secure/area"&gt;
  SSLVerifyClient      require
  SSLVerifyDepth       5
  SSLOptions           +FakeBasicAuth
  SSLRequireSSL
  SSLRequire       %{SSL_CLIENT_S_DN_O}  eq "Snake Oil, Ltd." \
               and %{SSL_CLIENT_S_DN_OU} in {"Staff", "CA", "Dev"}
&lt;/Directory&gt;
    </highlight>
</section>

<section id="intranet">
<title>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.</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
   à 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>

    <highlight language="config">
SSLCACertificateFile "conf/ssl.crt/company-ca.crt"

&lt;Directory "/usr/local/apache2/htdocs"&gt;
#   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è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} &gt;= 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
    Require              ip 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
&lt;/Directory&gt;
    </highlight>
</section>
</section>
<!-- /access control -->

<section id="logging">
    <title>Journalisation</title>

    <p><module>mod_ssl</module> peut enregistrer des informations de
    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 à vos besoins.</p>
</section>

</manualpage>