Serveur Apache HTTP Version 2.4
Description: | Chiffrement de haut niveau basé sur les protocoles Secure Sockets Layer (SSL) et Transport Layer Security (TLS) |
---|---|
Statut: | Extension |
Identificateur de Module: | ssl_module |
Fichier Source: | mod_ssl.c |
Ce module fournit le support SSL v3 et TLS v1 au serveur HTTP Apache. SSL v2 n'est plus supporté.
Ce module s'appuie sur OpenSSL pour fournir le moteur de chiffrement.
D'autres détails, discussions et exemples sont fournis dans la documentation SSL.
Ce module peut être configuré pour fournir aux espaces de nommage SSI
et CGI de nombreux éléments d'informations concernant SSL par le biais
de variables d'environnement supplémentaires. Par défaut, et pour
des raisons de performances, ces informations ne sont pas fournies (Voir
la directive SSLOptions
StdEnvVars ci-dessous).
Les variables générées se trouvent dans la table ci-dessous.
Ces informations peuvent également être disponible sous des noms différents
à des fins de compatibilité ascendante. Reportez-vous au chapitre Compatibilité pour plus de détails à
propos des variables de compatibilité.
Nom de la variable : | Type de valeur : | Description : |
---|---|---|
HTTPS | drapeau | HTTPS est utilisé. |
SSL_PROTOCOL | chaîne | La version du protocole SSL (SSLv3, TLSv1, TLSv1.1, TLSv1.2) |
SSL_SESSION_ID | chaîne | L'identifiant de session SSL codé en hexadécimal |
SSL_SESSION_RESUMED | chaîne | Session SSL initiale ou reprise. Note : plusieurs requêtes peuvent être servies dans le cadre de la même session SSL (initiale ou reprise) si les connexions persistantes (HTTP KeepAlive) sont utilisées |
SSL_SECURE_RENEG | chaîne | true si la renégociation sécurisée est supportée,
false dans le cas contraire |
SSL_CIPHER | chaîne | Le nom de l'algorithme de chiffrement |
SSL_CIPHER_EXPORT | chaîne | true si l'algorithme de chiffrement est un algorithme
exporté |
SSL_CIPHER_USEKEYSIZE | nombre | Nombre de bits de chiffrement (réellement utilisés) |
SSL_CIPHER_ALGKEYSIZE | nombre | Nombre de bits de chiffrement (possible) |
SSL_COMPRESS_METHOD | chaîne | Méthode de compression SSL négociée |
SSL_VERSION_INTERFACE | chaîne | La version du programme mod_ssl |
SSL_VERSION_LIBRARY | chaîne | La version du programme OpenSSL |
SSL_CLIENT_M_VERSION | chaîne | La version du certificat client |
SSL_CLIENT_M_SERIAL | chaîne | Le numéro de série du certificat client |
SSL_CLIENT_S_DN | chaîne | Le DN sujet du certificat client |
SSL_CLIENT_S_DN_ x509 | chaîne | Elément du DN sujet du client |
SSL_CLIENT_I_DN | chaîne | DN de l'émetteur du certificat du client |
SSL_CLIENT_I_DN_ x509 | chaîne | Elément du DN de l'émetteur du certificat du client |
SSL_CLIENT_V_START | chaîne | Validité du certificat du client (date de début) |
SSL_CLIENT_V_END | chaîne | Validité du certificat du client (date de fin) |
SSL_CLIENT_V_REMAIN | chaîne | Nombre de jours avant expiration du certificat du client |
SSL_CLIENT_A_SIG | chaîne | Algorithme utilisé pour la signature du certificat du client |
SSL_CLIENT_A_KEY | chaîne | Algorithme utilisé pour la clé publique du certificat du client |
SSL_CLIENT_CERT | chaîne | Certificat du client au format PEM |
SSL_CLIENT_CERT_CHAIN_ n |
chaîne | Certificats de la chaîne de certification du client au format PEM |
SSL_CLIENT_VERIFY | chaîne | NONE , SUCCESS , GENEROUS ou
FAILED: raison |
SSL_SERVER_M_VERSION | chaîne | La version du certificat du serveur |
SSL_SERVER_M_SERIAL | chaîne | The serial of the server certificate |
SSL_SERVER_S_DN | chaîne | DN sujet du certificat du serveur |
SSL_SERVER_S_DN_ x509 | chaîne | Elément du DN sujet du certificat du serveur |
SSL_SERVER_I_DN | chaîne | DN de l'émetteur du certificat du serveur |
SSL_SERVER_I_DN_ x509 | chaîne | Elément du DN de l'émetteur du certificat du serveur |
SSL_SERVER_V_START | chaîne | Validité du certificat du serveur (date de dédut) |
SSL_SERVER_V_END | chaîne | Validité du certificat du serveur (date de fin) |
SSL_SERVER_A_SIG | chaîne | Algorithme utilisé pour la signature du certificat du serveur |
SSL_SERVER_A_KEY | chaîne | Algorithme utilisé pour la clé publique du certificat du serveur |
SSL_SERVER_CERT | chaîne | Certificat du serveur au format PEM |
SSL_SRP_USER | chaîne | nom d'utilisateur SRP |
SSL_SRP_USERINFO | chaîne | informations sur l'utilisateur SRP |
SSL_TLS_SNI | string | Contenu de l'extension SNI TLS (si supporté par ClientHello) |
x509 spécifie un élément de DN X.509 parmi
C,ST,L,O,OU,CN,T,I,G,S,D,UID,Email
. A partir de la version
2.1 d'Apache, x509 peut aussi comporter un suffixe numérique
_n
. Si le DN en question comporte plusieurs attributs de
noms identiques, ce suffixe constitue un index débutant à zéro et
permettant de sélectionner un
attribut particulier. Par exemple, si le DN sujet du certificat du
serveur comporte deux champs OU, on peut utiliser
SSL_SERVER_S_DN_OU_0
et SSL_SERVER_S_DN_OU_1
pour référencer chacun d'entre eux. Un nom de variable sans suffixe
_n
est équivalent au même nom avec le suffixe
_0
, ce qui correspond au premier attribut (ou au seul)
caractérisant le DN.
Lorsque la table d'environnement est remplie en utilisant l'option
StdEnvVars
de la directive SSLOptions
, le premier attribut (ou le
seul) caractérisant le DN est enregistré avec un nom sans suffixe ;
autrement dit, aucune entrée possédant comme suffixe _0
n'est enregistrée.
Le format des variables *_DN a changé depuis la version
2.3.11 d'Apache HTTPD. Voir l'option LegacyDNStringFormat
de la directive SSLOptions
pour
plus de détails.
SSL_CLIENT_V_REMAIN
n'est disponible qu'à partir de la
version 2.1.
Plusieurs variables d'environnement additionnelles peuvent être
utilisées dans les expressions SSLRequire
, ou
dans les formats de journalisation personnalisés :
HTTP_USER_AGENT PATH_INFO AUTH_TYPE HTTP_REFERER QUERY_STRING SERVER_SOFTWARE HTTP_COOKIE REMOTE_HOST API_VERSION HTTP_FORWARDED REMOTE_IDENT TIME_YEAR HTTP_HOST IS_SUBREQ TIME_MON HTTP_PROXY_CONNECTION DOCUMENT_ROOT TIME_DAY HTTP_ACCEPT SERVER_ADMIN TIME_HOUR THE_REQUEST SERVER_NAME TIME_MIN REQUEST_FILENAME SERVER_PORT TIME_SEC REQUEST_METHOD SERVER_PROTOCOL TIME_WDAY REQUEST_SCHEME REMOTE_ADDR TIME REQUEST_URI REMOTE_USER
Dans ces contextes, deux formats spéciaux peuvent aussi être utilisés :
ENV:nom_variable
HTTP:nom_en-tête
Lorsque mod_ssl
est compilé dans le serveur Apache
ou même chargé (en mode DSO), des fonctions supplémentaires sont
disponibles pour le Format de journal personnalisé du
module mod_log_config
. A ce titre, la fonction de
format d'eXtension ``%{
nom-var}x
''
peut être utilisée pour présenter en extension toute variable fournie
par tout module, et en particulier celles fournies par mod_ssl et que
vous trouverez dans la table ci-dessus.
A des fins de compatibilité ascendante, il existe une fonction de format
cryptographique supplémentaire
``%{
nom}c
''. Vous trouverez toutes
les informations à propos de cette fonction dans le chapitre Compatibilité.
CustomLog logs/ssl_request_log "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
mod_ssl
enregistre des informations à propos de la
requête que l'on peut restituer dans les journaux avec la chaîne de
format %{nom}n
via le module
mod_log_config
.
Les informations enregistrées sont les suivantes :
ssl-access-forbidden
1
si l'accès a
été refusé suite à une directive SSLRequire
ou
SSLRequireSSL
.ssl-secure-reneg
mod_ssl
a été compilé avec une version
d'OpenSSL qui supporte la renégociation sécurisée, si SSL est utilisé
pour la connexion courante et si le client supporte lui aussi la
renégociation sécurisée, cette information contiendra la valeur
1
. Si le client ne supporte pas la renégociation
sécurisée, l'information contiendra la valeur 0
. Si
mod_ssl
n'a pas été compilé avec une version
d'OpenSSL qui supporte la renégociation sécurisée, ou si SSL n'est pas
utilisé pour la connexion courante, le contenu de l'information ne
sera pas défini.mod_ssl
propose quelques fournisseurs
d'autorisation à utiliser avec la directive Require
du module
mod_authz_core
.
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
.
Require ssl
Le fournisseur ssl
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.
Dans l'exemple suivant, l'accès est autorisé si le client est authentifié via un certificat client ou par nom d'utilisateur/mot de passe :
Require ssl-verify-client
Require valid-user
Description: | Fichier contenant une concaténation des certificats de CA codés en PEM pour l'authentification des clients |
---|---|
Syntaxe: | SSLCACertificateFile chemin-fichier |
Contexte: | configuration du serveur, serveur virtuel |
Statut: | Extension |
Module: | mod_ssl |
Cette directive permet de définir le fichier tout-en-un où vous
pouvez rassembler les certificats des Autorités de Certification (CAs)
pour les clients auxquels vous avez à faire. On les utilise pour
l'authentification des clients. Un tel fichier contient la simple
concaténation des différents fichiers de certificats codés en PEM, par
ordre de préférence. Cette directive peut être utilisée à la place et/ou
en complément de la directive SSLCACertificatePath
.
SSLCACertificateFile /usr/local/apache2/conf/ssl.crt/ca-bundle-client.crt
Description: | Répertoire des certificats de CA codés en PEM pour l'authentification des clients |
---|---|
Syntaxe: | SSLCACertificatePath chemin-répertoire |
Contexte: | configuration du serveur, serveur virtuel |
Statut: | Extension |
Module: | mod_ssl |
Cette directive permet de définir le répertoire où sont stockés les certificats des Autorités de Certification (CAs) pour les clients auxquels vous avez à faire. On les utilise pour vérifier le certificat du client au cours de l'authentification de ce dernier.
Les fichiers de ce répertoire doivent être codés en PEM et ils sont
accédés via des noms de fichier sous forme de condensés ou hash. Il ne
suffit donc pas de placer les fichiers de certificats dans ce répertoire
: vous devez aussi créer des liens symboliques nommés
valeur-de-hashage.N
, et vous devez toujours vous
assurer que ce répertoire contient les liens symboliques appropriés.
SSLCACertificatePath /usr/local/apache2/conf/ssl.crt/
Description: | Fichier contenant la concaténation des certificats de CA codés en PEM pour la définition de noms de CA acceptables |
---|---|
Syntaxe: | SSLCADNRequestFile chemin-fichier |
Contexte: | configuration du serveur, serveur virtuel |
Statut: | Extension |
Module: | mod_ssl |
Lorsque mod_ssl demande un certificat client, une liste de noms d'Autorités de Certification acceptables est envoyée au client au cours de la phase d'initialisation de la connexion SSL. Le client peut alors utiliser cette liste de noms de CA pour sélectionner un certificat client approprié parmi ceux dont il dispose.
Si aucune des directives SSLCADNRequestPath
ou SSLCADNRequestFile
n'est définie, la liste
de noms de CsA 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,
c'est la liste des noms de CAs qui sera effectivement utilisée pour
vérifier le certificat du client.
Dans certaines situations, il est utile de pouvoir envoyer
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 SSLCADNRequestPath
et/ou SSLCADNRequestFile
, 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.
SSLCADNRequestFile
doit
spécifier un fichier tout-en-un contenant une concaténation des
certificats de CA codés en PEM.
SSLCADNRequestFile /usr/local/apache2/conf/ca-names.crt
Description: | Répertoire contenant des fichiers de certificats de CA codés en PEM pour la définition de noms de CA acceptables |
---|---|
Syntaxe: | SSLCADNRequestPath chemin-répertoire |
Contexte: | configuration du serveur, serveur virtuel |
Statut: | Extension |
Module: | mod_ssl |
Cette directive optionnelle permet de définir la liste de noms de
CAs acceptables qui sera envoyée au client lorsqu'un certificat de
client est demandé. Voir la directive SSLCADNRequestFile
pour plus de
détails.
Les fichiers de ce répertoire doivent être codés en PEM et ils sont
accédés via des noms de fichier sous forme de condensés ou hash. Il ne
suffit donc pas de placer les fichiers de certificats dans ce répertoire
: vous devez aussi créer des liens symboliques nommés
valeur-de-hashage.N
, et vous devez toujours vous
assurer que ce répertoire contient les liens symboliques appropriés.
SSLCADNRequestPath /usr/local/apache2/conf/ca-names.crt/
Description: | Active la vérification des révocations basée sur les CRL |
---|---|
Syntaxe: | SSLCARevocationCheck chain|leaf|none |
Défaut: | SSLCARevocationCheck none |
Contexte: | configuration du serveur, serveur virtuel |
Statut: | Extension |
Module: | mod_ssl |
Active la vérification des révocations basée sur les Listes de
Révocations de Certificats (CRL). Au moins une des directives SSLCARevocationFile
ou SSLCARevocationPath
doit être définie.
Lorsque cette directive est définie à chain
(valeur
recommandée), les vérifications CRL sont effectuées sur tous les
certificats de la chaîne, alors que la valeur leaf
limite
la vérification au certificat hors chaîne (la feuille).
chain
ou
leaf
, les CRLs doivent être disponibles pour que la
validation réussisse
Avant la version 2.3.15, les vérifications CRL dans mod_ssl
réussissaient même si aucune CRL n'était trouvée dans les chemins
définis par les directives SSLCARevocationFile
ou SSLCARevocationPath
. Le comportement a
changé avec l'introduction de cette directive : lorsque la vérification
est activée, les CRLs doivent être présentes pour que la
validation réussisse ; dans le cas contraire, elle échouera avec une
erreur "CRL introuvable"
.
SSLCARevocationCheck chain
Description: | Fichier contenant la concaténation des CRLs des CA codés en PEM pour l'authentification des clients |
---|---|
Syntaxe: | SSLCARevocationFile chemin-fichier |
Contexte: | configuration du serveur, serveur virtuel |
Statut: | Extension |
Module: | mod_ssl |
Cette directive permet de définir le fichier tout-en-un où sont
rassemblées les Listes de Révocation de Certificats (CRLs) des Autorités
de certification (CAs) pour les clients auxquels vous avez à faire. On
les utilise pour l'authentification des clients. Un tel fichier contient
la simple concaténation des différents fichiers de CRLs codés en PEM,
dans l'ordre de préférence. Cette directive peut être utilisée à la
place et/ou en complément de la directive SSLCARevocationPath
.
SSLCARevocationFile /usr/local/apache2/conf/ssl.crl/ca-bundle-client.crl
Description: | Répertoire des CRLs de CA codés en PEM pour l'authentification des clients |
---|---|
Syntaxe: | SSLCARevocationPath chemin-répertoire |
Contexte: | configuration du serveur, serveur virtuel |
Statut: | Extension |
Module: | mod_ssl |
Cette directive permet de définir le répertoire où sont stockées les Listes de Révocation de Certificats (CRL) des Autorités de Certification (CAs) pour les clients auxquels vous avez à faire. On les utilise pour révoquer les certificats des clients au cours de l'authentification de ces derniers.
Les fichiers de ce répertoire doivent être codés en PEM et ils sont
accédés via des noms de fichier sous forme de condensés ou hash. Il ne
suffit donc pas de placer les fichiers de CRL dans ce répertoire
: vous devez aussi créer des liens symboliques nommés
valeur-de-hashage.N
, et vous devez toujours vous
assurer que ce répertoire contient les liens symboliques appropriés.
SSLCARevocationPath /usr/local/apache2/conf/ssl.crl/
Description: | Fichier contenant les certificats de CA du serveur codés en PEM |
---|---|
Syntaxe: | SSLCertificateChainFile chemin-fichier |
Contexte: | configuration du serveur, serveur virtuel |
Statut: | Extension |
Module: | mod_ssl |
SSLCertificateChainFile
est devenue obsolète avec la
version 2.4.8, lorsque la directive
SSLCertificateFile
a été étendue
pour supporter aussi les certificats de CA intermédiaires dans le
fichier de certificats du serveur.
Cette directive permet de définir le fichier optionnel tout-en-un où vous pouvez rassembler les certificats des Autorités de Certification (CA) qui forment la chaîne de certification du certificat du serveur. Cette chaîne débute par le certificat de la CA qui a délivré le certificat du serveur et peut remonter jusqu'au certificat de la CA racine. Un tel fichier contient la simple concaténation des différents certificats de CA codés en PEM, en général dans l'ordre de la chaîne de certification.
Elle doit être utilisée à la place et/ou en complément de la
directive SSLCACertificatePath
pour construire explicitement la chaîne de certification du serveur qui
est envoyée au navigateur en plus du certificat du serveur. Elle s'avère
particulièrement utile pour éviter les conflits avec les certificats de
CA lorsqu'on utilise l'authentification du client. Comme le fait de
placer un certificat de CA de la chaîne de certification du serveur dans
la directive SSLCACertificatePath
produit le même effet
pour la construction de la chaîne de certification, cette directive a
pour effet colatéral de faire accepter les certificats clients fournis
par cette même CA, au cours de l'authentification du client.
Soyez cependant prudent : fournir la chaîne de certification ne fonctionne que si vous utilisez un simple certificat de serveur RSA ou DSA. Si vous utilisez une paire de certificats couplés RSA+DSA , cela ne fonctionnera que si les deux certificats utilisent vraiment la même chaîne de certification. Dans le cas contraire, la confusion risque de s'installer au niveau des navigateurs.
SSLCertificateChainFile /usr/local/apache2/conf/ssl.crt/ca.crt
Description: | Fichier de données contenant le certificat X.509 du serveur codé en PEM |
---|---|
Syntaxe: | SSLCertificateFile chemin-fichier |
Contexte: | configuration du serveur, serveur virtuel |
Statut: | Extension |
Module: | mod_ssl |
Cette directive permet de définir le fichier de données contenant
les informations de certificat
X.509 du serveur codées au format PEM. Ce fichier doit contenir
au minimum un certificat d'entité finale (feuille). Depuis la version
2.4.8, il peut aussi contenir des certificats de CA
intermédiaires triés des feuilles à la racine, ainsi que des
SSLCertificateChainFile
(obsolètes).
Des éléments additionnels peuvent être présents, comme des paramètres
DH et/ou le nom EC curve pour les clés ephémères, respectivement générés
par openssl dhparam
et openssl ecparam
(supporté à partir de la version 2.4.7), et
enfin la clé privée du certificat d'entité finale. Si la clé privée est
chiffrée, une boîte de dialogue demandant le mot de passe s'ouvre au
démarrage.
Cette directive peut être utilisée plusieurs fois pour référencer
différents noms de fichiers, afin de supporter plusieurs algorithmes
pour l'authentification du serveur - en général RSA, DSA et ECC. Le
nombre d'algorithmes supportés dépend de la version d'OpenSSL utilisée
pour mod_ssl : à partir de la version 1.0.0, la commande openssl
list-public-key-algorithms
renvoie la liste de ces algorithmes.
A partir de la version 1.0.2 d'OpenSSL, cette directive permet de
configurer la chaîne de certification en fonction du certificat, ce qui
supprime une limitation de la directive obsolète SSLCertificateChainFile
. Cependant, les
paramètres DH et ECDH ne sont lus que depuis la première directive
SSLCertificateFile
car ils s'appliquent
indépendamment du type d'algorithme d'authentification.
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.
SSLCertificateFile /usr/local/apache2/conf/ssl.crt/server.crt
Description: | Fichier contenant la clé privée du serveur codée en PEM |
---|---|
Syntaxe: | SSLCertificateKeyFile chemin-fichier |
Contexte: | configuration du serveur, serveur virtuel |
Statut: | Extension |
Module: | mod_ssl |
Cette directive permet de définir le fichier contenant la clé privée du
serveur codée en PEM (la clé privée peut être associée au certificat
dans le fichier défini par la directive
SSLCertificateFile
, mais cette pratique est
déconseillée). Si la clé privée est
chiffrée, une boîte de dialogue demandant le mot de passe s'ouvre au
démarrage.
Cette directive peut être utilisée plusieurs fois pour référencer
différents noms de fichiers, afin de supporter plusieurs algorithmes
pour l'authentification du serveur. A chaque directive SSLCertificateKeyFile
doit être associée
une directive SSLCertificateFile
correspondante.
SSLCertificateKeyFile /usr/local/apache2/conf/ssl.key/server.key
Description: | Algorithmes de chiffrement disponibles pour la négociation au cours de l'initialisation de la connexion SSL |
---|---|
Syntaxe: | SSLCipherSuite algorithmes |
Défaut: | SSLCipherSuite DEFAULT (dépend de la version d'OpenSSL
installée) |
Contexte: | configuration du serveur, serveur virtuel, répertoire, .htaccess |
AllowOverride: | AuthConfig |
Statut: | Extension |
Module: | mod_ssl |
Cette directive complexe utilise la chaîne algorithmes contenant la liste des algorithmes de chiffrement OpenSSL que le client peut utiliser au cours de la phase d'initialisation de la connexion SSL. Notez que cette directive peut être utilisée aussi bien dans un contexte de serveur que dans un contexte de répertoire. Dans un contexte de serveur, elle s'applique à l'initialisation SSL standard lorsqu'une connexion est établie. Dans un contexte de répertoire, elle force une renégociation SSL avec la liste d'algorithmes de chiffrement spécifiée après la lecture d'une requête HTTP, mais avant l'envoi de la réponse HTTP.
La liste d'algorithmes de chiffrement SSL spécifiée par l'argument algorithmes comporte quatre attributs principaux auxquels s'ajoutent quelques attributs secondaires :
L'algorithme de chiffrement peut aussi provenir de l'extérieur. Les algorithmes SSLv2 ne sont plus supportés. Pour définir les algorithmes à utiliser, on peut soit spécifier tous les algorithmes à la fois, soit utiliser des alias pour spécifier une liste d'algorithmes dans leur ordre de préférence (voir Table 1). Les algorithmes et alias effectivement disponibles dépendent de la version d'openssl utilisée. Les versions ultérieures d'openssl inclueront probablement des algorithmes supplémentaires.
Symbole | Description |
---|---|
Algorithme d'échange de clés : | |
kRSA | Echange de clés RSA |
kDHr | Echange de clés Diffie-Hellman avec clé RSA |
kDHd | Echange de clés Diffie-Hellman avec clé DSA |
kEDH | Echange de clés Diffie-Hellman temporaires (pas de certificat) |
kSRP | échange de clés avec mot de passe distant sécurisé (SRP) |
Algorithmes d'authentification : | |
aNULL | Pas d'authentification |
aRSA | Authentification RSA |
aDSS | Authentification DSS |
aDH | Authentification Diffie-Hellman |
Algorithmes de chiffrement : | |
eNULL | Pas de chiffrement |
NULL | alias pour eNULL |
AES | Chiffrement AES |
DES | Chiffrement DES |
3DES | Chiffrement Triple-DES |
RC4 | Chiffrement RC4 |
RC2 | Chiffrement RC2 |
IDEA | Chiffrement IDEA |
Algorithmes de condensés MAC : | |
MD5 | Fonction de hashage MD5 |
SHA1 | Fonction de hashage SHA1 |
SHA | alias pour SHA1 |
SHA256 | >Fonction de hashage SHA256 |
SHA384 | >Fonction de hashage SHA384 |
Alias : | |
SSLv3 | tous les algorithmes de chiffrement SSL version 3.0 |
TLSv1 | tous les algorithmes de chiffrement TLS version 1.0 |
EXP | tous les algorithmes de chiffrement externes |
EXPORT40 | tous les algorithmes de chiffrement externes limités à 40 bits |
EXPORT56 | tous les algorithmes de chiffrement externes limités à 56 bits |
LOW | tous les algorithmes de chiffrement faibles (non externes, DES simple) |
MEDIUM | tous les algorithmes avec chiffrement 128 bits |
HIGH | tous les algorithmes utilisant Triple-DES |
RSA | tous les algorithmes utilisant l'échange de clés RSA |
DH | tous les algorithmes utilisant l'échange de clés Diffie-Hellman |
EDH | tous les algorithmes utilisant l'échange de clés Diffie-Hellman temporaires |
ECDH | échange de clés Elliptic Curve Diffie-Hellman |
ADH | tous les algorithmes utilisant l'échange de clés Diffie-Hellman anonymes |
AECDH | tous les algorithmes utilisant l'échange de clés Elliptic Curve Diffie-Hellman |
SRP | tous les algorithmes utilisant l'échange de clés avec mot de passe distant sécurisé (SRP) |
DSS | tous les algorithmes utilisant l'authentification DSS |
ECDSA | tous les algorithmes utilisant l'authentification ECDSA |
aNULL | tous les algorithmes n'utilisant aucune authentification |
Cela devient intéressant lorsque tous ces symboles sont combinés
ensemble pour spécifier les algorithmes disponibles et l'ordre dans
lequel vous voulez les utiliser. Pour simplifier tout cela, vous
disposez aussi d'alias (SSLv3, TLSv1, EXP, LOW, MEDIUM,
HIGH
) pour certains groupes d'algorithmes. Ces symboles peuvent
être reliés par des préfixes pour former la chaîne algorithmes.
Les préfixes disponibles sont :
+
: déplace les algorithmes qui conviennent à la
place courante dans la liste-
: supprime l'algorithme de la liste (peut être rajouté
plus tard)!
: supprime définitivement l'algorithme de la liste (ne
peut plus y être rajouté plus tard)aNULL
, eNULL
et
EXP
sont toujours désactivésDepuis la version 2.4.7, les
algorithmes de type null ou destinés à l'exportation sont toujours
désactivés car mod_ssl fait
obligatoirement précéder toute chaîne de suite d'algorithmes par
!aNULL:!eNULL:!EXP:
à l'initialisation.
Pour vous simplifier la vie, vous pouvez utiliser la commande
``openssl ciphers -v
'' qui vous fournit un moyen simple de
créer la chaîne algorithmes avec succès. La chaîne
algorithmes par défaut dépend de la version des bibliothèques
SSL installées. Supposons qu'elle contienne
``RC4-SHA:AES128-SHA:HIGH:MEDIUM:!aNULL:!MD5
'', ce qui
stipule de mettre RC4-SHA
et AES128-SHA
en
premiers, car ces algorithmes présentent un bon compromis entre vitesse
et sécurité. Viennent ensuite les algorithmes de sécurité élevée et
moyenne. En fin de compte, les algorithmes qui n'offrent aucune
authentification sont exclus, comme les algorithmes anonymes
Diffie-Hellman pour SSL, ainsi que tous les algorithmes qui utilisent
MD5
pour le hashage, car celui-ci est reconnu comme
insuffisant.
$ openssl ciphers -v 'RC4-SHA:AES128-SHA:HIGH:MEDIUM:!aNULL:!MD5' RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1 AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1 DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1 ... ... ... ... ... SEED-SHA SSLv3 Kx=RSA Au=RSA Enc=SEED(128) Mac=SHA1 PSK-RC4-SHA SSLv3 Kx=PSK Au=PSK Enc=RC4(128) Mac=SHA1 KRB5-RC4-SHA SSLv3 Kx=KRB5 Au=KRB5 Enc=RC4(128) Mac=SHA1
Vous trouverez la liste complète des algorithmes RSA & DH spécifiques à SSL dans la Table 2.
SSLCipherSuite RSA:!EXP:!NULL:+HIGH:+MEDIUM:-LOW
Symbole algorithme | Protocole | Echange de clés | Authentification | Chiffrement | Condensé MAC | Type |
---|---|---|---|---|---|---|
Algorithmes RSA : | ||||||
DES-CBC3-SHA | SSLv3 | RSA | RSA | 3DES(168) | SHA1 | |
IDEA-CBC-SHA | SSLv3 | RSA | RSA | IDEA(128) | SHA1 | |
RC4-SHA | SSLv3 | RSA | RSA | RC4(128) | SHA1 | |
RC4-MD5 | SSLv3 | RSA | RSA | RC4(128) | MD5 | |
DES-CBC-SHA | SSLv3 | RSA | RSA | DES(56) | SHA1 | |
EXP-DES-CBC-SHA | SSLv3 | RSA(512) | RSA | DES(40) | SHA1 | export |
EXP-RC2-CBC-MD5 | SSLv3 | RSA(512) | RSA | RC2(40) | MD5 | export |
EXP-RC4-MD5 | SSLv3 | RSA(512) | RSA | RC4(40) | MD5 | export |
NULL-SHA | SSLv3 | RSA | RSA | None | SHA1 | |
NULL-MD5 | SSLv3 | RSA | RSA | None | MD5 | |
Algorithmes Diffie-Hellman : | ||||||
ADH-DES-CBC3-SHA | SSLv3 | DH | None | 3DES(168) | SHA1 | |
ADH-DES-CBC-SHA | SSLv3 | DH | None | DES(56) | SHA1 | |
ADH-RC4-MD5 | SSLv3 | DH | None | RC4(128) | MD5 | |
EDH-RSA-DES-CBC3-SHA | SSLv3 | DH | RSA | 3DES(168) | SHA1 | |
EDH-DSS-DES-CBC3-SHA | SSLv3 | DH | DSS | 3DES(168) | SHA1 | |
EDH-RSA-DES-CBC-SHA | SSLv3 | DH | RSA | DES(56) | SHA1 | |
EDH-DSS-DES-CBC-SHA | SSLv3 | DH | DSS | DES(56) | SHA1 | |
EXP-EDH-RSA-DES-CBC-SHA | SSLv3 | DH(512) | RSA | DES(40) | SHA1 | export |
EXP-EDH-DSS-DES-CBC-SHA | SSLv3 | DH(512) | DSS | DES(40) | SHA1 | export |
EXP-ADH-DES-CBC-SHA | SSLv3 | DH(512) | None | DES(40) | SHA1 | export |
EXP-ADH-RC4-MD5 | SSLv3 | DH(512) | None | RC4(40) | MD5 | export |
Description: | Permet d'activer la compression au niveau SSL |
---|---|
Syntaxe: | SSLCompression on|off |
Défaut: | SSLCompression off |
Contexte: | configuration du serveur, serveur virtuel |
Statut: | Extension |
Module: | mod_ssl |
Compatibilité: | Disponible à partir de la version 2.4.3 du serveur HTTP
Apache, si on utilise une version d'OpenSSL 0.9.8 ou supérieure ;
l'utilisation dans un contexte de serveur virtuel n'est disponible que
si on utilise une version d'OpenSSL 1.0.0 ou supérieure. La valeur par
défaut était on dans la version 2.4.3. |
Cette directive permet d'activer la compression au niveau SSL.
L'activation de la compression est à l'origine de problèmes de sécurité dans la plupart des configurations (l'attaque nommée CRIME).
Description: | Active l'utilisation d'un accélérateur matériel de chiffrement |
---|---|
Syntaxe: | SSLCryptoDevice moteur |
Défaut: | SSLCryptoDevice builtin |
Contexte: | configuration du serveur |
Statut: | Extension |
Module: | mod_ssl |
Cette directive permet d'activer l'utilisation d'une carte accélératrice de chiffrement qui prendra en compte certaines parties du traitement relatif à SSL. Cette directive n'est utilisable que si la boîte à outils SSL à été compilée avec le support "engine" ; les versions 0.9.7 et supérieures d'OpenSSL possèdent par défaut le support "engine", alors qu'avec la version 0.9.6, il faut utiliser les distributions séparées "-engine".
Pour déterminer les moteurs supportés, exécutez la commande
"openssl engine
".
# Pour un accélérateur Broadcom : SSLCryptoDevice ubsec
Description: | Interrupteur marche/arrêt du moteur SSL |
---|---|
Syntaxe: | SSLEngine on|off|optional |
Défaut: | SSLEngine off |
Contexte: | configuration du serveur, serveur virtuel |
Statut: | Extension |
Module: | mod_ssl |
Cette directive permet d'activer/désactiver le moteur du protocole
SSL/TLS. Elle doit être utilisée dans une section <VirtualHost>
pour activer
SSL/TLS pour ce serveur virtuel particulier. Par défaut, le moteur du
protocole SSL/TLS est désactivé pour le serveur principal et tous les
serveurs virtuels configurés.
<VirtualHost _default_:443> SSLEngine on #... </VirtualHost>
Depuis la version 2.1 d'Apache, la directive
SSLEngine
peut être définie à
optional
, ce qui active le support de RFC 2817, Upgrading to
TLS Within HTTP/1.1. Pour le moment, aucun navigateur web ne supporte
RFC 2817.
Description: | Coimmutateur du mode SSL FIPS |
---|---|
Syntaxe: | SSLFIPS on|off |
Défaut: | SSLFIPS off |
Contexte: | configuration du serveur |
Statut: | Extension |
Module: | mod_ssl |
Cette directive permet d'activer/désactiver l'utilisation du drapeau FIPS_mode de la bibliothèque SSL. Elle doit être définie dans le contexte du serveur principal, et n'accepte pas les configurations sources de conflits (SSLFIPS on suivi de SSLFIPS off par exemple). Le mode s'applique à toutes les opérations de la bibliothèque SSL.
Si httpd a été compilé avec une bibliothèque SSL qui ne supporte pas le
drapeau FIPS_mode, la directive SSLFIPS on
échouera.
Reportez-vous au document sur la politique de sécurité FIPS 140-2 de la
bibliothèque du fournisseur SSL, pour les prérequis spécifiques
nécessaires à l'utilisation de mod_ssl selon un mode d'opération
approuvé par FIPS 140-2 ; notez que mod_ssl en lui-même n'est pas
validé, mais peut être décrit comme utilisant un module de chiffrement
validé par FIPS 140-2, lorsque tous les composants sont assemblés et mis
en oeuvre selon les recommandations de la politique de sécurité
applicable.
Description: | Option permettant de classer les algorithmes de chiffrement du serveur par ordre de préférence |
---|---|
Syntaxe: | SSLHonorCipherOrder on|off |
Défaut: | SSLHonorCipherOrder off |
Contexte: | configuration du serveur, serveur virtuel |
Statut: | Extension |
Module: | mod_ssl |
Normalement, ce sont les préférences du client qui sont prises en compte lors du choix d'un algorithme de chiffrement au cours d'une négociation SSLv3 ou TLSv1. Si cette directive est activée, ce sont les préférences du serveur qui seront prises en compte à la place.
SSLHonorCipherOrder on
Description: | Option permettant d'activer le support de la renégociation non sécurisée |
---|---|
Syntaxe: | SSLInsecureRenegotiation on|off |
Défaut: | SSLInsecureRenegotiation off |
Contexte: | configuration du serveur, serveur virtuel |
Statut: | Extension |
Module: | mod_ssl |
Compatibilité: | Disponible depuis httpd 2.2.15, si une version 0.9.8m ou supérieure d'OpenSSL est utilisée |
Comme il a été spécifié, toutes les versions des protocoles SSL et TLS (jusqu'à la version 1.2 de TLS incluse) étaient vulnérables à une attaque de type Man-in-the-Middle (CVE-2009-3555) au cours d'une renégociation. Cette vulnérabilité permettait à un attaquant de préfixer la requête HTTP (telle qu'elle était vue du serveur) avec un texte choisi. Une extension du protocole a été développée pour corriger cette vulnérabilité, sous réserve qu'elle soit supportée par le client et le serveur.
Si mod_ssl
est lié à une version 0.9.8m ou
supérieure d'OpenSSL, par défaut, la renégociation n'est accordée qu'aux
clients qui supportent la nouvelle extension du protocole. Si
cette directive est activée, la renégociation sera accordée aux anciens
clients (non patchés), quoique de manière non sécurisée
Si cette directive est activée, les connexions SSL seront vulnérables aux attaques de type préfixe Man-in-the-Middle comme décrit dans CVE-2009-3555.
SSLInsecureRenegotiation on
La variable d'environnement SSL_SECURE_RENEG
peut être
utilisée dans un script SSI ou CGI pour déterminer si la renégociation
sécurisée est supportée pour une connexion SSL donnée.
Description: | Définit l'URI du répondeur par défaut pour la validation OCSP |
---|---|
Syntaxe: | SSLOCSDefaultResponder uri |
Contexte: | configuration du serveur, serveur virtuel |
Statut: | Extension |
Module: | mod_ssl |
Cette directive permet de définir le répondeur OCSP par défaut. Si la
directive SSLOCSPOverrideResponder
n'est pas activée,
l'URI spécifié ne sera utilisé que si aucun URI de répondeur n'est
spécifié dans le certificat en cours de vérification.
Description: | Active la validation OCSP de la chaîne de certificats du client |
---|---|
Syntaxe: | SSLOCSPEnable on|off |
Défaut: | SSLOCSPEnable off |
Contexte: | configuration du serveur, serveur virtuel |
Statut: | Extension |
Module: | mod_ssl |
Cette directive permet d'activer la validation OCSP de la chaîne de certificats du client. Si elle est activée, les certificats de la chaîne de certificats du client seront validés auprès d'un répondeur OCSP, une fois la vérification normale effectuée (vérification des CRLs incluse).
Le répondeur OCSP utilisé est soit extrait du certificat lui-même,
soit spécifié dans la configuration ; voir les directives SSLOCSPDefaultResponder
et SSLOCSPOverrideResponder
.
SSLVerifyClient on SSLOCSPEnable on SSLOCSPDefaultResponder http://responder.example.com:8888/responder SSLOCSPOverrideResponder on
Description: | Force l'utilisation de l'URI du répondeur par défaut pour la validation OCSP |
---|---|
Syntaxe: | SSLOCSPOverrideResponder on|off |
Défaut: | SSLOCSPOverrideResponder off |
Contexte: | configuration du serveur, serveur virtuel |
Statut: | Extension |
Module: | mod_ssl |
Force l'utilisation, au cours d'une validation OCSP de certificat, du répondeur OCSP par défaut spécifié dans la configuration, que le certificat en cours de vérification fasse mention d'un répondeur OCSP ou non.
Description: | Délai d'attente pour les requêtes OCSP |
---|---|
Syntaxe: | SSLOCSPResponderTimeout secondes |
Défaut: | SSLOCSPResponderTimeout 10 |
Contexte: | configuration du serveur, serveur virtuel |
Statut: | Extension |
Module: | mod_ssl |
Cette option permet de définir le délai d'attente pour les requêtes à
destination des répondeurs OCSP, lorsque la directive SSLOCSPEnable
est à on.
Description: | Age maximum autorisé pour les réponses OCSP |
---|---|
Syntaxe: | SSLOCSPResponseMaxAge secondes |
Défaut: | SSLOCSPResponseMaxAge -1 |
Contexte: | configuration du serveur, serveur virtuel |
Statut: | Extension |
Module: | mod_ssl |
Cette option permet de définir l'âge maximum autorisé (la
"fraicheur") des réponses OCSP. La valeur par défault (-1
)
signifie qu'aucun âge maximum n'est défini ; autrement dit, les
réponses OCSP sont considérées comme valides tant que la valeur de leur
champ nextUpdate
se situe dans le futur.
Description: | Dérive temporelle maximale autorisée pour la validation des réponses OCSP |
---|---|
Syntaxe: | SSLOCSPResponseTimeSkew secondes |
Défaut: | SSLOCSPResponseTimeSkew 300 |
Contexte: | configuration du serveur, serveur virtuel |
Statut: | Extension |
Module: | mod_ssl |
Cette option permet de définir la dérive temporelle maximale
autorisée pour les réponses OCSP (lors de la vérification des champs
thisUpdate
et nextUpdate
).
Description: | Use a nonce within OCSP queries |
---|---|
Syntaxe: | SSLOCSPUseRequestNonce on|off |
Défaut: | SSLOCSPUseRequestNonce on |
Contexte: | configuration du serveur, serveur virtuel |
Statut: | Extension |
Module: | mod_ssl |
Compatibilité: | Available in httpd 2.4.10 and later |
La documentation de cette directive n'a pas encore t traduite. Veuillez vous reporter la version en langue anglaise.
Description: | Configuration des paramètres d'OpenSSL via son API SSL_CONF |
---|---|
Syntaxe: | SSLOpenSSLConfCmd commande valeur |
Contexte: | configuration du serveur, serveur virtuel |
Statut: | Extension |
Module: | mod_ssl |
Compatibilité: | Disponible depuis la version 2.4.8 du serveur HTTP Apache avec OpenSSL 1.0.2 ou supérieur |
Cette directive permet à mod_ssl d'accéder à l'API SSL_CONF
d'OpenSSL. Il n'est ainsi plus nécessaire d'implémenter des
directives supplémentaires pour mod_ssl
lorsque de nouvelles
fonctionnalités sont ajoutées à OpenSSL, ce qui rend la configuration de
ce dernier beaucoup plus souple.
Le jeu de commandes disponibles pour la directive
SSLOpenSSLConfCmd
dépend de la version d'OpenSSL
utilisée pour mod_ssl
(la version minimale 1.0.2 est un
prérequis). Pour obtenir la liste des commandes supportées, voir la
section Supported configuration file commands de la page de
manuel SSL_CONF_cmd(3)
d'OpenSSL.
Certaines commandes peuvent remplacer des directives existantes
(comme SSLCipherSuite
ou
SSLProtocol
) ; notez cependant
que la syntaxe et/ou les valeurs possibles peuvent différer.
SSLOpenSSLConfCmd Options -SessionTicket,ServerPreference SSLOpenSSLConfCmd ECDHParameters brainpoolP256r1 SSLOpenSSLConfCmd ServerInfoFile /usr/local/apache2/conf/server-info.pem SSLOpenSSLConfCmd Protocol "-ALL, TLSv1.2" SSLOpenSSLConfCmd SignatureAlgorithms RSA+SHA384:ECDSA+SHA256
Description: | Configure différentes options d'exécution du moteur SSL |
---|---|
Syntaxe: | SSLOptions [+|-]option ... |
Contexte: | configuration du serveur, serveur virtuel, répertoire, .htaccess |
AllowOverride: | Options |
Statut: | Extension |
Module: | mod_ssl |
Cette directive permet de contrôler différentes options d'exécution du
moteur SSL dans un contexte de répertoire. Normalement, si plusieurs
SSLOptions
peuvent s'appliquer à un répertoire, c'est la
plus spécifique qui est véritablement prise en compte ; les options ne
se combinent pas entre elles. Elles se combinent cependant entre elles
si elles sont toutes précédées par un symbole plus
(+
) ou moins (-
). Toute option précédée d'un
+
est ajoutée aux options actuellement en vigueur, et toute
option précédée d'un -
est supprimée de ces mêmes
options.
Les options disponibles sont :
StdEnvVars
Lorsque cette option est activée, le jeu standard de variables d'environnement SSL relatives à CGI/SSI est créé. Cette option est désactivée par défaut pour des raisons de performances, car l'extraction des informations constitue une opération assez coûteuse en ressources. On n'active donc en général cette option que pour les requêtes CGI et SSI.
ExportCertData
Lorsque cette option est activée, des variables d'environnement
CGI/SSI supplémentaires sont créées : SSL_SERVER_CERT
,
SSL_CLIENT_CERT
et
SSL_CLIENT_CERT_CHAIN_
n (avec n =
0,1,2,..). Elles contiennent les certificats X.509 codés en PEM du
serveur et du client pour la connexion HTTPS courante, et peuvent
être utilisées par les scripts CGI pour une vérification de
certificat plus élaborée. De plus, tous les autres certificats de la
chaîne de certificats du client sont aussi fournis. Tout ceci gonfle
un peu l'environnement, et c'est la raison pour laquelle vous ne
devez activer cette option qu'à la demande.
FakeBasicAuth
Lorsque cette option est activée, le Nom Distinctif (DN) sujet du
certificat client X509 est traduit en un nom d'utilisateur pour
l'autorisation HTTP de base. Cela signifie que les méthodes
d'authentification standard d'Apache peuvent être utilisées pour le
contrôle d'accès. Le nom d'utilisateur est tout simplement le Sujet
du certificat X509 du client (il peut être déterminé en utilisant la
commande OpenSSL openssl x509
: openssl x509
-noout -subject -in
certificat.crt
).
Notez qu'aucun mot de passe n'est envoyé par l'utilisateur. Chaque
entrée du fichier des utilisateurs doit comporter ce mot de passe :
``xxj31ZMTZzkVA
'', qui est la version chiffrée en DES
du mot ``password
''. Ceux qui travaillent avec un
chiffrement basé sur MD5 (par exemple sous FreeBSD ou BSD/OS,
etc...) doivent utiliser le condensé MD5 suivant pour le même mot :
``$1$OXLyS...$Owx8s2/m9/gfkcRVXzgoE/
''.
Notez que la directive AuthBasicFake
implémentée par le
module mod_auth_basic
peut être utilisée d'une
manière plus générale comme simulation d'authentification basique,
ce qui permet de contrôler la structure nom utilisateur/mot de
passe.
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.
OptRenegotiate
Cette option active la gestion optimisée de la renégociation des connexions SSL intervenant lorsque les directives SSL sont utilisées dans un contexte de répertoire. Par défaut un schéma strict est appliqué, et chaque reconfiguration des paramètres SSL au niveau du répertoire implique une phase de renégociation SSL complète. Avec cette option, mod_ssl essaie d'éviter les échanges non nécessaires en effectuant des vérifications de paramètres plus granulaires (mais tout de même efficaces). Néanmoins, ces vérifications granulaires peuvent ne pas correspondre à ce qu'attend l'utilisateur, et il est donc recommandé de n'activer cette option que dans un contexte de répertoire.
LegacyDNStringFormat
Cette option permet d'agir sur la manière dont les valeurs des
variables SSL_{CLIENT,SERVER}_{I,S}_DN
sont formatées.
Depuis la version 2.3.11, Apache HTTPD utilise par défaut un format
compatible avec la RFC 2253. Ce format utilise des virgules comme
délimiteurs entre les attributs, permet l'utilisation de caractères
non-ASCII (qui sont alors convertis en UTF8), échappe certains
caractères spéciaux avec des slashes inversés, et trie les attributs
en plaçant l'attribut "C" en dernière position.
Si l'option LegacyDNStringFormat
est présente, c'est
l'ancien format qui sera utilisé : les attributs sont triés avec
l'attribut "C" en première position, les séparateurs sont des
slashes non inversés, les caractères non-ASCII ne sont pas supportés
et le support des caractères spéciaux n'est pas fiable.
SSLOptions +FakeBasicAuth -StrictRequire <Files ~ "\.(cgi|shtml)$"> SSLOptions +StdEnvVars -ExportCertData <Files>
Description: | Méthode utilisée pour entrer le mot de passe pour les clés privées chiffrées |
---|---|
Syntaxe: | SSLPassPhraseDialog type |
Défaut: | SSLPassPhraseDialog builtin |
Contexte: | configuration du serveur |
Statut: | Extension |
Module: | mod_ssl |
Lors de son démarrage, Apache doit lire les différents fichiers de
certificats (voir la directive SSLCertificateFile
) et de clés privées
(voir la directive SSLCertificateKeyFile
) des serveurs
virtuels où SSL est activé. Comme, pour des raisons de sécurité, les
fichiers de clés privées sont en général chiffrés, mod_ssl doit
demander à l'administrateur un mot de passe pour déchiffrer ces
fichiers. L'argument type permet de choisir la manière dont
cette demande peut être formulée parmi les trois suivantes :
builtin
C'est la méthode par défaut, et un dialogue interactive de terminal s'ouvre au cours du démarrage juste avant qu'Apache ne se détache du terminal. A ce moment, l'administrateur doit entrer manuellement un mot de passe pour chaque fichier de clé privée chiffré. Etant donné qu'il peut y avoir un grand nombre de serveurs virtuels configurés avec SSL activé, le protocole de réutilisation suivant est utilisé pour minimiser le dialogue : lorsqu'un fichier de clé privée est chiffré, tous les mots de passe connus (au début, il n'y en a aucun, bien entendu) sont essayés. Si l'un de ces mots de passe connus convient, aucun dialogue ne s'ouvrira pour ce fichier de clé privée particulier. Si aucun ne convient, un autre mot de passe sera demandé à partir du terminal et sera mis en mémoire pour le fichier de clé privée suivant (pour lequel il pourra éventuellement être réutilisé).
Cette méthode confère à mod_ssl une grande souplesse (car pour N fichiers de clé privée chiffrés, vous pouvez utiliser N mots de passe différents - mais vous devrez alors tous les fournir, bien entendu), tout en minimisant le dialogue de terminal (vous pouvez en effet utiliser un seul mot de passe pour les N fichiers de clé privée et vous n'aurez alors à l'entrer qu'une seule fois).
|/chemin/vers/programme [arguments...]
Ce mode permet d'utiliser un programme externe qui va se présenter
comme une redirection vers un périphérique d'entrée particulier ; le
texte de prompt standard utilisé pour le mode builtin
est envoyé au programme sur stdin
, et celui-ci doit
renvoyer des mots de passe sur stdout
. Si
plusieurs mots de passe sont requis (ou si un mot de passe incorrect
a été entré), un texte de prompt supplémentaire sera écrit après le
retour du premier mot de passe, et d'autres mots de passe devront
alors être réécrits.
exec:/chemin/vers/programme
Ici, un programme externe est appelé au démarrage du serveur pour
chaque fichier de clé privée chiffré.Il est appelé avec deux
arguments (le premier est de la forme
``nom-serveur:port
'', le second
est ``RSA
'', ``DSA
'', ``ECC
''
ou un index entier commençant à 3 si plus de 3 clés ont été
configurées), qui
indiquent pour quels serveur et algorithme il doit écrire le mot de
passe correspondant sur stdout
. Avec les versions 2.4.8
(non réalisée) et
2.4.9, il est appelé avec un seul argument, une chaîne de la forme
"servername:portnumber:index
" (où index
est un nombre entier commençant à zéro), qui spécifie le serveur,
le port TCP et un numéro de certificat. Le but recherché est
l'exécution de vérifications de sécurité préalables permettant de
s'assurer que le système n'est pas victime d'une attaque, et de ne
fournir le mot de passe que si toutes les vérifications ont été
effectuées avec succès.
Ces vérifications de sécurité, ainsi que la manière dont le mot de
passe est déterminé peuvent être aussi sophistiqués que vous le
désirez. Mod_ssl ne définit que l'interface : un programme
exécutable qui écrit le mot de passe sur stdout
. Ni
plus, ni moins ! Ainsi, si vous êtes vraiment paranoïaque en matière
de sécurité, voici votre interface. Tout le reste doit être confié à
l'administrateur à titre d'exercice, car les besoins en sécurité
locale sont très différents.
L'algorithme de réutilisation est utilisé ici aussi. En d'autres termes, le programme externe n'est appelé qu'une fois par mot de passe unique.
SSLPassPhraseDialog exec:/usr/local/apache/sbin/pp-filter
Description: | Indique les versions du protocole SSL/TLS disponibles |
---|---|
Syntaxe: | SSLProtocol [+|-]protocole ... |
Défaut: | SSLProtocol all |
Contexte: | configuration du serveur, serveur virtuel |
Statut: | Extension |
Module: | mod_ssl |
Cette directive permet de définir quelles versions du protocole SSL/TLS seront acceptées lors de l'initialisation d'une nouvelle connexion.
Les protocoles disponibles sont les suivants (sensibles à la casse) :
SSLv3
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.
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. Il est supporté par la plupart des clients.
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.
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.
all
C'est un raccourci pour ``+SSLv3 +TLSv1
'' ou - à partir
de la version 1.0.1 d'OpenSSL - ``+SSLv3 +TLSv1 +TLSv1.1 +TLSv1.2
.
SSLProtocol TLSv1
Description: | Fichier contenant la concaténation des certificats de CA codés en PEM pour l'authentification des serveurs distants |
---|---|
Syntaxe: | SSLProxyCACertificateFile file-path |
Contexte: | configuration du serveur, serveur virtuel |
Statut: | Extension |
Module: | mod_ssl |
Cette directive permet de définir le fichier tout-en-un où sont
stockés les certificats des Autorités de Certification (CA) pour les
serveurs distants auxquels vous avez à faire. On les utilise
lors de l'authentification du serveur distant. Un tel fichier contient
la simple concaténation des différents fichiers de certificats codés en
PEM, classés par ordre de préférence. On peut utiliser cette directive à
la place et/ou en complément de la directive SSLProxyCACertificatePath
.
SSLProxyCACertificateFile /usr/local/apache2/conf/ssl.crt/ca-bundle-serveur.distant.crt
Description: | Répertoire des certificats de CA codés en PEM pour l'authentification des serveurs distants |
---|---|
Syntaxe: | SSLProxyCACertificatePath chemin-répertoire |
Contexte: | configuration du serveur, serveur virtuel |
Statut: | Extension |
Module: | mod_ssl |
Cette directive permet de spécifier le répertoire où sont stockés les certificats des Autorités de Certification (CAs) pour les serveurs distants auxquels vous avez à faire. On les utilise pour vérifier le certificat du serveur distant lors de l'authentification de ce dernier.
Les fichiers de ce répertoire doivent être codés en PEM et ils sont
accédés via des noms de fichier sous forme de condensés ou hash. Il ne
suffit donc pas de placer les fichiers de certificats dans ce répertoire
: vous devez aussi créer des liens symboliques nommés
valeur-de-hashage.N
, et vous devez toujours vous
assurer que ce répertoire contient les liens symboliques appropriés.
SSLProxyCACertificatePath /usr/local/apache2/conf/ssl.crt/
Description: | Active la vérification des révocations basée sur les CRLs pour l'authentification du serveur distant |
---|---|
Syntaxe: | SSLProxyCARevocationCheck chain|leaf|none |
Défaut: | SSLProxyCARevocationCheck none |
Contexte: | configuration du serveur, serveur virtuel |
Statut: | Extension |
Module: | mod_ssl |
Active la vérification des révocations basée sur les Listes de
révocations de Certificats (CRL) pour les serveurs distants
auxquels vous vous connectez. A moins une des directives SSLProxyCARevocationFile
ou SSLProxyCARevocationPath
doit être définie.
Lorsque cette directive est définie à chain
(valeur
recommandée), les vérifications CRL sont effectuées sur tous les
certificats de la chaîne, alors que la valeur leaf
limite
la vérification au certificat hors chaîne (la feuille).
chain
ou
leaf
, les CRLs doivent être disponibles pour que la
validation réussisse
Avant la version 2.3.15, les vérifications CRL dans mod_ssl
réussissaient même si aucune CRL n'était trouvée dans les chemins
définis par les directives SSLProxyCARevocationFile
ou SSLProxyCARevocationPath
. Le comportement a
changé avec l'introduction de cette directive : lorsque la vérification
est activée, les CRLs doivent être présentes pour que la
validation réussisse ; dans le cas contraire, elle échouera avec une
erreur "CRL introuvable"
.
SSLProxyCARevocationCheck chain
Description: | Fichier contenant la concaténation des CRLs de CA codés en PEM pour l'authentification des serveurs distants |
---|---|
Syntaxe: | SSLProxyCARevocationFile chemin-fichier |
Contexte: | configuration du serveur, serveur virtuel |
Statut: | Extension |
Module: | mod_ssl |
Cette directive permet de définir le fichier tout-en-un où sont
rassemblées les Listes de Révocation de Certificats (CRLs) des Autorités
de certification (CAs) pour les serveurs distants auxquels vous
avez à faire. On les utilise pour l'authentification des serveurs
distants. Un tel fichier contient la simple concaténation des différents
fichiers de CRLs codés en PEM, classés par ordre de préférence. Cette
directive peut être utilisée à la place et/ou en complément de la
directive SSLProxyCARevocationPath
.
SSLProxyCARevocationFile /usr/local/apache2/conf/ssl.crl/ca-bundle-serveur.distant.crl
Description: | Répertoire des CRLs de CA codés en PEM pour l'authentification des serveurs distants |
---|---|
Syntaxe: | SSLProxyCARevocationPath chemin-répertoire |
Contexte: | configuration du serveur, serveur virtuel |
Statut: | Extension |
Module: | mod_ssl |
Cette directive permet de définir le répertoire où sont stockées les Listes de Révocation de Certificats (CRL) des Autorités de Certification (CAs) pour les serveurs distants auxquels vous avez à faire. On les utilise pour révoquer les certificats des serveurs distants au cours de l'authentification de ces derniers.
Les fichiers de ce répertoire doivent être codés en PEM et ils sont
accédés via des noms de fichier sous forme de condensés ou hash. Il ne
suffit donc pas de placer les fichiers de CRL dans ce répertoire
: vous devez aussi créer des liens symboliques nommés
valeur-de-hashage.rN
, et vous devez toujours vous
assurer que ce répertoire contient les liens symboliques appropriés.
SSLProxyCARevocationPath /usr/local/apache2/conf/ssl.crl/
Description: | Configuration de la vérification du champ CN du certificat du serveur distant |
---|---|
Syntaxe: | SSLProxyCheckPeerCN on|off |
Défaut: | SSLProxyCheckPeerCN on |
Contexte: | configuration du serveur, serveur virtuel |
Statut: | Extension |
Module: | mod_ssl |
Cette directive permet de définir si le champ CN du certificat du serveur distant doit être comparé au nom de serveur de l'URL de la requête. S'ils ne correspondent pas, un code d'état 502 (Bad Gateway) est envoyé.
A partir de la version 2.4.5, SSLProxyCheckPeerCN a été remplacé par SSLProxyCheckPeerName
, et sa définition
n'est prise en compte que si SSLProxyCheckPeerName off
a
été spécifié.
SSLProxyCheckPeerCN on
Description: | Configuration de la vérification de l'expiration du certificat du serveur distant |
---|---|
Syntaxe: | SSLProxyCheckPeerExpire on|off |
Défaut: | SSLProxyCheckPeerExpire on |
Contexte: | configuration du serveur, serveur virtuel |
Statut: | Extension |
Module: | mod_ssl |
Cette directive permet de définir si l'expiration du certificat du serveur distant doit être vérifiée ou non. Si la vérification échoue, un code d'état 502 (Bad Gateway) est envoyé.
SSLProxyCheckPeerExpire on
Description: | Configure la vérification du nom d'hôte dans les certificats serveur distants |
---|---|
Syntaxe: | SSLProxyCheckPeerName on|off |
Défaut: | SSLProxyCheckPeerName on |
Contexte: | configuration du serveur, serveur virtuel |
Statut: | Extension |
Module: | mod_ssl |
Compatibilité: | Disponible à partir de la version 2.4.5 du serveur HTTP Apache |
Cette directive permet de configurer la vérification du nom d'hôte dans
les certificats de serveur lorsque mod_ssl agit en tant que client SSL.
La vérification est concluante si le nom d'hôte de l'URI de la requête
correspond soit à l'extension subjectAltName, soit à l'un des attributs
CN dans le sujet du certificat. Si la vérification échoue, la requête
SSL est annulée et un code d'erreur 502 (Bad Gateway) est renvoyé. Cette
directive remplace la directive SSLProxyCheckPeerCN
qui ne prenait en
compte que le premier attribut CN pour la vérification du nom d'hôte.
La vérification du nom d'hôte avec caractères générique est supportée de
la manière suivante : les entrées subjectAltName de type dNSName ou les
attributs CN commençant par *.
correspondront à tout nom
DNS comportant le même nombre d'éléments et le même suffixe (par
exemple, *.example.org
correspondra à
foo.example.org
, mais pas à
foo.bar.example.org
).
Description: | Algorithmes de chiffrement disponibles pour la négociation lors de l'initialisation d'une connexion SSL de mandataire |
---|---|
Syntaxe: | SSLProxyCipherSuite algorithmes |
Défaut: | SSLProxyCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+EXP |
Contexte: | configuration du serveur, serveur virtuel, répertoire, .htaccess |
AllowOverride: | AuthConfig |
Statut: | Extension |
Module: | mod_ssl |
Cette directive est équivalente à la directive
SSLCipherSuite
, mais s'applique à une connexion de
mandataire. Veuillez vous reporter à la directive SSLCipherSuite
pour plus
d'informations.
Description: | Interrupteur marche/arrêt du moteur de mandataire SSL |
---|---|
Syntaxe: | SSLProxyEngine on|off |
Défaut: | SSLProxyEngine off |
Contexte: | configuration du serveur, serveur virtuel |
Statut: | Extension |
Module: | mod_ssl |
Cette directive permet d'activer/désactiver l'utilisation du moteur de
protocole SSL/TLS pour le mandataire. On l'utilise en général à
l'intérieur d'une section <VirtualHost>
pour activer le protocole SSL/TLS
dans le cadre d'un mandataire pour un serveur virtuel particulier. Par
défaut, le moteur de protocole SSL/TLS est désactivé pour la fonction de
mandataire du serveur principal et de tous les serveurs virtuels
configurés.
Notez que la directive SSLProxyEngine ne doit généralement pas être utilisée dans le cadre d'un serveur virtuel qui agit en tant que mandataire direct (via les directives <Proxy> ou <ProxyRequest>). SSLProxyEngine n'est pas nécessaire pour activer un serveur mandataire direct pour les requêtes SSL/TLS.
<VirtualHost _default_:443> SSLProxyEngine on #... </VirtualHost>
Description: | Fichier de certificats de CA encodés PEM concaténés permettant au mandataire de choisir un certificat |
---|---|
Syntaxe: | SSLProxyMachineCertificateChainFile nom-fichier |
Contexte: | configuration du serveur |
AllowOverride: | Sans objet |
Statut: | Extension |
Module: | mod_ssl |
Cette directive permet de définir le fichier global où est enregistrée la chaîne de certification pour tous les certificats clients utilisés. Elle est nécessaire si le serveur distant présente une liste de certificats de CA qui ne sont pas les signataires directs d'un des certificats clients configurés.
Ce fichier contient tout simplement la concaténation des différents fichiers de certificats encodés PEM. Au démarrage, chaque certificat client configuré est examiné et une chaîne de certification est construite.
Si cette directive est définie, tous les certificats contenus dans le
fichier spécifié seront considérés comme étant de confiance, comme s'ils
étaient aussi désignés dans la directive SSLProxyCACertificateFile
.
SSLProxyMachineCertificateChainFile /usr/local/apache2/conf/ssl.crt/proxyCA.pem
Description: | Fichier contenant la concaténation des clés et certificats clients codés en PEM que le mandataire doit utiliser |
---|---|
Syntaxe: | SSLProxyMachineCertificateFile chemin-fichier |
Contexte: | configuration du serveur |
AllowOverride: | Sans objet |
Statut: | Extension |
Module: | mod_ssl |
Cette directive permet de définir le fichier tout-en-un où sont stockés les clés et certificats permettant au serveur mandataire de s'authentifier auprès des serveurs distants.
Le fichier spécifié est la simple concaténation des différents fichiers
de certificats codés en PEM, classés par ordre de préférence. Cette
directive s'utilise à la place ou en complément de la directive
SSLProxyMachineCertificatePath
.
Actuellement, les clés privées chiffrées ne sont pas supportées.
SSLProxyMachineCertificateFile /usr/local/apache2/conf/ssl.crt/proxy.pem
Description: | Répertoire des clés et certificats clients codés en PEM que le mandataire doit utiliser |
---|---|
Syntaxe: | SSLProxyMachineCertificatePath chemin-répertoire |
Contexte: | configuration du serveur |
AllowOverride: | Sans objet |
Statut: | Extension |
Module: | mod_ssl |
Cette directive permet de définir le répertoire où sont stockés les clés et certificats permettant au serveur mandataire de s'authentifier auprès des serveurs distants.
Les fichiers de ce répertoire doivent être codés en PEM et ils sont
accédés via des noms de fichier sous forme de condensés ou hash. Vous
devez donc aussi créer des liens symboliques nommés
valeur-de-hashage.N
, et vous devez toujours vous
assurer que ce répertoire contient les liens symboliques appropriés.
Actuellement, les clés privées chiffrées ne sont pas supportées.
SSLProxyMachineCertificatePath /usr/local/apache2/conf/proxy.crt/
Description: | Définit les protocoles SSL disponibles pour la fonction de mandataire |
---|---|
Syntaxe: | SSLProxyProtocol [+|-]protocole ... |
Défaut: | SSLProxyProtocol all |
Contexte: | configuration du serveur, serveur virtuel |
AllowOverride: | Options |
Statut: | Extension |
Module: | mod_ssl |
Cette directive permet de définir les protocoles SSL que mod_ssl peut utiliser lors de l'élaboration de son environnement de serveur pour la fonction de mandataire. Il ne se connectera qu'aux serveurs utilisant un des protocoles spécifiés.
Veuillez vous reporter à la directive SSLProtocol
pour plus d'informations.
Description: | Niveau de vérification du certificat du serveur distant |
---|---|
Syntaxe: | SSLProxyVerify niveau |
Défaut: | SSLProxyVerify none |
Contexte: | configuration du serveur, serveur virtuel |
Statut: | Extension |
Module: | mod_ssl |
Lorsqu'un mandataire est configuré pour faire suivre les requêtes vers un serveur SSL distant, cette directive permet de configurer la vérification du certificat de ce serveur distant.
Les valeurs de niveaux disponibles sont les suivantes :
En pratique, seuls les niveaux none et require sont vraiment intéressants, car le niveau optional ne fonctionne pas avec tous les serveurs, et le niveau optional_no_ca va tout à fait à l'encontre de l'idée que l'on peut se faire de l'authentification (mais peut tout de même être utilisé pour établir des pages de test SSL, etc...).
SSLProxyVerify require
Description: | Niveau de profondeur maximum dans les certificats de CA lors de la vérification du certificat du serveur distant |
---|---|
Syntaxe: | SSLProxyVerifyDepth niveau |
Défaut: | SSLProxyVerifyDepth 1 |
Contexte: | configuration du serveur, serveur virtuel |
AllowOverride: | AuthConfig |
Statut: | Extension |
Module: | mod_ssl |
Cette directive permet de définir le niveau de profondeur maximum jusqu'auquel mod_ssl doit aller au cours de sa vérification avant de décider que le serveur distant ne possède pas de certificat valide.
La profondeur correspond en fait au nombre maximum de fournisseurs de
certificats intermédiaires, c'est à dire le nombre maximum de
certificats
de CA que l'on peut consulter lors de la vérification du certificat du
serveur distant. Une profondeur de 0 signifie que seuls les certificats
de serveurs distants auto-signés sont acceptés, et la profondeur par
défaut de 1 que le certificat du serveur distant peut être soit
auto-signé, soit signé par une CA connue directement du serveur (en
d'autres termes, le certificat de CA est référencé par la directive
SSLProxyCACertificatePath
),
etc...
SSLProxyVerifyDepth 10
Description: | Source de déclenchement du Générateur de Nombres Pseudo-Aléatoires (PRNG) |
---|---|
Syntaxe: | SSLRandomSeed contexte source
[nombre] |
Contexte: | configuration du serveur |
Statut: | Extension |
Module: | mod_ssl |
Cette directive permet de définir une ou plusieurs sources de
déclenchement du Générateur de Nombres Pseudo-Aléatoires (PRNG) dans
OpenSSL au démarrage du serveur (si contexte a pour valeur
startup
) et/ou juste avant l'établissement d'une nouvelle
connexion SSL (si contexte a pour valeur connect
).
Cette directive ne peut être utilisée qu'au niveau du serveur global car
le PRNG est un service global.
Les différentes valeurs de source disponibles sont :
builtin
Cette source de déclenchement intégrée est toujours disponible. Son utilisation consomme un minimum de cycles CPU en cours d'exécution, et son utilisation ne présente de ce fait aucun problème. La source utilisée pour déclencher le PRNG contient la date courante, l'identifiant du processus courant et (si disponible) un extrait de 1Ko aléatoirement choisi de la structure d'Apache pour les échanges inter-processus. Ceci présente un inconvénient car le caractère aléatoire de cette source n'est pas vraiment fort, et au démarrage (lorsque la structure d'échanges n'est pas encore disponible), cette source ne produit que quelques octets d'entropie. Vous devez donc toujours utiliser une source de déclenchement additionnelle, au moins pour le démarrage.
file:/chemin/vers/source
Cette variante utilise un fichier externe
file:/chemin/vers/source
comme source de déclenchement
du PRNG. Lorsque nombre est spécifié, seuls les
nombre premiers octets du fichier forment l'entropie (et
nombre est fourni comme premier argument à
/chemin/vers/source
). Lorsque nombre n'est pas
spécifié, l'ensemble du fichier forme l'entropie (et 0
est fourni comme premier argument à
/chemin/vers/source
). Utilisez cette source en
particulier au démarrage, par exemple avec un fichier de
périphérique /dev/random
et/ou
/dev/urandom
(qui sont en général présent sur les
plate-formes dérivées d'Unix modernes comme FreeBSD et Linux).
Soyez cependant prudent : en général,
/dev/random
ne fournit que l'entropie dont il dispose
réellement ; en d'autres termes, lorsque vous demandez 512 octets
d'entropie, si le périphérique ne dispose que de 100 octets, deux
choses peuvent se produire : sur certaines plates-formes, vous ne
recevez que les 100 octets, alors que sur d'autres, la lecture se
bloque jusqu'à ce qu'un nombre suffisant d'octets soit disponible
(ce qui peut prendre beaucoup de temps). Il est préférable ici
d'utiliser le périphérique /dev/urandom
, car il ne se
bloque jamais et fournit vraiment la quantité de données demandées.
Comme inconvénient, les données reçues ne sont pas forcément de la
meilleure qualité.
exec:/chemin/vers/programme
Cette variante utilise un exécutable externe
/chemin/vers/programme
comme source de déclenchement du
PRNG. Lorsque nombre est spécifié, seules les
nombre premiers octets de son flux stdout
forment l'entropie. Lorsque nombre n'est pas spécifié,
l'intégralité des données produites sur stdout
forment
l'entropie. N'utilisez cette variante qu'au démarrage où une source
de déclenchement fortement aléatoire est nécessaire, en utilisant
un programme externe (comme dans l'exemple
ci-dessous avec l'utilitaire truerand
basé sur la
bibliothèque truerand de AT&T que vous trouverez
dans la distribution de mod_ssl). Bien entendu, l'utilisation de
cette variante dans un contexte "connection" ralentit le serveur de
manière trop importante, et en général, vous devez donc éviter
d'utiliser des programmes externes dans ce contexte.
egd:/chemin/vers/socket-egd
(Unix seulement)
Cette variante utilise le socket de domaine Unix du Démon Générateur d'Entropie externe ou Entropy Gathering Daemon ou EGD (voir http://www.lothar.com/tech /crypto/) pour déclencher le PRNG. N'utilisez cette variante que si votre plate-forme ne possède pas de périphérique random ou urandom.
SSLRandomSeed startup builtin SSLRandomSeed startup file:/dev/random SSLRandomSeed startup file:/dev/urandom 1024 SSLRandomSeed startup exec:/usr/local/bin/truerand 16 SSLRandomSeed connect builtin SSLRandomSeed connect file:/dev/random SSLRandomSeed connect file:/dev/urandom 1024
Description: | Définit la taille du tampon de renégociation SSL |
---|---|
Syntaxe: | SSLRenegBufferSize taille |
Défaut: | SSLRenegBufferSize 131072 |
Contexte: | répertoire, .htaccess |
AllowOverride: | AuthConfig |
Statut: | Extension |
Module: | mod_ssl |
Si une renégociation SSL est requise dans un contexte de répertoire,
par exemple avec l'utilisation de SSLVerifyClient
dans un bloc Directory ou
Location, mod_ssl doit mettre en tampon en mémoire tout corps de requête
HTTP en attendant qu'une nouvelle initialisation de connexion SSL puisse
être effectuée. Cette directive permet de définir la quantité de mémoire
à allouer pour ce tampon.
Notez que dans de nombreuses configurations, le client qui envoie un corps de requête n'est pas forcément digne de confiance, et l'on doit par conséquent prendre en considération la possibilité d'une attaque de type déni de service lorsqu'on modifie la valeur de cette directive.
SSLRenegBufferSize 262144
Description: | N'autorise l'accès que lorsqu'une expression booléenne complexe et arbitraire est vraie |
---|---|
Syntaxe: | SSLRequire expression |
Contexte: | répertoire, .htaccess |
AllowOverride: | AuthConfig |
Statut: | Extension |
Module: | mod_ssl |
SSLRequire
est obsolète et doit en général être
remplacée par l'expression Require. La syntaxe ap_expr de l'expression Require
est
une extension de la syntaxe de SSLRequire
, avec les
différences suivantes :
Avec SSLRequire
, les opérateurs de comparaison
<
, <=
, ... sont strictement équivalents
aux opérateurs lt
, le
, ... , et fonctionnent
selon une méthode qui compare tout d'abord la longueur des deux chaînes,
puis l'ordre alphabétique. Les expressions ap_expr, quant à elles, possèdent deux jeux
d'opérateurs de comparaison : les opérateurs <
,
<=
, ... effectuent une comparaison alphabétique de
chaînes, alors que les opérateurs -lt
, -le
,
... effectuent une comparaison d'entiers. Ces derniers possèdent aussi
des alias sans tiret initial : lt
, le
, ...
Cette directive permet de spécifier une condition générale d'accès qui doit être entièrement satisfaite pour que l'accès soit autorisé. C'est une directive très puissante, car la condition d'accès spécifiée est une expression booléenne complexe et arbitraire contenant un nombre quelconque de vérifications quant aux autorisations d'accès.
L'expression doit respecter la syntaxe suivante (fournie ici sous la forme d'une notation dans le style de la grammaire BNF) :
expr ::= "true" | "false" | "!" expr | expr "&&" expr | expr "||" expr | "(" expr ")" | comp comp ::= word "==" word | word "eq" word | word "!=" word | word "ne" word | word "<" word | word "lt" word | word "<=" word | word "le" word | word ">" word | word "gt" word | word ">=" word | word "ge" word | word "in" "{" wordlist "}" | word "in" "PeerExtList(" word ")" | word "=~" regex | word "!~" regex wordlist ::= word | wordlist "," word word ::= digit | cstring | variable | function digit ::= [0-9]+ cstring ::= "..." variable ::= "%{" varname "}" function ::= funcname "(" funcargs ")"
Pour varname
, toute variable décrite dans Variables d'environnement pourra être utilisée.
Pour funcname
, vous trouverez la liste des fonctions
disponibles dans la documentation
ap_expr.
expression est interprétée et traduite sous une forme machine interne lors du chargement de la configuration, puis évaluée lors du traitement de la requête. Dans le contexte des fichiers .htaccess, expression est interprétée et exécutée chaque fois que le fichier .htaccess intervient lors du traitement de la requête.
SSLRequire ( %{SSL_CIPHER} !~ m/^(EXP|NULL)-/ \ and %{SSL_CLIENT_S_DN_O} eq "Snake Oil, Ltd." \ and %{SSL_CLIENT_S_DN_OU} in {"Staff", "CA", "Dev"} \ and %{TIME_WDAY} -ge 1 and %{TIME_WDAY} -le 5 \ and %{TIME_HOUR} -ge 8 and %{TIME_HOUR} -le 20 ) \ or %{REMOTE_ADDR} =~ m/^192\.76\.162\.[0-9]+$/
La fonction PeerExtList(identifiant objet)
recherche une instance d'extension de certificat X.509 identifiée par
identifiant objet (OID) dans le certificat client. L'expression est
évaluée à true si la partie gauche de la chaîne correspond exactement à
la valeur d'une extension identifiée par cet OID (Si plusieurs
extensions possèdent le même OID, l'une d'entre elles au moins doit
correspondre).
SSLRequire "foobar" in PeerExtList("1.2.3.4.5.6")
L'identifiant objet peut être spécifié soit comme un nom
descriptif reconnu par la bibliothèque SSL, tel que
"nsComment"
, soit comme un OID numérique tel que
"1.2.3.4.5.6"
.
Les expressions contenant des types connus de la bibliothèque SSL sont transformées en chaînes avant comparaison. Pour les extensions contenant un type non connu de la bibliothèque SSL, mod_ssl va essayer d'interpréter la valeur s'il s'agit d'un des types ASN.1 primaires UTF8String, IA5String, VisibleString, ou BMPString. Si l'extension correspond à un de ces types, la chaîne sera convertie en UTF-8 si nécessaire, puis comparée avec la partie gauche de l'expression.
Description: | Interdit l'accès lorsque la requête HTTP n'utilise pas SSL |
---|---|
Syntaxe: | SSLRequireSSL |
Contexte: | répertoire, .htaccess |
AllowOverride: | AuthConfig |
Statut: | Extension |
Module: | mod_ssl |
Cette directive interdit l'accès si HTTP sur SSL (c'est à dire HTTPS) n'est pas activé pour la connexion courante. Ceci est très pratique dans un serveur virtuel où SSL est activé ou dans un répertoire pour se protéger des erreurs de configuration qui pourraient donner accès à des ressources protégées. Lorsque cette directive est présente, toutes les requêtes qui n'utilisent pas SSL sont rejetées.
SSLRequireSSL
Description: | Type du cache de session SSL global et inter-processus |
---|---|
Syntaxe: | SSLSessionCache type |
Défaut: | SSLSessionCache none |
Contexte: | configuration du serveur |
Statut: | Extension |
Module: | mod_ssl |
Cette directive permet de configurer le type de stockage du cache de session SSL global et inter-processus. Ce cache est une fonctionnalité optionnelle qui accélère le traitement parallèle des requêtes. Pour ce qui est des requêtes vers un même processus du serveur (via HTTP keep-alive), OpenSSL met en cache les informations de session SSL en interne. Mais comme les clients modernes demandent des images en ligne et d'autres données via des requêtes parallèles (un nombre de quatre requêtes parallèles est courant), ces requêtes vont être servies par plusieurs processus du serveur pré-déclenchés. Ici, un cache inter-processus permet d'éviter des négociations de session inutiles.
Les quatre types de stockage suivants sont actuellement supportés :
none
Cette valeur désactive le cache de session global et inter-processus, ce qui va ralentir le serveur de manière sensible et peut poser problème avec certains navigateurs, en particulier si les certificats clients sont activés. Cette configuration n'est pas recommandée.
nonenotnull
Cette valeur désactive tout cache de session global et inter-processus. Cependant, elle force OpenSSL à envoyer un identifiant de session non nul afin de s'adapter aux clients bogués qui en nécessitent un.
dbm:/chemin/vers/fichier-données
Cette valeur utilise un fichier de hashage DBM sur disque local
pour synchroniser les caches OpenSSL locaux en mémoire des processus
du serveur. Ce cache de session peut être sujet à des problèmes de
fiabilité sous forte charge. Pour l'utiliser, le module
mod_socache_dbm
doit être chargé.
shmcb:/chemin/vers/fichier-données
[(
nombre)
]
Cette valeur utilise un tampon cyclique à hautes performances
(d'une taille d'environ nombre octets) dans un segment de
mémoire partagée en RAM (établi via
/chemin/vers/fichier-données
, pour synchroniser les
caches OpenSSL locaux en mémoire des processus du serveur. C'est le
type de cache de session recommandé. Pour l'utiliser, le module
mod_socache_shmcb
doit être chargé.
dc:UNIX:/chemin/vers/socket
Cette valeur utilise les bibliothèques de mise en cache de
sessions distribuée sur cache distant "distcache".
L'argument doit spécifier le serveur ou mandataire à utiliser en
utilisant la syntaxe d'adressage distcache ; par exemple,
UNIX:/chemin/vers/socket
spécifie une socket de domaine
Unix (en général un mandataire de dc_client local) ;
IP:serveur.example.com:9001
spécifie une adresse IP.
Pour l'utiliser, le module mod_socache_dc
doit être
chargé.
SSLSessionCache dbm:/usr/local/apache/logs/ssl_gcache_data SSLSessionCache shmcb:/usr/local/apache/logs/ssl_gcache_data(512000)
Le mutex ssl-cache
permet de sérialiser l'accès au cache
de session afin d'éviter toute corruption. Ce mutex peut être configuré
via la directive Mutex
.
Description: | Nombre de secondes avant l'expiration d'une session SSL dans le cache de sessions |
---|---|
Syntaxe: | SSLSessionCacheTimeout secondes |
Défaut: | SSLSessionCacheTimeout 300 |
Contexte: | configuration du serveur, serveur virtuel |
Statut: | Extension |
Module: | mod_ssl |
Compatibilité: | S'applique aussi à la reprise de session TLS (RFC 5077) à partir de la version 2.4.10 du serveur HTTP Apache |
Cette directive permet de définir la durée de vie en secondes des informations stockées dans le cache de sessions SSL global et inter-processus, dans le cache OpenSSL interne en mémoire et pour les sessions réinitialisées par la reprise de session TLS (RFC 5077). elle peut être définie à une valeur d'environ 15 à des fins de test, mais à une valeur très supérieure comme 300 en production.
SSLSessionCacheTimeout 600
Description: | Clé de chiffrement/déchiffrement permanente pour les tickets de session TLS |
---|---|
Syntaxe: | SSLSessionTicketKeyFile chemin-fichier |
Contexte: | configuration du serveur, serveur virtuel |
Statut: | Extension |
Module: | mod_ssl |
Compatibilité: | Disponible depuis la version 2.4.0 du serveur HTTP Apache, sous réserve que l'on utilise une version 0.9.8h ou supérieure 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 é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 est préférable d'utiliser les clés (aléatoires) générées par mod_ssl au démarrage du serveur.
Le fichier doit contenir 48 octets de données aléatoires créées de préférence par une source à haute entropie. Sur un système de type UNIX, il est possible de créer le fichier contenant la clé de la manière suivante :
dd if=/dev/random of=/chemin/vers/fichier.tkey bs=1 count=48
Ces clés doivent être renouvelées fréquemment, car il s'agit du seul moyen d'invalider un ticket de session existant - OpenSSL ne permet pas actuellement de spécifier une limite à la durée de vie des tickets.
Ce fichier contient des données sensibles et doit donc être protégé
par des permissions similaires à celles du fichier spécifié par la
directive SSLCertificateKeyFile
.
Description: | Source d'aléa pour utilisateur SRP inconnu |
---|---|
Syntaxe: | SSLSRPUnknownUserSeed secret-string |
Contexte: | configuration du serveur, serveur virtuel |
Statut: | Extension |
Module: | mod_ssl |
Compatibilité: | Disponible depuis la version 2.4.4 du serveur HTTP Apache, si la version 1.0.1 ou supérieure d'OpenSSL est utilisée. |
Cette directive permet de définir la source d'aléa à utiliser pour les utilisateurs SRP inconnus, ceci afin de combler les manques en cas d'existence d'un tel utilisateur. Elle définit une chaîne secrète. Si cette directive n'est pas définie, Apache renverra une alerte UNKNOWN_PSK_IDENTITY aux clients qui fournissent un nom d'utilisateur inconnu.
SSLSRPUnknownUserSeed "secret"
Description: | Chemin du fichier de vérification SRP |
---|---|
Syntaxe: | SSLSRPVerifierFile file-path |
Contexte: | configuration du serveur, serveur virtuel |
Statut: | Extension |
Module: | mod_ssl |
Compatibilité: | Disponible depuis la version 2.4.4 du serveur HTTP Apache, si la version 1.0.1 ou supérieure d'OpenSSL est utilisée. |
Cette directive permet d'activer TLS-SRP et de définir le chemin du fichier de vérification OpenSSL SRP (Mot de passe distant sécurisé) contenant les noms d'utilisateurs TLS-SRP, les vérificateurs, les "grains de sel" (salts), ainsi que les paramètres de groupe.
SSLSRPVerifierFile "/path/to/file.srpv"
Le fichier de vérification peut être créé via l'utilitaire en ligne de
commande openssl
:
openssl srp -srpvfile passwd.srpv -userinfo "some info" -add username
La valeur affectée au paramètre optionnel -userinfo
est
enregistrée dans la variable d'environnement
SSL_SRP_USERINFO
.
Description: | Configuration du cache pour l'agrafage OCSP |
---|---|
Syntaxe: | SSLStaplingCache type |
Contexte: | configuration du serveur |
Statut: | Extension |
Module: | mod_ssl |
Compatibilité: | Disponible si on utilise OpenSSL version 0.9.8h ou supérieure |
Si SSLUseStapling
est à "on",
cette directive permet de configurer le cache destiné à stocker les
réponses OCSP incluses dans la négociation TLS. La configuration d'un
cache est obligatoire pour pouvoir utiliser l'agrafage OCSP. A
l'exception de none
et nonenotnull
, cette
directive supporte les mêmes types de stockage que la directive
SSLSessionCache
.
Le mutex ssl-stapling
permet de sérialiser l'accès au
cache d'agrafage OCSP afin d'en prévenir la corruption. Ce mutex peut
être configuré via la directive Mutex
.
Description: | Durée de vie des réponses invalides dans le cache pour agrafage OCSP |
---|---|
Syntaxe: | SSLStaplingErrorCacheTimeout secondes |
Défaut: | SSLStaplingErrorCacheTimeout 600 |
Contexte: | configuration du serveur, serveur virtuel |
Statut: | Extension |
Module: | mod_ssl |
Compatibilité: | Disponible si on utilise OpenSSL version 0.9.8h ou supérieure |
Cette directive permet de définir la durée de vie des réponses
invalides dans le cache pour agrafage OCSP configuré via la
directive SSLStaplingCache
. Pour
définir la durée de vie des réponses valides, voir la directive
SSLStaplingStandardCacheTimeout
.
Description: | Génère une réponse "tryLater" pour les requêtes OCSP échouées |
---|---|
Syntaxe: | SSLStaplingFakeTryLater on|off |
Défaut: | SSLStaplingFakeTryLater on |
Contexte: | configuration du serveur, serveur virtuel |
Statut: | Extension |
Module: | mod_ssl |
Compatibilité: | Disponible si on utilise OpenSSL version 0.9.8h ou supérieure |
Lorsque cette directive est activée, et si une requête vers un
serveur OCSP à des fins d'inclusion dans une négociation TLS échoue,
mod_ssl va générer une réponse "tryLater" pour le client (SSLStaplingReturnResponderErrors
doit être
activée).
Description: | Remplace l'URI du serveur OCSP spécifié dans l'extension AIA du certificat |
---|---|
Syntaxe: | SSLStaplingForceURL uri |
Contexte: | configuration du serveur, serveur virtuel |
Statut: | Extension |
Module: | mod_ssl |
Compatibilité: | Disponible si on utilise OpenSSL version 0.9.8h ou supérieure |
Cette directive permet de remplacer l'URI du serveur OCSP extraite de l'extension authorityInfoAccess (AIA) du certificat. Elle peut s'avérer utile lorsqu'on passe par un mandataire
Description: | Temps d'attente maximum pour les requêtes vers les serveurs OCSP |
---|---|
Syntaxe: | SSLStaplingResponderTimeout secondes |
Défaut: | SSLStaplingResponderTimeout 10 |
Contexte: | configuration du serveur, serveur virtuel |
Statut: | Extension |
Module: | mod_ssl |
Compatibilité: | Disponible si on utilise OpenSSL version 0.9.8h ou supérieure |
Cette directive permet de définir le temps d'attente maximum lorsque
mod_ssl envoie une requête vers un serveur OCSP afin d'obtenir une
réponse destinée à être incluse dans les négociations TLS avec les
clients (SSLUseStapling
doit
avoir été activée au préalable).
Description: | Age maximum autorisé des réponses OCSP incluses dans la négociation TLS |
---|---|
Syntaxe: | SSLStaplingResponseMaxAge secondes |
Défaut: | SSLStaplingResponseMaxAge -1 |
Contexte: | configuration du serveur, serveur virtuel |
Statut: | Extension |
Module: | mod_ssl |
Compatibilité: | Disponible si on utilise OpenSSL version 0.9.8h ou supérieure |
Cette directive permet de définir l'âge maximum autorisé
("fraîcheur") des réponses OCSP incluses dans la négociation TLS
(SSLUseStapling
doit
avoir été activée au préalable). La valeur par défaut (-1
)
ne définit aucun âge maximum, ce qui signifie que les réponses OCSP sont
considérées comme valides à partir du moment où le contenu de leur champ
nextUpdate
se trouve dans le futur.
Description: | Durée de vie maximale autorisée des réponses OCSP incluses dans la négociation TLS |
---|---|
Syntaxe: | SSLStaplingResponseTimeSkew secondes |
Défaut: | SSLStaplingResponseTimeSkew 300 |
Contexte: | configuration du serveur, serveur virtuel |
Statut: | Extension |
Module: | mod_ssl |
Compatibilité: | Disponible si on utilise OpenSSL version 0.9.8h ou supérieure |
Cette directive permet de spécifier l'intervalle de temps maximum que
mod_ssl va calculer en faisant la différence entre les contenus des
champs nextUpdate
et thisUpdate
des réponses
OCSP incluses dans la négociation TLS. Pour pouvoir utiliser cette
directive, SSLUseStapling
doit
être à "on".
Description: | Transmet au client les erreurs survenues lors des requêtes OCSP |
---|---|
Syntaxe: | SSLStaplingReturnResponderErrors on|off |
Défaut: | SSLStaplingReturnResponderErrors on |
Contexte: | configuration du serveur, serveur virtuel |
Statut: | Extension |
Module: | mod_ssl |
Compatibilité: | Disponible si on utilise OpenSSL version 0.9.8h ou supérieure |
Lorsque cette directive est activée, mod_ssl va transmettre au client les
réponses concernant les requêtes OCSP échouées (erreurs d'état, réponses
périmées, etc...). Lorsqu'elle est à off
, aucune réponse
concernant les requêtes OCSP échouées ne sera incluse dans les
négociation TLS avec les clients.
Description: | Durée de vie des réponses OCSP dans le cache |
---|---|
Syntaxe: | SSLStaplingStandardCacheTimeout secondes |
Défaut: | SSLStaplingStandardCacheTimeout 3600 |
Contexte: | configuration du serveur, serveur virtuel |
Statut: | Extension |
Module: | mod_ssl |
Compatibilité: | Disponible si on utilise OpenSSL version 0.9.8h ou supérieure |
Cette directive permet de définir la durée de vie des réponses OCSP
dans le cache configuré via la directive SSLStaplingCache
. Elle ne s'applique qu'aux
réponse valides, alors que la directive SSLStaplingErrorCacheTimeout
s'applique aux
réponses invalides ou non disponibles.
Description: | Contrôle de l'accès des clients non-SNI à un serveur virtuel à base de nom. |
---|---|
Syntaxe: | SSLStrictSNIVHostCheck on|off |
Défaut: | SSLStrictSNIVHostCheck off |
Contexte: | configuration du serveur, serveur virtuel |
Statut: | Extension |
Module: | mod_ssl |
Compatibilité: | Disponible depuis la version 2.2.12 d'Apache |
Cette directive permet de contrôler l'accès des clients non-SNI à un serveur
virtuel à base de nom. Si elle est définie à on
dans le
serveur virtuel à base de nom par défaut, les
clients non-SNI ne seront autorisés à accéder à aucun serveur virtuel
appartenant à cette combinaison IP/port. Par
contre, si elle est définie à on
dans un serveur virtuel
quelconque, les clients non-SNI ne se verront interdire l'accès qu'à ce
serveur.
Cette option n'est disponible que si httpd a été compilé avec une version d'OpenSSL supportant SNI.
SSLStrictSNIVHostCheck on
Description: | Nom de la variable servant à déterminer le nom de l'utilisateur |
---|---|
Syntaxe: | SSLUserName nom-var |
Contexte: | configuration du serveur, répertoire, .htaccess |
AllowOverride: | AuthConfig |
Statut: | Extension |
Module: | mod_ssl |
Cette variable permet de définir le champ "user" de l'objet de la
requête Apache. Ce champ est utilisé par des modules de plus bas niveau
pour identifier l'utilisateur avec une chaîne de caractères. En
particulier, l'utilisation de cette directive peut provoquer la
définition de la variable d'environnement REMOTE_USER
.
La valeur de l'argument nom-var peut correspondre à toute variable d'environnement SSL.
Notez que cette directive est sans effet si l'option
FakeBasicAuth
est utilisée (voir SSLOptions).
SSLUserName SSL_CLIENT_S_DN_CN
Description: | Active l'ajout des réponses OCSP à la négociation TLS |
---|---|
Syntaxe: | SSLUseStapling on|off |
Défaut: | SSLUseStapling off |
Contexte: | configuration du serveur, serveur virtuel |
Statut: | Extension |
Module: | mod_ssl |
Compatibilité: | Disponible si on utilise OpenSSL version 0.9.8h ou supérieure |
Cette directive permet d'activer l'"Agrafage OCSP" (OCSP stapling)
selon la définition de l'extension TLS "Certificate Status Request"
fournie dans la RFC 6066. Si elle est activée et si le client le
demande, mod_ssl va inclure une réponse OCSP à propos de son propre
certificat dans la négociation TLS. Pour pouvoir activer l'Agrafage
OCSP, il est nécessaire de configurer un SSLStaplingCache
.
L'agrafage OCSP dispense le client de requérir le serveur OCSP
directement ; il faut cependant noter que selon les spécifications de la
RFC 6066, la réponse CertificateStatus
du serveur ne peut
inclure une réponse OCSP que pour un seul certificat. Pour les
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
Multiple Certificate Status Extension).
Description: | Niveau de vérification du certificat client |
---|---|
Syntaxe: | SSLVerifyClient niveau |
Défaut: | SSLVerifyClient none |
Contexte: | configuration du serveur, serveur virtuel, répertoire, .htaccess |
AllowOverride: | AuthConfig |
Statut: | Extension |
Module: | mod_ssl |
Cette directive permet de définir le niveau de vérification du certificat pour l'authentification du client. Notez que cette directive peut être utilisée à la fois dans les contextes du serveur principal et du répertoire. Dans le contexte du serveur principal, elle s'applique au processus d'authentification du client utilisé au cours de la négociation SSL standard lors de l'établissement d'une connexion. Dans un contexte de répertoire, elle force une renégociation SSL avec le niveau de vérification du client spécifié, après la lecture d'une requête HTTP, mais avant l'envoi de la réponse HTTP.
Les valeurs de niveau disponibles sont les suivantes :
En pratique, seuls les niveaux none et require sont vraiment intéressants, car le niveau optional ne fonctionne pas avec tous les navigateurs, et le niveau optional_no_ca va vraiment à l'encontre de l'idée que l'on peut se faire de l'authentification (mais peut tout de même être utilisé pour établir des pages de test SSL, etc...)
SSLVerifyClient require
Description: | Profondeur maximale des certificats de CA pour la vérification des certificats clients |
---|---|
Syntaxe: | SSLVerifyDepth nombre |
Défaut: | SSLVerifyDepth 1 |
Contexte: | configuration du serveur, serveur virtuel, répertoire, .htaccess |
AllowOverride: | AuthConfig |
Statut: | Extension |
Module: | mod_ssl |
Cette directive permet de spécifier la profondeur maximale à laquelle mod_ssl va effectuer sa vérification avant de décider que le client ne possède pas de certificat valide. Notez que cette directive peut être utilisée à la fois dans les contextes du serveur principal et de répertoire. Dans le contexte du serveur principal, elle s'applique au processus d'authentification du client utilisé au cours de la négociation SSL standard lors de l'établissement d'une connexion. Dans un contexte de répertoire, elle force une renégociation SSL avec le client selon la nouvelle profondeur spécifiée, après la lecture d'une requête HTTP, mais avant l'envoi de la réponse HTTP.
La profondeur correspond au nombre maximum de fournisseurs de
certificats intermédiaires, c'est à dire le nombre maximum de
certificats de CA que l'on est autorisé à suivre lors de la vérification
du certificat du client. Une profondeur de 0 signifie que seuls les
certificats clients auto-signés sont acceptés ; la profondeur par défaut
de 1 signifie que le certificat client peut être soit auto-signé, soit
signé par une CA connue directement du serveur (c'est à dire que le
certificat de la CA doit être référencé par la directive SSLCACertificatePath
), etc...
SSLVerifyDepth 10