Module Apache mod_ssl

Sommaire

Ce module fournit le support SSL v3 et TLS v1 au serveur HTTPApache. SSL v2 n'est plus supporté.

Ce module s'appuie surOpenSSLpour fournir le moteur de chiffrement.

D'autres détails, discussions et exemples sont fournis dans ladocumentation SSL.

Sujets

• Variables d'environnement
• Formats de journauxpersonnalisés
• Information à propos de la requête
• Extension pour l'interprétationdes expressions
• Fournisseurs d'autorisationdisponibles avec Require

Directives

• SSLCACertificateFile
• SSLCACertificatePath
• SSLCADNRequestFile
• SSLCADNRequestPath
• SSLCARevocationCheck
• SSLCARevocationFile
• SSLCARevocationPath
• SSLCertificateChainFile
• SSLCertificateFile
• SSLCertificateKeyFile
• SSLCipherSuite
• SSLCompression
• SSLCryptoDevice
• SSLEngine
• SSLFIPS
• SSLHonorCipherOrder
• SSLInsecureRenegotiation
• SSLOCSPDefaultResponder
• SSLOCSPEnable
• SSLOCSPNoverify
• SSLOCSPOverrideResponder
• SSLOCSPProxyURL
• SSLOCSPResponderCertificateFile
• SSLOCSPResponderTimeout
• SSLOCSPResponseMaxAge
• SSLOCSPResponseTimeSkew
• SSLOCSPUseRequestNonce
• SSLOpenSSLConfCmd
• SSLOptions
• SSLPassPhraseDialog
• SSLProtocol
• SSLProxyCACertificateFile
• SSLProxyCACertificatePath
• SSLProxyCARevocationCheck
• SSLProxyCARevocationFile
• SSLProxyCARevocationPath
• SSLProxyCheckPeerCN
• SSLProxyCheckPeerExpire
• SSLProxyCheckPeerName
• SSLProxyCipherSuite
• SSLProxyEngine
• SSLProxyMachineCertificateChainFile
• SSLProxyMachineCertificateFile
• SSLProxyMachineCertificatePath
• SSLProxyProtocol
• SSLProxyVerify
• SSLProxyVerifyDepth
• SSLRandomSeed
• SSLRenegBufferSize
• SSLRequire
• SSLRequireSSL
• SSLSessionCache
• SSLSessionCacheTimeout
• SSLSessionTicketKeyFile
• SSLSessionTickets
• SSLSRPUnknownUserSeed
• SSLSRPVerifierFile
• SSLStaplingCache
• SSLStaplingErrorCacheTimeout
• SSLStaplingFakeTryLater
• SSLStaplingForceURL
• SSLStaplingResponderTimeout
• SSLStaplingResponseMaxAge
• SSLStaplingResponseTimeSkew
• SSLStaplingReturnResponderErrors
• SSLStaplingStandardCacheTimeout
• SSLStrictSNIVHostCheck
• SSLUserName
• SSLUseStapling
• SSLVerifyClient
• SSLVerifyDepth
• SSLVHostSNIPolicy

Traitement des bugs

• Journal des modifications de httpd
• Problèmes connus
• Signaler un bug

Voir aussi

• Commentaires

Variables d'environnement

