From: Lucien Gentis Date: Mon, 11 May 2026 16:12:48 +0000 (+0000) Subject: fr doc XML files updates. X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=b58e2a94a47fd40fef9f98baefc03b460961c167;p=thirdparty%2Fapache%2Fhttpd.git fr doc XML files updates. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1934101 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/docs/manual/mod/mod_policy.xml.fr b/docs/manual/mod/mod_policy.xml.fr index 06708cc95a..b819a94283 100644 --- a/docs/manual/mod/mod_policy.xml.fr +++ b/docs/manual/mod/mod_policy.xml.fr @@ -1,7 +1,7 @@ - + + + + diff --git a/docs/manual/mod/mod_proxy_scgi.xml.fr b/docs/manual/mod/mod_proxy_scgi.xml.fr index 5cf6c91cac..b9d7cd1690 100644 --- a/docs/manual/mod/mod_proxy_scgi.xml.fr +++ b/docs/manual/mod/mod_proxy_scgi.xml.fr @@ -1,7 +1,7 @@  - + diff --git a/docs/manual/mod/mod_session.xml.fr b/docs/manual/mod/mod_session.xml.fr index 10addd2da8..03eca521a5 100644 --- a/docs/manual/mod/mod_session.xml.fr +++ b/docs/manual/mod/mod_session.xml.fr @@ -1,7 +1,7 @@ - + + diff --git a/docs/manual/mod/mod_ssl.xml.fr b/docs/manual/mod/mod_ssl.xml.fr index 4b4b1207f0..ee5e5d9978 100644 --- a/docs/manual/mod/mod_ssl.xml.fr +++ b/docs/manual/mod/mod_ssl.xml.fr @@ -1,7 +1,7 @@ - + @@ -367,16 +367,19 @@ module="mod_ssl">SSLOptions n'a pas été définie.

Fournisseurs d'autorisation disponibles avec Require -

mod_ssl propose quelques fournisseurs - d'autorisation à utiliser avec la directive mod_ssl propose les fournisseurs + d'autorisation suivants à utiliser avec la directive Require du module mod_authz_core.

Require ssl

Le fournisseur ssl refuse l'accès si une connexion - n'est pas chiffrée avec SSL. L'effet est similaire à celui de la - directive SSLRequireSSL.

+ n'est pas chiffrée avec SSL. À la différence de la directive + SSLRequireSSL, cette directive peut être utilisée + conjointement avec d’autres directives Require dans + les blocs RequireAny ou + RequireAll.

@@ -388,7 +391,7 @@ disponibles avec Require
Require ssl-verify-client -

Le fournisseur ssl autorise l'accès si +

Le fournisseur ssl-verify-client autorise l'accès si l'utilisateur est authentifié via un certificat client valide. Ceci n'a un effet que si SSLVerifyClient optional est actif.

@@ -799,30 +802,25 @@ casse) :

Il s'agit du protocole Secure Sockets Layer (SSL) version 3.0 de Netscape Corporation. C'est le successeur de SSLv2 et le prédécesseur de TLSv1, mais est considéré comme - obsolète dans la RFC - 7568

