From: Vincent Deffontaines Date: Mon, 18 Dec 2017 19:00:26 +0000 (+0000) Subject: Introducing 6 new .fr translations X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=52b6e926ec968a9c95af53f77bcaf520d008497a;p=apache Introducing 6 new .fr translations git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1818609 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/docs/manual/mod/mod_proxy_http2.xml.fr b/docs/manual/mod/mod_proxy_http2.xml.fr new file mode 100644 index 0000000000..1520e8e51a --- /dev/null +++ b/docs/manual/mod/mod_proxy_http2.xml.fr @@ -0,0 +1,122 @@ + + + + + + + + + + + +mod_proxy_http2 +Support de HTTP/2 pour mod_proxy +Extension +mod_proxy_http2.c +proxy_http2_module + + +

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

+ +

Ce module nécessite la présence de mod_proxy ; + pour pouvoir traiter les requêtes mandatées HTTP/2, + mod_proxy et mod_proxy_http2 doivent donc + être chargés par le serveur.

+ +

mod_proxy_http2 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).

+ +

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

+ +

Ce module s'appuie sur libnghttp2 pour + fournir le moteur central http/2.

+ + Avertissement

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.

 + + Avertissement +

N'activez pas le mandatement avant d'avoir sécurisé votre serveur. Les serveurs + mandataires ouverts sont dangereux non seulement pour votre propre réseau, + mais aussi pour l'Internet au sens large.

+ + +mod_http2 +mod_proxy +mod_proxy_connect + +
Exemples de base + +

Les exemples ci-dessous montrent comment configurer HTTP/2 pour des + connexions d'arrière-plan vers un mandataire inverse.

+ + HTTP/2 (TLS) + +ProxyPass "/app" "h2://app.example.com" +ProxyPassReverse "/app" "https://app.example.com" + + + + HTTP/2 (non sécurisé) + +ProxyPass "/app" "h2c://app.example.com" +ProxyPassReverse "/app" "http://app.example.com" + + + + +

Pour mandater en inverse les protocoles h2 ou + h2c, on utilise la directive + ProxyPassReverse avec les schèmes habituels + https et respectivement + http qui sont connus et utilisés par l'agent utilisateur.

+ +
+ +
Informations sur les requêtes +

mod_proxy_http fournit les informations sur les requêtes + suivantes pour enregistrement dans les journaux en utilisant le format + %{VARNAME}n avec les directives LogFormat ou ErrorLogFormat : +

+
+
proxy-source-port
+
Le numéro de port local utilisé pour la connexion vers le serveur + d'arrière-plan.
+
proxy-status
+
Le statut HTTP/2 en provenance du serveur d'arrière-plan.
+
+
+ + diff --git a/docs/manual/mod/mod_proxy_http2.xml.meta b/docs/manual/mod/mod_proxy_http2.xml.meta index 2ccd79bba6..071a546512 100644 --- a/docs/manual/mod/mod_proxy_http2.xml.meta +++ b/docs/manual/mod/mod_proxy_http2.xml.meta @@ -8,5 +8,6 @@ en + fr diff --git a/docs/manual/mod/mod_proxy_wstunnel.xml.fr b/docs/manual/mod/mod_proxy_wstunnel.xml.fr new file mode 100644 index 0000000000..d7f0ea81e8 --- /dev/null +++ b/docs/manual/mod/mod_proxy_wstunnel.xml.fr @@ -0,0 +1,126 @@ + + + + + + + + + + + +mod_proxy_wstunnel +Module pour mod_proxy supportant les +websockets +Extension +mod_proxy_wstunnel.c +proxy_wstunnel_module +Disponible à partir de la version 2.4.5 du serveur HTTP +Apache + + +

Pour utiliser ce module, mod_proxy doit être + chargé. Il fournit le support du tunnelling pour les connexions + websocket vers un serveur websockets d'arrière-plan. La connexion + est automatiquement promue en connexion websocket :

+ + Réponse HTTP + +Upgrade: WebSocket +Connection: Upgrade + + + +

Le mandatement des requêtes vers un serveur websockets comme +echo.websocket.org peut être configuré via la directive ProxyPass :

+ +ProxyPass "/ws2/" "ws://echo.websocket.org/" +ProxyPass "/wss2/" "wss://echo.websocket.org/" + + +

La répartition de charge entre plusieurs serveurs d'arrière-plan peut être +configurée via le module mod_proxy_balancer.

+ +

