Module Apache mod_ssl

SSLCACertificateFile Directive

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

SSLCACertificatePath Directive

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/

SSLCADNRequestFile Directive

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

SSLCADNRequestPath Directive

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/

SSLCARevocationCheck Directive

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

SSLCARevocationCheck chain

SSLCARevocationFile Directive

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

SSLCARevocationPath Directive

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/

SSLCertificateChainFile Directive

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

SSLCertificateFile Directive

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.

SSLCertificateFile /usr/local/apache2/conf/ssl.crt/server.crt

SSLCertificateKeyFile Directive

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

SSLCipherSuite Directive

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 :

• 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 or SHA1, SHA256, SHA384.

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.

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 :

• none: ajoute l'algorithme � la liste
• +: 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)

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

SSLCompression Directive

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

SSLCryptoDevice Directive

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

SSLEngine Directive

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.

SSLFIPS Directive

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.

SSLHonorCipherOrder Directive

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

SSLInsecureRenegotiation Directive

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

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.

SSLOCSPDefaultResponder Directive

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.

SSLOCSPEnable Directive

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

SSLOCSPOverrideResponder Directive

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.

SSLOCSPResponderTimeout Directive

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.

SSLOCSPResponseMaxAge Directive

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.

SSLOCSPResponseTimeSkew Directive

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

SSLOCSPUseRequestNonce Directive

La documentation de cette directive n'a pas encore t traduite. Veuillez vous reporter la version en langue anglaise.

SSLOpenSSLConfCmd Directive

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

SSLOptions Directive

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>

SSLPassPhraseDialog Directive

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

SSLProtocol Directive

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

SSLProxyCACertificateFile Directive

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

SSLProxyCACertificatePath Directive

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/

SSLProxyCARevocationCheck Directive

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

SSLProxyCARevocationCheck chain

SSLProxyCARevocationFile Directive

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

SSLProxyCARevocationPath Directive

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/

SSLProxyCheckPeerCN Directive

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

SSLProxyCheckPeerExpire Directive

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

SSLProxyCheckPeerName Directive

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

SSLProxyCipherSuite Directive

Cette directive est �quivalente � la directive SSLCipherSuite, mais s'applique � une connexion de mandataire. Veuillez vous reporter � la directive SSLCipherSuite pour plus d'informations.

SSLProxyEngine Directive

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>

SSLProxyMachineCertificateChainFile Directive

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.

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

SSLProxyMachineCertificateFile Directive

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.

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

SSLProxyMachineCertificatePath Directive

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.

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

SSLProxyProtocol Directive

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.

SSLProxyVerify Directive

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 :

• none: aucun certificat n'est requis pour le serveur distant
• optional: le serveur distant peut pr�senter un certificat valide
• require: le serveur distant doit 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 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

SSLProxyVerifyDepth Directive

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

SSLRandomSeed Directive

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

SSLRenegBufferSize Directive

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.

SSLRenegBufferSize 262144

SSLRequire Directive

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

Voir aussi

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

SSLRequireSSL Directive

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

SSLSessionCache Directive

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.

SSLSessionCacheTimeout Directive

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

SSLSessionTicketKeyFile Directive

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 :

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.

SSLSRPUnknownUserSeed Directive

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.

SSLSRPVerifierFile Directive

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.

Le fichier de v�rification peut �tre cr�� via l'utilitaire en ligne de commande openssl :

La valeur affect�e au param�tre optionnel -userinfo est enregistr�e dans la variable d'environnement SSL_SRP_USERINFO.

SSLStaplingCache Directive

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.

SSLStaplingErrorCacheTimeout Directive

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.

SSLStaplingFakeTryLater Directive

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

SSLStaplingForceURL Directive

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

SSLStaplingResponderTimeout Directive

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

SSLStaplingResponseMaxAge Directive

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.

SSLStaplingResponseTimeSkew Directive

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

SSLStaplingReturnResponderErrors Directive

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.

SSLStaplingStandardCacheTimeout Directive

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.

SSLStrictSNIVHostCheck Directive

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.

SSLStrictSNIVHostCheck on

SSLUserName Directive

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

SSLUseStapling Directive

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

SSLVerifyClient Directive

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 :

• none: aucun certificat client n'est requis
• optional: le client peut pr�senter un certificat valide
• require: le client doit 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).

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

SSLVerifyDepth Directive

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