<-
Apache > Serveur HTTP > Documentation > Version 2.4 > Modules

Module Apache mod_ssl

Langues Disponibles:  en  |  fr 

Description:Chiffrement de haut niveau basé sur les protocoles Secure Sockets Layer (SSL) et Transport Layer Security (TLS)
Statut:Extension
Identificateur de Module:ssl_module
Fichier Source:mod_ssl.c

Sommaire

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

Ce module s'appuie sur OpenSSL pour fournir le moteur de chiffrement.

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

Support Apache!

Sujets

Directives

Traitement des bugs

Voir aussi

top

Variables d'environnement

Ce module peut être configuré pour fournir aux espaces de nommage SSI et CGI de nombreux éléments d'informations concernant SSL par le biais de variables d'environnement supplémentaires. Par défaut, et pour des raisons de performances, ces informations ne sont pas fournies (Voir la directive SSLOptions StdEnvVars ci-dessous). Les variables générées se trouvent dans la table ci-dessous. Ces informations peuvent également être disponible sous des noms différents à des fins de compatibilité ascendante. Reportez-vous au chapitre Compatibilité pour plus de détails à propos des variables de compatibilité.

Nom de la variable : Type de valeur : Description :
HTTPS drapeau HTTPS est utilisé.
SSL_PROTOCOL chaîne La version du protocole SSL (SSLv3, TLSv1, TLSv1.1, TLSv1.2)
SSL_SESSION_ID chaîne L'identifiant de session SSL codé en hexadécimal
SSL_SESSION_RESUMED chaîne Session SSL initiale ou reprise. Note : plusieurs requêtes peuvent être servies dans le cadre de la même session SSL (initiale ou reprise) si les connexions persistantes (HTTP KeepAlive) sont utilisées
SSL_SECURE_RENEG chaîne true si la renégociation sécurisée est supportée, false dans le cas contraire
SSL_CIPHER chaîne Le nom de l'algorithme de chiffrement
SSL_CIPHER_EXPORT chaîne true si l'algorithme de chiffrement est un algorithme exporté
SSL_CIPHER_USEKEYSIZE nombre Nombre de bits de chiffrement (réellement utilisés)
SSL_CIPHER_ALGKEYSIZE nombre Nombre de bits de chiffrement (possible)
SSL_COMPRESS_METHOD chaîne Méthode de compression SSL négociée
SSL_VERSION_INTERFACE chaîne La version du programme mod_ssl
SSL_VERSION_LIBRARY chaîne La version du programme OpenSSL
SSL_CLIENT_M_VERSION chaîne La version du certificat client
SSL_CLIENT_M_SERIAL chaîne Le numéro de série du certificat client
SSL_CLIENT_S_DN chaîne Le DN sujet du certificat client
SSL_CLIENT_S_DN_x509 chaîne Elément du DN sujet du client
SSL_CLIENT_SAN_Email_n chaîne Les entrées d'extension subjectAltName du certificat client de type rfc822Name
SSL_CLIENT_SAN_DNS_n chaîne Les entrées d'extension subjectAltName du certificat client de type dNSName
SSL_CLIENT_SAN_OTHER_msUPN_n chaîne Extensions subjectAltName de type otherName du certificat client, forme Microsoft du nom principal de l'utilisateur (OID 1.3.6.1.4.1.311.20.2.3)
SSL_CLIENT_I_DN chaîne DN de l'émetteur du certificat du client
SSL_CLIENT_I_DN_x509 chaîne Elément du DN de l'émetteur du certificat du client
SSL_CLIENT_V_START chaîne Validité du certificat du client (date de début)
SSL_CLIENT_V_END chaîne Validité du certificat du client (date de fin)
SSL_CLIENT_V_REMAIN chaîne Nombre de jours avant expiration du certificat du client
SSL_CLIENT_A_SIG chaîne Algorithme utilisé pour la signature du certificat du client
SSL_CLIENT_A_KEY chaîne Algorithme utilisé pour la clé publique du certificat du client
SSL_CLIENT_CERT chaîne Certificat du client au format PEM
SSL_CLIENT_CERT_CHAIN_n chaîne Certificats de la chaîne de certification du client au format PEM
SSL_CLIENT_CERT_RFC4523_CEA chaîne Numéro de série et fournisseur du certificat. le format correspond à celui de la CertificateExactAssertion dans la RFC4523
SSL_CLIENT_VERIFY chaîne NONE, SUCCESS, GENEROUS ou FAILED:raison
SSL_SERVER_M_VERSION chaîne La version du certificat du serveur
SSL_SERVER_M_SERIAL chaîne The serial of the server certificate
SSL_SERVER_S_DN chaîne DN sujet du certificat du serveur
SSL_SERVER_S_DN_x509 chaîne Elément du DN sujet du certificat du serveur
SSL_SERVER_SAN_Email_n chaîne Les entrées d'extension subjectAltName du certificat de serveur de type rfc822Name
SSL_SERVER_SAN_DNS_n chaîne Les entrées d'extension subjectAltName du certificat de serveur de type dNSName
SSL_SERVER_SAN_OTHER_dnsSRV_n chaîne Extensions subjectAltName de type otherName du certificat serveur, sous la forme SRVName (OID 1.3.6.1.5.5.7.8.7, RFC 4985)
SSL_SERVER_I_DN chaîne DN de l'émetteur du certificat du serveur
SSL_SERVER_I_DN_x509 chaîne Elément du DN de l'émetteur du certificat du serveur
SSL_SERVER_V_START chaîne Validité du certificat du serveur (date de dédut)
SSL_SERVER_V_END chaîne Validité du certificat du serveur (date de fin)
SSL_SERVER_A_SIG chaîne Algorithme utilisé pour la signature du certificat du serveur
SSL_SERVER_A_KEY chaîne Algorithme utilisé pour la clé publique du certificat du serveur
SSL_SERVER_CERT chaîne Certificat du serveur au format PEM
SSL_SRP_USER chaîne nom d'utilisateur SRP
SSL_SRP_USERINFO chaîne informations sur l'utilisateur SRP
SSL_TLS_SNI string Contenu de l'extension SNI TLS (si supporté par ClientHello)

