Serveur Apache HTTP Version 2.5

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.
 Exemple de configuration basique
 Exemple de configuration basique Suites de chiffrement et mise en application de la sécurité
de haut niveau
 Suites de chiffrement et mise en application de la sécurité
de haut niveau Comment créer un serveur qui accepte tous les types de
chiffrement en général, mais exige un chiffrement fort pour pouvoir
accéder à une URL particulière ?
 Comment créer un 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 ? Authentification du client et contrôle d'accès
 Authentification du client et contrôle d'accès Journalisation
 JournalisationVotre configuration SSL doit comporter au moins les directives suivantes :
Listen 443
<VirtualHost *:443>
    ServerName www.example.com
    SSLEngine on
    SSLCertificateFile /path/to/www.example.com.cert
    SSLCertificateKeyFile /path/to/www.example.com.key
</VirtualHost>
Les directives suivantes ne permettent que les chiffrements de plus haut niveau :
      SSLCipherSuite HIGH:!aNULL:!MD5
    
 Avec la configuration qui suit, vous indiquez une préférence pour des algorityhmes de chiffrement spécifiques optimisés en matière de rapidité (le choix final sera opéré par mod_ssl, dans la mesure ou le client les supporte) :
SSLCipherSuite RC4-SHA:AES128-SHA:HIGH:!aNULL:!MD5
SSLHonorCipherOrder on
    
Dans ce cas bien évidemment, une directive SSLCipherSuite au niveau du serveur principal
    qui restreint le choix des suites de chiffrement aux versions les plus
    fortes ne conviendra pas. mod_ssl peut cependant être
    reconfiguré au sein de blocs Location qui permettent
    d'adapter la configuration générale à un répertoire spécifique ;
    mod_ssl peut alors forcer automatiquement une
    renégociation des paramètres SSL pour parvenir au but recherché.
    Cette configuration peut se présenter comme suit :
# soyons très tolérant a priori
SSLCipherSuite ALL:!aNULL:RC4+RSA:+HIGH:+MEDIUM:+LOW:+EXP:+eNULL
<Location /strong/area>
# sauf pour https://hostname/strong/area/ et ses sous-répertoires
# qui exigent des chiffrements forts
SSLCipherSuite HIGH:!aNULL:!MD5
</Location>
    
Lorsque vous connaissez tous vos clients (comme c'est en général le cas
    au sein d'un intranet d'entreprise), vous pouvez imposer une
    authentification basée uniquement sur les certificats. Tout ce dont vous
    avez besoin pour y parvenir est de créer des certificats clients signés par
    le certificat de votre propre autorité de certification
    (ca.crt), et d'authentifier les clients à l'aide de ces
    certificats.
# 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
    
Pour forcer les clients à s'authentifier à l'aide de certificats pour une
URL particulière, vous pouvez utiliser les fonctionnalités de reconfiguration
de mod_ssl en fonction du répertoire :
SSLVerifyClient none
SSLCACertificateFile conf/ssl.crt/ca.crt
<Location /secure/area>
SSLVerifyClient require
SSLVerifyDepth 1
</Location>
    
La clé du problème consiste à vérifier si une partie du certificat
    client correspond à ce que vous attendez. Cela signifie en général
    consulter tout ou partie du nom distinctif (DN), afin de vérifier s'il
    contient une chaîne connue. Il existe deux méthodes pour y parvenir ;
    on utilise soit le module mod_auth_basic, soit la
    directive SSLRequire.
La méthode du module mod_auth_basic est en général
    incontournable lorsque les certificats ont un contenu arbitraire, ou
    lorsque leur DN ne contient aucun champ connu
    (comme l'organisation, etc...). Dans ce cas, vous devez construire une base
    de données de mots de passe contenant tous les clients
    autorisés, comme suit :
SSLVerifyClient      none
SSLCACertificateFile conf/ssl.crt/ca.crt
SSLCACertificatePath conf/ssl.crt
<Directory /usr/local/apache2/htdocs/secure/area>
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
</Directory>
    
    
    Le mot de passe utilisé dans cet exemple correspond à la chaîne de
    caractères "password" chiffrée en DES. Voir la documentation de la
    directive SSLOptions pour
    plus de détails.
/C=DE/L=Munich/O=Snake Oil, Ltd./OU=Staff/CN=Foo:xxj31ZMTZzkVA /C=US/L=S.F./O=Snake Oil, Ltd./OU=CA/CN=Bar:xxj31ZMTZzkVA /C=US/L=L.A./O=Snake Oil, Ltd./OU=Dev/CN=Quux:xxj31ZMTZzkVA
Lorsque vos clients font tous partie d'une même hiérarchie, ce qui
    apparaît dans le DN, vous pouvez les authentifier plus facilement en
    utilisant la directive SSLRequire, comme suit :
SSLVerifyClient      none
SSLCACertificateFile conf/ssl.crt/ca.crt
SSLCACertificatePath conf/ssl.crt
<Directory /usr/local/apache2/htdocs/secure/area>
  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"}
</Directory>
    
On suppose dans ces exemples que les clients de l'intranet ont des
   adresses IP dans la gamme 192.168.1.0/24, et que la partie de l'intranet
   à laquelle vous voulez autoriser l'accès depuis l'Internet est
   /usr/local/apache2/htdocs/subarea. Ces lignes de configuration
   doivent se trouver en dehors de votre hôte virtuel HTTPS, afin qu'elles
   s'appliquent à la fois à HTTP et HTTPS.
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é
    Require              ip 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
    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
</Directory>
    
mod_ssl peut enregistrer des informations de
    débogage très verbeuses dans le journal des erreurs, lorsque sa
    directive LogLevel est définie
    à des niveaux de trace élevés. Par contre, sur un serveur très
    sollicité, le niveau info sera probablement déjà trop
    élevé. Souvenez-vous que vous pouvez configurer la directive
    LogLevel par module afin de
    pourvoir à vos besoins.