From: Lucien Gentis Date: Sat, 15 Aug 2026 13:34:12 +0000 (+0000) Subject: fr doc XML file update. X-Git-Url: http://git.ipfire.org/gitweb/index.cgi?a=commitdiff_plain;h=4ba70e72a6ae83cf1c031824653c788d72943c2e;p=thirdparty%2Fapache%2Fhttpd.git fr doc XML file update. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1937139 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/docs/manual/mod/mod_ssl.xml.fr b/docs/manual/mod/mod_ssl.xml.fr index 4649333387..7c74273edc 100644 --- a/docs/manual/mod/mod_ssl.xml.fr +++ b/docs/manual/mod/mod_ssl.xml.fr @@ -1,7 +1,7 @@ - + @@ -1366,6 +1366,91 @@ redémarrage du serveur est requis pour que les changements prennent effet.

+ +SSLStoreURI +Stockage du certificat et de la clé du serveur +SSLStoreURI uri +server config +virtual host +Disponible à partir de la version 2.5.1 du serveur HTTP Apache +s’il est lié à OpenSSL v3 ou supérieure. + + +

+Cette directive permet de définir, sous la forme d’un URI, un emplacement de +stockage pour les certificats, les certificats intermédiaires et les clés +privées. +

+

+L’URI désigne des données encodées en PEM ou un fichier PKCS12, et possède le +protocole file: par défaut. Les autres protocoles possibles sont +(liste non exhaustive) : pkcs11: pour les cartes à puce et les +modules de sécurité matériel (HSM - Hardware Security Module), cng: +pour le stockage des certificats sous Windows et handle: pour les +modules de plateforme sécurisée (TPM - Trusted Platform Module). Sous Windows, où +le chemin de fichier est aussi un URI valable, le protocole file: +doit être utilisé. +

+

+La directive peut être spécifiée plusieurs fois avec des URI plus précis pour +cibler des clés et certificats spécifiques, ou une seule fois avec un URI +général comme pkcs11: qui cible tous les certificats et clés +possibles. Les certificats, certificats intermédiaires et les clés peuvent être +définis dans n’importe quel ordre. +

+

Les certificats et les clés sont traités comme suit : +

+
    +
  • Les certificats feuille qui n’ont pas pour fonction l’Authentification +du Serveur sont ignorés.
    • +
  • La correspondance entre le nom d’hôte ou l’adresse IP des autres certificats +feuille et la directive ServerName et +toutes les directives ServerAlias est +vérifiée. Si ce n’est pas le cas, ces certificats sont ignorés.
    • +
  • Les certificats intermédiaires sont conçus pour construire des chaînes de +certification du mieux qu’ils peuvent.
    • +
  • Les clés sont associées aux certificats feuille ; tout certificat sans clé +privée est ignoré.
    • +
  • Les certificats feuille avec clé privée sont triés du plus ancien au plus +récent, puis transmis à la configuration.
    • +
  • La paire certificat/clé la plus récente pour chaque type d’algorithme +(RSA, ECDSA, etc.) sera utilisée pour chaque serveur virtuel.
    • +
  • Pour vous aider, le serveur vous indiquera le nombre de certificats trouvés +pour chaque type si aucun certificat ne convient.
    • +
+ +

Si la clé privée est chiffrée, l’invite de saisie de la phrase secrète +sera ouverte au démarrage.

+ +Exemple + +# Exemple utilisant un fichier encodé en PEM. +SSLStoreURI "/usr/local/apache2/conf/ssl.crt/server.crt" +# Exemple utilisant un fichier PKCS12. +SSLStoreURI "/usr/local/apache2/conf/ssl.crt/server.p12" +# Exemple utilisant un certificat et une clé privée depuis un jeton PKCS#11 : +SSLStoreURI "pkcs11:token=My%20Token%20Name;id=45" + + + +

Ce fichier est lu au démarrage du serveur, alors que ce dernier s'exécute +encore en tant que root (avant la restriction de ses privilèges) ; +il ne doit donc être la propriété que de root et lisible uniquement +par ce dernier. Le fichier n'est pas relu en fonctionnement normal ; un +redémarrage du serveur est requis pour que les changements prennent effet.