En fait, ce module permet d'accepter d'autres protocoles ; vous pouvez à cet +effet utiliser le paramètre upgrade de la directive ProxyPass. La valeur NONE +signifie que vous court-circuitez la consultation de l'en-tête, mais que vous +autorisez quand-même WebSocket. La valeur ANY signifie que Upgrade +va lire les en-têtes de la requête et les utilisera dans l'en-tête +Upgrade de la réponse.

+ + +mod_proxy + + +ProxyWebsocketAsync +Création d'un tunnel asynchrone +ProxyWebsocketAsync ON|OFF +server config +virtual host + + + +

Cette directive permet d'imposer la création d'un tunnel + asynchrone. Si le module MPM utilisé ne supporte pas les + fonctionnalités nécessaires, le tunnel est créé en mode synchrone.

+ Note

Le support du mode asynchrone est + au stade expérimental et est susceptible d'évoluer.

 + + + + +ProxyWebsocketIdleTimeout +Temps d'attente maximum pour des données sur le tunnel websockets +ProxyWebsocketIdleTimeout num[ms] +ProxyWebsocketIdleTimeout 0 +server config +virtual host + + + +

Cette directive permet de définir un temps maximum pendant lequel + le tunnel pourra rester ouvert et inactif. Par défaut, ce temps est exprimé + en secondes, mais vous pouvez le spécifier en millisecondes en utilisant le + suffixe ms.

+ + + + +ProxyWebsocketAsyncDelay +Temps d'attente synchrone maximum pour des données +ProxyWebsocketAsyncDelay num[ms] +ProxyWebsocketAsyncDelay 0 +server config +virtual host + + + +

Si la directive ProxyWebsocketAsync est + activée, cette directive permet de définir le temps maximum pendant lequel + le serveur attendra des données en mode synchrone. Par défaut, ce temps est exprimé + en secondes, mais vous pouvez le spécifier en millisecondes en utilisant le + suffixe ms.

+ + Note

Le support du mode asynchrone est + au stade expérimental et est susceptible d'évoluer.

 + + + + diff --git a/docs/manual/mod/mod_proxy_wstunnel.xml.meta b/docs/manual/mod/mod_proxy_wstunnel.xml.meta index d12fab9bcb..6c0a516e2a 100644 --- a/docs/manual/mod/mod_proxy_wstunnel.xml.meta +++ b/docs/manual/mod/mod_proxy_wstunnel.xml.meta @@ -8,5 +8,6 @@ en + fr diff --git a/docs/manual/mod/mod_ssl_ct.xml.fr b/docs/manual/mod/mod_ssl_ct.xml.fr new file mode 100644 index 0000000000..1a9901f165 --- /dev/null +++ b/docs/manual/mod/mod_ssl_ct.xml.fr @@ -0,0 +1,621 @@ + + + + + + + + + + + +mod_ssl_ct +Implémentation de la transparence des certificats +(Certificat Transparency - RFC 6962) + +Extension +mod_ssl_ct.c +ssl_ct_module + + + +

Ce module implémente la transparence des certificats en conjonction +avec mod_ssl et les outils en ligne de commande du +projet open source certificate-transparency. +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 : http://www.certificate-transparency.org/. +Voici la signification des termes utilisés dans cette documentation :

+ +
+
Certificate log
+
Un Certificate log, auquel on fera référence avec le simple + terme log 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.
+ +
Horodatage signé du certificat (Signed Certificate Timestamp - SCT)
+
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.
+
+ +

Cette implémentation pour Apache httpd fournit les fonctionnalités +suivantes pout les serveurs et mandataires TLS :

+ +
    +
  • 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.
    • +
  • 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.
    • +
  • 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.
    • +
+ +

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, mod_ssl_ct 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.

+ +Ce module en est au stade expérimental pour les raisons suivantes +: +
    +
  • Tests et retours d'information insuffisants
    • +
  • Repose sur une version non stable (version 1.0.2, Beta 3 ou + supérieure) d'OpenSSL pour les + opérations de base
    • +
  • Implémentation de la fonctionnalité d'audit hors + ligne incomplète
    • +
+ +

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.

+ + + +
+ Vue d'ensemble du fonctionnement au niveau du serveur + +

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.

+ +

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 + CTServerHelloSCTLimit.

+ +

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.

+ +

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

+ +
+ +
+ Vue d'ensemble du fonctionnement au niveau du serveur + mandataire + +

