--- /dev/null
+<?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 : 1783722 -->
+<!-- French translation : Lucien GENTIS -->
+<!-- $LastChangedRevision: 2017022501 $ -->
+
+<!--
+ 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.
+-->
+
+<modulesynopsis metafile="mod_proxy_http2.xml.meta">
+
+<name>mod_proxy_http2</name>
+<description>Support de HTTP/2 pour <module>mod_proxy</module></description>
+<status>Extension</status>
+<sourcefile>mod_proxy_http2.c</sourcefile>
+<identifier>proxy_http2_module</identifier>
+
+<summary>
+ <p><module>mod_proxy_http2</module> ne
+ supporte que HTTP/2 et ne permet pas de rétrogradation vers HTTP/1.1. Cela
+ signifie que le serveur d'arrière-plan doit supporter HTTP/2 car HTTP/1.1 ne
+ pourra alors pas être utilisé.</p>
+
+ <p>Ce module <em>nécessite</em> la présence de <module>mod_proxy</module> ;
+ pour pouvoir traiter les requêtes mandatées HTTP/2,
+ <module>mod_proxy</module> et <module>mod_proxy_http2</module> doivent donc
+ être chargés par le serveur.</p>
+
+ <p><module>mod_proxy_http2</module> travaille avec des requêtes entrantes en
+ HTTP/1.1 ou HTTP/2. Dans les deux cas, les requêtes vers le même serveur
+ d'arrière-plan sont envoyées
+ via une seule connexion TCP, dans la mesure du possible (autrement dit
+ lorsque la connexion peut être réutilisée).</p>
+
+ <p>Avertissement : il ne sera effectué aucune tentative de fusion de
+ plusieurs requêtes entrantes HTTP/1 (devant être mandatées vers le même
+ serveur d'arrière-plan) vers des flux HTTP/2 appartenant à la même requête
+ HTTP/2. Chaque requête HTTP/1 entrante sera mandatée vers le serveur
+ d'arrière-plan en utilisant une requête HTTP/2 séparée (tout en réutilisant
+ si possible la même connexion TCP).</p>
+
+ <p>Ce module s'appuie sur <a href="http://nghttp2.org/">libnghttp2</a> pour
+ fournir le moteur central http/2.</p>
+
+ <note type="warning"><title>Avertissement</title> <p>Ce module en est au
+ stade expérimental. Ses comportement, directives et valeurs par défauts sont
+ donc susceptibles de modifications d'une version à l'autre plus fréquentes
+ que pour les autres modules. A ce titre, il est fortement conseillé aux
+ utilisateurs de consulter le fichier "CHANGES" pour prendre connaissance de
+ ces modifications.</p> </note>
+
+ <note type="warning"><title>Avertissement</title>
+ <p>N'activez pas le mandatement avant d'avoir <a
+ href="mod_proxy.html#access">sécurisé votre serveur</a>. Les serveurs
+ mandataires ouverts sont dangereux non seulement pour votre propre réseau,
+ mais aussi pour l'Internet au sens large.</p>
+ </note>
+</summary>
+<seealso><module>mod_http2</module></seealso>
+<seealso><module>mod_proxy</module></seealso>
+<seealso><module>mod_proxy_connect</module></seealso>
+
+ <section id="examples"><title>Exemples de base</title>
+
+ <p>Les exemples ci-dessous montrent comment configurer HTTP/2 pour des
+ connexions d'arrière-plan vers un mandataire inverse.</p>
+
+ <example><title>HTTP/2 (TLS)</title>
+ <highlight language="config">
+ProxyPass "/app" "h2://app.example.com"
+ProxyPassReverse "/app" "https://app.example.com"
+ </highlight>
+ </example>
+
+ <example><title>HTTP/2 (non sécurisé)</title>
+ <highlight language="config">
+ProxyPass "/app" "h2c://app.example.com"
+ProxyPassReverse "/app" "http://app.example.com"
+ </highlight>
+ </example>
+
+ <note>
+ <p>Pour mandater en inverse les protocoles <code>h2</code> ou
+ <code>h2c</code>, on utilise la directive
+ <directive>ProxyPassReverse</directive> avec les schèmes habituels
+ <code>https</code> et respectivement
+ <code>http</code> qui sont connus et utilisés par l'agent utilisateur.</p>
+ </note>
+ </section> <!-- /examples -->
+
+<section id="notes"><title>Informations sur les requêtes</title>
+ <p><module>mod_proxy_http</module> fournit les informations sur les requêtes
+ suivantes pour enregistrement dans les journaux en utilisant le format
+ <code>%{VARNAME}n</code> avec les directives <directive
+ module="mod_log_config">LogFormat</directive> ou <directive
+ module="core">ErrorLogFormat</directive> :
+ </p>
+ <dl>
+ <dt>proxy-source-port</dt>
+ <dd>Le numéro de port local utilisé pour la connexion vers le serveur
+ d'arrière-plan.</dd>
+ <dt>proxy-status</dt>
+ <dd>Le statut HTTP/2 en provenance du serveur d'arrière-plan.</dd>
+ </dl>
+</section>
+
+</modulesynopsis>
--- /dev/null
+<?xml version="1.0"?>
+<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
+<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
+<!-- English Revision : 1690137 -->
+<!-- French translation : Lucien GENTIS -->
+<!-- $LastChangedRevision: 2015071101 $ -->
+
+<!--
+ 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.
+-->
+
+<modulesynopsis metafile="mod_ssl_ct.xml.meta">
+
+<name>mod_ssl_ct</name>
+<description>Implémentation de la transparence des certificats
+(Certificat Transparency - RFC 6962)
+</description>
+<status>Extension</status>
+<sourcefile>mod_ssl_ct.c</sourcefile>
+<identifier>ssl_ct_module</identifier>
+
+<summary>
+
+<p>Ce module implémente la transparence des certificats en conjonction
+avec <module>mod_ssl</module> et les outils en ligne de commande du
+projet open source <a
+href="https://code.google.com/p/certificate-transparency/">certificate-transparency</a>.
+Le but de la transparence des certificats consiste à révéler
+l'utilisation de certificats de confiance délivrés par
+erreur ou dans un but malintentionné. Vous trouverez plus de détails à
+propos de la transparence des certificats ici : <a
+href="http://www.certificate-transparency.org/">http://www.certificate-transparency.org/</a>.
+Voici la signification des termes utilisés dans cette documentation :</p>
+
+<dl>
+ <dt>Certificate log</dt>
+ <dd>Un Certificate log, auquel on fera référence avec le simple
+ terme <q>log</q> tout au long de ce document, est un service réseau
+ auquel les certificats de serveurs sont soumis. Un agent
+ utilisateur peut vérifier que le certificat d'un serveur auquel il
+ accède a bien été soumis à un log auquel il fait confiance, et que le log
+ lui-même n'a pas rencontré de problème avec ce certificat.</dd>
+
+ <dt>Horodatage signé du certificat (Signed Certificate Timestamp - SCT)</dt>
+ <dd>Il s'agit d'une information en provenance d'un log indiquant qu'il
+ a validé un certificat. Cet horodatage est signé avec la clé publique
+ du log. Un ou plusieurs SCTs sont passés au client durant la phase de
+ négociation de la connexion, soit dans le ServerHello (extension TLS),
+ soit dans l'extension du certificat, soit dans une réponse OCSP
+ jointe.</dd>
+</dl>
+
+<p>Cette implémentation pour Apache httpd fournit les fonctionnalités
+suivantes pout les serveurs et mandataires TLS :</p>
+
+<ul>
+ <li>Les SCTs peuvent être extraits automatiquement des logs, et en
+ conjonction avec tout SCT défini statiquement, envoyés aux clients
+ qui les supportent durant la phase ServerHello de la négociation de la
+ connexion.</li>
+ <li>Le serveur mandataire peut recevoir les SCTs en provenance du
+ serveur original au cours de la phase ServerHello sous la forme d'une
+ extension de certificat, et/ou au sein des réponses OCSP agrafées ;
+ tout SCT reçu peut être validé partiellement en ligne, et
+ éventuellement mis en file d'attente pour un examen plus approfondi
+ hors ligne.</li>
+ <li>Le serveur mandataire peut être configuré de façon à refuser la
+ communication avec un serveur original qui ne fournit pas de SCT
+ pouvant âtre validé en ligne.</li>
+</ul>
+
+<p>La configuration des logs peut être définie statiquement au niveau de
+la configuration du serveur web, ou enregistrée dans une base de données
+SQLite3. Dans ce dernier cas, <module>mod_ssl_ct</module> rechargera à
+intervalles réguliers la base de données, de façon à ce que tout
+changement dans la configuration de la maintenance et de la propagation
+des logs pour un site spécifique ne nécessite pas de redémarrer httpd.</p>
+
+<note>Ce module en est au stade expérimental pour les raisons suivantes
+:
+<ul>
+ <li>Tests et retours d'information insuffisants</li>
+ <li>Repose sur une version non stable (version 1.0.2, Beta 3 ou
+ supérieure) d'OpenSSL pour les
+ opérations de base</li>
+ <li>Implémentation de la <a href="#audit">fonctionnalité d'audit hors
+ ligne</a> incomplète</li>
+</ul>
+
+<p>Les mécanismes de configuration, le format des données enregistrées
+pour l'audit hors ligne, ainsi que d'autres caractéristiques sont
+appelés à évoluer en fonction des tests et retours d'informations à
+venir.</p>
+</note>
+</summary>
+
+<section id="server">
+ <title>Vue d'ensemble du fonctionnement au niveau du serveur</title>
+
+ <p>Les serveurs doivent pouvoir envoyer les SCTs aux clients. Les SCTs
+ seront envoyés sous la forme d'une extension de certificat ou au sein
+ d'une réponse OCSP agrafée sans logique préprogrammée. Ce module gère
+ l'envoi des SCTs configurés par l'administrateur ou en provenance des
+ logs définis.</p>
+
+ <p>Le nombre de SCTs envoyés au cours de la phase ServerHello (c'est à
+ dire les SCTs autres que ceux inclus dans une extension de certificat
+ ou une réponse OCSP agrafée) peut être limité via la directive
+ <directive module="mod_ssl_ct">CTServerHelloSCTLimit</directive>.</p>
+
+ <p>Pour chaque certificat de serveur, un processus maintient une liste
+ de SCTs à envoyer au cours de la phase ServerHello ; cette liste est
+ créée à partir des SCTs configurés statiquement, mais aussi à partir
+ de ceux reçus depuis les logs. Les logs marqués comme suspects ou
+ arrivés à péremption seront ignorés. A intervalles réguliers, le
+ processus va soumettre les certificats à un log selon les besoins
+ (suite à un changement de configuration du log ou de sa durée de vie),
+ et reconstruire la concaténation des SCTs.</p>
+
+ <p>La liste des SCTs pour un certificat de serveur sera envoyée au
+ cours de la phase ClientHello, lorsque ce certificat de serveur
+ particulier est utilisé, à tout client qui fait savoir qu'il supporte
+ cette fonctionnalité.</p>
+
+</section>
+
+<section id="proxy">
+ <title>Vue d'ensemble du fonctionnement au niveau du serveur
+ mandataire</title>
+
+ <p>Le serveur mandataire indique qu'il supporte la Transparence des
+ Certificats au cours de la phase ClientHello en incluant l'extension
+ <em>signed_certificate_timestamp</em>. Il peut reconnaître les SCTs
+ reçus au cours de la phase ServerHello dans une extension du
+ certificat du serveur original, ou au sein d'une réponse OCSP agrafée.</p>
+
+ <p>Une vérification en ligne est effectuée pour tout SCT reçu :</p>
+
+ <ul>
+ <li>Le repère de temps de chaque SCT peut être vérifié pour voir
+ s'il n'est pas encore valide en le comparant avec l'heure actuelle
+ ou tout intervalle de temps valide défini pour le log.</li>
+ <li>Dans le cas d'un SCT issu d'un log pour lequel une clé publique
+ a été définie, la signature du serveur sera vérifiée.</li>
+ </ul>
+
+ <p>Si la vérification échoue ou renvoie un résultat négatif pour au
+ moins un SCT et si la directive <directive
+ module="mod_ssl_ct">CTProxyAwareness</directive> est définie à
+ <em>require</em>, la tentative de connexion est abandonnée.</p>
+
+ <p>En outre, si la directive <directive
+ module="mod_ssl_ct">CTAuditStorage</directive> est définie, la chaîne
+ de certification du serveur et les SCTs sont stockés pour une
+ vérification hors ligne.</p>
+
+ <p>A titre d'optimisation, la vérification en ligne et le stockage des
+ données en provenance du serveur ne sont effectués que la première
+ fois où un processus enfant du serveur web reçoit ces données, ce qui
+ permet d'économiser du temps processeur et de l'espace disque. Dans le
+ cas d'une configuration typique de mandataire inverse, seule une
+ légère augmentation de la charge processeur sera induite.</p>
+
+</section>
+
+<section id="logconf">
+ <title>Configuration du log</title>
+
+ <p>Les serveurs et les mandataires utilisent des informations
+ différentes en ce qui concerne les logs et leurs traitements. Cette
+ <em>configuration des logs</em> peut être effectuée de deux manières :</p>
+
+ <ul>
+ <li>On peut créer une base de données pour configurer le log en
+ utilisant la commande <program>ctlogconfig</program> et en
+ définissant le chemin vers cette base de données via la directive
+ <directive module="mod_ssl_ct">CTLogConfig</directive>.
+ <module>mod_ssl_ct</module> relit la base de données à
+ intervalles réguliers ; cette méthode de configuration supporte donc
+ les mises à jour dynamiques. En outre, la commande d'audit hors
+ ligne <code>ctauditscts</code> peut utiliser cette configuration pour
+ trouver l'URL des logs.</li>
+
+ <li>On peut aussi configurer les logs statiquement via la directive
+ <directive module="mod_ssl_ct">CTStaticLogConfig</directive>. Toute
+ modification de cette directive nécessitera alors un redémarrage du serveur
+ pour être prise en compte, comme pour toutes les autres directives.</li>
+ </ul>
+
+ <p>Les éléments de configuration pouvant être définis par l'une ou
+ l'autre méthode sont les suivants :</p>
+
+ <dl>
+ <dt>Identifiant du log</dt>
+ <dd>L'identifiant du log est le hash SHA-256 de sa clé publique, et
+ est inclus dans tout SCT. Ceci permet d'identifier aisément un log
+ particulier lorsqu'on définit des plages de repères de temps
+ valides ou certaines autres informations.</dd>
+
+ <dt>Clé publique du log</dt>
+ <dd>Un mandataire doit disposer de la clé publique du log afin de
+ pouvoir vérifier la signature dans les SCTs en provenance de ce log.
+ <br />
+ Un serveur doit posséder la clé publique du log afin de pouvoir lui
+ soumettre des certificats.</dd>
+
+ <dt>Configuration générale confiance/méfiance</dt>
+ <dd>Il s'agit d'un mécanisme permettant d'instaurer une méfiance ou
+ de restaurer une confiance envers un log donné pour certaines
+ raisons particulières (y compris la simple interruption des
+ interactions avec le log dans les situations où il est hors ligne).</dd>
+
+ <dt>Repères de temps minima et/ou maxima valides</dt>
+ <dd>Lorsqu'ils sont définis, le mandataire pourra vérifier que les
+ repères de temps contenus dans les SCTs sont compris dans une plage
+ valide</dd>
+
+ <dt>URL du log</dt>
+ <dd>Pour qu'un serveur puisse soumettre des certificats de serveur à
+ un log, il doit connaître l'URL de ce dernier (pour son API). Le
+ serveur soumettra chaque certificat de serveur afin d'obtenir un
+ SCT pour chaque log dont l'URL est définie, sauf pour les logs aussi
+ marqués comme non dignes de confiance ou si l'heure actuelle ne se
+ situe dans aucune des plages de temps valides définies.
+ <br />
+ L'audit hors ligne des SCTs reçus par un mandataire nécessite aussi
+ de connaître l'URL du log.</dd>
+ </dl>
+
+ <p>En général, seuls quelque uns de ces éléments de configuration sont
+ définis pour un log donné. Pour plus de détails, veuillez vous référer
+ à la documentation de la directive <directive
+ module="mod_ssl_ct">CTStaticLogConfig</directive> et de la commande
+ <program>ctlogconfig</program>.</p>
+
+</section>
+
+<section id="static">
+ <title>Stockage des SCTs sous une forme compréhensible pour mod_ssl_ct</title>
+
+ <p>Le module <module>mod_ssl_ct</module> permet de configurer les SCTs
+ de manière statique via la directive
+ <directive>CTStaticSCTs</directive>. Ils doivent alors être sous une forme
+ binaire prête à être envoyée au client.</p>
+
+ <p>Vous trouverez dans le <a
+ href="https://github.com/tomrittervg/ct-tools">Dépôt ct-tools de Tom
+ Ritter</a> un exemple de code sous la forme d'un script Python
+ (<code>write-sct.py</code>) permettant de générer un SCT sous un
+ format correct avec des données en provenance d'un log.</p>
+</section>
+
+<section id="logging">
+ <title>Journalisation des repères de temps des certificats (CT) dans
+ le journal des accès</title>
+
+ <p>Dans les deux modes mandataire et serveur, les variables
+ <code>SSL_CT_PROXY_STATUS</code> et
+ <code>SSL_CT_CLIENT_STATUS</code> sont définies et indiquent si le
+ serveur supporte les CTs.</p>
+
+ <p>Dans le mode mandataire, la variable
+ <code>SSL_CT_PROXY_SCT_SOURCES</code> est définie pour indiquer si des
+ SCTs ont été reçus ainsi que leur source (phase ServerHello de la
+ connexion, extension de certificat, etc...).</p>
+
+ <p>Les valeurs de ces variables peuvent être journalisées via la
+ chaîne de format <code>%{<em>varname</em>}e</code> de
+ <module>mod_log_config</module>.</p>
+</section>
+
+<section id="audit">
+ <title>Audit hors ligne pour mandataire</title>
+
+ <p>Le support de cette fonctionnalité en est au stade expérimental, et
+ est implémenté par la commande <code>ctauditscts</code>, qui repose
+ elle-même sur l'utilitaire <code>verify_single_proof.py</code> du
+ projet open source <em>certificate-transparency</em>. La commande
+ <code>ctauditscts</code> peut parcourir des données, et ainsi effectuer
+ un audit hors ligne (activé via la directive <directive
+ module="mod_ssl_ct">CTAuditStorage</directive>) en invoquant
+ l'utilitaire <code>verify_single_proof.py</code>.</p>
+
+ <p>Voici quelques indication à l'état brut pour l'utilisation de
+ <code>ctauditscts</code> :</p>
+
+ <ul>
+ <li>Créez un <em>virtualenv</em> en utilisant le fichier
+ <code>requirements.txt</code> du projet
+ <em>certificate-transparency</em>, et exécuter les étapes suivantes
+ avec ce <em>virtualenv</em> activé.</li>
+ <li>Définissez <code>PYTHONPATH</code> de façon à inclure le
+ répertoire <code>python</code> dans les chemins par défaut des
+ utilitaires du projet <em>certificate-transparency</em>.</li>
+ <li>Définissez <code>PATH</code> de façon à inclure le chemin du
+ répertoire <code>python/ct/client/tools</code>.</li>
+ <li>Exécutez la commande <code>ctauditscts</code> avec comme
+ arguments la valeur de la directive
+ <directive>CTAuditStorage</directive>, et éventuellement le chemin
+ de la base de données de configuration des logs. Cette dernière sera
+ utilisée pour extraire les URLs des logs en fonction de leurs
+ identifiants.</li>
+ </ul>
+
+ <p>Les données stockées à des fins d'audit peuvent aussi être
+ utilisées par d'autres programmes ; veuillez vous référer au code
+ source de <code>ctauditscts</code> pour plus de détails à propos du
+ traitement des données.</p>
+</section>
+
+<directivesynopsis>
+<name>CTAuditStorage</name>
+<description>Répertoire de stockage des données pour l'audit hors ligne</description>
+<syntax>CTAuditStorage <em>directory</em></syntax>
+<default>none</default>
+<contextlist><context>server config</context></contextlist>
+
+<usage>
+ <p>La directive <directive>CTAuditStorage</directive> permet de
+ définir le chemin du répertoire où les données destinées à un audit hors
+ ligne seront stockées. Ce répertoire doit exister au préalable. Si le
+ chemin contenu dans l'argument <em>directory</em> n'est pas absolu, il
+ sera considéré comme relatif au chemin défini par la directive
+ <directive module="core">DefaultRuntimeDir</directive>.</p>
+
+ <p>Si cette directive n'est pas définie, aucune donnée ne sera stockée
+ en vue d'un audit hors ligne.</p>
+
+ <p>Le répertoire considéré contiendra des fichiers nommés
+ <code><em>PID</em>.tmp</code> pour les processus enfants actifs et
+ <code><em>PID</em>.out</code> pour les processus enfants terminés. Les
+ données disponibles pour un audit hors ligne sont donc contenues dans les
+ fichiers <code>.out</code>. La commande expérimentale
+ <code>ctauditscts</code> (située dans l'arborescence des sources de
+ httpd, mais non encore prise en compte par le processus
+ d'installation), fait appel aux utilitaires du projet
+ <em>certificate-transparency</em> pour effectuer l'audit.</p>
+</usage>
+</directivesynopsis>
+
+<directivesynopsis>
+<name>CTLogClient</name>
+<description>Chemin de l'utilitaire client du log certificate-transparency</description>
+<syntax>CTLogClient <em>executable</em></syntax>
+<default>none</default>
+<contextlist><context>server config</context>
+</contextlist>
+
+<usage>
+ <p><em>executable</em> est le chemin complet de l'utilitaire client du
+ log qui est normalement le fichier <code>cpp/client/ct</code> (ou
+ <code>ct.exe</code>) de l'arborescence des sources du projet open
+ source <a
+ href="https://code.google.com/p/certificate-transparency/">certificate-transparency</a>.</p>
+
+ <p>Il est possible d'utiliser une implémentation alternative pour
+ extraire les SCTs d'un certificat de serveur à partir du moment où
+ l'interface de la ligne de commande est équivalente.</p>
+
+ <p>Si cette directive n'est pas définie, il n'est pas possible de
+ soumettre les certificats aux logs pour en extraire les SCTs ; seuls
+ les SCTs gérés par l'administrateur ou situés dans une extension de
+ certificat seront alors fournis aux clients.</p>
+</usage>
+</directivesynopsis>
+
+<directivesynopsis>
+<name>CTLogConfigDB</name>
+<description>Base de données pour la configuration des logs avec mises à
+jour dynamiques</description>
+<syntax>CTLogConfigDB <em>filename</em></syntax>
+<default>none</default>
+<contextlist><context>server config</context></contextlist>
+
+<usage>
+ <p>La directive <directive>CTLogConfigDB</directive> permet de définir
+ le nom de la base de données contenant la configuration des logs
+ connus. Si le chemin contenu dans <em>filename</em> n'est pas absolu,
+ il est considéré comme relatif au chemin défini par la directive
+ <directive module="core">ServerRoot</directive>.</p>
+
+ <p>Veuillez vous référer à la documentation du programme
+ <program>ctlogconfig</program> qui gère la base de données.</p>
+</usage>
+</directivesynopsis>
+
+<directivesynopsis>
+<name>CTMaxSCTAge</name>
+<description>Age maximum d'un SCT obtenu depuis un log avant son
+raffraîchissement</description>
+<syntax>CTMaxSCTAge <em>num-seconds</em></syntax>
+<default>1 jour</default>
+<contextlist><context>server config</context></contextlist>
+
+<usage>
+ <p>Les certificats de serveur dont les SCTs sont supérieurs à cet âge
+ maximum seront soumis à nouveau aux logs définis. En général, le log
+ va renvoyer le même SCT que précédemment, mais ceux-ci font alors l'objet
+ d'une opération de la part du log. Les SCTs seront raffraîchis autant que
+ nécessaire au cours du fonctionnement normal du serveur, les nouveaux
+ SCTs étant envoyés aux clients au fur et à mesure de leur
+ disponibilité.</p>
+</usage>
+</directivesynopsis>
+
+<directivesynopsis>
+<name>CTProxyAwareness</name>
+<description>Niveau de prise en compte et de mise en oeuvre des CTs pour un
+mandataire
+</description>
+<syntax>CTProxyAwareness <em>oblivious|aware|require</em></syntax>
+<default>aware</default>
+<contextlist><context>server config</context>
+<context>virtual host</context></contextlist>
+
+<usage>
+ <p>Cette directive permet de contrôler la prise en compte et les
+ recherches de SCTs valides pour un mandataire. Les options disponibles
+ sont les suivantes :</p>
+
+ <dl>
+ <dt>oblivious</dt>
+ <dd>Le mandataire de demandera jamais de SCTs, et par conséquent
+ n'en examinera pas. Le processus de transparance des certificats est
+ alors entièrement désactivé pour ce mandataire.</dd>
+
+ <dt>aware</dt>
+ <dd>Le mandataire prendra en charge l'ensemble du processus de
+ transparence des certificats, à savoir la recherche de SCTs et leur
+ examen. Le mandataire n'interrompra cependant pas la connexion si le
+ serveur original ne fournit pas de SCTs valides.</dd>
+
+ <dt>require</dt>
+ <dd>Le mandataire interrompra la connexion avec le serveur original
+ si ce dernir ne fournit pas au moins un SCT qui passe avec succès le
+ test de validation en ligne.</dd>
+ </dl>
+
+</usage>
+</directivesynopsis>
+
+<directivesynopsis>
+<name>CTSCTStorage</name>
+<description>Répertoire où les SCTs sont stockés</description>
+<syntax>CTSCTStorage <em>directory</em></syntax>
+<default>none</default>
+<contextlist><context>server config</context>
+</contextlist>
+
+<usage>
+ <p>La directive <directive>CTSCTStorage</directive> permet de définir
+ le nom du répertoire où les SCTs et listes de SCTs seront stockés. Si
+ le chemin contenu dans <em>directory</em> n'est pas absolu, il sera
+ considéré comme relatif au chemin défini par la directive <directive
+ module="core">DefaultRuntimeDir</directive>.</p>
+
+ <p>Chaque certificat voit ses informations stockées dans un sous-répertoire
+ qui lui est propre ; le nom de ce sous-répertoire correspond au hash
+ SHA-256 du certificat considéré.</p>
+
+ <p>Les sous-répertoires propres à chaque certificat contiennent des
+ SCTs en provenance des logs définis, des listes de SCTs préparées à
+ partir des SCTs configurés statiquement et des SCTs extraits, ainsi
+ que diverses informations utilisées pour gérer les SCTs.</p>
+</usage>
+</directivesynopsis>
+
+<directivesynopsis>
+<name>CTServerHelloSCTLimit</name>
+<description>Nombre maximum de SCTs pouvant être renvoyés au cours de la
+phase ServerHello</description>
+<syntax>CTServerHelloSCTLimit <em>limit</em></syntax>
+<default>100</default>
+<contextlist><context>server config</context>
+</contextlist>
+
+<usage>
+ <p>Cette directive permet de définir le nombre maximum de SCTs pouvant
+ être renvoyés par un serveur TLS au cours de la phase ServerHello dans
+ le cas où le nombre de logs définis et de SCTs définis statiquement
+ est assez important.</p>
+
+ <p>En général, seuls quelques SCTs sont disponibles, cette directive
+ n'est donc nécessaire que dans certaines circonstances particulières.</p>
+
+ <p>Cette directive ne tient pas compte des SCTs contenus dans les
+ extensions de certificats ou les réponses OCSP agrafées.</p>
+</usage>
+</directivesynopsis>
+
+<directivesynopsis>
+<name>CTStaticLogConfig</name>
+<description>Configuration statique d'un log</description>
+<syntax>CTStaticLogConfig <em>log-id|-</em> <em>public-key-file|-</em>
+<em>1|0|-</em> <em>min-timestamp|-</em> <em>max-timestamp|-</em>
+<em>log-URL|-</em></syntax>
+<default>none</default>
+<contextlist><context>server config</context>
+</contextlist>
+
+<usage>
+ <p>Cette directive permet de configurer un log particulier. Elle est
+ particulièrement appropriée dans les cas où cette configuration est
+ rarement modifiée. Si votre cas nécessite plutôt une configuration
+ dynamique, veuillez vous référer à la documentation de la directive
+ <directive module="mod_ssl_ct">CTLogConfigDB</directive>.</p>
+
+ <p>Chacun des six champs doit être renseigné, mais en général, la
+ configuration d'un log nécessite peu d'information ; utilisez
+ <em>-</em> lorsque vous ne disposez d'aucune information à spécifier
+ pour un champ particulier. Par exemple, dans le cas d'une
+ configuration de serveur simple (non mandataire), l'administrateur n'a
+ besoin de spécifier que l'URL du log auquel soumettre des certificats de
+ serveur afin d'en extraire les SCTs.</p>
+
+ <p>Les champs se définissent comme suit :</p>
+
+ <dl>
+ <dt><em>log-id</em></dt>
+ <dd>Il s'agit de l'identifiant du log qui correspond au hash SHA-256
+ de la clé publique du log, codé en hexadécimal. Cette chaîne a une
+ taille de 64 caractères.
+ <br />
+ Ce champ peut être omis lorsque <em>public-key-file</em> est
+ renseigné.</dd>
+
+ <dt><em>public-key-file</em></dt>
+ <dd>Il s'agit du chemin d'un fichier contenant la clé publique du log
+ codée au format PEM. Si ce chemin n'est pas absolu, il est considéré
+ comme relatif au chemin défini par la directive <directive
+ module="core">ServerRoot</directive>.</dd>
+
+ <dt><em>trust/distrust</em></dt>
+ <dd>Définissez ce champ à <em>1</em> pour marquer le log comme non
+ digne de confiance, ou pour tout simplement interdire son
+ utilisation pour le traitement des certificats. Définissez ce champ
+ à <em>-</em> ou <em>0</em> (valeur par défaut) pour accorder votre
+ confiance au log.</dd>
+
+ <dt><em>min-timestamp</em> et <em>max-timestamp</em></dt>
+ <dd>Un repère de temps (timestamp) est un temps exprimé en
+ millisecondes depuis le temps epoch, sans tenir compte des secondes
+ sautées. C'est le format de temps utilisé dans les SCTs. Le repère
+ de temps doit être fourni sous la forme d'un nombre décimal.
+ <br />
+ Spécifiez <strong><code>-</code></strong> pour un des repères de
+ temps s'il n'est pas connu. Par exemple, lorsque vous définissez le
+ repère de temps minimum valide pour un log qui reste valide,
+ spécifiez <strong><code>-</code></strong> pour
+ <em>max-timestamp</em>.
+ <br />
+ Les SCTs reçu par le mandataire depuis ce log seront invalides si le
+ repère de temps est plus ancien que <em>min-timestamp</em> ou plus
+ récent que <em>max-timestamp</em>.</dd>
+
+ <dt><em>log-URL</em></dt>
+ <dd>Il s'agit de l'URL du log auquel soumettre les certificats de
+ serveur et ainsi obtenir des SCTs à envoyer aux clients.</dd>
+ </dl>
+</usage>
+
+<seealso>Le paragraphe <a href="#logconf">Configuration des logs</a>
+contient des informations à caractère plus général à propos des champs qui
+peuvent être définis via cette directive.</seealso>
+
+</directivesynopsis>
+
+<directivesynopsis>
+<name>CTStaticSCTs</name>
+<description>Configuration statique d'un ou plusieurs SCTs pour un
+certificat de serveur
+</description>
+<syntax>CTStaticSCTs <em>certificate-pem-file</em> <em>sct-directory</em></syntax>
+<default>none</default>
+<contextlist><context>server config</context>
+</contextlist>
+
+<usage>
+ <p>Cette directive permet de définir statiquement un ou plusieurs SCTs
+ correspondant à un certificat de serveur. Ce mécanisme peut être
+ utilisé à la place ou en complément de l'obtention dynamique des SCTs
+ en provenance des logs. Toute modification dans le jeu de SCTs d'un
+ certificat de serveur particulier sera prise en compte de manière
+ dynamique sans avoir à redémarrer le serveur.</p>
+
+ <p><em>certificate-pem-file</em> fait référence au fichier contenant
+ le certificat de serveur au format PEM. Si ce chemin n'est pas absolu,
+ il sera considéré comme relatif au chemin défini par la directive
+ <directive module="core">ServerRoot</directive>.</p>
+
+ <p><em>sct-directory</em> doit contenir le chemin vers un ou plusieurs
+ fichiers possédant l'extension de nom de fichier <code>.sct</code>,
+ représentant un ou plusieurs SCTs correspondant au certificat de
+ serveur. Si ce chemin n'est pas absolu,
+ il sera considéré comme relatif au chemin défini par la directive
+ <directive module="core">ServerRoot</directive>.</p>
+
+ <p>Si <em>sct-directory</em> est vide, aucun message d'erreur ne sera
+ affiché.</p>
+
+ <p>Cette directive peut servir à identifier des répertoires de SCTs
+ gérés par une autre infrastructure, sous réserve qu'ils soient
+ enregistrés au format binaire avec l'extension de nom de fichier
+ <em>.sct</em>.</p>
+</usage>
+</directivesynopsis>
+
+</modulesynopsis>
--- /dev/null
+<?xml version="1.0"?>
+<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
+<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
+<!-- English Revision : 1421821 -->
+<!-- French translation : Lucien GENTIS -->
+<!-- $LastChangedRevision: 2012121601 $ -->
+
+<!--
+ 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.
+-->
+
+<modulesynopsis metafile="mod_version.xml.meta">
+<name>mod_version</name>
+<description>Configuration dépendant de la version</description>
+<status>Extension</status>
+<sourcefile>mod_version.c</sourcefile>
+<identifier>version_module</identifier>
+
+<summary>
+ <p>Ce module a été conçu pour être utilisé dans les suites de tests
+ et les grands réseaux qui doivent prendre en compte différentes
+ versions de httpd et différentes configurations. Il fournit un
+ nouveau conteneur -- <directive type="section"
+ module="mod_version">IfVersion</directive>, qui apporte une grande
+ souplesse dans la vérification de version en permettant une
+ comparaison numérique et l'utilisation d'expressions
+ rationnelles.</p>
+
+ <example><title>Exemples</title>
+ <highlight language="config">
+<IfVersion 2.4.2>
+ # la version actuelle de httpd est exactement 2.4.2
+</IfVersion>
+
+<IfVersion >= 2.5>
+ # utilise vraiment les nouvelles fonctionnalités :-)
+</IfVersion>
+ </highlight>
+ </example>
+
+ <p>Voir ci-dessous pour d'autres exemples.</p>
+</summary>
+
+<directivesynopsis type="section">
+<name>IfVersion</name>
+<description>Contient des portions de configuration dépendantes de la
+version</description>
+<syntax><IfVersion [[!]<var>opérateur</var>] <var>version</var>> ...
+</IfVersion></syntax>
+<contextlist><context>server config</context><context>virtual host
+</context>
+<context>directory</context><context>.htaccess</context></contextlist>
+<override>All</override>
+
+<usage>
+ <p>La section <directive type="section">IfVersion</directive>
+ rassemble des directives de configuration qui ne sont exécutées que
+ si la version de httpd satisfait aux critères spécifiés. Pour une
+ comparaison normale (numérique), l'argument <var>version</var> doit
+ être spécifié sous le format
+ <code><var>majeur</var>[.<var>mineur</var>[.<var>patch</var>]]</code>,
+ comme par exemple <code>2.1.0</code> ou <code>2.2</code>.
+ <var>mineur</var> et <var>patch</var> sont optionnels. Si ces
+ numéros sont absents, il se voient affectée implicitement la valeur
+ 0. Les <var>opérateur</var>s numériques suivants sont autorisés
+ :</p>
+
+ <table style="zebra" border="1">
+ <tr><th><var>opérateur</var></th><th>description</th></tr>
+ <tr><td><code>=</code> ou <code>==</code></td>
+ <td>La version de httpd est égale à la valeur
+ spécifiée</td></tr>
+ <tr><td><code>></code></td>
+ <td>La version de httpd est supérieure à la valeur
+ spécifiée</td></tr>
+ <tr><td><code>>=</code></td>
+ <td>La version de httpd est supérieure ou égale à la valeur
+ spécifiée</td></tr>
+ <tr><td><code><</code></td>
+ <td>La version de httpd est inférieure à la valeur
+ spécifiée</td></tr>
+ <tr><td><code><=</code></td>
+ <td>La version de httpd est inférieure ou égale à la valeur
+ spécifiée</td></tr>
+ </table>
+
+ <example><title>Exemple</title>
+ <highlight language="config">
+<IfVersion >= 2.3>
+ # la condition n'est satisfaite que pour les versions de httpd
+ # supérieures ou égales à 2.3
+</IfVersion>
+ </highlight>
+ </example>
+
+ <p>En plus d'une comparaison numérique, il est possible de comparer
+ la version de httpd avec une <glossary ref="regex">expression
+ rationnelle</glossary>. Il existe deux méthodes pour spécifier cette
+ dernière :</p>
+
+ <table style="zebra" border="1">
+ <tr><th><var>opérateur</var></th><th>description</th></tr>
+ <tr><td><code>=</code> ou <code>==</code></td>
+ <td><var>version</var> est de la forme
+ <code>/<var>regex</var>/</code></td></tr>
+ <tr><td><code>~</code></td>
+ <td><var>version</var> est de la forme
+ <code><var>regex</var></code></td></tr>
+ </table>
+
+ <example><title>Exemple</title>
+ <highlight language="config">
+<IfVersion = /^2.4.[01234]$/>
+ # exemple de contournement pour les versions boguées
+</IfVersion>
+ </highlight>
+ </example>
+
+ <p>Pour inverser la condition, tous les opérateurs peuvent être
+ préfixés par un point d'exclamation (<code>!</code>) :</p>
+
+ <example>
+ <highlight language="config">
+<IfVersion !~ ^2.4.[01234]$>
+ # pas pour ces versions
+</IfVersion>
+ </highlight>
+ </example>
+
+ <p>Si <var>opérateur</var> est absent, sa valeur implicite est
+ <code>=</code>.</p>
+</usage>
+</directivesynopsis>
+
+</modulesynopsis>
projects / apache / commitdiff