x509 spécifie un élément de DN X.509 parmi C,ST,L,O,OU,CN,T,I,G,S,D,UID,Email. A partir de la version 2.2.0 d'Apache, x509 peut aussi comporter un suffixe numérique _n. Si le DN en question comporte plusieurs attributs de noms identiques, ce suffixe constitue un index débutant à zéro et permettant de sélectionner un attribut particulier. Par exemple, si le DN sujet du certificat du serveur comporte deux champs OU, on peut utiliser SSL_SERVER_S_DN_OU_0 et SSL_SERVER_S_DN_OU_1 pour référencer chacun d'entre eux. Un nom de variable sans suffixe _n est équivalent au même nom avec le suffixe _0, ce qui correspond au premier attribut (ou au seul) caractérisant le DN. Lorsque la table d'environnement est remplie en utilisant l'option StdEnvVars de la directive SSLOptions, le premier attribut (ou le seul) caractérisant le DN est enregistré avec un nom sans suffixe ; autrement dit, aucune entrée possédant comme suffixe _0 n'est enregistrée.

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 conversion de la valeur de l'attribut en UTF-8. Il doit être placé après le suffixe index (s'il existe). On utilisera par exemple SSL_SERVER_S_DN_OU_RAW ou SSL_SERVER_S_DN_OU_0_RAW.

Le format des variables *_DN a changé depuis la version 2.3.11 d'Apache HTTPD. Voir l'option LegacyDNStringFormat de la directive SSLOptions pour plus de détails.

SSL_CLIENT_V_REMAIN n'est disponible qu'à partir de la version 2.1.

Plusieurs variables d'environnement additionnelles peuvent être utilisées dans les expressions SSLRequire, ou dans les formats de journalisation personnalisés :

HTTP_USER_AGENT        PATH_INFO             AUTH_TYPE
HTTP_REFERER           QUERY_STRING          SERVER_SOFTWARE
HTTP_COOKIE            REMOTE_HOST           API_VERSION
HTTP_FORWARDED         REMOTE_IDENT          TIME_YEAR
HTTP_HOST              IS_SUBREQ             TIME_MON
HTTP_PROXY_CONNECTION  DOCUMENT_ROOT         TIME_DAY
HTTP_ACCEPT            SERVER_ADMIN          TIME_HOUR
THE_REQUEST            SERVER_NAME           TIME_MIN
REQUEST_FILENAME       SERVER_PORT           TIME_SEC
REQUEST_METHOD         SERVER_PROTOCOL       TIME_WDAY
REQUEST_SCHEME         REMOTE_ADDR           TIME
REQUEST_URI            REMOTE_USER

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

ENV:nom_variable
Correspond à la variable d'environnement standard nom_variable.
HTTP:nom_en-tête
Correspond à la valeur de l'en-tête de requête dont le nom est nom_en-tête.
top

Formats de journaux personnalisés

Lorsque mod_ssl est compilé dans le serveur Apache ou même chargé (en mode DSO), des fonctions supplémentaires sont disponibles pour le Format de journal personnalisé du module mod_log_config. A ce titre, la fonction de format d'eXtension ``%{nom-var}x'' peut être utilisée pour présenter en extension toute variable fournie par tout module, et en particulier celles fournies par mod_ssl et que vous trouverez dans la table ci-dessus.

A des fins de compatibilité ascendante, il existe une fonction de format cryptographique supplémentaire ``%{nom}c''. Vous trouverez toutes les informations à propos de cette fonction dans le chapitre Compatibilité.

Exemple

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

Ces formats sont disponibles même si l'option StdEnvVars de la directive SSLOptions n'a pas été définie.

top

Information à propos de la requête

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

Les informations enregistrées sont les suivantes :

ssl-access-forbidden
Cette information contient la valeur 1 si l'accès a été refusé suite à une directive SSLRequire ou SSLRequireSSL.
ssl-secure-reneg
Si mod_ssl a été compilé avec une version d'OpenSSL qui supporte la renégociation sécurisée, si SSL est utilisé pour la connexion courante et si le client supporte lui aussi la renégociation sécurisée, cette information contiendra la valeur 1. Si le client ne supporte pas la renégociation sécurisée, l'information contiendra la valeur 0. Si mod_ssl n'a pas été compilé avec une version d'OpenSSL qui supporte la renégociation sécurisée, ou si SSL n'est pas utilisé pour la connexion courante, le contenu de l'information ne sera pas défini.
top

Extension pour l'interprétation des expressions

Lorsque mod_ssl est compilé statiquement avec Apache, ou même chargé dynamiquement (en tant que module DSO), toute variable en provenance de mod_ssl peut être utilisée pour l'interprétation des expression ap_expr. Les variables peuvent être référencées en utilisant la syntaxe ``%{varname}''. A partir de la version 2.4.18, on peut aussi utiliser la syntaxe de style mod_rewrite ``%{SSL:varname}'', ou la syntaxe de style fonction ``ssl(varname)''.

Exemple (en utilisant mod_headers)

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'option StdEnvVars de la directive SSLOptions n'a pas été définie.

top

Fournisseurs d'autorisation disponibles avec Require

mod_ssl propose quelques fournisseurs d'autorisation à utiliser avec la directive Require du module mod_authz_core.

Require ssl

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

Require ssl

Require ssl-verify-client

Le fournisseur ssl autorise l'accès si l'utilisateur est authentifié via un certificat client valide. Ceci n'a un effet que si SSLVerifyClient optional est actif.