+ +Utilisation simultanée de SSLCertificateFile et +SSLStoreURI +

+Vous pouvez utiliser simultanément SSLCertificateFile et SSLStoreURI ; il n’y a +cependant pas de recoupement entre ces deux mécanismes. Un certificat défini par +SSLCertificateFile ne sera pas associé à une clé provenant de SSLStoreURI. +

+ + + + + SSLCACertificatePath Répertoire des certificats de CA codés en PEM pour @@ -1435,6 +1520,50 @@ redémarrage du serveur est requis pour que les changements prennent effet.

 + +SSLTrustURI +Stockage du certificat de CA du serveur pour l’authentification du +client +SSLTrustURI uri +server config +virtual host +AuthConfig +Disponible à partir de la version 2.5.1 du serveur HTTP Apache, +quand il est lié avec OpenSSL v3 ou supérieure. + + +

Cette directive permet de définir les URI où vous pouvez stocker les +certificats des autorités de certification (CA) pour les clients auxquels vous +avez à faire. Ces certificats sont utilisés pour l’authentification des clients. +Cette directive peut être utilisée à la place ou en plus des directives +SSLCACertificateFile ou SSLCACertificatePath.

+Exemple + +# faire confiance à des certificats contenus dans un paquet de certificats encodé en PEM +SSLTrustURI "/usr/local/apache2/conf/ssl.crt/ca-bundle-client.crt" +# faire confiance à tous les certificats dans une machine Linux typique +SSLTrustURI "pkcs11:token=System%20Trust" +# faire confiance à tous les certificats dans le stockage de confiance de +# Windows +SSLTrustURI "org.openssl.winstore:" + + + +

+Cette directive lit aussi les listes de révocation de certificats (CRL) des +autorités de certification (CA) pour les clients auxquels vous avez à faire. Ces +listes sont utilisées pour révoquer des certificats client lors d’une +authentification client.

+ +

Ce fichier est lu au démarrage du serveur, alors que ce dernier s'exécute +encore en tant que root (avant la restriction de ses privilèges) ; +il ne doit donc être la propriété que de root et lisible uniquement +par ce dernier. Le fichier n'est pas relu en fonctionnement normal ; un +redémarrage du serveur est requis pour que les changements prennent effet.

+ + + SSLCADNRequestFile Fichier contenant la concaténation des certificats de CA @@ -1451,12 +1580,14 @@ alors utiliser cette liste de noms de CA pour sélectionner un certificat client approprié parmi ceux dont il dispose.

Si aucune des directives SSLCADNRequestFile, SSLCADNRequestPath ou SSLCADNRequestFile n'est définie, la liste -de noms de CsA acceptables envoyée au client est la liste des noms de +module="mod_ssl">SSLTrustRequestURI n'est définie, la liste +de noms de CA acceptables envoyée au client est la liste des noms de tous les certificats de CA spécifiés par les directives SSLCACertificateFile et SSLCACertificatePath ; en d'autres termes, +module="mod_ssl">SSLCACertificateFile, SSLCACertificatePath et SSLTrustURI ; en d'autres termes, c'est la liste des noms de CAs qui sera effectivement utilisée pour vérifier le certificat du client.

@@ -1465,8 +1596,9 @@ une liste de noms de CA acceptables qui diffère de la liste des CAs effectivement utilisés pour vérifier le certificat du client ; considérons par exemple le cas où le certificat du client est signé par des CAs intermédiaires. On peut ici utiliser les directives SSLCADNRequestFile, SSLCADNRequestPath et/ou SSLCADNRequestFile, et les noms de CA +module="mod_ssl">SSLTrustRequestURI, et les noms de CA acceptables seront alors extraits de l'ensemble des certificats contenus dans le répertoire et/ou le fichier définis par cette paire de directives.

@@ -1526,6 +1658,70 @@ effet.

 + +SSLTrustRequestURI +Stockage des certificats de CA pour la définition de noms de CA +acceptables +SSLTrustRequestURI uri +server config +virtual host + + +