Le serveur mandataire indique qu'il supporte la Transparence des + Certificats au cours de la phase ClientHello en incluant l'extension + signed_certificate_timestamp. 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.

+ +

Une vérification en ligne est effectuée pour tout SCT reçu :

+ +
    +
  • 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.
    • +
  • 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.
    • +
+ +

Si la vérification échoue ou renvoie un résultat négatif pour au + moins un SCT et si la directive CTProxyAwareness est définie à + require, la tentative de connexion est abandonnée.

+ +

En outre, si la directive CTAuditStorage est définie, la chaîne + de certification du serveur et les SCTs sont stockés pour une + vérification hors ligne.

+ +

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.

+ +
+ +
+ Configuration du log + +

Les serveurs et les mandataires utilisent des informations + différentes en ce qui concerne les logs et leurs traitements. Cette + configuration des logs peut être effectuée de deux manières :

+ +
    +
  • On peut créer une base de données pour configurer le log en + utilisant la commande ctlogconfig et en + définissant le chemin vers cette base de données via la directive + CTLogConfig. + mod_ssl_ct 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 ctauditscts peut utiliser cette configuration pour + trouver l'URL des logs.
    • + +
  • On peut aussi configurer les logs statiquement via la directive + CTStaticLogConfig. Toute + modification de cette directive nécessitera alors un redémarrage du serveur + pour être prise en compte, comme pour toutes les autres directives.
    • +
+ +

Les éléments de configuration pouvant être définis par l'une ou + l'autre méthode sont les suivants :

+ +
+
Identifiant du log
+
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.
+ +
Clé publique du log
+
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. +
+ Un serveur doit posséder la clé publique du log afin de pouvoir lui + soumettre des certificats.
+ +
Configuration générale confiance/méfiance
+
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).
+ +
Repères de temps minima et/ou maxima valides
+
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
+ +
URL du log
+
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. +
+ L'audit hors ligne des SCTs reçus par un mandataire nécessite aussi + de connaître l'URL du log.
+
+ +

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 CTStaticLogConfig et de la commande + ctlogconfig.

+ +
+ +
+ Stockage des SCTs sous une forme compréhensible pour mod_ssl_ct + +

Le module mod_ssl_ct permet de configurer les SCTs + de manière statique via la directive + CTStaticSCTs. Ils doivent alors être sous une forme + binaire prête à être envoyée au client.

+ +

Vous trouverez dans le Dépôt ct-tools de Tom + Ritter un exemple de code sous la forme d'un script Python + (write-sct.py) permettant de générer un SCT sous un + format correct avec des données en provenance d'un log.

+
+ +
+ Journalisation des repères de temps des certificats (CT) dans + le journal des accès + +

Dans les deux modes mandataire et serveur, les variables + SSL_CT_PROXY_STATUS et + SSL_CT_CLIENT_STATUS sont définies et indiquent si le + serveur supporte les CTs.

+ +

Dans le mode mandataire, la variable + SSL_CT_PROXY_SCT_SOURCES 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...).

+ +

Les valeurs de ces variables peuvent être journalisées via la + chaîne de format %{varname}e de + mod_log_config.

+
+ +
+ Audit hors ligne pour mandataire + +

Le support de cette fonctionnalité en est au stade expérimental, et + est implémenté par la commande ctauditscts, qui repose + elle-même sur l'utilitaire verify_single_proof.py du + projet open source certificate-transparency. La commande + ctauditscts peut parcourir des données, et ainsi effectuer + un audit hors ligne (activé via la directive CTAuditStorage) en invoquant + l'utilitaire verify_single_proof.py.

+ +

Voici quelques indication à l'état brut pour l'utilisation de + ctauditscts :

+ +
    +
  • Créez un virtualenv en utilisant le fichier + requirements.txt du projet + certificate-transparency, et exécuter les étapes suivantes + avec ce virtualenv activé.
    • +
  • Définissez PYTHONPATH de façon à inclure le + répertoire python dans les chemins par défaut des + utilitaires du projet certificate-transparency.
    • +
  • Définissez PATH de façon à inclure le chemin du + répertoire python/ct/client/tools.
    • +
  • Exécutez la commande ctauditscts avec comme + arguments la valeur de la directive + CTAuditStorage, 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.
    • +
+ +

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 ctauditscts pour plus de détails à propos du + traitement des données.

+
+ + +CTAuditStorage +Répertoire de stockage des données pour l'audit hors ligne +CTAuditStorage directory +none +server config + + +

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.

