Module Apache mod_ssl_ct

Directive CTAuditStorage ¶

La directive CTAuditStorage 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 directory n'est pas absolu, il sera considéré comme relatif au chemin défini par la directive DefaultRuntimeDir.

Si cette directive n'est pas définie, aucune donnée ne sera stockée en vue d'un audit hors ligne.

Le répertoire considéré contiendra des fichiers nommés PID.tmp pour les processus enfants actifs et PID.out pour les processus enfants terminés. Les données disponibles pour un audit hors ligne sont donc contenues dans les fichiers .out. La commande expérimentale ctauditscts (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 certificate-transparency pour effectuer l'audit.

Directive CTLogClient ¶

executable est le chemin complet de l'utilitaire client du log qui est normalement le fichier cpp/client/ct (ou ct.exe) de l'arborescence des sources du projet open source certificate-transparency.

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.

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.

Directive CTLogConfigDB ¶

La directive CTLogConfigDB permet de définir le nom de la base de données contenant la configuration des logs connus. Si le chemin contenu dans filename n'est pas absolu, il est considéré comme relatif au chemin défini par la directive ServerRoot.

Veuillez vous référer à la documentation du programme ctlogconfig qui gère la base de données.

Directive CTMaxSCTAge ¶

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

Directive CTProxyAwareness ¶

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 :

oblivious

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.

aware

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.

require

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.

Directive CTSCTStorage ¶

La directive CTSCTStorage permet de définir le nom du répertoire où les SCTs et listes de SCTs seront stockés. Si le chemin contenu dans directory n'est pas absolu, il sera considéré comme relatif au chemin défini par la directive DefaultRuntimeDir.

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

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.

Directive CTServerHelloSCTLimit ¶

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.

En général, seuls quelques SCTs sont disponibles, cette directive n'est donc nécessaire que dans certaines circonstances particulières.

Cette directive ne tient pas compte des SCTs contenus dans les extensions de certificats ou les réponses OCSP agrafées.

Directive CTStaticLogConfig ¶

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

Chacun des six champs doit être renseigné, mais en général, la configuration d'un log nécessite peu d'information ; utilisez - 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.

Les champs se définissent comme suit :

log-id

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.
Ce champ peut être omis lorsque public-key-file est renseigné.

public-key-file

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

trust/distrust

Définissez ce champ à 1 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 à - ou 0 (valeur par défaut) pour accorder votre confiance au log.

min-timestamp et max-timestamp

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.
Spécifiez - 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 - pour max-timestamp.
Les SCTs reçu par le mandataire depuis ce log seront invalides si le repère de temps est plus ancien que min-timestamp ou plus récent que max-timestamp.

log-URL

Il s'agit de l'URL du log auquel soumettre les certificats de serveur et ainsi obtenir des SCTs à envoyer aux clients.

Voir aussi

• Le paragraphe Configuration des logs contient des informations à caractère plus général à propos des champs qui peuvent être définis via cette directive.

Directive CTStaticSCTs ¶

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.

certificate-pem-file 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 ServerRoot.

sct-directory doit contenir le chemin vers un ou plusieurs fichiers possédant l'extension de nom de fichier .sct, 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 ServerRoot.

Si sct-directory est vide, aucun message d'erreur ne sera affiché.

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