Dans l'exemple suivant, l'accès est autorisé si le client est authentifié via un certificat client ou par nom d'utilisateur/mot de passe :

Require ssl-verify-client
Require valid-user
top

Directive SSLCACertificateFile

Description:Fichier contenant une concaténation des certificats de CA codés en PEM pour l'authentification des clients
Syntaxe:SSLCACertificateFile chemin-fichier
Contexte:configuration globale, serveur virtuel
Statut:Extension
Module:mod_ssl

Cette directive permet de définir le fichier tout-en-un où vous pouvez rassembler les certificats des Autorités de Certification (CAs) pour les clients auxquels vous avez à faire. On les utilise pour l'authentification des clients. Un tel fichier contient la simple concaténation des différents fichiers de certificats codés en PEM, par ordre de préférence. Cette directive peut être utilisée à la place et/ou en complément de la directive SSLCACertificatePath.

Exemple

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

Directive SSLCACertificatePath

Description:Répertoire des certificats de CA codés en PEM pour l'authentification des clients
Syntaxe:SSLCACertificatePath chemin-répertoire
Contexte:configuration globale, serveur virtuel
Statut:Extension
Module:mod_ssl

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

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

Exemple

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

Directive SSLCADNRequestFile

Description:Fichier contenant la concaténation des certificats de CA codés en PEM pour la définition de noms de CA acceptables
Syntaxe:SSLCADNRequestFile chemin-fichier
Contexte:configuration globale, serveur virtuel
Statut:Extension
Module:mod_ssl

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

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

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

SSLCADNRequestFile doit spécifier un fichier tout-en-un contenant une concaténation des certificats de CA codés en PEM.

Exemple

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

Directive SSLCADNRequestPath

Description:Répertoire contenant des fichiers de certificats de CA codés en PEM pour la définition de noms de CA acceptables
Syntaxe:SSLCADNRequestPath chemin-répertoire
Contexte:configuration globale, serveur virtuel
Statut:Extension
Module:mod_ssl

Cette directive optionnelle permet de définir la liste de noms de CAs acceptables qui sera envoyée au client lorsqu'un certificat de client est demandé. Voir la directive SSLCADNRequestFile pour plus de détails.

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

Exemple

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

Directive SSLCARevocationCheck

Description:Active la vérification des révocations basée sur les CRL
Syntaxe:SSLCARevocationCheck chain|leaf|none [flags ...]
Défaut:SSLCARevocationCheck none
Contexte:configuration globale, serveur virtuel
Statut:Extension
Module:mod_ssl
Compatibilité:Le drapeau optionnel flags est disponible à partir de la version 2.4.21 du serveur HTTP Apache

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

Exemple

SSLCARevocationCheck chain

Compatibilité avec la branche 2.2

SSLCARevocationCheck chain no_crl_for_cert_ok
top

Directive SSLCARevocationFile

Description:Fichier contenant la concaténation des CRLs des CA codés en PEM pour l'authentification des clients
Syntaxe:SSLCARevocationFile chemin-fichier
Contexte:configuration globale, serveur virtuel
Statut:Extension
Module:mod_ssl

Cette directive permet de définir le fichier tout-en-un où sont rassemblées les Listes de Révocation de Certificats (CRLs) des Autorités de certification (CAs) pour les clients auxquels vous avez à faire. On les utilise pour l'authentification des clients. Un tel fichier contient la simple concaténation des différents fichiers de CRLs codés en PEM, dans l'ordre de préférence. Cette directive peut être utilisée à la place et/ou en complément de la directive SSLCARevocationPath.

Exemple

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

Directive SSLCARevocationPath

Description:Répertoire des CRLs de CA codés en PEM pour l'authentification des clients
Syntaxe:SSLCARevocationPath chemin-répertoire
Contexte:configuration globale, serveur virtuel
Statut:Extension
Module:mod_ssl

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

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

Exemple

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

Directive SSLCertificateChainFile

Description:Fichier contenant les certificats de CA du serveur codés en PEM
Syntaxe:SSLCertificateChainFile chemin-fichier
Contexte:configuration globale, serveur virtuel
Statut:Extension
Module:mod_ssl

SSLCertificateChainFile est obsolète

SSLCertificateChainFile est devenue obsolète avec la version 2.4.8, lorsque la directive SSLCertificateFile a été étendue pour supporter aussi les certificats de CA intermédiaires dans le fichier de certificats du serveur.

Cette directive permet de définir le fichier optionnel tout-en-un où vous pouvez rassembler les certificats des Autorités de Certification (CA) qui forment la chaîne de certification du certificat du serveur. Cette chaîne débute par le certificat de la CA qui a délivré le certificat du serveur et peut remonter jusqu'au certificat de la CA racine. Un tel fichier contient la simple concaténation des différents certificats de CA codés en PEM, en général dans l'ordre de la chaîne de certification.

Elle doit être utilisée à la place et/ou en complément de la directive SSLCACertificatePath pour construire explicitement la chaîne de certification du serveur qui est envoyée au navigateur en plus du certificat du serveur. Elle s'avère particulièrement utile pour éviter les conflits avec les certificats de CA lorsqu'on utilise l'authentification du client. Comme le fait de placer un certificat de CA de la chaîne de certification du serveur dans la directive SSLCACertificatePath produit le même effet pour la construction de la chaîne de certification, cette directive a pour effet colatéral de faire accepter les certificats clients fournis par cette même CA, au cours de l'authentification du client.

Soyez cependant prudent : fournir la chaîne de certification ne fonctionne que si vous utilisez un simple certificat de serveur RSA ou DSA. Si vous utilisez une paire de certificats couplés RSA+DSA , cela ne fonctionnera que si les deux certificats utilisent vraiment la même chaîne de certification. Dans le cas contraire, la confusion risque de s'installer au niveau des navigateurs.

