Module Apache mod_ssl

Directive SSLCACertificateFile

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"

Directive SSLCACertificatePath

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

Directive SSLCADNRequestFile

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"

Directive SSLCADNRequestPath

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

Directive SSLCARevocationCheck

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

flags peut prendre comme valeurs

• no_crl_for_cert_ok

  Avant la version 2.3.15, les vérifications CRL dans mod_ssl réussissaient même si aucune CRL n'était trouvée dans les chemins définis par les directives SSLCARevocationFile ou SSLCARevocationPath.

  Le comportement a changé avec l'introduction de la directive SSLCARevocationFile : par défaut avec chain ou leaf, les CRLs doivent être présentes pour que la validation réussisse ; dans le cas contraire, elle échouera avec une erreur "unable to get certificate CRL".

  La valeur no_crl_for_cert_ok du drapeau flag permet de retrouver le comportement précédent.

SSLCARevocationCheck chain

SSLCARevocationCheck chain no_crl_for_cert_ok

Directive SSLCARevocationFile

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"

Directive SSLCARevocationPath

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

Directive SSLCertificateChainFile

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"

Directive SSLCertificateFile

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). La directive peut être utilisée plusieurs fois (elle référence des fichiers différents) pour accepter plusieurs algorithmes d'authentification au niveau du serveur - souvent RSA, DSA et ECC. Le nombre d'algorithmes supportés dépend de la version d'OpenSSL utilisée avec mod_ssl : à partir de la version 1.0.0, la commande openssl list-public-key-algorithms affiche la liste des algorithmes supportés. Voir aussi la note ci-dessous à propos des limitations des versions d'OpenSSL antérieures à 1.0.2 et la manière de les contourner.

Les fichiers peuvent aussi contenir des certificats de CA intermédiaires triés depuis la feuille vers la racine. Cette fonctionnalité est disponible depuis la version 2.4.8 du serveur HTTP Apache, et rend obsolète la directive SSLCertificateChainFile. A partir de la version 1.0.2 d'OpenSSL, il est alors possible de configurer la chaîne de certification en fonction du certificat.

Depuis la version 2.4.7 du serveur HTTP Apache, on peut aussi ajouter des paramètres DH personnalisés et un nom EC curve pour les clés éphémères à la fin du premier fichier défini par la directive SSLCertificateFile. Ces paramètres peuvent être générés avec les commandes openssl dhparam et openssl ecparam, et ils peuvent être ajoutés tel quel à la fin du premier fichier de certificat. En effet, seul le premier fichier de certificat défini peut être utilisé pour enregistrer des paramètres personnalisés, car ces derniers s'appliquent indépendamment de l'algorithme d'authentification utilisé.

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

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

Directive SSLCertificateKeyFile

Cette directive permet de définir le fichier contenant la clé privée du serveur codée en PEM. 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.

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

SSLCertificateKeyFile "/usr/local/apache2/conf/ssl.key/server.key"

Directive SSLCipherSuite

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

Directive SSLCompression

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

Directive SSLCryptoDevice

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

Directive SSLEngine

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.

Directive SSLFIPS

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.

Directive SSLHonorCipherOrder

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

Directive SSLInsecureRenegotiation

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.

Directive SSLOCSPDefaultResponder

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.

Directive SSLOCSPEnable

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

Directive SSLOCSPNoverify

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

Directive SSLOCSPOverrideResponder

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.

Directive SSLOCSPProxyURL

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

Directive SSLOCSPResponderCertificateFile

Cette directive permet de définir un fichier contenant une liste de certificats de confiance du répondeur OCSP à utiliser au cours de la validation du certificat du répondeur OCSP. Les certificats fournis peuvent être considérés comme de confiance sans a