+ + + + +CTLogClient +Chemin de l'utilitaire client du log certificate-transparency +CTLogClient executable +none +server config + + + +

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.

+ + + + +CTLogConfigDB +Base de données pour la configuration des logs avec mises à +jour dynamiques +CTLogConfigDB filename +none +server config + + +

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.

+ + + + +CTMaxSCTAge +Age maximum d'un SCT obtenu depuis un log avant son +raffraîchissement +CTMaxSCTAge num-seconds +1 jour +server config + + +

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

+ + + + +CTProxyAwareness +Niveau de prise en compte et de mise en oeuvre des CTs pour un +mandataire + +CTProxyAwareness oblivious|aware|require +aware +server config +virtual host + + +

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.
+
+ + + + + +CTSCTStorage +Répertoire où les SCTs sont stockés +CTSCTStorage directory +none +server config + + + +

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.

+ + + + +CTServerHelloSCTLimit +Nombre maximum de SCTs pouvant être renvoyés au cours de la +phase ServerHello +CTServerHelloSCTLimit limit +100 +server config + + + +

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.

+ + + + +CTStaticLogConfig +Configuration statique d'un log +CTStaticLogConfig log-id|- public-key-file|- +1|0|- min-timestamp|- max-timestamp|- +log-URL|- +none +server config + + + +

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.
+
+ + +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. + + + + +CTStaticSCTs +Configuration statique d'un ou plusieurs SCTs pour un +certificat de serveur + +CTStaticSCTs certificate-pem-file sct-directory +none +server config + + + +

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.

+ + + + diff --git a/docs/manual/mod/mod_ssl_ct.xml.meta b/docs/manual/mod/mod_ssl_ct.xml.meta index c33bcb9fde..8fc8c4826d 100644 --- a/docs/manual/mod/mod_ssl_ct.xml.meta +++ b/docs/manual/mod/mod_ssl_ct.xml.meta @@ -8,5 +8,6 @@ en + fr diff --git a/docs/manual/mod/mod_syslog.xml.fr b/docs/manual/mod/mod_syslog.xml.fr new file mode 100644 index 0000000000..9926ee9cd8 --- /dev/null +++ b/docs/manual/mod/mod_syslog.xml.fr @@ -0,0 +1,59 @@ + + + + + + + + + + + +mod_syslog +Support du fournisseur de journalisation "syslog" +Extension +mod_syslog.c +syslog_module + + + +

Ce module implémente le fournisseur de journalisation "syslog". + Il permet de journaliser les messages d'erreur via syslogd(8).

+ + +
+ Exemples + +

Si le système le supporte, l'utilisation du paramètre + syslog avec la directive ErrorLog (voir la + documentation du module core) à la place d'un nom + de fichier permet de journaliser les messages d'erreur via + syslogd(8). Par défaut, c'est le port syslog local7 qui + est utilisé, mais vous pouvez le modifier via la syntaxe + syslog:port où port pourra + correspondre à un des noms habituellement définis dans la + documentation de syslog(1). La définition de ce port est réellement + globale, et même si elle est modifiée au niveau d'un serveur + virtuel, elle affecte l'ensemble du serveur.

+ + ErrorLog syslog:user + +
+ + + diff --git a/docs/manual/mod/mod_syslog.xml.meta b/docs/manual/mod/mod_syslog.xml.meta index cb174b302f..bf9b2c11e9 100644 --- a/docs/manual/mod/mod_syslog.xml.meta +++ b/docs/manual/mod/mod_syslog.xml.meta @@ -8,5 +8,6 @@ en + fr diff --git a/docs/manual/mod/mod_systemd.xml.fr b/docs/manual/mod/mod_systemd.xml.fr new file mode 100644 index 0000000000..2766954785 --- /dev/null +++ b/docs/manual/mod/mod_systemd.xml.fr @@ -0,0 +1,79 @@ + + + + + + + + + + + +mod_systemd +Fournit un support amélioré pour l'intégration de systemd +Extension +mod_systemd.c +systemd_module + + +

Ce module implémente le support de l'intégration de systemd. Il + permet de démarrer httpd en temps que service avec le paramètre de + systemd Type=notify (voir la page de manuel + systemd.service(5) pour plus de détails). Il ajoute aussi des + statistiques à la sortie de la commande systemctl + status, et fournit diverses directives pour l'intégration de + systemd. +