+ obsolète dans la 7568.

  • TLSv1

    Il s'agit du protocole Transport Layer Security (TLS) version 1.0. - C'est le successeur de SSLv3, et il est défini dans la RFC2246.

    • + C'est le successeur de SSLv3, et il est défini dans la 2246.

  • TLSv1.1 (à partir de la version 1.0.1 d'OpenSSL)

    - Une révision du protocole TLS 1.0 définie dans la RFC 4346. Il est + Une révision du protocole TLS 1.0 définie dans la 4346. Il est supporté par la plupart des clients.

  • TLSv1.2 (à partir de la version 1.0.1 d'OpenSSL)

    - Une révision du protocole TLS 1.1 définie dans la RFC 5246.

    • + Une révision du protocole TLS 1.1 définie dans la 5246.

  • TLSv1.3 (avec OpenSSL version 1.1.1 et supérieures)

    - Une nouvelle version du protocole TLS définie dans la RFC 8446.

    • + Une nouvelle version du protocole TLS définie dans la 8446.

  • all

    @@ -1153,38 +1151,52 @@ indépendamment de l'algorithme d'authentification utilisé.

    Enfin, il est aussi possible d'ajouter la clé privée du certificat de l'entité finale au fichier de certificat, ce qui permet de se passer d'une directive SSLCertificateKeyFile séparée. Cette -pratique est cependant fortement déconseillée. Dans ce cas, les fichiers de -certificat qui contiennent de telles clés embarquées doivent être définis -après les certificats qui utilisent un fichier de clé séparé. En outre, -si la clé est chiffrée, une boîte de dialogue pour entrer le mot de -passe de la clé s'ouvre au démarrage du serveur. -

    +module="mod_ssl">SSLCertificateKeyFile séparée.

    + +N’enregistrez pas clé et certificat dans le même +fichier +

    Cette pratique est fortement déconseillée pour les raisons suivantes :

    +
      +
    • Sécurité : conserver la clé privée dans un fichier séparé +permet une gestion plus stricte des permissions de fichier. Le fichier de +certificat peut être lisible par tous (ce sont des données publiques), alors que +le fichier de clé ne doit être lisible que par le superutilisateur. Combiner +les deux dans un même fichier implique que toute vulnérabilité ou mauvaise +configuration qui expose le fichier du certificat exposera aussi la clé privée.
      • +
    • Contrainte d’ordre : si un fichier combiné est utilisé, +toute directive SSLCertificateFile référençant un tel +fichier doit apparaître après toute directive +SSLCertificateFile qui utilise un fichier de clé séparé. +Ne pas respecter cet ordre provoquera des erreurs au démarrage.
      • +
    • Maintenance : avec des fichiers séparés, il est +immédiatement possible de savoir quel fichier contient quoi, ce qui simplifie la +rotation des certificats et les audits.
      • +
    +

    Si la clé privée est chiffrée, la phrase secrète est demandée au démarrage.

    +

    Plutôt que de stocker les certificats et les clés privées dans des fichiers, on peut utiliser un identificateur de certificat pour identifier un certificat -stocké dans un jeton. Actuellement, seuls les URIs PKCS#11 sont reconnus comme -identificateurs de certificats et peuvent être utilisés en conjonction avec le -moteur ou le fournisseur OpenSSL pkcs11. Si la directive SSLCertificateKeyFile est absente, le certificat et -la clé privée peuvent être chargés avec l'identificateur spécifié via la -directive SSLCertificateFile.

    +stocké dans un jeton. Actuellement, seuls les URIs PKCS#11 (7512) +sont reconnus comme identificateurs de certificats et peuvent être utilisés en +conjonction avec le moteur ou le fournisseur OpenSSL pkcs11. Si la +directive SSLCertificateKeyFile est +absente, le certificat et la clé privée peuvent être chargés avec +l'identificateur spécifié via la directive SSLCertificateFile.

    Interopérabilité des paramètres DH avec les nombres premiers de plus de 1024 bits

    -Depuis la version 2.4.7, mod_ssl utilise des -paramètres DH standardisés avec des nombres premiers de 2048, 3072 et -4096 bits, et avec des nombres premiers de 6144 et 8192 bits depuis la -version 2.4.10 (voir RFC -3526), et les fournit aux clients en fonction de la longueur de la -clé du certificat RSA/DSA. En particulier avec les clients basés sur -Java (versions 7 et antérieures), ceci peut provoquer des erreurs au -cours de la négociation - voir cette réponse de la FAQ SSL pour -contourner les problèmes de ce genre. +Depuis la version 2.4.7, mod_ssl utilise des paramètres DH standardisés avec des +nombres premiers de 2048, 3072 et 4096 bits, et avec des nombres premiers de +6144 et 8192 bits depuis la version 2.4.10 (voir la 3526), et les +fournit aux clients en fonction de la longueur de la clé du certificat RSA/DSA. +En particulier avec les clients basés sur Java (versions 7 et antérieures), ceci +peut provoquer des erreurs au cours de la négociation - voir cette réponse de la FAQ SSL pour contourner les +problèmes de ce genre.

    @@ -1261,19 +1273,20 @@ pour l'authentification du serveur. A chaque directive SSLCertificateKeyFile doit être associée une directive SSLCertificateFile correspondante.

    -

    -La clé privée peut aussi être ajoutée au fichier défini par la directive -SSLCertificateFile, mais cette -pratique est fortement déconseillée. Dans ce cas, les fichiers de -certificats qui comportent une telle clé doivent être définis après les -certificats qui utilisent un fichier de clé séparé.

    +N’enregistrez pas clé et certificat dans le même +fichier +

    La clé privée peut aussi être combinée avec le certificat dans le fichier +spécifié par la directive SSLCertificateFile, mais cette pratique est +fortement déconseillée. Voir l’avertissement dans la documentation de la +directive SSLCertificateFile pour une explication +complète des risques et contraintes.

    Plutôt que de stocker des clés privées dans des fichiers, il est possible d'identifier une clé privée via un identifiant stocké dans un jeton. -Actuellement, seuls les PKCS#11 -URIs sont reconnus comme identifiants de clés privées et peuvent être -utilisés en conjonction avec le moteur ou le fournisseur OpenSSL -pkcs11.

    +Actuellement, seuls les URIs PKCS#11 (7512) sont reconnus comme +identifiants de clés privées et peuvent être utilisés en conjonction avec le +moteur ou le fournisseur OpenSSL pkcs11.

    Exemple @@ -1891,21 +1904,16 @@ Les options disponibles sont :

  • StrictRequire

    - Cette option force l'interdiction d'accès lorsque - SSLRequireSSL ou SSLRequire a décidé que - l'accès devait être interdit. Par défaut, dans le cas où - une directive ``Satisfy any'' est utilisée, et si - d'autres restrictions d'accès ont été franchies, on passe en général - outre l'interdiction d'accès due à SSLRequireSSL ou - SSLRequire (parce que c'est ainsi que le mécanisme - Satisfy d'Apache doit fonctionner). Pour des - restrictions d'accès plus strictes, vous pouvez cependant utiliser - SSLRequireSSL et/ou SSLRequire en - combinaison avec une option ``SSLOptions - +StrictRequire''. Une directive ``Satisfy Any'' - n'a alors aucune chance d'autoriser l'accès si mod_ssl a décidé de - l'interdire.

    + Cette option force l'interdiction d'accès lorsque SSLRequireSSL ou SSLRequire a décidé que l’accès doit être + interdit. Sans l’option StrictRequire, il est possible pour + d’autres directives d’autorisation (comme RequireAny) d’outrepasser l’interdiction d’accès + de SSL et d’accorder tout de même l’accès. Avec SSLOptions + +StrictRequire, l’interdiction de SSLRequireSSL ou + SSLRequire s’applique de manière inconditionnelle, sans tenir + compte d’autres directives d’autorisation éventuelles.

  • OptRenegotiate

    @@ -2921,10 +2929,13 @@ définition de la variable d'environnement REMOTE_USER. La valeur de l'argument nom-var peut correspondre à toute variable d'environnement SSL.

    -

    Lorsque l'option FakeBasicAuth est activée, cette -directive contrôle la valeur du nom d'utilisateur contenue dans -l'en-tête d'authentification de base (voir SSLOptions).

    +

    Lorsque l’option FakeBasicAuth (voir SSLOptions) ou la directive AuthBasicFake sont activées, cette directive permet +de contrôler quelle partie du certificat client est utilisée comme nom +d’utilisateur. Sans la directive SSLUserName, +REMOTE_USER peut ne pas être définie pour d’autres modules ou +scripts CGI.

    Exemple @@ -2942,6 +2953,7 @@ du serveur par ordre de préférence SSLHonorCipherOrder off server config virtual host +Disponible à partir de la version 2.1 du serveur HTTP Apache

    Normalement, ce sont les préférences du client qui sont prises en @@ -2986,13 +2998,12 @@ SSLCryptoDevice ubsec

    À partir de la version 3.0 d'OpenSSL, si aucun moteur n'est spécifié alors -que la clé ou le certificat sont spécifiés à l'aide d'URIs PKCS#11, le chargement de la +que la clé ou le certificat sont spécifiés à l'aide d'un URIs PKCS#11 (7512), le chargement de la clé et du certificat est tenté à partir d'un fournisseur OpenSSL. Le fournisseur OpenSSL à utiliser doit être défini et configuré dans le fichier de configuration d'OpenSSL et il doit prendre en charge la méthode -STORE pour les URIs PKCS#11. +STORE pour les URIs PKCS#11 (7512).

    @@ -3001,12 +3012,14 @@ STORE pour les URIs PKCS#11SSLOCSPEnable Active la validation OCSP de la chaîne de certificats du client -SSLOCSPEnable on|leaf|off +SSLOCSPEnable on|leaf|off [flags] SSLOCSPEnable off server config virtual host Le mode leaf est disponible à partir de la version -2.4.34 du serveur HTTP Apache +2.4.34 du serveur HTTP Apache. Le drapeau no_ocsp_for_cert_ok est +disponible à partir de la version 2.4.29 du serveur HTTP Apache. +

    Cette directive permet d'activer la validation OCSP de la chaîne de @@ -3020,6 +3033,17 @@ soit spécifié dans la configuration ; voir les directives SSLOCSPDefaultResponder et SSLOCSPOverrideResponder.

    +

    Les drapeaux facultatifs suivants sont disponibles :

    +
      +
    • no_ocsp_for_cert_ok +

      Normalement, Si la validation OCSP est activée, un certificat qui ne + contient pas d’URL de réponse OCSP provoquera un échec de validation. + Ajouter ce drapeau permet à un tel certificat de passer la validation. Cela + s’avère utile dans les environnements où certains certificats de la chaîne + ne contiennent pas d’information de réponse OCSP.

      +
      • +
    + Exemple SSLVerifyClient on @@ -3210,7 +3234,7 @@ certificats de serveur comportant des certificats de CA intermédiaires dans leur chaîne (c'est un cas typique de nos jours), l'implémentation actuelle de l'agrafage OCSP n'atteint que partiellement l'objectif d' "économie en questions/réponse et en ressources". Pour plus de détails, -voir la RFC 6961 (TLS +voir la 6961 (TLS Multiple Certificate Status Extension).

    @@ -3341,8 +3365,12 @@ réponses concernant les requêtes OCSP "good", les réponses périmées, etc...). Lorsqu'elle est à off, seules les réponses indiquant un statut de certificat -"good" seront incluses dans les -négociations TLS avec les clients.

    +"good" ou "revoked" seront incluses dans les +négociations TLS avec les clients. +Les réponses avec un statut "revoked" sont toujours incluses quelle que soit +cette définition, car supprimer une révocation connue constituerait un risque +de sécurité. +

     @@ -3413,7 +3441,7 @@ d'OpenSSL

    Cette directive permet de définir une clé secrète pour le chiffrement et le déchiffrement des tickets de session TLS selon les préconisations -de la RFC 5077. Elle a +de la 5077. Elle a été conçue à l'origine pour les environnements de clusters où les données des sessions TLS doivent être partagées entre plusieurs noeuds. Pour les configurations ne comportant qu'une seule instance de httpd, il @@ -3618,8 +3646,7 @@ répertoire spécifié

    -ECH est décrit dans draft-ietf-tls-esni +ECH est décrit dans la 9849 ; httpd prend en charge ECH « shared-mode Â» où l’instance de httpd effectue le déchiffrement ECH et héberge les sites web ECH « public-name Â» et « backend Â».