Exemple

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

Directive SSLCertificateFile

Description:Fichier de données contenant le certificat X.509 du serveur codé en PEM
Syntaxe:SSLCertificateFile chemin-fichier
Contexte:configuration globale, serveur virtuel
Statut:Extension
Module:mod_ssl

Cette directive permet de définir le fichier de données contenant les informations de certificat X.509 du serveur codées au format PEM. Ce fichier doit contenir au minimum un certificat d'entité finale (feuille). 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.

Interopérabilité des paramètres DH avec les nombres premiers de plus de 1024 bits

Depuis la version 2.4.7, mod_ssl utilise des paramètres DH standardisés avec des nombres premiers de 2048, 3072 et 4096 bits, et avec des nombres premiers de 6144 et 8192 bits depuis la version 2.4.10 (voir RFC 3526), et les fournit aux clients en fonction de la longueur de la clé du certificat RSA/DSA. En particulier avec les clients basés sur Java (versions 7 et antérieures), ceci peut provoquer des erreurs au cours de la négociation - voir cette réponse de la FAQ SSL pour contourner les problèmes de ce genre.

Paramètres DH par défaut lorsqu'on utilise plusieurs certificats et une version d'OpenSSL antérieure à 1.0.2.

Lorsqu'on utilise plusieurs certificats pour supporter différents algorithmes d'authentification (comme RSA, DSA, mais principalement ECC) et une version d'OpenSSL antérieure à 1.0.2, il est recommandé soit d'utiliser des paramètres DH spécifiques (solution à privilégier) en les ajoutant au premier fichier certificat (comme décrit ci-dessus), soit d'ordonner les directives SSLCertificateFile de façon à ce que les certificats RSA/DSA soit placés après les certificats ECC.