Quand un certificat client est demandé par mod_ssl, une liste de noms +d’autorités de certification acceptables est envoyée au client lors de la +négociation SSL. Le client peut utiliser ces noms de CA pour sélectionner un +certificat client approprié parmi ceux dont il dispose.

+ +

Si aucune des directives SSLCADNRequestFile, SSLCADNRequestPath ou SSLTrustRequestURI n'est définie, la liste +de noms de CA acceptables envoyée au client est la liste des noms de +tous les certificats de CA spécifiés par les directives SSLCACertificateFile, SSLCACertificatePath et SSLTrustURI ; en d'autres termes, +c'est la liste des noms de CAs qui sera effectivement utilisée pour +vérifier le certificat du client.

+ +

Dans certaines circonstances, il peut s’avérer utile de pouvoir envoyer un +jeu de noms de CA acceptables qui diffère du jeu de CA effectivement utilisé +pour vérifier le certificat client — par exemple, dans le cas où les certificats +client sont signés par des CA intermédiaires. Dans ces cas, il est possible +d’utiliser les directives SSLCADNRequestFile, SSLCADNRequestPath et/ou SSLTrustRequestURI ; les noms de CA acceptables +seront alors issus du jeu complet de certificats et/ou du fichier spécifiés par +ces directives.

+ +

La directive SSLTrustRequestURI doit +spécifier un URI de stockage de certificats tout-en-un contenant un jeu +de certificats de CA.

+ +Exemple + +SSLTrustRequestURI "file:///usr/local/apache2/conf/ca-names.crt" + + + +

La directive SSLCADNRequestFile peut être remplacée par un URI +file: désignant un fichier de certificats encodés en PEM, et la +directive SSLCADNRequestPath peut être remplacée par un URI +file: désignant un répertoire de certificats encodés en PEM. +

+ +

Les fichiers de ce répertoire sont lus au démarrage du serveur, alors que ce +dernier s'exécute encore en tant que root (avant la restriction de +ses privilèges) ; il ne doit donc être la propriété que de root et +lisible uniquement par ce dernier. Le fichier n'est pas relu en fonctionnement +normal ; un redémarrage du serveur est requis pour que les changements prennent +effet.

+ + + SSLCARevocationPath Répertoire des CRLs de CA codés en PEM pour @@ -2448,6 +2644,102 @@ SSLProxyMachineCertificateChainFile + +SSLProxyStoreURI +Stockages des certificats et des clés d’un serveur mandataire +SSLProxyStoreURI uri +server config virtual host +proxy section +Disponible à partir de la version 2.5.1 du serveur HTTP Apache, +quand il est lié avec OpenSSL v3 ou supérieure. + + +

+Cette directive désigne un emplacement de stockage contenant des +certificats, des certificats intermédiaires et des clés privées, représenté par +un URI à utiliser lors de l’authentification auprès d’un autre serveur +mandataire. +

+

+L’URI désigne des données encodées en PEM ou un fichier PKCS12, et possède le +protocole file: par défaut. Les autres protocoles possibles sont +(liste non exhaustive) : pkcs11: pour les cartes à puce et les +modules de sécurité matériel (HSM - Hardware Security Module), cng: +pour le stockage des certificats sous Windows et handle: pour les +modules de plateforme sécurisée (TPM - Trusted Platform Module). Sous Windows, où +le chemin de fichier est aussi un URI valable, le protocole file: +doit être utilisé. +

+

+La directive peut être spécifiée plusieurs fois avec des URI plus précis pour +cibler des clés et certificats spécifiques, ou une seule fois avec un URI +général comme pkcs11: qui cible tous les certificats et clés +possibles. Les certificats, certificats intermédiaires et les clés peuvent être +définis dans n’importe quel ordre. +

+

Les certificats et clés de mandataire sont traités comme suit : +