+ + + +IdleShutdown +Permet d'arrêter httpd lorsque qu'il est inactif pendant un +certain temps. +IdleShutdown seconds +IdleShutdown 0 +server config + + +

La directive IdleShutdown permet d'arrêter + httpd lorsque qu'il est inactif pendant un certain temps. Ce statut + d'inactivité se base sur le nombre d'octets envoyés ; par conséquent, si + aucun octet n'est envoyé pendant le temps spécifié par cette + directive, httpd sera arrêté. Par défaut, IdleShutdown est définie à + 0, ce qui signifie que cette fonctionnalité est désactivée. +

+ +

Cette fonctionnalité prend tout son sens en combinaison avec + l'activation du socket systemd (voir la page de manuel + systemd.socket(5)). En effet, lorsque httpd est démarré par systemd + suite à l'arrivée d'une ou plusieurs requêtes HTTP, cette directive + vous permet d'arrêter httpd automatiquement lorsque toutes les + requêtes ont été traitées. +

+ + Particularité de cette implémentation

+ De par la conception de cette implémentation, l'inactivité de httpd + n'est vérifiée que toutes les 10 secondes, ce qui signifie que si + vous spécifiez IdleShutdown 14, httpd ne s'arrêtera + qu'après 20 secondes d'inactivité. +

+ + + + + diff --git a/docs/manual/mod/mod_systemd.xml.meta b/docs/manual/mod/mod_systemd.xml.meta index 736c72dc7a..edb0b7cbc9 100644 --- a/docs/manual/mod/mod_systemd.xml.meta +++ b/docs/manual/mod/mod_systemd.xml.meta @@ -8,5 +8,6 @@ en + fr diff --git a/docs/manual/mod/mod_version.xml.fr b/docs/manual/mod/mod_version.xml.fr new file mode 100644 index 0000000000..c7c503f76b --- /dev/null +++ b/docs/manual/mod/mod_version.xml.fr @@ -0,0 +1,148 @@ + + + + + + + + + + +mod_version +Configuration dépendant de la version +Extension +mod_version.c +version_module + + +

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 -- IfVersion, qui apporte une grande + souplesse dans la vérification de version en permettant une + comparaison numérique et l'utilisation d'expressions + rationnelles.

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

Voir ci-dessous pour d'autres exemples.

+ + + +IfVersion +Contient des portions de configuration dépendantes de la +version +<IfVersion [[!]opérateur] version> ... +</IfVersion> +server configvirtual host + +directory.htaccess +All + + +

La section IfVersion + 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 version doit + être spécifié sous le format + majeur[.mineur[.patch]], + comme par exemple 2.1.0 ou 2.2. + mineur et patch sont optionnels. Si ces + numéros sont absents, il se voient affectée implicitement la valeur + 0. Les opérateurs numériques suivants sont autorisés + :

+ + + + + + + + + + + + + +
opérateurdescription
= ou ==La version de httpd est égale à la valeur + spécifiée
>La version de httpd est supérieure à la valeur + spécifiée
>=La version de httpd est supérieure ou égale à la valeur + spécifiée
<La version de httpd est inférieure à la valeur + spécifiée
<=La version de httpd est inférieure ou égale à la valeur + spécifiée
+ + Exemple + +<IfVersion >= 2.3> + # la condition n'est satisfaite que pour les versions de httpd + # supérieures ou égales à 2.3 +</IfVersion> + + + +

En plus d'une comparaison numérique, il est possible de comparer + la version de httpd avec une expression + rationnelle. Il existe deux méthodes pour spécifier cette + dernière :

+ + + + + + + +
opérateurdescription
= ou ==version est de la forme + /regex/
~version est de la forme + regex
+ + Exemple + +<IfVersion = /^2.4.[01234]$/> + # exemple de contournement pour les versions boguées +</IfVersion> + + + +

Pour inverser la condition, tous les opérateurs peuvent être + préfixés par un point d'exclamation (!) :

+ + + +<IfVersion !~ ^2.4.[01234]$> + # pas pour ces versions +</IfVersion> + + + +

Si opérateur est absent, sa valeur implicite est + =.

+ + + + diff --git a/docs/manual/mod/mod_version.xml.meta b/docs/manual/mod/mod_version.xml.meta index 4fbd74a3a1..5dcdb84f2e 100644 --- a/docs/manual/mod/mod_version.xml.meta +++ b/docs/manual/mod/mod_version.xml.meta @@ -8,6 +8,7 @@ en + fr ja ko