Ce module peut être configuré pour fournir aux espaces de nommage SSIet CGI de nombreux éléments d'informations concernant SSL par le biaisde variables d'environnement supplémentaires. Par défaut, sauf pourHTTPS etSSL_TLS_SNI qui sont toujours définies, cesinformations ne sont pas fournies pour des raisons de performances (Voirla directiveSSLOptionsStdEnvVars 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 chapitreCompatibilité pour plus de détails àpropos des variables de compatibilité.

x509 spécifie un élément de DN X.509 parmiC,ST,L,O,OU,CN,T,I,G,S,D,UID,Email. A partir de la version2.2.0 d'Apache,x509 peut aussi comporter un suffixe numérique_n. Si le DN en question comporte plusieurs attributs denoms identiques, ce suffixe constitue un index débutant à zéro etpermettant de sélectionner unattribut particulier. Par exemple, si le DN sujet du certificat duserveur comporte deux champs OU, on peut utiliserSSL_SERVER_S_DN_OU_0 etSSL_SERVER_S_DN_OU_1pour 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'optionStdEnvVars de la directiveSSLOptions, le premier attribut (ou leseul) caractérisant le DN est enregistré avec un nom sans suffixe ;autrement dit, aucune entrée possédant comme suffixe_0n'est enregistrée.

A partir de la version 2.4.32 de httpd, on peut ajouter le suffixe_RAW àx509 dans un composant DN afin d'empêcher la conversionde la valeur de l'attribut en UTF-8. Il doit être placé après le suffixe index(s'il existe). On utilisera par exempleSSL_SERVER_S_DN_OU_RAW ouSSL_SERVER_S_DN_OU_0_RAW.

Le format des variables*_DN a changé depuis la version2.3.11 d'Apache HTTPD. Voir l'optionLegacyDNStringFormatde la directiveSSLOptions pourplus de détails.

SSL_CLIENT_V_REMAIN n'est disponible qu'à partir de laversion 2.1.

Plusieurs variables d'environnement additionnelles peuvent êtreutilisées dans les expressionsSSLRequire, oudans les formats de journalisation personnalisés :

HTTP_USER_AGENT        PATH_INFO             AUTH_TYPEHTTP_REFERER           QUERY_STRING          SERVER_SOFTWAREHTTP_COOKIE            REMOTE_HOST           API_VERSIONHTTP_FORWARDED         REMOTE_IDENT          TIME_YEARHTTP_HOST              IS_SUBREQ             TIME_MONHTTP_PROXY_CONNECTION  DOCUMENT_ROOT         TIME_DAYHTTP_ACCEPT            SERVER_ADMIN          TIME_HOURTHE_REQUEST            SERVER_NAME           TIME_MINREQUEST_FILENAME       SERVER_PORT           TIME_SECREQUEST_METHOD         SERVER_PROTOCOL       TIME_WDAYREQUEST_SCHEME         REMOTE_ADDR           TIMEREQUEST_URI            REMOTE_USER

Dans ces contextes, deux formats spéciaux peuvent aussi être utilisés:

ENV:nom_variable

Correspond à la variable d'environnement standardnom_variable.

HTTP:nom_en-tête

Correspond à la valeur de l'en-tête de requête dont le nom estnom_en-tête.

Formats de journauxpersonnalisés

Lorsquemod_ssl est compilé dans le serveur Apacheou même chargé (en mode DSO), des fonctions supplémentaires sontdisponibles pour leFormat de journal personnalisé dumodulemod_log_config. A ce titre, la fonction deformat d'eXtension ``%{nom-var}x''peut être utilisée pour présenter en extension toute variable fourniepar tout module, et en particulier celles fournies par mod_ssl et quevous trouverez dans la table ci-dessus.

A des fins de compatibilité ascendante, il existe une fonction de formatcryptographique supplémentaire``%{nom}c''. Vous trouverez toutesles informations à propos de cette fonction dans le chapitreCompatibilité.

CustomLog "logs/ssl_request_log" "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"

Ces formats sont disponibles même si l'optionStdEnvVars de ladirectiveSSLOptions n'a pas étédéfinie.

Information à propos de la requête

mod_ssl enregistre des informations à propos de larequête que l'on peut restituer dans les journaux avec la chaîne deformat%{nom}n via le modulemod_log_config.

Les informations enregistrées sont les suivantes :

ssl-access-forbidden

Cette information contient la valeur1 si l'accès a été refusé suite à une directiveSSLRequire ouSSLRequireSSL.

ssl-secure-reneg

Simod_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 valeur1. Si le client ne supporte pas la renégociation sécurisée, l'information contiendra la valeur0. Simod_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.

Extension pour l'interprétationdes expressions

Lorsquemod_ssl est compilé statiquement avecApache, ou même chargé dynamiquement (en tant que module DSO), toutevariable en provenance demod_ssl peutêtre utilisée pour l'interprétation desexpression ap_expr. Les variables peuvent être référencées enutilisant la syntaxe ``%{varname}''.A partir de la version 2.4.18, on peut aussi utiliser la syntaxe destylemod_rewrite``%{SSL:varname}'', ou la syntaxe destyle fonction ``ssl(varname)''.

Header set X-SSL-PROTOCOL "expr=%{SSL_PROTOCOL}"Header set X-SSL-CIPHER "expr=%{SSL:SSL_CIPHER}"

Cette fonctionnalité est disponible même si l'optionStdEnvVars de la directiveSSLOptions n'a pas été définie.

Fournisseurs d'autorisationdisponibles avec Require

mod_ssl propose quelques fournisseurs d'autorisation à utiliser avec la directiveRequire du modulemod_authz_core.

Require ssl

Le fournisseurssl refuse l'accès si une connexion n'est pas chiffrée avec SSL. L'effet est similaire à celui de la directiveSSLRequireSSL.

Require ssl

Require ssl-verify-client

Le fournisseurssl autorise l'accès si l'utilisateur est authentifié via un certificat client valide. Ceci n'a un effet que siSSLVerifyClient 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-clientRequire valid-user

DirectiveSSLCACertificateFile

Cette directive permet de définir le fichiertout-en-un où vouspouvez rassembler les certificats des Autorités de Certification (CAs)pour les clients auxquels vous avez à faire. On les utilise pourl'authentification des clients. Un tel fichier contient la simpleconcaténation des différents fichiers de certificats codés en PEM, parordre de préférence. Cette directive peut être utilisée à la place et/ouen complément de la directiveSSLCACertificatePath.

SSLCACertificateFile "/usr/local/apache2/conf/ssl.crt/ca-bundle-client.crt"

DirectiveSSLCACertificatePath

Cette directive permet de définir le répertoire où sont stockés lescertificats des Autorités de Certification (CAs) pour les clientsauxquels vous avez à faire. On les utilise pour vérifier le certificatdu client au cours de l'authentification de ce dernier.

Les fichiers de ce répertoire doivent être codés en PEM et ils sontaccédés via des noms de fichier sous forme de condensés ou hash. Il nesuffit donc pas de placer les fichiers de certificats dans ce répertoire: vous devez aussi créer des liens symboliques nommésvaleur-de-hashage.N, et vous devez toujours vousassurer que ce répertoire contient les liens symboliques appropriés.

SSLCACertificatePath "/usr/local/apache2/conf/ssl.crt/"

DirectiveSSLCADNRequestFile

Lorsque mod_ssl demande un certificat client, une liste denomsd'Autorités de Certification acceptables est envoyée au client aucours de la phase d'initialisation de la connexion SSL. Le client peutalors utiliser cette liste de noms de CA pour sélectionner un certificatclient approprié parmi ceux dont il dispose.

Si aucune des directivesSSLCADNRequestPath ouSSLCADNRequestFile n'est définie, la listede noms de CsA acceptables envoyée au client est la liste des noms detous les certificats de CA spécifiés par les directivesSSLCACertificateFile etSSLCACertificatePath ; en d'autres termes,c'est la liste des noms de CAs qui sera effectivement utilisée pourvérifier le certificat du client.

Dans certaines situations, il est utile de pouvoir envoyerune liste de noms de CA acceptables qui diffère de la liste des CAseffectivement utilisés pour vérifier le certificat du client ;considérons par exemple le cas où le certificat du client est signé pardes CAs intermédiaires. On peut ici utiliser les directivesSSLCADNRequestPath et/ouSSLCADNRequestFile, et les noms de CAacceptables seront alors extraits de l'ensemble des certificats contenusdans le répertoire et/ou le fichier définis par cette paire dedirectives.

SSLCADNRequestFile doitspécifier un fichiertout-en-un contenant une concaténation descertificats de CA codés en PEM.

SSLCADNRequestFile "/usr/local/apache2/conf/ca-names.crt"

DirectiveSSLCADNRequestPath

Cette directive optionnelle permet de définir la liste denoms deCAs acceptables qui sera envoyée au client lorsqu'un certificat declient est demandé. Voir la directiveSSLCADNRequestFile pour plus dedétails.

Les fichiers de ce répertoire doivent être codés en PEM et ils sontaccédés via des noms de fichier sous forme de condensés ou hash. Il nesuffit donc pas de placer les fichiers de certificats dans ce répertoire: vous devez aussi créer des liens symboliques nommésvaleur-de-hashage.N, et vous devez toujours vousassurer que ce répertoire contient les liens symboliques appropriés.

SSLCADNRequestPath "/usr/local/apache2/conf/ca-names.crt/"

DirectiveSSLCARevocationCheck

Active la vérification des révocations basée sur les Listes deRévocations de Certificats (CRL). Au moins une des directivesSSLCARevocationFile ouSSLCARevocationPath doit être définie.Lorsque cette directive est définie àchain (valeurrecommandée), les vérifications CRL sont effectuées sur tous lescertificats de la chaîne, alors que la valeurleaf limitela vérification au certificat hors chaîne (la feuille).

flags peut prendre comme valeurs

• no_crl_for_cert_ok

  Avant la version 2.3.15, les vérifications CRL dans mod_sslréussissaient même si aucune CRL n'était trouvée dans les cheminsdéfinis par les directivesSSLCARevocationFile ouSSLCARevocationPath.

  Le comportement achangé avec l'introduction de la directiveSSLCARevocationFile : par défaut avecchain ouleaf, les CRLsdoivent être présentes pour que lavalidation réussisse ; dans le cas contraire, elle échouera avec uneerreur"unable to get certificate CRL".

  La valeurno_crl_for_cert_ok du drapeauflag permet deretrouver le comportement précédent.

SSLCARevocationCheck chain

SSLCARevocationCheck chain no_crl_for_cert_ok

DirectiveSSLCARevocationFile

Cette directive permet de définir le fichiertout-en-un où sontrassemblées les Listes de Révocation de Certificats (CRLs) des Autoritésde certification (CAs) pour les clients auxquels vous avez à faire. Onles utilise pour l'authentification des clients. Un tel fichier contientla 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 à laplace et/ou en complément de la directiveSSLCARevocationPath.

SSLCARevocationFile"/usr/local/apache2/conf/ssl.crl/ca-bundle-client.crl"

DirectiveSSLCARevocationPath

Cette directive permet de définir le répertoire où sont stockées lesListes de Révocation de Certificats (CRL) des Autorités de Certification(CAs) pour les clients auxquels vous avez à faire. On les utilise pourrévoquer les certificats des clients au cours de l'authentification deces derniers.

Les fichiers de ce répertoire doivent être codés en PEM et ils sontaccédés via des noms de fichier sous forme de condensés ou hash. Il nesuffit donc pas de placer les fichiers de CRL dans ce répertoire: vous devez aussi créer des liens symboliques nommésvaleur-de-hashage.N, et vous devez toujours vousassurer que ce répertoire contient les liens symboliques appropriés.

SSLCARevocationPath "/usr/local/apache2/conf/ssl.crl/"

DirectiveSSLCertificateChainFile

Cette directive permet de définir le fichier optionneltout-en-un où vous pouvez rassembler les certificats desAutorités de Certification (CA) qui forment la chaîne de certificationdu certificat du serveur. Cette chaîne débute par le certificat de la CAqui a délivré le certificat du serveur et peut remonter jusqu'aucertificat de la CA racine. Un tel fichier contient la simpleconcaténation des différents certificats de CA codés en PEM, en généraldans l'ordre de la chaîne de certification.

Elle doit être utilisée à la place et/ou en complément de ladirectiveSSLCACertificatePathpour construire explicitement la chaîne de certification du serveur quiest envoyée au navigateur en plus du certificat du serveur. Elle s'avèreparticulièrement utile pour éviter les conflits avec les certificats deCA lorsqu'on utilise l'authentification du client. Comme le fait deplacer un certificat de CA de la chaîne de certification du serveur dansla directiveSSLCACertificatePath produit le même effetpour la construction de la chaîne de certification, cette directive apour effet colatéral de faire accepter les certificats clients fournispar cette même CA, au cours de l'authentification du client.

Soyez cependant prudent : fournir la chaîne de certification nefonctionne que si vous utilisez unsimple certificat deserveur RSAou DSA. Si vous utilisez une paire de certificatscouplés RSA+DSA , cela ne fonctionnera que si les deux certificatsutilisent vraimentla même chaîne de certification. Dans le cascontraire, la confusion risque de s'installer au niveau desnavigateurs.

SSLCertificateChainFile "/usr/local/apache2/conf/ssl.crt/ca.crt"

DirectiveSSLCertificateFile

Cette directive permet de définir le fichier de données contenant lesinformations de certificat X.509 du serveur codées au format PEM oul'identificateur de certificat via un jeton cryptographique. Si on utilise unfichier au format PEM, ce dernier doit contenir au minimum un certificatd'entité finale (feuille).La directive peut être utilisée plusieurs fois (elle référence desfichiers différents) pour accepter plusieurs algorithmesd'authentification au niveau du serveur - souvent RSA, DSA et ECC. Lenombre d'algorithmes supportés dépend de la version d'OpenSSL utiliséeavec mod_ssl : à partir de la version 1.0.0, la commandeopenssllist-public-key-algorithms affiche la liste des algorithmessupportés. Voir aussi la note ci-dessous à propos des limitations des versionsd'OpenSSL antérieures à 1.0.2 et la manière de les contourner.

Les fichiers peuvent aussi contenir des certificats de CAintermédiaires triés depuis la feuille vers la racine. Cettefonctionnalité est disponible depuis la version 2.4.8 du serveur HTTPApache, et rend obsolète la directiveSSLCertificateChainFile. A partir de laversion 1.0.2 d'OpenSSL, il est alors possible de configurer la chaînede certification en fonction du certificat.

Depuis la version 2.4.7 du serveur HTTP Apache, on peut aussi ajouterdes paramètres DH personnalisés et un nom ECcurve pour les clés éphémères à la fin du premier fichier défini par ladirectiveSSLCertificateFile.Ces paramètres peuvent être générés avec les commandesopenssldhparam etopenssl ecparam, et ils peuvent êtreajoutés tel quel à la fin du premier fichier de certificat. En effet,seul le premier fichier de certificat défini peut être utilisé pourenregistrer des paramètres personnalisés, car ces derniers s'appliquentindépendamment de l'algorithme d'authentification utilisé.

Enfin, il est aussi possible d'ajouter la clé privée du certificat del'entité finale au fichier de certificat, ce qui permet de se passerd'une directiveSSLCertificateKeyFile séparée. Cettepratique est cependant fortement déconseillée. Dans ce cas, les fichiers decertificat qui contiennent de telles clés embarquées doivent être définisaprès les certificats qui utilisent un fichier de clé séparé. En outre,si la clé est chiffrée, une boîte de dialogue pour entrer le mot depasse de la clé s'ouvre au démarrage du serveur.

Plutôt que de stocker les certificats et les clés privées dans des fichiers,on peut utiliser un identificateur de certificat pour identifier un certificatstocké dans un jeton. Actuellement, seuls lesURIs PKCS#11 sont reconnus commeidentificateurs de certificats et peuvent être utilisés en conjonction avec lemoteur ou le fournisseur OpenSSLpkcs11. Si la directiveSSLCertificateKeyFile est absente, le certificat etla clé privée peuvent être chargés avec l'identificateur spécifié via ladirectiveSSLCertificateFile.

# Exemple utilisant un fichier codé en PEM.SSLCertificateFile "/usr/local/apache2/conf/ssl.crt/server.crt"# Exemple d'utilisation d'un certificat et d'une clé privés issus d'un jeton# PKCS#11 :SSLCertificateFile "pkcs11:token=My%20Token%20Name;id=45"

DirectiveSSLCertificateKeyFile

Cette directive permet de définir le fichier contenant la clé privée du serveurcodée en PEM ou l'identifiant de la clé via un jeton cryptographique défini. Sila clé privée est chiffrée, une boîte de dialogue demandant le mot de passe decette dernière s'ouvre au démarrage du serveur.

Cette directive peut être utilisée plusieurs fois pour référencerdifférents noms de fichiers, afin de supporter plusieurs algorithmespour l'authentification du serveur. A chaque directiveSSLCertificateKeyFile doit être associéeune directiveSSLCertificateFile correspondante.

La clé privée peut aussi être ajoutée au fichier défini par la directiveSSLCertificateFile, mais cettepratique est fortement déconseillée. Dans ce cas, les fichiers decertificats qui comportent une telle clé doivent être définis après lescertificats qui utilisent un fichier de clé séparé.

Plutôt que de stocker des clés privées dans des fichiers, il est possibled'identifier une clé privée via un identifiant stocké dans un jeton.Actuellement, seuls lesPKCS#11URIs sont reconnus comme identifiants de clés privées et peuvent êtreutilisés en conjonction avec le moteur ou le fournisseur OpenSSLpkcs11.

# Pour utiliser une clé privée stockée dans fichier encodé PEM :SSLCertificateKeyFile "/usr/local/apache2/conf/ssl.key/server.key"# Pour utiliser une clé privée à partir d'un jeton PKCS#11 :SSLCertificateKeyFile "pkcs11:token=My%20Token%20Name;id=45"

DirectiveSSLCipherSuite

Cette directive complexe utilise la chaînecipher-speccontenant la liste des algorithmes de chiffrement OpenSSL que le clientpeut utiliser au cours de la phase d'initialisation de la connexion SSL. Laspécification optionnelle du protocole permet de configurer la suited'algorithmes de chiffrement pour une version spécifique de SSL. Une des valeurspossibles est "SSL" pour toutes les versions du protocole SSL jusqu'à TLSv1.2compris.

Notez que cette directive peut être utilisée aussi bien dans un contextede serveur que dans un contexte de répertoire. Dans un contexte deserveur, elle s'applique à l'initialisation SSL standard lorsqu'uneconnexion est établie. Dans un contexte de répertoire, elle force unerenégociation SSL avec la liste d'algorithmes de chiffrement spécifiéeaprès la lecture d'une requête HTTP, mais avant l'envoi de la réponseHTTP.

Si la bibliothèque SSL supporte TLSv1.3 (versions d'OpenSSL 1.1.1 etsupérieures), il est possible de spécifier le paramètre "TLSv1.3" pourconfigurer la suite d'algorithmes de chiffrement pour ce protocole. CommeTLSv1.3 n'autorise pas la renégociation, spécifier pour lui des algorithmes dechiffrement dans un contexte de répertoire n'est pas autorisé

Pour obtenir la liste des noms d'algorithmes de chiffrement pour TLSv1.3, seréférer à ladocumentationOpenSSL.

La liste d'algorithmes de chiffrement SSL spécifiée par l'argumentcipher-spec comporte quatre attributs principaux auxquelss'ajoutent quelques attributs secondaires :

• Algorithme d'échange de clés:
  RSA, Diffie-Hellman, Elliptic Curve Diffie-Hellman, Secure Remote Password.
• Algorithme d'authentification:
  RSA, Diffie-Hellman, DSS, ECDSA, ou none.
• Algorithme de chiffrement:
  AES, DES, Triple-DES, RC4, RC2, IDEA, etc...
• Algorithme de condensé MAC:
  MD5, SHA ou SHA1, SHA256, SHA384.

L'algorithme de chiffrement peut aussi provenir de l'extérieur. Lesalgorithmes SSLv2 ne sont plus supportés.Pour définir les algorithmes à utiliser, onpeut soit spécifier tous les algorithmes à la fois, soit utiliser desalias pour spécifier une liste d'algorithmes dans leur ordre depréférence (voirTable 1). Les algorithmes etalias effectivement disponibles dépendent de la version d'opensslutilisée. Les versions ultérieures d'openssl sont susceptibles d'incluredes algorithmes supplémentaires.

Cela devient intéressant lorsque tous ces symboles sont combinésensemble pour spécifier les algorithmes disponibles et l'ordre danslequel vous voulez les utiliser. Pour simplifier tout cela, vousdisposez 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înealgorithmes.Les préfixes disponibles sont :

• none: ajoute l'algorithme à la liste
• +: déplace les algorithmes qui conviennent à laplace courante dans la liste
• -: supprime l'algorithme de la liste (peut être rajoutéplus tard)
• !: supprime définitivement l'algorithme de la liste (nepeutplus y être rajouté plus tard)

Pour vous simplifier la vie, vous pouvez utiliser la commande``openssl ciphers -v'' qui vous fournit un moyen simple decréer la chaînealgorithmes avec succès. La chaînealgorithmes par défaut dépend de la version des bibliothèquesSSL installées. Supposons qu'elle contienne``RC4-SHA:AES128-SHA:HIGH:MEDIUM:!aNULL:!MD5'', ce quistipule de mettreRC4-SHA etAES128-SHA enpremiers, car ces algorithmes présentent un bon compromis entre vitesseet sécurité. Viennent ensuite les algorithmes de sécurité élevée etmoyenne. En fin de compte, les algorithmes qui n'offrent aucuneauthentification sont exclus, comme les algorithmes anonymesDiffie-Hellman pour SSL, ainsi que tous les algorithmes qui utilisentMD5 pour le hashage, car celui-ci est reconnu commeinsuffisant.

$ openssl ciphers -v 'RC4-SHA:AES128-SHA:HIGH:MEDIUM:!aNULL:!MD5'RC4-SHA                 SSLv3 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=SHA1AES128-SHA              SSLv3 Kx=RSA      Au=RSA  Enc=AES(128)  Mac=SHA1DHE-RSA-AES256-SHA      SSLv3 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA1...                     ...               ...     ...           ...SEED-SHA                SSLv3 Kx=RSA      Au=RSA  Enc=SEED(128) Mac=SHA1PSK-RC4-SHA             SSLv3 Kx=PSK      Au=PSK  Enc=RC4(128)  Mac=SHA1KRB5-RC4-SHA            SSLv3 Kx=KRB5     Au=KRB5 Enc=RC4(128)  Mac=SHA1

Vous trouverez la liste complète des algorithmes RSA & DHspécifiques à SSL dans laTable 2.

SSLCipherSuite RSA:!EXP:!NULL:+HIGH:+MEDIUM:-LOW

DirectiveSSLCompression

Cette directive permet d'activer la compression au niveau SSL.

DirectiveSSLCryptoDevice

Cette directive permet d'activer l'utilisation d'une carte accélératricede chiffrement qui prendra en compte certaines parties du traitementrelatif à SSL. Cette directive n'est utilisable que si la boîte àoutils SSL à été compilée avec le support "engine" ; les versions 0.9.7et supérieures d'OpenSSL possèdent par défaut le support "engine", alorsqu'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

À partir de la version 3.0 d'OpenSSL, si aucun moteur n'est spécifié alorsque la clé ou le certificat sont spécifiés à l'aide d'URIs PKCS#11, le chargement de laclé et du certificat est tenté à partir d'un fournisseur OpenSSL. Le fournisseurOpenSSL à utiliser doit être défini et configuré dans le fichier deconfiguration d'OpenSSL et il doit prendre en charge laméthodeSTORE pour lesURIs PKCS#11.

DirectiveSSLEngine

Cette directive permet d'activer/désactiver le moteur du protocoleSSL/TLS. Elle doit être utilisée dans une section<VirtualHost> pour activerSSL/TLS pour ce serveur virtuel particulier. Par défaut, le moteur duprotocole SSL/TLS est désactivé pour le serveur principal et tous lesserveurs virtuels configurés.

<VirtualHost _default_:443>SSLEngine on#...</VirtualHost>

DirectiveSSLFIPS

Cette directive permet d'activer/désactiver l'utilisation du drapeauFIPS_mode de la bibliothèque SSL. Elle doit être définie dans lecontexte du serveur principal, et n'accepte pas les configurationssources de conflits (SSLFIPS on suivi de SSLFIPS off par exemple). Lemode 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 ledrapeau FIPS_mode, la directiveSSLFIPS on échouera.Reportez-vous au document sur la politique de sécurité FIPS 140-2 de labibliothèque du fournisseur SSL, pour les prérequis spécifiquesnécessaires à l'utilisation de mod_ssl selon un mode d'opérationapprouvé par FIPS 140-2 ; notez que mod_ssl en lui-même n'est pasvalidé, mais peut être décrit comme utilisant un module de chiffrementvalidé par FIPS 140-2, lorsque tous les composants sont assemblés et misen oeuvre selon les recommandations de la politique de sécuritéapplicable.

DirectiveSSLHonorCipherOrder

Normalement, ce sont les préférences du client qui sont prises encompte lors du choix d'un algorithme de chiffrement au cours d'unenégociation SSLv3 ou TLSv1. Si cette directive est activée, ce sont lespréférences du serveur qui seront prises en compte à la place.

SSLHonorCipherOrder on

DirectiveSSLInsecureRenegotiation

Comme il a été spécifié, toutes les versions des protocoles SSL etTLS (jusqu'à la version 1.2 de TLS incluse) étaient vulnérables à uneattaque de type Man-in-the-Middle (CVE-2009-3555)au cours d'une renégociation. Cette vulnérabilité permettait à unattaquant de préfixer la requête HTTP (telle qu'elle était vue duserveur) avec un texte choisi. Une extension du protocole a étédéveloppée pour corriger cette vulnérabilité, sous réserve qu'elle soitsupportée par le client et le serveur.

Simod_ssl est lié à une version 0.9.8m ousupérieure d'OpenSSL, par défaut, la renégociation n'est accordée qu'auxclients qui supportent la nouvelle extension du protocole. Sicette directive est activée, la renégociation sera accordée aux anciensclients (non patchés), quoique de manière non sécurisée

SSLInsecureRenegotiation on

La variable d'environnementSSL_SECURE_RENEG peut êtreutilisée dans un script SSI ou CGI pour déterminer si la renégociationsécurisée est supportée pour une connexion SSL donnée.

DirectiveSSLOCSPDefaultResponder

Cette directive permet de définir le répondeur OCSP par défaut. Si ladirectiveSSLOCSPOverrideResponder n'est pas activée,l'URI spécifié ne sera utilisé que si aucun URI de répondeur n'estspécifié dans le certificat en cours de vérification.

DirectiveSSLOCSPEnable

Cette directive permet d'activer la validation OCSP de la chaîne decertificats du client. Si elle est activée, les certificats de la chaînede certificats du client seront validés auprès d'un répondeur OCSP, unefois la vérification normale effectuée (vérification des CRLsincluse). En mode 'leaf', seul le certificat du client sera validé.

Le répondeur OCSP utilisé est soit extrait du certificat lui-même,soit spécifié dans la configuration ; voir les directivesSSLOCSPDefaultResponder etSSLOCSPOverrideResponder.

SSLVerifyClient onSSLOCSPEnable onSSLOCSPDefaultResponder "http://responder.example.com:8888/responder"SSLOCSPOverrideResponder on

DirectiveSSLOCSPNoverify

Cette directive permet d'éviter la vérification des certificatsdes répondeurs OCSP, ce qui peut s'avérer utile lorsqu'on teste un serveur OCSP.

DirectiveSSLOCSPOverrideResponder

Force l'utilisation, au cours d'une validation OCSP de certificat, durépondeur OCSP par défaut spécifié dans la configuration, que lecertificat en cours de vérification fasse mention d'un répondeur OCSP ounon.

DirectiveSSLOCSPProxyURL

Cette directive permet de définir l'URL d'un mandataire HTTP qui devra êtreutilisé pour toutes les requêtes vers un répondeur OCSP.

DirectiveSSLOCSPResponderCertificateFile

Cette directive permet de définir un fichier contenant une liste decertificats de confiance du répondeur OCSP à utiliser au cours de la validationdu certificat du répondeur OCSP. Les certificats fournis peuventêtre considérés comme de confiance sans avoir à effectuer de vérificationssupplémentaires. Ce processus de validation du certificat du répondeur OCSPintervient en général lorsque ce dernier est autosigné ou tout simplement absentde la réponse OCSP.

DirectiveSSLOCSPResponderTimeout

Cette option permet de définir le délai d'attente pour les requêtes àdestination des répondeurs OCSP, lorsque la directiveSSLOCSPEnable est à on.

DirectiveSSLOCSPResponseMaxAge

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, lesréponses OCSP sont considérées comme valides tant que la valeur de leurchampnextUpdate se situe dans le futur.

DirectiveSSLOCSPResponseTimeSkew

Cette option permet de définir la dérive temporelle maximaleautorisée pour les réponses OCSP (lors de la vérification des champsthisUpdate etnextUpdate).

DirectiveSSLOCSPUseRequestNonce

La documentation de cette directiven'a pas encore t traduite. Veuillez vous reporter la versionen langue anglaise.

DirectiveSSLOpenSSLConfCmd

Cette directive permet à mod_ssl d'accéder à l'APISSL_CONFd'OpenSSL. Il n'est ainsi plus nécessaire d'implémenter desdirectives supplémentaires pourmod_ssl lorsque de nouvellesfonctionnalités sont ajoutées à OpenSSL, ce qui rend la configuration dece dernier beaucoup plus souple.

Le jeu de commandes disponibles pour la directiveSSLOpenSSLConfCmd dépend de la version d'OpenSSLutilisée pourmod_ssl (la version minimale 1.0.2 est unprérequis). Pour obtenir la liste des commandes supportées, voir lasectionSupported configuration file commands de la page demanuel d'OpenSSLSSL_CONF_cmd(3).

Certaines commandes peuvent remplacer des directives existantes(commeSSLCipherSuite ouSSLProtocol) ; notez cependantque la syntaxe et/ou les valeurs possibles peuvent différer.

SSLOpenSSLConfCmd Options -SessionTicket,ServerPreferenceSSLOpenSSLConfCmd ECDHParameters brainpoolP256r1SSLOpenSSLConfCmd ServerInfoFile"/usr/local/apache2/conf/server-info.pem"SSLOpenSSLConfCmd Protocol "-ALL, TLSv1.2"SSLOpenSSLConfCmd SignatureAlgorithms RSA+SHA384:ECDSA+SHA256

DirectiveSSLOptions

Cette directive permet de contrôler différentes options d'exécution dumoteur SSL dans un contexte de répertoire. Normalement, si plusieursSSLOptions peuvent s'appliquer à un répertoire, c'est laplus spécifique qui est véritablement prise en compte ; les options nese combinent pas entre elles. Elles se combinent cependant entre ellessi elles sonttoutes 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 touteoption précédée d'un- est supprimée de ces mêmesoptions.

Lesoptions 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 etSSL_CLIENT_CERT_CHAIN_n (avecn = 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 OpenSSLopenssl x509 :openssl x509 -noout -subject -incertificat.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 directiveAuthBasicFake implémentée par le modulemod_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 optionforce l'interdiction d'accès lorsqueSSLRequireSSL ouSSLRequire 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 ouSSLRequire (parce que c'est ainsi que le mécanismeSatisfy d'Apache doit fonctionner). Pour des restrictions d'accès plus strictes, vous pouvez cependant utiliserSSLRequireSSL et/ouSSLRequire 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é, etchaque reconfiguration des paramètres SSL au niveau du répertoire implique une phase de renégociation SSLcomplè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 variablesSSL_{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'optionLegacyDNStringFormat 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>

DirectiveSSLPassPhraseDialog

Lors de son démarrage, Apache doit lire les différents fichiers decertificats (voir la directiveSSLCertificateFile) et de clés privées(voir la directiveSSLCertificateKeyFile) des serveursvirtuels où SSL est activé. Comme, pour des raisons de sécurité, lesfichiers de clés privées sont en général chiffrés, mod_ssl doitdemander à l'administrateur un mot de passe pour déchiffrer cesfichiers. L'argumenttype permet de choisir la manière dontcette 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, vouspouvez 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 modebuiltin est envoyé au programme surstdin, et celui-ci doit renvoyer des mots de passe surstdout. 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 surstdout. 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 surstdout. 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"

DirectiveSSLProtocol

Cette directive permet de définir quelles versions du protocole SSL/TLSseront acceptées lors de l'initialisation d'une nouvelle connexion.

Lesprotocoles disponibles sont les suivants (sensibles à lacasse) :

• 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, mais est considéré comme obsolète dans laRFC 7568

• TLSv1

  Il s'agit du protocole Transport Layer Security (TLS) version 1.0. C'est le successeur de SSLv3, et il est défini dans laRFC2246. 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 laRFC 4346.

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

  Une révision du protocole TLS 1.1 définie dans laRFC 5246.

• TLSv1.3 (à partir de la version 1.1.1 d'OpenSSL)

  Une nouvelle version du protocole TLS définie dans laRFC 8446.

• all

  C'est un raccourci pour ``+SSLv3 +TLSv1'' ou - à partir de la version 1.0.1 d'OpenSSL - ``+SSLv3 +TLSv1 +TLSv1.1 +TLSv1.2'' (sauf si OpenSSL a été compilé avec l'option ``no-ssl3'', auquel casall n'inclura pas+SSLv3).

SSLProtocol TLSv1

DirectiveSSLProxyCACertificateFile

Cette directive permet de définir le fichiertout-en-un où sontstockés les certificats des Autorités de Certification (CA) pour lesserveurs distants auxquels vous avez à faire. On les utiliselors de l'authentification du serveur distant. Un tel fichier contientla simple concaténation des différents fichiers de certificats codés enPEM, classés par ordre de préférence. On peut utiliser cette directive àla place et/ou en complément de la directiveSSLProxyCACertificatePath.

SSLProxyCACertificateFile"/usr/local/apache2/conf/ssl.crt/ca-bundle-serveur.distant.crt"

DirectiveSSLProxyCACertificatePath

Cette directive permet de spécifier le répertoire où sont stockés lescertificats des Autorités de Certification (CAs) pour les serveursdistants auxquels vous avez à faire. On les utilise pour vérifier lecertificat du serveur distant lors de l'authentification de cedernier.

Les fichiers de ce répertoire doivent être codés en PEM et ils sontaccédés via des noms de fichier sous forme de condensés ou hash. Il nesuffit donc pas de placer les fichiers de certificats dans ce répertoire: vous devez aussi créer des liens symboliques nommésvaleur-de-hashage.N, et vous devez toujours vousassurer que ce répertoire contient les liens symboliques appropriés.

SSLProxyCACertificatePath "/usr/local/apache2/conf/ssl.crt/"

DirectiveSSLProxyCARevocationCheck

Active la vérification des révocations basée sur les Listes derévocations de Certificats (CRL) pour lesserveurs distantsauxquels vous vous connectez. A moins une des directivesSSLProxyCARevocationFile ouSSLProxyCARevocationPath doit être définie.Lorsque cette directive est définie àchain (valeurrecommandée), les vérifications CRL sont effectuées sur tous lescertificats de la chaîne, alors que la valeurleaf limitela vérification au certificat hors chaîne (la feuille).

SSLProxyCARevocationCheck chain

DirectiveSSLProxyCARevocationFile

Cette directive permet de définir le fichiertout-en-un où sontrassemblées les Listes de Révocation de Certificats (CRLs) des Autoritésde certification (CAs) pour lesserveurs distants auxquels vousavez à faire. On les utilise pour l'authentification des serveursdistants. Un tel fichier contient la simple concaténation des différentsfichiers de CRLs codés en PEM, classés par ordre de préférence. Cettedirective peut être utilisée à la place et/ou en complément de ladirectiveSSLProxyCARevocationPath.

SSLProxyCARevocationFile"/usr/local/apache2/conf/ssl.crl/ca-bundle-serveur.distant.crl"

DirectiveSSLProxyCARevocationPath

Cette directive permet de définir le répertoire où sont stockées lesListes de Révocation de Certificats (CRL) des Autorités de Certification(CAs) pour les serveurs distants auxquels vous avez à faire. On lesutilise pour révoquer les certificats des serveurs distants au cours del'authentification de ces derniers.

Les fichiers de ce répertoire doivent être codés en PEM et ils sontaccédés via des noms de fichier sous forme de condensés ou hash. Il nesuffit donc pas de placer les fichiers de CRL dans ce répertoire: vous devez aussi créer des liens symboliques nommésvaleur-de-hashage.rN, et vous devez toujours vousassurer que ce répertoire contient les liens symboliques appropriés.

SSLProxyCARevocationPath "/usr/local/apache2/conf/ssl.crl/"

DirectiveSSLProxyCheckPeerCN

Cette directive permet de définir si le champ CN du certificat du serveurdistant doit être comparé au nom de serveur de l'URL de la requête. S'ils necorrespondent pas, un code d'état 502 (Bad Gateway) est envoyé. A partir de laversion 2.4.5, SSLProxyCheckPeerCN a été remplacé parSSLProxyCheckPeerName.

De la version 2.4.5 à la version 2.4.20, spécifierSSLProxyCheckPeerNameoff était suffisant pour obtenir ce comportement (car la valeur pardéfaut deSSLProxyCheckPeerCN étaiton). Avec cesversions, les deux directives doivent être définies àoff pouréviter toute validation du nom de certificat du serveur distant, et denombreux utilisateurs ont signalé ce comportement comme très perturbant.

A partir de la version 2.4.21, toutes les configurations qui activent au moinsune des deux directivesSSLProxyCheckPeerName ouSSLProxyCheckPeerCN adopteront le nouveau comportement de ladirectiveSSLProxyCheckPeerName, ettoutes les configurations qui désactivent une des deux directivesSSLProxyCheckPeerName ouSSLProxyCheckPeerCNéviteront toute validation du nom de certificat du serveur distant. Seule laconfiguration suivante permettra de retrouver la comparaison de CNtraditionnelle pour les versions 2.4.21 et supérieures :

SSLProxyCheckPeerCN onSSLProxyCheckPeerName off

DirectiveSSLProxyCheckPeerExpire

Cette directive permet de définir si l'expiration du certificat duserveur distant doit être vérifiée ou non. Si la vérification échoue, uncode d'état 502 (Bad Gateway) est envoyé.

SSLProxyCheckPeerExpire on

DirectiveSSLProxyCheckPeerName

Cette directive permet de configurer la vérification du nom d'hôte pourles certificats serveur lorsque mod_ssl agit en tant que client SSL. Lavérification réussit si le nom d'hôte de l'URI de la requête correspond à undes attributs CN du sujet du certificat, ou à l'extension subjectAltName. Si lavérification échoue, la requête SSLavorte, et un code d'erreur 502 (Bad Gateway) est renvoyé.

Les caractères génériques sont supportés dans certains cas bien spécifiques :une entrée subjectAltName de type dNSName ou les attributs CNcommençant par*. correspondront à tout nom d'hôte comportantle même nombre de champs et le même suffixe ; par exemple,*.example.org correspondra àfoo.example.org,mais pas àfoo.bar.example.org car le nombre d'éléments dans lesnom est différent.

Cette fonctionnalité a été introduite avec la version 2.4.5 et l'emporte sur ladirectiveSSLProxyCheckPeerCN qui necomparait que la valeur exacte du premier attribut CN avec le nom d'hôte.Cependant, de nombreux utilisateurs étaient déconcertés par le comportementinduit par l'utilisation de ces deux directives individuellement, si bien que cecomportement a été amélioré avec la version 2.4.21. Voir la description de ladirectiveSSLProxyCheckPeerCN pour lecomportement original et des détails à propos de ces améliorations.

DirectiveSSLProxyCipherSuite

Cette directive est équivalente à la directiveSSLCipherSuite, mais s'applique à une connexion demandataire. Veuillez vous reporter à la directiveSSLCipherSuite pour plus d'informations.

DirectiveSSLProxyEngine

Cette directive permet d'activer/désactiver l'utilisation du moteur deprotocole SSL/TLS pour le mandataire. On l'utilise en général àl'intérieur d'une section<VirtualHost> pour activer le protocole SSL/TLSdans le cadre d'un mandataire pour un serveur virtuel particulier. Pardéfaut, le moteur de protocole SSL/TLS est désactivé pour la fonction demandataire du serveur principal et de tous les serveurs virtuelsconfigurés.

Notez que la directiveSSLProxyEngine ne doitgénéralement pas être utilisée dans le cadre d'un serveur virtuel qui agit entant que mandataire direct (via les directives<Proxy> ouProxyRequests).SSLProxyEngine n'est pas nécessaire pour activer unserveur mandataire direct pour les requêtes SSL/TLS.

<VirtualHost _default_:443>    SSLProxyEngine on    #...</VirtualHost>

DirectiveSSLProxyMachineCertificateChainFile

Cette directive permet de définir le fichier global où est enregistréela chaîne de certification pour tous les certificats clients utilisés.Elle est nécessaire si le serveur distant présente une liste decertificats de CA qui ne sont pas les signataires directs d'un descertificats clients configurés.

Ce fichier contient tout simplement la concaténation des différentsfichiers de certificats encodés PEM. Au démarrage, chaque certificatclient configuré est examiné et une chaîne de certification estconstruite.

SSLProxyMachineCertificateChainFile"/usr/local/apache2/conf/ssl.crt/proxyCA.pem"

DirectiveSSLProxyMachineCertificateFile

Cette directive permet de définir le fichier tout-en-un où sont stockésles clés et certificats permettant au serveur mandataire des'authentifier auprès des serveurs distants.

Le fichier spécifié est la simple concaténation des différents fichiers decertificats codés en PEM. Cette directive s'utilise à la place ou en complémentde la directiveSSLProxyMachineCertificatePath. Le fichier spécifiépeut contenir un nombre quelconque de paires certificat client/clé privéeassociée, et chaque paire peut être spécifiée selon l'ordre (certificat, clé) ou(clé, certificat). Des certificats non-feuilles (CA) peuvent aussi être inclusdans le fichier et sont traités comme s'ils avaient été définis à l'aide de ladirectiveSSLProxyMachineCertificateChainFile.

Lorsqu'un serveur distant sollicite le serveur pour obtenir un certificatclient, ce dernier doit fournir une liste denoms d'autorités decertification acceptables au cours de la négociation. Si cette liste n'estpas fournie,mod_ssl utilisera la première paire certificat/cléclient définie. Si par contre cette listeest fournie,mod_ssl va la parcourir afin de trouver un certificat clientdéfini qui a été fourni soit directement par l'autorité de certificationconsidérée, soit indirectement via un nombre quelconque de certificats d'autorités decertification intermédiaires. La chaîne de certificats d'autorités decertification intermédiaires peut être construite à partir de ceux qui sontinclus dans le fichier ou configurésà l'aide de la directiveSSLProxyMachineCertificateChainFile. Le premiercertificat défini correspondant sera alors fourni comme réponse au cours de lanégociation

Si la liste de noms de CAest fournie au serveur distant, et siaucun certificat client correspondant n'est trouvé, aucun certificatclient ne sera fourni parmod_ssl, ce qui fera probablementéchouer la négociation SSL/TLS (en fonction de la configuration du serveurdistant).

SSLProxyMachineCertificateFile"/usr/local/apache2/conf/ssl.crt/proxy.pem"

DirectiveSSLProxyMachineCertificatePath

Cette directive permet de définir le répertoire où sont stockés les cléset certificats clients permettant au serveur mandataire de s'authentifier auprèsdes serveurs distants.

mod_ssl va essayer de charger tous les fichiers contenus dans le répertoirespécifié, comme si ces derniers étaient définis individuellement via ladirectiveSSLProxyMachineCertificateFile.

SSLProxyMachineCertificatePath "/usr/local/apache2/conf/proxy.crt/"

DirectiveSSLProxyProtocol

Cette directive permet de définir les protocoles SSL que mod_ssl peututiliser lors de l'élaboration de son environnement de serveur pour lafonction de mandataire. Il ne se connectera qu'aux serveurs utilisant undes protocoles spécifiés.

Veuillez vous reporter à la directiveSSLProtocol pour plus d'informations.

DirectiveSSLProxyVerify

Lorsqu'un mandataire est configuré pour faire suivre les requêtesvers un serveur SSL distant, cette directive permet de configurer lavérification du certificat de ce serveur distant.

Les valeurs deniveaux disponibles sont les suivantes :

• none: aucun certificat n'est requis pour le serveur distant
• optional: le serveur distantpeut présenter un certificat valide
• require: le serveur distantdoit présenter un certificat valide
• optional_no_ca: le serveur distant peut présenter un certificat valide
  mais il n'est pas nécessaire qu'il soit vérifiable (avec succès).

En pratique, seuls les niveauxnone etrequire sont vraiment intéressants, car le niveauoptional ne fonctionne pas avec tous les serveurs, etle niveauoptional_no_ca va tout à fait à l'encontre del'idée que l'on peut se faire de l'authentification (mais peut tout demême être utilisé pour établir des pages de test SSL, etc...).

SSLProxyVerify require

DirectiveSSLProxyVerifyDepth

Cette directive permet de définir le niveau de profondeur maximumjusqu'auquel mod_ssl doit aller au cours de sa vérification avant dedécider que le serveur distant ne possède pas de certificat valide.

La profondeur correspond en fait au nombre maximum de fournisseurs decertificats intermédiaires, c'est à dire le nombre maximum decertificatsde CA que l'on peut consulter lors de la vérification du certificat duserveur distant. Une profondeur de 0 signifie que seuls les certificatsde serveurs distants auto-signés sont acceptés, et la profondeur pardéfaut de 1 que le certificat du serveur distant peut être soitauto-signé, soit signé par une CA connue directement du serveur (end'autres termes, le certificat de CA est référencé par la directiveSSLProxyCACertificatePath),etc...

SSLProxyVerifyDepth 10

DirectiveSSLRandomSeed

Cette directive permet de définir une ou plusieurs sources dedéclenchement du Générateur de Nombres Pseudo-Aléatoires (PRNG) dansOpenSSL au démarrage du serveur (sicontexte a pour valeurstartup) et/ou juste avant l'établissement d'une nouvelleconnexion SSL (sicontexte a pour valeurconnect).Cette directive ne peut être utilisée qu'au niveau du serveur global carle PRNG est un service global.

Les différentes valeurs desource 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 un extrait de 128 octets aléatoirement choisi dans la pile. 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 externefile:/chemin/vers/source comme source de déclenchement du PRNG. Lorsquenombre est spécifié, seuls lesnombre premiers octets du fichier forment l'entropie (etnombre est fourni comme premier argument à/chemin/vers/source). Lorsquenombre n'est pas spécifié, l'ensemble du fichier forme l'entropie (et0 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. Lorsquenombre est spécifié, seules lesnombre premiers octets de son fluxstdout forment l'entropie. Lorsquenombre n'est pas spécifié, l'intégralité des données produites surstdout 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'utilitairetruerand basé sur la bibliothèquetruerand 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 (voirhttp://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 builtinSSLRandomSeed startup "file:/dev/random"SSLRandomSeed startup "file:/dev/urandom" 1024SSLRandomSeed startup "exec:/usr/local/bin/truerand" 16SSLRandomSeed connect builtinSSLRandomSeed connect "file:/dev/random"SSLRandomSeed connect "file:/dev/urandom" 1024

DirectiveSSLRenegBufferSize

Si une renégociation SSL est requise dans un contexte de répertoire,par exemple avec l'utilisation deSSLVerifyClient dans un bloc Directory ouLocation, mod_ssl doit mettre en tampon en mémoire tout corps de requêteHTTP 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.

SSLRenegBufferSize 262144

DirectiveSSLRequire

Cette directive permet de spécifier une condition générale d'accèsqui 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éeest une expression booléenne complexe et arbitraire contenant un nombrequelconque de vérifications quant aux autorisations d'accès.

L'expression doit respecter la syntaxe suivante (fournie icisous la forme d'une notation dans le style de la grammaire BNF) :

expr     ::= "true" | "false"           | "!" expr           | expr "&&" expr           | expr "||" expr           | "(" expr ")"           | compcomp     ::= 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 "!~" regexwordlist ::= word           | wordlist "," wordword     ::= digit           | cstring           | variable           | functiondigit    ::= [0-9]+cstring  ::= "..."variable ::= "%{" varname "}"function ::= funcname "(" funcargs ")"

Pourvarname, toute variable décrite dansVariables d'environnement pourra être utilisée.Pourfuncname, vous trouverez la liste des fonctionsdisponibles dans ladocumentationap_expr.

expression est interprétée et traduitesous une forme machine interne lors du chargement de la configuration,puis évaluée lors du traitement de la requête. Dans le contexte desfichiers .htaccess,expression est interprétée et exécutéechaque fois que le fichier .htaccess intervient lors du traitement de larequê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 fonctionPeerExtList(identifiant objet)recherche une instance d'extension de certificat X.509 identifiée paridentifiant 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 plusieursextensions possèdent le même OID, l'une d'entre elles au moins doitcorrespondre).

SSLRequire "foobar" in PeerExtList("1.2.3.4.5.6")

Voir aussi

• Les variables d'environnement dans leserveur HTTP Apache, pour d'autres exemples.
• Require expr
• Syntaxe générale des expressions dans leserveur HTTP Apache

DirectiveSSLRequireSSL

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 dansun serveur virtuel où SSL est activé ou dans un répertoire pour seprotéger des erreurs de configuration qui pourraient donner accès à desressources protégées. Lorsque cette directive est présente, toutes lesrequêtes qui n'utilisent pas SSL sont rejetées.

SSLRequireSSL

DirectiveSSLSessionCache

Cette directive permet de configurer le type de stockage du cache desession SSL global et inter-processus. Ce cache est une fonctionnalitéoptionnelle qui accélère le traitement parallèle des requêtes. Pour cequi est des requêtes vers un même processus du serveur (via HTTPkeep-alive), OpenSSL met en cache les informations de session SSL eninterne. Mais comme les clients modernes demandent des images en ligneet d'autres données via des requêtes parallèles (un nombre de quatrerequêtes parallèles est courant), ces requêtes vont être servies parplusieurs processus du serveur pré-déclenchés. Ici, un cacheinter-processus permet d'éviter des négociations de sessioninutiles.

Les quatretypes de stockage suivants sont actuellementsupporté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 modulemod_socache_dbm doit être chargé.

• shmcb:/chemin/vers/fichier-données[(nombre)]

  Cette valeur utilise un tampon cyclique à hautes performances (d'une taille d'environnombre 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 modulemod_socache_shmcb doit être chargé.

• dc:UNIX:/chemin/vers/socket

  Cette valeur utilise les bibliothèques de mise en cache de sessions distribuée surdistcache. 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 modulemod_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 mutexssl-cache permet de sérialiser l'accès au cachede session afin d'éviter toute corruption. Ce mutex peut être configurévia la directiveMutex.

DirectiveSSLSessionCacheTimeout

Cette directive permet de définir la durée de vie en secondes desinformations stockées dans le cache de sessions SSL global etinter-processus, dans le cache OpenSSL interne en mémoire et pourles 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 à unevaleur très supérieure comme 300 en production.

SSLSessionCacheTimeout 600

DirectiveSSLSessionTicketKeyFile

Cette directive permet de définir une clé secrète pour le chiffrementet le déchiffrement des tickets de session TLS selon les préconisationsde laRFC 5077. Elle aété conçue à l'origine pour les environnements de clusters où lesdonnées des sessions TLS doivent être partagées entre plusieurs noeuds.Pour les configurations ne comportant qu'une seule instance de httpd, ilest préférable d'utiliser les clés (aléatoires) générées par mod_ssl audémarrage du serveur.

Le fichier doit contenir 48 octets de données aléatoires créées depré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èresuivante :

Ces clés doivent être renouvelées fréquemment, car il s'agit du seulmoyen d'invalider un ticket de session existant - OpenSSL ne permet pasactuellement de spécifier une limite à la durée devie des tickets. Une nouvelle clé ne peut être utilisée qu'après avoirredémarré le serveur. Tous les tickets de session existants deviennentinvalides après le redémarrage du serveur.

DirectiveSSLSessionTickets

Cette directive permet d'activer ou de désactiver l'utilisation destickets de session TLS (RFC 5077).

DirectiveSSLSRPUnknownUserSeed

Cette directive permet de définir la source d'aléa à utiliserpour les utilisateurs SRP inconnus, ceci afin de combler les manques encas d'existence d'un tel utilisateur. Elle définit une chaîne secrète. Sicette directive n'est pas définie, Apache renverra une alerteUNKNOWN_PSK_IDENTITY aux clients qui fournissent un nom d'utilisateurinconnu.

DirectiveSSLSRPVerifierFile

Cette directive permet d'activer TLS-SRP et de définir le chemin dufichier 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.

Le fichier de vérification peut être créé via l'utilitaire en ligne decommandeopenssl :

La valeur affectée au paramètre optionnel-userinfo estenregistrée dans la variable d'environnementSSL_SRP_USERINFO.

DirectiveSSLStaplingCache

SiSSLUseStapling est à "on",cette directive permet de configurer le cache destiné à stocker lesréponses OCSP incluses dans la négociation TLS. La configuration d'uncache est obligatoire pour pouvoir utiliser l'agrafage OCSP. Al'exception denone etnonenotnull, cettedirective supporte les mêmes types de stockage que la directiveSSLSessionCache.

DirectiveSSLStaplingErrorCacheTimeout

Cette directive permet de définir la durée de vie des réponsesinvalides dans le cache pour agrafage OCSP configuré via ladirectiveSSLStaplingCache. Pourdéfinir la durée de vie des réponses valides, voir la directiveSSLStaplingStandardCacheTimeout.

DirectiveSSLStaplingFakeTryLater

Lorsque cette directive est activée, et si une requête vers unserveur 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 êtreactivée).

DirectiveSSLStaplingForceURL

Cette directive permet de remplacer l'URI du serveur OCSP extraite del'extension authorityInfoAccess (AIA) du certificat. Elle peut s'avérerutile lorsqu'on passe par un mandataire

DirectiveSSLStaplingResponderTimeout

Cette directive permet de définir le temps d'attente maximum lorsquemod_ssl envoie une requête vers un serveur OCSP afin d'obtenir uneréponse destinée à être incluse dans les négociations TLS avec lesclients (SSLUseStapling doitavoir été activée au préalable).

DirectiveSSLStaplingResponseMaxAge

Cette directive permet de définir l'âge maximum autorisé("fraîcheur") des réponses OCSP incluses dans la négociation TLS(SSLUseStapling doitavoir é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 sontconsidérées comme valides à partir du moment où le contenu de leur champnextUpdate se trouve dans le futur.

DirectiveSSLStaplingResponseTimeSkew

Cette directive permet de spécifier l'intervalle de temps maximum quemod_ssl va calculer en faisant la différence entre les contenus deschampsnextUpdate etthisUpdate des réponsesOCSP incluses dans la négociation TLS. Pour pouvoir utiliser cettedirective,SSLUseStapling doitêtre à "on".

DirectiveSSLStaplingReturnResponderErrors

Lorsque cette directive est activée, mod_ssl va transmettre au client lesréponses concernant les requêtes OCSPéchouées (comme les réponses avec un statut général autre que"successful", les réponses avec un statut de certificat autre que"good", les réponses arrivées à expiration, etc...). Lorsqu'elle est àoff, seules les réponses avec unstatut de certificat égal à "good" seront incluses dans la négociationTLS.

DirectiveSSLStaplingStandardCacheTimeout

Cette directive permet de définir la durée de vie des réponses OCSPdans le cache configuré via la directiveSSLStaplingCache. Elle ne s'applique qu'auxréponsevalides, alors que la directiveSSLStaplingErrorCacheTimeout s'applique auxréponses invalides ou non disponibles.

DirectiveSSLStrictSNIVHostCheck

Cette directive permet de contrôler l'accès des clients non-SNI à un serveurvirtuel à base de nom. Si elle est définie àon dans leserveur virtuel à base de nom par défaut, lesclients non-SNI ne seront autorisés à accéder à aucun serveur virtuelappartenant à cette combinaison IP/port. Parcontre, si elle est définie àon dans un serveur virtuelquelconque, les clients non-SNI ne se verront interdire l'accès qu'à ceserveur.

SSLStrictSNIVHostCheck on

DirectiveSSLUserName

Cette variable permet de définir le champ "user" de l'objet de larequête Apache. Ce champ est utilisé par des modules de plus bas niveaupour identifier l'utilisateur avec une chaîne de caractères. Enparticulier, l'utilisation de cette directive peut provoquer ladéfinition de la variable d'environnementREMOTE_USER.La valeur de l'argumentnom-var peut correspondre à toutevariable d'environnement SSL.

Notez que cette directive est sans effet si l'optionFakeBasicAuth est utilisée (voirSSLOptions).

SSLUserName SSL_CLIENT_S_DN_CN

DirectiveSSLUseStapling

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 ledemande, mod_ssl va inclure une réponse OCSP à propos de son proprecertificat dans la négociation TLS. Pour pouvoir activer l'AgrafageOCSP, il est nécessaire de configurer unSSLStaplingCache.

L'agrafage OCSP dispense le client de requérir le serveur OCSPdirectement ; il faut cependant noter que selon les spécifications de laRFC 6066, la réponseCertificateStatus du serveur ne peutinclure une réponse OCSP que pour un seul certificat. Pour lescertificats de serveur comportant des certificats de CA intermédiairesdans leur chaîne (c'est un cas typique de nos jours), l'implémentationactuelle 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 laRFC 6961 (TLSMultiple Certificate Status Extension).

Lorsque l'agrafage OCSP est activé, le mutexssl-stapling contrôle l'accès au cache de l'agrafage OCSPafin de prévenir toute corruption, et le mutexsss-stapling-refresh contrôle le raffraîchissement desréponses OCSP. Ces mutex peuvent être configurés via la directiveMutex.

DirectiveSSLVerifyClient

Cette directive permet de définir le niveau de vérification ducertificat pour l'authentification du client. Notez que cette directivepeut être utilisée à la fois dans les contextes du serveur principal etdu répertoire. Dans le contexte du serveur principal, elle s'applique auprocessus d'authentification du client utilisé au cours de lanégociation SSL standard lors de l'établissement d'une connexion. Dansun contexte de répertoire, elle force une renégociation SSL avec leniveau de vérification du client spécifié, après la lecture d'unerequête HTTP, mais avant l'envoi de la réponse HTTP.

Les valeurs deniveau disponibles sont les suivantes :

• none: aucun certificat client n'est requis
• optional: le clientpeut présenter un certificat valide
• require: le clientdoit présenter un certificat valide
• optional_no_ca: le client peut présenter un certificat valide, mais il n'est pas nécessaire que ce dernier soit vérifiable (avec succès). Cette option ne peut pas être utilisée lors de l'authentification du client.

SSLVerifyClient require

DirectiveSSLVerifyDepth

Cette directive permet de spécifier la profondeur maximale à laquellemod_ssl va effectuer sa vérification avant de décider que le client nepossède pas de certificat valide. Notez que cette directive peut êtreutilisée à la fois dans les contextes du serveur principal et derépertoire. Dans le contexte du serveur principal, elle s'applique auprocessus d'authentification du client utilisé au cours de lanégociation SSL standard lors de l'établissement d'une connexion. Dansun contexte de répertoire, elle force une renégociation SSL avec leclient selon la nouvelle profondeur spécifiée, après la lecture d'unerequête HTTP, mais avant l'envoi de la réponse HTTP.

La profondeur correspond au nombre maximum de fournisseurs decertificats intermédiaires, c'est à dire le nombre maximum decertificats de CA que l'on est autorisé à suivre lors de la vérificationdu certificat du client. Une profondeur de 0 signifie que seuls lescertificats clients auto-signés sont acceptés ; la profondeur par défautde 1 signifie que le certificat client peut être soit auto-signé, soitsigné par une CA connue directement du serveur (c'est à dire que lecertificat de la CA doit être référencé par la directiveSSLCACertificatePath), etc...

SSLVerifyDepth 10

DirectiveSSLVHostSNIPolicy

Cette directive permet de définir la politique à appliquer lors de lavérification de la compatibilité du<serveur virtuel> identifié par l’en-têteHost d’une requête HTTP avec le<serveur virtuel> identifié depuis l’extension SNIenvoyée au cours de la négociation de la connexion TLS initiale. Si une requêteHTTP est associée à un serveur virtuel comportant une configuration SSL/TLSincompatible selon la politique utilisée, un message d’erreur HTTP avec coded’état 421 ("Misdirected Request") sera envoyé.

La politique s’applique aussi aux connexions TLS pour lesquelles uneextension SNI n’est pas envoyée lors de la négociation de connexion, etutilisant la première définition de serveur virtuel ou la définition par défaut.Si l’en-tête Host d’une requête HTTP sur une telle connexion identifie unserveur virtuel autre que celui par défaut, la politique de compatibilité seratestée.

La politiquestrict bloque toute requête HTTP associée à unserveur virtuel différent de celui identifié par SNI. La politiqueinsecure autorise toute requête, quel que soit le serveur virtuelassocié ; une telle configuration pourra être vulnérable àCVE-2025-23048.

Les politiquessecure (politique par défaut) etauthonly comparent certains aspects spécifiques des deux serveursvirtuels, qui sont regroupés en deux catégories :

• certificat/clé de serveur ou restrictions de protocole/algorithme de chiffrement : directives qui déterminent le certificat ou la clé du serveur (SSLCertificateKeyFile, etc.), restrictions de protocole ou d’algorithme de chiffrement (SSLProtocol etSSLCipherSuite)
• configuration de la certification et de l’authentification du client : directives qui affectent l’authentification du client et la vérification de son certificat via TLS, telles queSSLVerifyClient,SSLVerifyMode,SSLCACertificatePath,SSLSRPVerifierFile; toute utilisation deSSLOpenSSLConfCmd

Le tableau suivant indique quand une requête HTTP sera bloquée ou autoriséelorsque les configurations des serveurs virtuels diffèrent de la manièredécrite, et en fonction des différentes politiques utilisées :

SSLVHostSNIPolicy authonly