Cette limitation est présente dans les anciennes versions d'OpenSSL qui présentent toujours le dernier certificat configuré, au lieu de laisser le serveur HTTP Apache déterminer le certificat sélectionné lors de la phase de négociation de la connexion (lorsque les paramètres DH doivent être envoyés à l'hôte distant). De ce fait, le serveur peut sélectionner des paramètres DH par défaut basés sur la longueur de la clé du mauvais certificat (les clés ECC sont beaucoup plus petites que les clés RSA/DSA et leur longueur n'est pas pertinente pour la sélection des nombres premiers DH).

Ce problème peut être résolu en créant et configurant des paramètres DH spécifiques (comme décrit ci-dessus), car ils l'emportent toujours sur les paramètres DH par défaut, et vous pourrez ainsi utiliser une longueur spécifique et appropriée.

Exemple

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

Directive SSLCertificateKeyFile

Description:Fichier contenant la clé privée du serveur codée en PEM
Syntaxe:SSLCertificateKeyFile chemin-fichier
Contexte:configuration globale, serveur virtuel
Statut:Extension
Module:mod_ssl

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

Exemple

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

Directive SSLCipherSuite

Description:Algorithmes de chiffrement disponibles pour la négociation au cours de l'initialisation de la connexion SSL
Syntaxe:SSLCipherSuite [protocol] cipher-spec
Défaut:SSLCipherSuite DEFAULT (dépend de la version d'OpenSSL installée)
Contexte:configuration globale, serveur virtuel, répertoire, .htaccess
Surcharges autorisées:AuthConfig
Statut:Extension
Module:mod_ssl

Cette directive complexe utilise la chaîne cipher-spec contenant la liste des algorithmes de chiffrement OpenSSL que le client peut utiliser au cours de la phase d'initialisation de la connexion SSL. La spécification optionnelle du protocole permet de configurer la suite d'algorithmes de chiffrement pour une version spécifique de SSL. Une des valeurs possibles est "SSL" pour toutes les versions du protocole SSL jusqu'à TLSv1.2 compris.

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.

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

Pour obtenir la liste des noms d'algorithmes de chiffrement pour TLSv1.3, se référer à la the OpenSSL documentation.

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

L'algorithme de chiffrement peut aussi provenir de l'extérieur. Les algorithmes SSLv2 ne sont plus supportés. Pour définir les algorithmes à utiliser, on peut soit spécifier tous les algorithmes à la fois, soit utiliser des alias pour spécifier une liste d'algorithmes dans leur ordre de préférence (voir Table 1). Les algorithmes et alias effectivement disponibles dépendent de la version d'openssl utilisée. Les versions ultérieures d'openssl sont susceptibles d'inclure des algorithmes supplémentaires.

Symbole Description
Algorithme d'échange de clés :
kRSA Echange de clés RSA
kDHr Echange de clés Diffie-Hellman avec clé RSA
kDHd Echange de clés Diffie-Hellman avec clé DSA
kEDH Echange de clés Diffie-Hellman temporaires (pas de certificat)
kSRP échange de clés avec mot de passe distant sécurisé (SRP)
Algorithmes d'authentification :
aNULL Pas d'authentification
aRSA Authentification RSA
aDSS Authentification DSS
aDH Authentification Diffie-Hellman
Algorithmes de chiffrement :
eNULL Pas de chiffrement
NULL alias pour eNULL
AES Chiffrement AES
DES Chiffrement DES
3DES Chiffrement Triple-DES
RC4 Chiffrement RC4
RC2 Chiffrement RC2
IDEA Chiffrement IDEA
Algorithmes de condensés MAC :
MD5 Fonction de hashage MD5
SHA1 Fonction de hashage SHA1
SHA alias pour SHA1
SHA256 Fonction de hashage SHA256
SHA384 Fonction de hashage SHA384
Alias :
SSLv3 tous les algorithmes de chiffrement SSL version 3.0
TLSv1 tous les algorithmes de chiffrement TLS version 1.0
EXP tous les algorithmes de chiffrement externes
EXPORT40 tous les algorithmes de chiffrement externes limités à 40 bits
EXPORT56 tous les algorithmes de chiffrement externes limités à 56 bits
LOW tous les algorithmes de chiffrement faibles (non externes, DES simple)
MEDIUM tous les algorithmes avec chiffrement 128 bits
HIGH tous les algorithmes utilisant Triple-DES
RSA tous les algorithmes utilisant l'échange de clés RSA
DH tous les algorithmes utilisant l'échange de clés Diffie-Hellman
EDH tous les algorithmes utilisant l'échange de clés Diffie-Hellman temporaires
ECDH Echange de clés Elliptic Curve Diffie-Hellman
ADH tous les algorithmes utilisant l'échange de clés Diffie-Hellman anonymes
AECDH tous les algorithmes utilisant l'échange de clés Elliptic Curve Diffie-Hellman
SRP tous les algorithmes utilisant l'échange de clés avec mot de passe distant sécurisé (SRP)
DSS tous les algorithmes utilisant l'authentification DSS
ECDSA tous les algorithmes utilisant l'authentification ECDSA
aNULL tous les algorithmes n'utilisant aucune authentification

Cela devient intéressant lorsque tous ces symboles sont combinés ensemble pour spécifier les algorithmes disponibles et l'ordre dans lequel vous voulez les utiliser. Pour simplifier tout cela, vous disposez aussi d'alias (SSLv3, TLSv1, EXP, LOW, MEDIUM, HIGH) pour certains groupes d'algorithmes. Ces symboles peuvent être reliés par des préfixes pour former la chaîne algorithmes. Les préfixes disponibles sont :

Les algorithmes aNULL, eNULL et EXP sont toujours désactivés

Depuis la version 2.4.7, les algorithmes de type null ou destinés à l'exportation sont toujours désactivés car mod_ssl ajoute obligatoirement !aNULL:!eNULL:!EXP à toute chaîne d'algorithme de chiffrement à l'initialisation.

Pour vous simplifier la vie, vous pouvez utiliser la commande ``openssl ciphers -v'' qui vous fournit un moyen simple de créer la chaîne algorithmes avec succès. La chaîne algorithmes par défaut dépend de la version des bibliothèques SSL installées. Supposons qu'elle contienne ``RC4-SHA:AES128-SHA:HIGH:MEDIUM:!aNULL:!MD5'', ce qui stipule de mettre RC4-SHA et AES128-SHA en premiers, car ces algorithmes présentent un bon compromis entre vitesse et sécurité. Viennent ensuite les algorithmes de sécurité élevée et moyenne. En fin de compte, les algorithmes qui n'offrent aucune authentification sont exclus, comme les algorithmes anonymes Diffie-Hellman pour SSL, ainsi que tous les algorithmes qui utilisent MD5 pour le hashage, car celui-ci est reconnu comme insuffisant.

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

Vous trouverez la liste complète des algorithmes RSA & DH spécifiques à SSL dans la Table 2.

Exemple

SSLCipherSuite RSA:!EXP:!NULL:+HIGH:+MEDIUM:-LOW
Symbole algorithme Protocole Echange de clés Authentification Chiffrement Condensé MAC Type
Algorithmes RSA :
DES-CBC3-SHA SSLv3 RSA RSA 3DES(168) SHA1
IDEA-CBC-SHA SSLv3 RSA RSA IDEA(128) SHA1
RC4-SHA SSLv3 RSA RSA RC4(128) SHA1
RC4-MD5 SSLv3 RSA RSA RC4(128) MD5
DES-CBC-SHA SSLv3 RSA RSA DES(56) SHA1
EXP-DES-CBC-SHA SSLv3 RSA(512) RSA DES(40) SHA1 export
EXP-RC2-CBC-MD5 SSLv3 RSA(512) RSA RC2(40) MD5 export
EXP-RC4-MD5 SSLv3 RSA(512) RSA RC4(40) MD5 export
NULL-SHA SSLv3 RSA RSA None SHA1
NULL-MD5 SSLv3 RSA RSA None MD5
Algorithmes Diffie-Hellman :
ADH-DES-CBC3-SHA SSLv3 DH None 3DES(168) SHA1
ADH-DES-CBC-SHA SSLv3 DH None DES(56) SHA1
ADH-RC4-MD5 SSLv3 DH None RC4(128) MD5
EDH-RSA-DES-CBC3-SHA SSLv3 DH RSA 3DES(168) SHA1
EDH-DSS-DES-CBC3-SHA SSLv3 DH DSS 3DES(168) SHA1
EDH-RSA-DES-CBC-SHA SSLv3 DH RSA DES(56) SHA1
EDH-DSS-DES-CBC-SHA SSLv3 DH DSS DES(56) SHA1
EXP-EDH-RSA-DES-CBC-SHA SSLv3 DH(512) RSA DES(40) SHA1 export
EXP-EDH-DSS-DES-CBC-SHA SSLv3 DH(512) DSS DES(40) SHA1 export
EXP-ADH-DES-CBC-SHA SSLv3 DH(512) None DES(40) SHA1 export
EXP-ADH-RC4-MD5 SSLv3 DH(512) None RC4(40) MD5 export
top

Directive SSLCompression

Description:Permet d'activer la compression au niveau SSL
Syntaxe:SSLCompression on|off
Défaut:SSLCompression off
Contexte:configuration globale, serveur virtuel
Statut:Extension
Module:mod_ssl
Compatibilité:Disponible à partir de la version 2.4.3 du serveur HTTP Apache, si on utilise une version d'OpenSSL 0.9.8 ou supérieure ; l'utilisation dans un contexte de serveur virtuel n'est disponible que si on utilise une version d'OpenSSL 1.0.0 ou supérieure. La valeur par défaut était on dans la version 2.4.3.

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

L'activation de la compression est à l'origine de problèmes de sécurité dans la plupart des configurations (l'attaque nommée CRIME).

top

Directive SSLCryptoDevice

Description:Active l'utilisation d'un accélérateur matériel de chiffrement
Syntaxe:SSLCryptoDevice moteur
Défaut:SSLCryptoDevice builtin
Contexte:configuration globale
Statut:Extension
Module:mod_ssl

Cette directive permet d'activer l'utilisation d'une carte accélératrice de chiffrement qui prendra en compte certaines parties du traitement relatif à SSL. Cette directive n'est utilisable que si la boîte à outils SSL à été compilée avec le support "engine" ; les versions 0.9.7 et supérieures d'OpenSSL possèdent par défaut le support "engine", alors qu'avec la version 0.9.6, il faut utiliser les distributions séparées "-engine".

Pour déterminer les moteurs supportés, exécutez la commande "openssl engine".

Exemple

# Pour un accélérateur Broadcom :
SSLCryptoDevice ubsec
top

Directive SSLEngine

Description:Interrupteur marche/arrêt du moteur SSL
Syntaxe:SSLEngine on|off|optional
Défaut:SSLEngine off
Contexte:configuration globale, serveur virtuel
Statut:Extension
Module:mod_ssl

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

Exemple

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

top

Directive SSLFIPS

Description:Coimmutateur du mode SSL FIPS
Syntaxe:SSLFIPS on|off
Défaut:SSLFIPS off
Contexte:configuration globale
Statut:Extension
Module:mod_ssl

Cette directive permet d'activer/désactiver l'utilisation du drapeau FIPS_mode de la bibliothèque SSL. Elle doit être définie dans le contexte du serveur principal, et n'accepte pas les configurations sources de conflits (SSLFIPS on suivi de SSLFIPS off par exemple). Le mode s'applique à toutes les opérations de la bibliothèque SSL.

Si httpd a été compilé avec une bibliothèque SSL qui ne supporte pas le drapeau FIPS_mode, la directive SSLFIPS on échouera. Reportez-vous au document sur la politique de sécurité FIPS 140-2 de la bibliothèque du fournisseur SSL, pour les prérequis spécifiques nécessaires à l'utilisation de mod_ssl selon un mode d'opération approuvé par FIPS 140-2 ; notez que mod_ssl en lui-même n'est pas validé, mais peut être décrit comme utilisant un module de chiffrement validé par FIPS 140-2, lorsque tous les composants sont assemblés et mis en oeuvre selon les recommandations de la politique de sécurité applicable.

top

Directive SSLHonorCipherOrder

Description:Option permettant de classer les algorithmes de chiffrement du serveur par ordre de préférence
Syntaxe:SSLHonorCipherOrder on|off
Défaut:SSLHonorCipherOrder off
Contexte:configuration globale, serveur virtuel
Statut:Extension
Module:mod_ssl

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

Exemple

SSLHonorCipherOrder on
top

Directive SSLInsecureRenegotiation

Description:Option permettant d'activer le support de la renégociation non sécurisée
Syntaxe:SSLInsecureRenegotiation on|off
Défaut:SSLInsecureRenegotiation off
Contexte:configuration globale, serveur virtuel
Statut:Extension
Module:mod_ssl
Compatibilité:Disponible depuis httpd 2.2.15, si une version 0.9.8m ou supérieure d'OpenSSL est utilisée

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

Si mod_ssl est lié à une version 0.9.8m ou supérieure d'OpenSSL, par défaut, la renégociation n'est accordée qu'aux clients qui supportent la nouvelle extension du protocole. Si cette directive est activée, la renégociation sera accordée aux anciens clients (non patchés), quoique de manière non sécurisée

Avertissement à propos de la sécurité

Si cette directive est activée, les connexions SSL seront vulnérables aux attaques de type préfixe Man-in-the-Middle comme décrit dans CVE-2009-3555.

Exemple

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.

top

Directive SSLOCSPDefaultResponder

Description:Définit l'URI du répondeur par défaut pour la validation OCSP
Syntaxe:SSLOCSPDefaultResponder uri
Contexte:configuration globale, serveur virtuel
Statut:Extension
Module:mod_ssl

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

top

Directive SSLOCSPEnable

Description:Active la validation OCSP de la chaîne de certificats du client
Syntaxe:SSLOCSPEnable on|leaf|off
Défaut:SSLOCSPEnable off
Contexte:configuration globale, serveur virtuel
Statut:Extension
Module:mod_ssl
Compatibilité:Le mode leaf est disponible à partir de la version 2.4.34 du serveur HTTP Apache

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). 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 directives SSLOCSPDefaultResponder et SSLOCSPOverrideResponder.

Exemple

SSLVerifyClient on
SSLOCSPEnable on
SSLOCSPDefaultResponder "http://responder.example.com:8888/responder"
SSLOCSPOverrideResponder on
top

Directive SSLOCSPNoverify

Description:Evite la vérification des certificats des répondeurs OCSP
Syntaxe:SSLOCSPNoverify On/Off
Défaut:SSLOCSPNoverify Off
Contexte:configuration globale, serveur virtuel
Statut:Extension
Module:mod_ssl
Compatibilité:Disponible à partir de la version 2.4.26 du serveur HTTP Apache, sous réserve d'utiliser une version 0.9.7 ou supérieure d'OpenSSL

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.

top

Directive SSLOCSPOverrideResponder

Description:Force l'utilisation de l'URI du répondeur par défaut pour la validation OCSP
Syntaxe:SSLOCSPOverrideResponder on|off
Défaut:SSLOCSPOverrideResponder off
Contexte:configuration globale, serveur virtuel
Statut:Extension
Module:mod_ssl

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

top

Directive SSLOCSPProxyURL

Description:Adresse de mandataire à utiliser pour les requêtes OCSP
Syntaxe:SSLOCSPProxyURL url
Contexte:configuration globale, serveur virtuel
Statut:Extension
Module:mod_ssl
Compatibilité:Disponible à partir de la version 2.4.19 du serveur HTTP Apache

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.

top

Directive SSLOCSPResponderCertificateFile

Description:Fournit un jeu de certificats de confiance du répondeur OCSP avec encodage PEM
Syntaxe:SSLOCSPResponderCertificateFile file
Contexte:configuration globale, serveur virtuel
Statut:Extension
Module:mod_ssl
Compatibilité:Disponible à partir de la version 2.4.26 du serveur HTTP Apache, sous réserve d'utiliser une version 0.9.7 ou supérieure d'OpenSSL

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 avoir à effectuer de vérifications supplémentaires. Ce processus de validation du certificat du répondeur OCSP intervient en général lorsque ce dernier est autosigné ou tout simplement absent de la réponse OCSP.

top

Directive SSLOCSPResponderTimeout

Description:Délai d'attente pour les requêtes OCSP
Syntaxe:SSLOCSPResponderTimeout secondes
Défaut:SSLOCSPResponderTimeout 10
Contexte:configuration globale, serveur virtuel
Statut:Extension
Module:mod_ssl

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

top

Directive SSLOCSPResponseMaxAge

Description:Age maximum autorisé pour les réponses OCSP
Syntaxe:SSLOCSPResponseMaxAge secondes
Défaut:SSLOCSPResponseMaxAge -1
Contexte:configuration globale, serveur virtuel
Statut:Extension
Module:mod_ssl

Cette option permet de définir l'âge maximum autorisé (la "fraicheur") des réponses OCSP. La valeur par défault (-1) signifie qu'aucun âge maximum n'est défini ; autrement dit, les réponses OCSP sont considérées comme valides tant que la valeur de leur champ nextUpdate se situe dans le futur.

top

Directive SSLOCSPResponseTimeSkew

Description:Dérive temporelle maximale autorisée pour la validation des réponses OCSP
Syntaxe:SSLOCSPResponseTimeSkew secondes
Défaut:SSLOCSPResponseTimeSkew 300
Contexte:configuration globale, serveur virtuel
Statut:Extension
Module:mod_ssl

Cette option permet de définir la dérive temporelle maximale autorisée pour les réponses OCSP (lors de la vérification des champs thisUpdate et nextUpdate).

top

Directive SSLOCSPUseRequestNonce

Description:Use a nonce within OCSP queries
Syntaxe:SSLOCSPUseRequestNonce on|off
Défaut:SSLOCSPUseRequestNonce on
Contexte:configuration globale, serveur virtuel
Statut:Extension
Module:mod_ssl
Compatibilité:Available in httpd 2.4.10 and later

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

top

Directive SSLOpenSSLConfCmd

Description:Configuration des paramètres d'OpenSSL via son API SSL_CONF
Syntaxe:SSLOpenSSLConfCmd commande valeur
Contexte:configuration globale, serveur virtuel
Statut:Extension
Module:mod_ssl
Compatibilité:Disponible depuis la version 2.4.8 du serveur HTTP Apache avec OpenSSL 1.0.2 ou supérieur

Cette directive permet à mod_ssl d'accéder à l'API SSL_CONF d'OpenSSL. Il n'est ainsi plus nécessaire d'implémenter des directives supplémentaires pour mod_ssl lorsque de nouvelles fonctionnalités sont ajoutées à OpenSSL, ce qui rend la configuration de ce dernier beaucoup plus souple.

Le jeu de commandes disponibles pour la directive SSLOpenSSLConfCmd dépend de la version d'OpenSSL utilisée pour mod_ssl (la version minimale 1.0.2 est un prérequis). Pour obtenir la liste des commandes supportées, voir la section Supported configuration file commands de la page de manuel d'OpenSSL SSL_CONF_cmd(3).

Certaines commandes peuvent remplacer des directives existantes (comme SSLCipherSuite ou SSLProtocol) ; notez cependant que la syntaxe et/ou les valeurs possibles peuvent différer.

Examples

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
top

Directive SSLOptions

Description:Configure différentes options d'exécution du moteur SSL
Syntaxe:SSLOptions [+|-]option ...
Contexte:configuration globale, serveur virtuel, répertoire, .htaccess
Surcharges autorisées:Options
Statut:Extension
Module:mod_ssl

Cette directive permet de contrôler différentes options d'exécution du moteur SSL dans un contexte de répertoire. Normalement, si plusieurs SSLOptions peuvent s'appliquer à un répertoire, c'est la plus spécifique qui est véritablement prise en compte ; les options ne se combinent pas entre elles. Elles se combinent cependant entre elles si elles sont toutes précédées par un symbole plus (+) ou moins (-). Toute option précédée d'un + est ajoutée aux options actuellement en vigueur, et toute option précédée d'un - est supprimée de ces mêmes options.

Les options disponibles sont :

Exemple

SSLOptions +FakeBasicAuth -StrictRequire
<Files ~ "\.(cgi|shtml)$">
    SSLOptions +StdEnvVars -ExportCertData
</Files>
top

Directive SSLPassPhraseDialog

Description:Méthode utilisée pour entrer le mot de passe pour les clés privées chiffrées
Syntaxe:SSLPassPhraseDialog type
Défaut:SSLPassPhraseDialog builtin
Contexte:configuration globale
Statut:Extension
Module:mod_ssl

Lors de son démarrage, Apache doit lire les différents fichiers de certificats (voir la directive SSLCertificateFile) et de clés privées (voir la directive SSLCertificateKeyFile) des serveurs virtuels où SSL est activé. Comme, pour des raisons de sécurité, les fichiers de clés privées sont en général chiffrés, mod_ssl doit demander à l'administrateur un mot de passe pour déchiffrer ces fichiers. L'argument type permet de choisir la manière dont cette demande peut être formulée parmi les trois suivantes :

Exemple

SSLPassPhraseDialog "exec:/usr/local/apache/sbin/pp-filter"
top

Directive SSLProtocol

Description:Indique les versions du protocole SSL/TLS disponibles
Syntaxe:SSLProtocol [+|-]protocole ...
Défaut:SSLProtocol all -SSLv3 (jusqu'à la version 2.4.16 : all)
Contexte:configuration globale, serveur virtuel
Statut:Extension
Module:mod_ssl

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

Les protocoles disponibles sont les suivants (sensibles à la casse) :

Exemple

SSLProtocol TLSv1
top

Directive SSLProxyCACertificateFile

Description:Fichier contenant la concaténation des certificats de CA codés en PEM pour l'authentification des serveurs distants
Syntaxe:SSLProxyCACertificateFile file-path
Contexte:configuration globale, serveur virtuel, section proxy
Statut:Extension
Module:mod_ssl
Compatibilité:Le contexte d'une section proxy est supporté à partir de la version 2.4.30 du serveur HTTP Apache

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.

Exemple

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

Directive SSLProxyCACertificatePath

Description:Répertoire des certificats de CA codés en PEM pour l'authentification des serveurs distants
Syntaxe:SSLProxyCACertificatePath chemin-répertoire
Contexte:configuration globale, serveur virtuel, section proxy
Statut:Extension
Module:mod_ssl
Compatibilité:Le contexte d'une section proxy est supporté à partir de la version 2.4.30 du serveur HTTP Apache

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.

Exemple

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

Directive SSLProxyCARevocationCheck

Description:Active la vérification des révocations basée sur les CRLs pour l'authentification du serveur distant
Syntaxe:SSLProxyCARevocationCheck chain|leaf|none
Défaut:SSLProxyCARevocationCheck none
Contexte:configuration globale, serveur virtuel, section proxy
Statut:Extension
Module:mod_ssl
Compatibilité:Le contexte d'une section proxy est supporté à partir de la version 2.4.30 du serveur HTTP Apache

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

Lorsque la directive est définie à chain ou leaf, les CRLs doivent être disponibles pour que la validation réussisse

Avant la version 2.3.15, les vérifications CRL dans mod_ssl réussissaient même si aucune CRL n'était trouvée dans les chemins définis par les directives SSLProxyCARevocationFile ou SSLProxyCARevocationPath. Le comportement a changé avec l'introduction de cette directive : lorsque la vérification est activée, les CRLs doivent être présentes pour que la validation réussisse ; dans le cas contraire, elle échouera avec une erreur "CRL introuvable".

Exemple

SSLProxyCARevocationCheck chain
top

Directive SSLProxyCARevocationFile

Description:Fichier contenant la concaténation des CRLs de CA codés en PEM pour l'authentification des serveurs distants
Syntaxe:SSLProxyCARevocationFile chemin-fichier
Contexte:configuration globale, serveur virtuel, section proxy
Statut:Extension
Module:mod_ssl
Compatibilité:Le contexte d'une section proxy est supporté à partir de la version 2.4.30 du serveur HTTP Apache

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.

Exemple

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

Directive SSLProxyCARevocationPath

Description:Répertoire des CRLs de CA codés en PEM pour l'authentification des serveurs distants
Syntaxe:SSLProxyCARevocationPath chemin-répertoire
Contexte:configuration globale, serveur virtuel, section proxy
Statut:Extension
Module:mod_ssl
Compatibilité:Le contexte d'une section proxy est supporté à partir de la version 2.4.30 du serveur HTTP Apache

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.

Exemple

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

Directive SSLProxyCheckPeerCN

Description:Configuration de la vérification du champ CN du certificat du serveur distant
Syntaxe:SSLProxyCheckPeerCN on|off
Défaut:SSLProxyCheckPeerCN on
Contexte:configuration globale, serveur virtuel, section proxy
Statut:Extension
Module:mod_ssl
Compatibilité:Le contexte d'une section proxy est supporté à partir de la version 2.4.30 du serveur HTTP Apache

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.

De la version 2.4.5 à la version 2.4.20, spécifier SSLProxyCheckPeerName off était suffisant pour obtenir ce comportement (car la valeur par défaut de SSLProxyCheckPeerCN était on). Avec ces versions, les deux directives doivent être définies à off pour éviter toute validation du nom de certificat du serveur distant, et de nombreux utilisateurs ont signalé ce comportement comme très perturbant.

A partir de la version 2.4.21, toutes les configurations qui activent au moins une des deux directives SSLProxyCheckPeerName ou SSLProxyCheckPeerCN adopteront le nouveau comportement de la directive SSLProxyCheckPeerName, et toutes les configurations qui désactivent une des deux directives SSLProxyCheckPeerName ou SSLProxyCheckPeerCN éviteront toute validation du nom de certificat du serveur distant. Seule la configuration suivante permettra de retrouver la comparaison de CN traditionnelle pour les versions 2.4.21 et supérieures :

Exemple

SSLProxyCheckPeerCN on
SSLProxyCheckPeerName off
top

Directive SSLProxyCheckPeerExpire

Description:Configuration de la vérification de l'expiration du certificat du serveur distant
Syntaxe:SSLProxyCheckPeerExpire on|off
Défaut:SSLProxyCheckPeerExpire on
Contexte:configuration globale, serveur virtuel, section proxy
Statut:Extension
Module:mod_ssl
Compatibilité:Le contexte d'une section proxy est supporté à partir de la version 2.4.30 du serveur HTTP Apache

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

Exemple

SSLProxyCheckPeerExpire on
top

Directive SSLProxyCheckPeerName

Description:Configure la vérification du nom d'hôte dans les certificats serveur distants