mirror of
https://github.com/apache/httpd.git
synced 2025-11-09 15:21:02 +03:00
52b6e926ec
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1818609 13f79535-47bb-0310-9956-ffa450edef68
622 lines
30 KiB
Plaintext
622 lines
30 KiB
Plaintext
<?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>
|