+
    +
  • Les certificats feuille qui n’ont pas pour fonction l’Authentification +du Serveur sont ignorés.
    • +
  • Les certificats intermédiaires sont conçus pour construire des chaînes de +certification du mieux qu’ils peuvent.
    • +
  • Les clés sont associées aux certificats feuille ; tout certificat sans clé +privée est ignoré.
    • +
  • Les certificats feuille avec clé privée sont triés du plus ancien au plus +récent, et pris en compte lors de la négociation SSL avec un mandataire.
    • +
  • Pour vous aider, le mandataire vous indiquera le nombre de certificats +trouvés pour chaque type si aucun certificat ne convient.
    • +
+ +

Si la clé privée est chiffrée, l’invite de saisie de la phrase secrète +sera ouverte au démarrage.

+ +Exemple + +# Exemple utilisant un fichier encodé en PEM. +SSLProxyStoreURI "/usr/local/apache2/conf/ssl.crt/proxy.pem" +# Exemple utilisant un fichier PKCS12. +SSLProxyStoreURI "/usr/local/apache2/conf/ssl.crt/proxy.p12" +# Exemple utilisant un certificat et une clé privée depuis un jeton PKCS#11 : +SSLProxyStoreURI "pkcs11:token=My%20Token%20Name;id=45" + + + +

Ce fichier est lu au démarrage du serveur, alors que ce dernier s'exécute +encore en tant que root (avant la restriction de ses privilèges) ; +il ne doit donc être la propriété que de root et lisible uniquement +par ce dernier. Le fichier n'est pas relu en fonctionnement normal ; un +redémarrage du serveur est requis pour que les changements prennent effet.

+ +

Lorsqu’un serveur distant le met au défi de fournir un certificat client, le +serveur doit fournir une liste de noms d’autorités de certification +acceptables lors de la négociation. Si une telle liste n’est pas +fournie, mod_ssl utilisera les certificat et clé client les +plus récemment fournis. Si une liste de noms de CA est fournie, +mod_ssl va parcourir cette liste pour tenter de trouver un +certificat client configuré qui a été fourni soit directement par ce CA, soit +indirectement par un nombre quelconque de CA intermédiaires. +

+ +

Si la liste de noms ce CA est fournie par le serveur distant, et si +aucun certificat client correspondant ne peut être trouvé, aucun +certificat client ne sera fourni par mod_ssl, qui fera +probablement échouer la négociation SSL/TLS (en fonction de la configuration du +serveur distant).

+ +Utilisation simultanée de +SSLProxyMachineCertificateFile et SSLProxyStoreURI +

Vous pouvez utiliser simultanément SSLProxyMachineCertificateFile et +SSLProxyStoreURI ; il n’y a cependant pas de recoupement entre ces deux +mécanismes. Un certificat défini par SSLProxyMachineCertificateFile ne sera pas +associé à une clé provenant de SSLProxyStoreURI. +

+ + + + + SSLProxyVerify Niveau de vérification du certificat du serveur @@ -2800,6 +3092,38 @@ SSLProxyCACertificateFile + +SSLProxyTrustURI +Stockage du certificat de CA du mandataire pour l’authentification +du serveur distant +SSLProxyTrustURI uri +server config virtual host +proxy section +Disponible à partir de la version 2.5.1 du serveur HTTP Apache, +quand il est lié avec OpenSSL v3 ou supérieure. + + +

Cette directive permet de définir les URI où vous pouvez stocker les +certificats des autorités de certification (CA) pour les serveurs +distants auxquels vous avez à faire. Ces certificats sont utilisés pour +l’authentification des serveurs distants. Cette directive peut être utilisée à +la place ou en plus des directives SSLProxyCACertificateFile ou SSLProxyCACertificatePath.

+Exemple + +SSLProxyTrustURI "/usr/local/apache2/conf/ssl.crt/ca-bundle-remote-server.crt" + + +

+Cette directive lit aussi les listes de révocation de certificats (CRL) des +autorités de certification (CA) pour les serveurs distants auxquels vous avez à +faire, s’ils sont dans la portée. Ces listes sont utilisées pour révoquer les +certificats du serveur distant lors de l’authentification de ce dernier. +

+ + + SSLProxyCARevocationPath Répertoire des CRLs de CA codés en PEM pour