mod_ssl - Serveur HTTP Apache Version 2.4

Serveur HTTP Apache Version 2.4

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.

### Sujets

- Variables d'environnement
- Formats de journaux personnalisés
- Information à propos de la requête
- Extension pour l'interprétation des expressions
- Fournisseurs d'autorisation disponibles avec Require

### Directives

### Traitement des bugs

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

## 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, sauf pour `HTTPS` et `SSL_TLS_SNI` qui sont toujours définies, ces informations ne sont pas fournies pour des raisons de performances (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.

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

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

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

## Fournisseurs d'autorisation disponibles avec Require ¶

`mod_ssl` propose les fournisseurs d'autorisation suivants à 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. À la différence de la directive `SSLRequireSSL` directive, cette directive peut être combinée avec d'autres directives `Require` dans les blocs `RequireAny` ou `RequireAll`.

    Require ssl

### Require ssl-verify-client

Le fournisseur `ssl-verify-client` 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

## Directive SSLCACertificateFile ¶

Description: | Fichier contenant une concaténation des certificats de CA codés en PEM pour l'authentification des clients
Syntaxe: | `SSLCACertificateFile file-path`
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"

Ce fichier est lu au démarrage du serveur, alors que ce dernier s'exécute encore en tant que `root` (avant la restriction de ses privilèges) ; il ne doit donc être la propriété que de `root` et lisible uniquement par ce dernier. Le fichier n'est pas relu en fonctionnement normal ; un redémarrage du serveur est requis pour que les changements prennent effet.

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

Les fichiers de ce répertoire sont lus au démarrage du serveur, alors que ce dernier s'exécute encore en tant que `root` (avant la restriction de ses privilèges) ; il ne doit donc être la propriété que de `root` et lisible uniquement par ce dernier. Le fichier n'est pas relu en fonctionnement normal ; un redémarrage du serveur est requis pour que les changements prennent effet.

## 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 file-path`
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"

Ce fichier est lu au démarrage du serveur, alors que ce dernier s'exécute encore en tant que `root` (avant la restriction de ses privilèges) ; il ne doit donc être la propriété que de `root` et lisible uniquement par ce dernier. Le fichier n'est pas relu en fonctionnement normal ; un redémarrage du serveur est requis pour que les changements prennent effet.

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

Les fichiers de ce répertoire sont lus au démarrage du serveur, alors que ce dernier s'exécute encore en tant que `root` (avant la restriction de ses privilèges) ; il ne doit donc être la propriété que de `root` et lisible uniquement par ce dernier. Le fichier n'est pas relu en fonctionnement normal ; un redémarrage du serveur est requis pour que les changements prennent effet.

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

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

### Exemple

    SSLCARevocationCheck chain

### Compatibilité avec la branche 2.2

    SSLCARevocationCheck chain no_crl_for_cert_ok

## Directive SSLCARevocationFile ¶

Description: | Fichier contenant la concaténation des CRLs des CA codés en PEM pour l'authentification des clients
Syntaxe: | `SSLCARevocationFile file-path`
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"

Ce fichier est lu au démarrage du serveur, alors que ce dernier s'exécute encore en tant que `root` (avant la restriction de ses privilèges) ; il ne doit donc être la propriété que de `root` et lisible uniquement par ce dernier. Le fichier n'est pas relu en fonctionnement normal ; un redémarrage du serveur est requis pour que les changements prennent effet.

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

Les fichiers de ce répertoire sont lus au démarrage du serveur, alors que ce dernier s'exécute encore en tant que `root` (avant la restriction de ses privilèges) ; il ne doit donc être la propriété que de `root` et lisible uniquement par ce dernier. Le fichier n'est pas relu en fonctionnement normal ; un redémarrage du serveur est requis pour que les changements prennent effet.

## Directive SSLCertificateChainFile ¶

Description: | Fichier contenant les certificats de CA du serveur codés en PEM
Syntaxe: | `SSLCertificateChainFile file-path`
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"

Ce fichier est lu au démarrage du serveur, alors que ce dernier s'exécute encore en tant que `root` (avant la restriction de ses privilèges) ; il ne doit donc être la propriété que de `root` et lisible uniquement par ce dernier. Le fichier n'est pas relu en fonctionnement normal ; un redémarrage du serveur est requis pour que les changements prennent effet.

## Directive SSLCertificateFile ¶

Description: | Fichier de données contenant les informations de certificat X.509 du serveur codées au format PEM ou identificateur de jeton
Syntaxe: | `SSLCertificateFile file-path|certid`
Contexte: | configuration globale, serveur virtuel
Statut: | Extension
Module: | mod_ssl
Compatibilité: | L'option certid est disponible à partir de la version 2.4.42 du serveur HTTP Apache.

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 ou l'identificateur de certificat via un jeton cryptographique. Si on utilise un fichier au format PEM, ce dernier 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é.

### N'enregistrez pas clé et certificat dans le même fichier

Cette pratique est fortement déconseillée pour les raisons suivantes :

- Sécurité : conserver la clé privée dans un fichier séparé permet une gestion plus stricte des permissions de fichier. Le fichier de certificat peut être lisible par tous (ce sont des données publiques), alors que le fichier de clé ne doit être lisible que par le superutilisateur. Combiner les deux dans un même fichier implique que toute vulnérabilité ou mauvaise configuration qui expose le fichier du certificat exposera aussi la clé privée.
- Contrainte d'ordre : si un fichier combiné est utilisé, toute directive `SSLCertificateFile` référençant un tel fichier doit apparaître après toute directive `SSLCertificateFile` qui utilise un fichier de clé séparé. Ne pas respecter cet ordre provoquera des erreurs au démarrage.
- Maintenance : avec des fichiers séparés, il est immédiatement possible de savoir quel fichier contient quoi, ce qui simplifie la rotation des certificats et les audits.

Si la clé privée est chiffrée, la phrase secrète est demandée au démarrage.

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.

Plutôt que de stocker les certificats et les clés privées dans des fichiers, on peut utiliser un identificateur de certificat pour identifier un certificat stocké dans un jeton. Actuellement, seuls les URIs PKCS#11 (RFC 7512) sont reconnus comme identificateurs de certificats et peuvent être utilisés en conjonction avec le moteur ou le fournisseur OpenSSL `pkcs11`. Si la directive `SSLCertificateKeyFile` est absente, le certificat et la clé privée peuvent être chargés avec l'identificateur spécifié via la directive `SSLCertificateFile`.

### 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 la 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

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

Ce fichier est lu au démarrage du serveur, alors que ce dernier s'exécute encore en tant que `root` (avant la restriction de ses privilèges) ; il ne doit donc être la propriété que de `root` et lisible uniquement par ce dernier. Le fichier n'est pas relu en fonctionnement normal ; un redémarrage du serveur est requis pour que les changements prennent effet.

## Directive SSLCertificateKeyFile ¶

Description: | Fichier contenant la clé privée du serveur codée en PEM
Syntaxe: | `SSLCertificateKeyFile file-path|keyid`
Contexte: | configuration globale, serveur virtuel
Statut: | Extension
Module: | mod_ssl
Compatibilité: | keyid est disponible à partir de la version 2.4.42 du serveur HTTP Apache.

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

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.

### N'enregistrez pas clé et certificat dans le même fichier

La clé privée peut aussi être combinée avec le certificat dans le fichier spécifié par la directive `SSLCertificateFile`, mais cette pratique est fortement déconseillée. Voir l'avertissement dans la documentation de la directive `SSLCertificateFile` pour une explication complète des risques et contraintes.

Plutôt que de stocker des clés privées dans des fichiers, il est possible d'identifier une clé privée via un identifiant stocké dans un jeton. Actuellement, seuls les URIs PKCS#11 (RFC 7512) sont reconnus comme identifiants de clés privées et peuvent être utilisés en conjonction avec le moteur ou le fournisseur OpenSSL `pkcs11`.

### Exemple

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

Ce fichier est lu au démarrage du serveur, alors que ce dernier s'exécute encore en tant que `root` (avant la restriction de ses privilèges) ; il ne doit donc être la propriété que de `root` et lisible uniquement par ce dernier, car il contient la clé privée. Le fichier n'est pas relu en fonctionnement normal ; un redémarrage du serveur est requis pour que les changements prennent effet.

## 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 documentation OpenSSL.

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 :

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

L'algorithme de chiffrement peut aussi provenir de l'extérieur. 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 :

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

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

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

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

À partir de la version 3.0 d'OpenSSL, si aucun moteur n'est spécifié alors que la clé ou le certificat sont spécifiés à l'aide d'URIs PKCS#11 (RFC 7512), le chargement de la clé et du certificat est tenté à partir d'un fournisseur OpenSSL. Le fournisseur OpenSSL à utiliser doit être défini et configuré dans le fichier de configuration d'OpenSSL et il doit prendre en charge la méthode STORE pour les URIs PKCS#11 (RFC 7512).

## Directive SSLEngine ¶

Description: | Interrupteur marche/arrêt du moteur SSL
Syntaxe: | `SSLEngine on|off`
Défaut: | `SSLEngine off`
Contexte: | configuration globale, serveur virtuel
Statut: | Extension
Module: | mod_ssl
Compatibilité: | La prise en charge de l'argument "optional" a été supprimée avec la version 2.4.64. Cet argument activait la prise en charge de la RFC 2817 (mise à niveau de TLS).

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>

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

## 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
Compatibilité: | Disponible à partir de la version 2.1 du serveur HTTP Apache

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

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

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

## Directive SSLOCSPEnable ¶

Description: | Active la validation OCSP de la chaîne de certificats du client
Syntaxe: | `SSLOCSPEnable on|leaf|off [flags]`
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. Le drapeau no_ocsp_for_cert_ok est disponible à partir de la version 2.4.29 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`.

Les drapeaux facultatifs suivants sont disponibles :

- `no_ocsp_for_cert_ok`

  Normalement, Si la validation OCSP est activée, un certificat qui ne contient pas d'URL de réponse OCSP provoquera un échec de validation. Ajouter ce drapeau permet à un tel certificat de passer la validation. Cela s'avère utile dans les environnements où certains certificats de la chaîne ne contiennent pas d'information de réponse OCSP.

### Exemple

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

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

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

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

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

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

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

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

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

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

## 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 :

- `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 doit être interdit. Sans l'option `StrictRequire`, il est possible pour d'autres directives d'autorisation (comme `<RequireAny>`) d'outrepasser l'interdiction d'accès de SSL et d'accorder tout de même l'accès. Avec `SSLOptions +StrictRequire`, l'interdiction de `SSLRequireSSL` ou `SSLRequire` s'applique de manière inconditionnelle, sans tenir compte d'autres directives d'autorisation éventuelles.

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

### Exemple

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

## 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 :

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

### Exemple

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

## 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) :

- `SSLv3`

  Il s'agit du protocole Secure Sockets Layer (SSL) version 3.0 de Netscape Corporation. C'est le successeur de SSLv2 et le prédécesseur de TLSv1, mais est considéré comme obsolète dans la RFC 7568.

- `TLSv1`

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

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

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

- `all`

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

### Exemple

    SSLProtocol TLSv1

### La directive `SSLProtocol` et les serveurs virtuels basés sur le nom

Avant OpenSSL 1.1.1, et même si l'indication du nom de serveur (Server Name Indication ou SNI) permettait de déterminer le serveur virtuel cible assez tôt au cours de la négociation TLS, il était impossible de changer de version de protocole TLS à ce point, si bien que le `SSLProtocol` négocié se basait toujours sur celui du serveur virtuel de base (le premier serveur virtuel déclaré avec le couple `IP:port` de la connexion).

A partir de la version 2.4.42, si le serveur HTTP Apache est compilé avec une version 1.1.1. ou supérieure d'OpenSSL, et si le client fournit la SNI dans la négociation TLS, le `SSLProtocol` de chaque serveur virtuel (basé sur le nom) pourra être pris en compte et le sera.

A des fins de compatibilité avec les versions précédentes, si un serveur virtuel basé sur le nom n'a aucune directive `SSLProtocol` définie, c'est le protocole du serveur virtuel de base qui s'appliquera, à moins qu'une directive `SSLProtocol` ne soit configurée au niveau global, auquel cas c'est le protocole défini par cette directive qui s'appliquera (ce dernier cas relève cependant plus d'un comportement logique que d'un souci de compatibilité).

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

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

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

## Directive SSLProxyCARevocationFile ¶

Description: | Fichier contenant la concaténation des CRLs de CA codés en PEM pour l'authentification des serveurs distants
Syntaxe: | `SSLProxyCARevocationFile 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 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"

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

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

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

## Directive SSLProxyCheckPeerName ¶

Description: | Configure la vérification du nom d'hôte dans les certificats serveur distants
Syntaxe: | `SSLProxyCheckPeerName on|off`
Défaut: | `SSLProxyCheckPeerName on`
Contexte: | configuration globale, serveur virtuel, section proxy
Statut: | Extension
Module: | mod_ssl
Compatibilité: | Disponible à partir de la version 2.4.5 du serveur HTTP Apache Le contexte d'une section proxy est supporté à partir de la version 2.4.30 du serveur HTTP Apache

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

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

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

## Directive SSLProxyCipherSuite ¶

Description: | Algorithmes de chiffrement disponibles pour la négociation lors de l'initialisation d'une connexion SSL de mandataire
Syntaxe: | `SSLProxyCipherSuite [protocol] cipher-spec`
Défaut: | `SSLProxyCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+EXP`
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 est équivalente à la directive `SSLCipherSuite`, mais s'applique à une connexion de mandataire. Veuillez vous reporter à la directive `SSLCipherSuite` pour plus d'informations.

## Directive SSLProxyEngine ¶

Description: | Interrupteur marche/arrêt du moteur de mandataire SSL
Syntaxe: | `SSLProxyEngine on|off`
Défaut: | `SSLProxyEngine off`
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 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 `ProxyRequests`). `SSLProxyEngine` n'est pas nécessaire pour activer un serveur mandataire direct pour les requêtes SSL/TLS.

### Exemple

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

## Directive SSLProxyMachineCertificateChainFile ¶

Description: | Fichier de certificats de CA encodés PEM concaténés permettant au mandataire de choisir un certificat
Syntaxe: | `SSLProxyMachineCertificateChainFile nom-fichier`
Contexte: | configuration 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 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.

### Avertissement en matière de sécurité

Si cette directive est définie, tous les certificats contenus dans le fichier spécifié seront considérés comme étant de confiance, comme s'ils étaient aussi désignés dans la directive `SSLProxyCACertificateFile`.

### Exemple

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

## Directive SSLProxyMachineCertificateFile ¶

Description: | Fichier contenant la concaténation des clés et certificats clients codés en PEM que le mandataire doit utiliser
Syntaxe: | `SSLProxyMachineCertificateFile chemin-fichier`
Contexte: | configuration globale, serveur virtuel, section proxy
Statut: | Extension
Module: | mod_ssl
Compatibilité: | Le contexte d'une section proxy est pris en charge à partir de la version 2.4.30 du serveur HTTP Apache L'inclusion de certificats non-feuilles (CA) est prise en charge à partir de la version 2.4.59.

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. Cette directive s'utilise à la place ou en complément de la directive `SSLProxyMachineCertificatePath`. Le fichier spécifié peut contenir un nombre quelconque de paires certificat client/clé privée associée, et chaque paire peut être spécifiée selon l'ordre (certificat, clé) ou (clé, certificat). Des certificats non-feuilles (CA) peuvent aussi être inclus dans le fichier et sont traités comme s'ils avaient été définis à l'aide de la directive `SSLProxyMachineCertificateChainFile`.

Lorsqu'un serveur distant sollicite le serveur pour obtenir un certificat client, ce dernier doit fournir une liste de noms d'autorités de certification acceptables au cours de la négociation. Si cette liste n'est pas fournie, `mod_ssl` utilisera la première paire certificat/clé client définie. Si par contre cette liste est fournie, `mod_ssl` va la parcourir afin de trouver un certificat client défini qui a été fourni soit directement par l'autorité de certification considérée, soit indirectement via un nombre quelconque de certificats d'autorités de certification intermédiaires. La chaîne de certificats d'autorités de certification intermédiaires peut être construite à partir de ceux qui sont inclus dans le fichier ou configurés à l'aide de la directive `SSLProxyMachineCertificateChainFile`. Le premier certificat défini correspondant sera alors fourni comme réponse au cours de la négociation

Si la liste de noms de CA est fournie au serveur distant, et si aucun certificat client correspondant n'est trouvé, aucun certificat client ne sera fourni par `mod_ssl`, ce qui fera probablement échouer la négociation SSL/TLS (en fonction de la configuration du serveur distant).

Actuellement, les clés privées chiffrées ne sont pas supportées.

Seules les clés au format PKCS1 RSA, DSA ou EC sont supportées. Les clés au format PKCS8, autrement dit celles commençant par "`-----BEGIN PRIVATE KEY-----`", doivent être converties via une commande du style "`openssl rsa -in private-pkcs8.pem -outform pem`".

### Exemple

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

## Directive SSLProxyMachineCertificatePath ¶

Description: | Répertoire des clés et certificats clients codés en PEM que le mandataire doit utiliser
Syntaxe: | `SSLProxyMachineCertificatePath chemin-répertoire`
Contexte: | configuration 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és les clés et certificats clients permettant au serveur mandataire de s'authentifier auprès des serveurs distants.

mod_ssl va essayer de charger tous les fichiers contenus dans le répertoire spécifié, comme si ces derniers étaient définis individuellement via la directive `SSLProxyMachineCertificateFile`.

Actuellement, les clés privées chiffrées ne sont pas supportées.

Seules les clés au format PKCS1 RSA, DSA ou EC sont supportées. Les clés au format PKCS8, autrement dit celles commençant par "`-----BEGIN PRIVATE KEY-----`", doivent être converties via une commande du style "`openssl rsa -in private-pkcs8.pem -outform pem`".

### Exemple

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

## Directive SSLProxyProtocol ¶

Description: | Définit les protocoles SSL disponibles pour la fonction de mandataire
Syntaxe: | `SSLProxyProtocol [+|-]protocole ...`
Défaut: | `SSLProxyProtocol all -SSLv3 (jusqu'à la version 2.4.16: all)`
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 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.

## Directive SSLProxyVerify ¶

Description: | Niveau de vérification du certificat du serveur distant
Syntaxe: | `SSLProxyVerify niveau`
Défaut: | `SSLProxyVerify 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

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

### Exemple

    SSLProxyVerify require

## Directive SSLProxyVerifyDepth ¶

Description: | Niveau de profondeur maximum dans les certificats de CA lors de la vérification du certificat du serveur distant
Syntaxe: | `SSLProxyVerifyDepth niveau`
Défaut: | `SSLProxyVerifyDepth 1`
Contexte: | configuration 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 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...

### Exemple

    SSLProxyVerifyDepth 10

## Directive SSLRandomSeed ¶

Description: | Source de déclenchement du Générateur de Nombres Pseudo-Aléatoires (PRNG)
Syntaxe: | `SSLRandomSeed contexte source [nombre]`
Contexte: | configuration globale
Statut: | Extension
Module: | mod_ssl

Cette directive permet de définir une ou plusieurs sources de déclenchement du Générateur de Nombres Pseudo-Aléatoires (PRNG) dans OpenSSL au démarrage du serveur (si contexte a pour valeur `startup`) et/ou juste avant l'établissement d'une nouvelle connexion SSL (si contexte a pour valeur `connect`). Cette directive ne peut être utilisée qu'au niveau du serveur global car le PRNG est un service global.

Les différentes valeurs de source disponibles sont :

- `builtin`

  Cette source de déclenchement intégrée est toujours disponible. Son utilisation consomme un minimum de cycles CPU en cours d'exécution, et son utilisation ne présente de ce fait aucun problème. La source utilisée pour déclencher le PRNG contient la date courante, l'identifiant du processus courant et un extrait de 128 octets aléatoirement choisi dans la pile. Ceci présente un inconvénient car le caractère aléatoire de cette source n'est pas vraiment fort, et au démarrage (lorsque la structure d'échanges n'est pas encore disponible), cette source ne produit que quelques octets d'entropie. Vous devez donc toujours utiliser une source de déclenchement additionnelle, au moins pour le démarrage.

- `file:/chemin/vers/source`

  Cette variante utilise un fichier 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.

### Exemple

    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

## Directive SSLRenegBufferSize ¶

Description: | Définit la taille du tampon de renégociation SSL
Syntaxe: | `SSLRenegBufferSize taille`
Défaut: | `SSLRenegBufferSize 131072`
Contexte: | répertoire, .htaccess
Surcharges autorisées: | AuthConfig
Statut: | Extension
Module: | mod_ssl

Si une renégociation SSL est requise dans un contexte de répertoire, par exemple avec l'utilisation de `SSLVerifyClient` dans un bloc Directory ou Location, mod_ssl doit mettre en tampon en mémoire tout corps de requête HTTP en attendant qu'une nouvelle initialisation de connexion SSL puisse être effectuée. Cette directive permet de définir la quantité de mémoire à allouer pour ce tampon.

Notez que dans de nombreuses configurations, le client qui envoie un corps de requête n'est pas forcément digne de confiance, et l'on doit par conséquent prendre en considération la possibilité d'une attaque de type déni de service lorsqu'on modifie la valeur de cette directive.

### Exemple

    SSLRenegBufferSize 262144

## Directive SSLRequire ¶

Description: | N'autorise l'accès que lorsqu'une expression booléenne complexe et arbitraire est vraie
Syntaxe: | `SSLRequire expression`
Contexte: | répertoire, .htaccess
Surcharges autorisées: | AuthConfig
Statut: | Extension
Module: | mod_ssl

### SSLRequire est obsolète

`SSLRequire` est obsolète et doit en général être remplacée par l'expression Require. La syntaxe ap_expr de l'expression `Require` est une extension de la syntaxe de `SSLRequire`, avec les différences suivantes :

Avec `SSLRequire`, les opérateurs de comparaison `<`, `<=`, ... sont strictement équivalents aux opérateurs `lt`, `le`, ... , et fonctionnent selon une méthode qui compare tout d'abord la longueur des deux chaînes, puis l'ordre alphabétique. Les expressions ap_expr, quant à elles, possèdent deux jeux d'opérateurs de comparaison : les opérateurs `<`, `<=`, ... effectuent une comparaison alphabétique de chaînes, alors que les opérateurs `-lt`, `-le`, ... effectuent une comparaison d'entiers. Ces derniers possèdent aussi des alias sans tiret initial : `lt`, `le`, ...

Cette directive permet de spécifier une condition générale d'accès qui doit être entièrement satisfaite pour que l'accès soit autorisé. C'est une directive très puissante, car la condition d'accès spécifiée est une expression booléenne complexe et arbitraire contenant un nombre quelconque de vérifications quant aux autorisations d'accès.

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

>     expr     ::= "true" | "false"
>                | "!" expr
>                | expr "&&" expr
>                | expr "||" expr
>                | "(" expr ")"
>                | comp

>     comp     ::= word "==" word | word "eq" word
>                | word "!=" word | word "ne" word
>                | word "<"  word | word "lt" word
>                | word "<=" word | word "le" word
>                | word ">"  word | word "gt" word
>                | word ">=" word | word "ge" word
>                | word "in" "{" wordlist "}"
>                | word "in" "PeerExtList(" word ")"
>                | word "=~" regex
>                | word "!~" regex

>     wordlist ::= word
>                | wordlist "," word

>     word     ::= digit
>                | cstring
>                | variable
>                | function

>     digit    ::= [0-9]+
>     cstring  ::= "..."
>     variable ::= "%{" varname "}"
>     function ::= funcname "(" funcargs ")"

Pour `varname`, toute variable décrite dans Variables d'environnement pourra être utilisée. Pour `funcname`, vous trouverez la liste des fonctions disponibles dans la documentation ap_expr.

expression est interprétée et traduite sous une forme machine interne lors du chargement de la configuration, puis évaluée lors du traitement de la requête. Dans le contexte des fichiers .htaccess, expression est interprétée et exécutée chaque fois que le fichier .htaccess intervient lors du traitement de la requête.

### Exemple

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

### Exemple

    SSLRequire "foobar" in PeerExtList("1.2.3.4.5.6")

### Notes à propos de la fonction PeerExtList

- L'identifiant objet peut être spécifié soit comme un nom descriptif reconnu par la bibliothèque SSL, tel que `"nsComment"`, soit comme un OID numérique tel que `"1.2.3.4.5.6"`.

- Les expressions contenant des types connus de la bibliothèque SSL sont transformées en chaînes avant comparaison. Pour les extensions contenant un type non connu de la bibliothèque SSL, mod_ssl va essayer d'interpréter la valeur s'il s'agit d'un des types ASN.1 primaires UTF8String, IA5String, VisibleString, ou BMPString. Si l'extension correspond à un de ces types, la chaîne sera convertie en UTF-8 si nécessaire, puis comparée avec la partie gauche de l'expression.

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

## Directive SSLRequireSSL ¶

Description: | Interdit l'accès lorsque la requête HTTP n'utilise pas SSL
Syntaxe: | `SSLRequireSSL`
Contexte: | répertoire, .htaccess
Surcharges autorisées: | AuthConfig
Statut: | Extension
Module: | mod_ssl

Cette directive interdit l'accès si HTTP sur SSL (c'est à dire HTTPS) n'est pas activé pour la connexion courante. Ceci est très pratique dans un serveur virtuel où SSL est activé ou dans un répertoire pour se protéger des erreurs de configuration qui pourraient donner accès à des ressources protégées. Lorsque cette directive est présente, toutes les requêtes qui n'utilisent pas SSL sont rejetées.

### Exemple

    SSLRequireSSL

## Directive SSLSessionCache ¶

Description: | Type du cache de session SSL global et inter-processus
Syntaxe: | `SSLSessionCache type`
Défaut: | `SSLSessionCache none`
Contexte: | configuration globale
Statut: | Extension
Module: | mod_ssl

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

Les quatre types de stockage suivants sont actuellement supportés :

- `none`

  Cette valeur désactive le cache de session global et inter-processus, ce qui va ralentir le serveur de manière sensible et peut poser problème avec certains navigateurs, en particulier si les certificats clients sont activés. Cette configuration n'est pas recommandée.

- `nonenotnull`

  Cette valeur désactive tout cache de session global et inter-processus. Cependant, elle force OpenSSL à envoyer un identifiant de session non nul afin de s'adapter aux clients bogués qui en nécessitent un.

- `dbm:/chemin/vers/fichier-données`

  Cette valeur utilise un fichier de hashage DBM sur disque local pour synchroniser les caches OpenSSL locaux en mémoire des processus du serveur. Ce cache de session peut être sujet à des problèmes de fiabilité sous forte charge. Pour l'utiliser, le module `mod_socache_dbm` doit être chargé.

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

  Cette valeur utilise un tampon cyclique à hautes performances (d'une taille d'environ nombre octets) dans un segment de mémoire partagée en RAM (établi via `/chemin/vers/fichier-données`, pour synchroniser les caches OpenSSL locaux en mémoire des processus du serveur. C'est le type de cache de session recommandé. Pour l'utiliser, le module `mod_socache_shmcb` doit être chargé.

- `dc:UNIX:/chemin/vers/socket`

  Cette valeur utilise les bibliothèques de mise en cache de sessions distribuée sur 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é.

### Exemples

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

## Directive SSLSessionCacheTimeout ¶

Description: | Nombre de secondes avant l'expiration d'une session SSL dans le cache de sessions
Syntaxe: | `SSLSessionCacheTimeout secondes`
Défaut: | `SSLSessionCacheTimeout 300`
Contexte: | configuration globale, serveur virtuel
Statut: | Extension
Module: | mod_ssl
Compatibilité: | S'applique aussi à la reprise de session TLS (RFC 5077) à partir de la version 2.4.10 du serveur HTTP Apache

Cette directive permet de définir la durée de vie en secondes des informations stockées dans le cache de sessions SSL global et inter-processus, dans le cache OpenSSL interne en mémoire et pour les sessions réinitialisées par la reprise de session TLS (RFC 5077). elle peut être définie à une valeur d'environ 15 à des fins de test, mais à une valeur très supérieure comme 300 en production.

### Exemple

    SSLSessionCacheTimeout 600

## Directive SSLSessionTicketKeyFile ¶

Description: | Clé de chiffrement/déchiffrement permanente pour les tickets de session TLS
Syntaxe: | `SSLSessionTicketKeyFile file-path`
Contexte: | configuration globale, serveur virtuel
Statut: | Extension
Module: | mod_ssl
Compatibilité: | Disponible depuis la version 2.4.0 du serveur HTTP Apache, sous réserve que l'on utilise une version 0.9.8h ou supérieure d'OpenSSL

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

Le fichier doit contenir 48 octets de données aléatoires créées de préférence par une source à haute entropie. Sur un système de type UNIX, il est possible de créer le fichier contenant la clé de la manière suivante :

`dd if=/dev/random of=/chemin/vers/fichier.tkey bs=1 count=48`

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

Ce fichier contient des données sensibles et doit donc être protégé par des permissions similaires à celles du fichier spécifié par la directive `SSLCertificateKeyFile`.

## Directive SSLSessionTickets ¶

Description: | Active ou désactive les tickets de session TLS
Syntaxe: | `SSLSessionTickets on|off`
Défaut: | `SSLSessionTickets on`
Contexte: | configuration globale, serveur virtuel
Statut: | Extension
Module: | mod_ssl
Compatibilité: | Disponible à partir de la version 2.4.11 du serveur HTTP Apache, sous réserve d'utiliser OpenSSL version 0.9.8f ou supérieure.

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

Les tickets de session TLS sont activés par défaut. Les utiliser sans redémarrer le serveur selon une périodicité appropriée (par exemple quotidiennement) compromet cependant le niveau de confidentialité.

## Directive SSLSRPUnknownUserSeed ¶

Description: | Source d'aléa pour utilisateur SRP inconnu
Syntaxe: | `SSLSRPUnknownUserSeed secret-string`
Contexte: | configuration globale, serveur virtuel
Statut: | Extension
Module: | mod_ssl
Compatibilité: | Disponible depuis la version 2.4.4 du serveur HTTP Apache, si la version 1.0.1 ou supérieure d'OpenSSL est utilisée.

Cette directive permet de définir la source d'aléa à utiliser pour les utilisateurs SRP inconnus, ceci afin de combler les manques en cas d'existence d'un tel utilisateur. Elle définit une chaîne secrète. Si cette directive n'est pas définie, Apache renverra une alerte UNKNOWN_PSK_IDENTITY aux clients qui fournissent un nom d'utilisateur inconnu.

### Exemple

`SSLSRPUnknownUserSeed "secret"`

## Directive SSLSRPVerifierFile ¶

Description: | Chemin du fichier de vérification SRP
Syntaxe: | `SSLSRPVerifierFile file-path`
Contexte: | configuration globale, serveur virtuel
Statut: | Extension
Module: | mod_ssl
Compatibilité: | Disponible depuis la version 2.4.4 du serveur HTTP Apache, si la version 1.0.1 ou supérieure d'OpenSSL est utilisée.

Cette directive permet d'activer TLS-SRP et de définir le chemin du fichier de vérification OpenSSL SRP (Mot de passe distant sécurisé) contenant les noms d'utilisateurs TLS-SRP, les vérificateurs, les "grains de sel" (salts), ainsi que les paramètres de groupe.

### Exemple

`SSLSRPVerifierFile "/path/to/file.srpv"`

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

### Création du fichier de vérification SRP

`openssl srp -srpvfile passwd.srpv -userinfo "some info" -add username`

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

## Directive SSLStaplingCache ¶

Description: | Configuration du cache pour l'agrafage OCSP
Syntaxe: | `SSLStaplingCache type`
Contexte: | configuration globale
Statut: | Extension
Module: | mod_ssl
Compatibilité: | Disponible si on utilise OpenSSL version 0.9.8h ou supérieure

Si `SSLUseStapling` est à "on", cette directive permet de configurer le cache destiné à stocker les réponses OCSP incluses dans la négociation TLS. La configuration d'un cache est obligatoire pour pouvoir utiliser l'agrafage OCSP. A l'exception de `none` et `nonenotnull`, cette directive supporte les mêmes types de stockage que la directive `SSLSessionCache`.

## Directive SSLStaplingErrorCacheTimeout ¶

Description: | Durée de vie des réponses invalides dans le cache pour agrafage OCSP
Syntaxe: | `SSLStaplingErrorCacheTimeout secondes`
Défaut: | `SSLStaplingErrorCacheTimeout 600`
Contexte: | configuration globale, serveur virtuel
Statut: | Extension
Module: | mod_ssl
Compatibilité: | Disponible si on utilise OpenSSL version 0.9.8h ou supérieure

Cette directive permet de définir la durée de vie des réponses invalides dans le cache pour agrafage OCSP configuré via la directive `SSLStaplingCache`. Pour définir la durée de vie des réponses valides, voir la directive `SSLStaplingStandardCacheTimeout`.

## Directive SSLStaplingFakeTryLater ¶

Description: | Génère une réponse "tryLater" pour les requêtes OCSP échouées
Syntaxe: | `SSLStaplingFakeTryLater on|off`
Défaut: | `SSLStaplingFakeTryLater on`
Contexte: | configuration globale, serveur virtuel
Statut: | Extension
Module: | mod_ssl
Compatibilité: | Disponible si on utilise OpenSSL version 0.9.8h ou supérieure

Lorsque cette directive est activée, et si une requête vers un serveur OCSP à des fins d'inclusion dans une négociation TLS échoue, mod_ssl va générer une réponse "tryLater" pour le client (`SSLStaplingReturnResponderErrors` doit être activée).

## Directive SSLStaplingForceURL ¶

Description: | Remplace l'URI du serveur OCSP spécifié dans l'extension AIA du certificat
Syntaxe: | `SSLStaplingForceURL uri`
Contexte: | configuration globale, serveur virtuel
Statut: | Extension
Module: | mod_ssl
Compatibilité: | Disponible si on utilise OpenSSL version 0.9.8h ou supérieure

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

## Directive SSLStaplingResponderTimeout ¶

Description: | Temps d'attente maximum pour les requêtes vers les serveurs OCSP
Syntaxe: | `SSLStaplingResponderTimeout secondes`
Défaut: | `SSLStaplingResponderTimeout 10`
Contexte: | configuration globale, serveur virtuel
Statut: | Extension
Module: | mod_ssl
Compatibilité: | Disponible si on utilise OpenSSL version 0.9.8h ou supérieure

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

## Directive SSLStaplingResponseMaxAge ¶

Description: | Age maximum autorisé des réponses OCSP incluses dans la négociation TLS
Syntaxe: | `SSLStaplingResponseMaxAge secondes`
Défaut: | `SSLStaplingResponseMaxAge -1`
Contexte: | configuration globale, serveur virtuel
Statut: | Extension
Module: | mod_ssl
Compatibilité: | Disponible si on utilise OpenSSL version 0.9.8h ou supérieure

Cette directive permet de définir l'âge maximum autorisé ("fraîcheur") des réponses OCSP incluses dans la négociation TLS (`SSLUseStapling` doit avoir été activée au préalable). La valeur par défaut (`-1`) ne définit aucun âge maximum, ce qui signifie que les réponses OCSP sont considérées comme valides à partir du moment où le contenu de leur champ `nextUpdate` se trouve dans le futur.

## Directive SSLStaplingResponseTimeSkew ¶

Description: | Durée de vie maximale autorisée des réponses OCSP incluses dans la négociation TLS
Syntaxe: | `SSLStaplingResponseTimeSkew secondes`
Défaut: | `SSLStaplingResponseTimeSkew 300`
Contexte: | configuration globale, serveur virtuel
Statut: | Extension
Module: | mod_ssl
Compatibilité: | Disponible si on utilise OpenSSL version 0.9.8h ou supérieure

Cette directive permet de spécifier l'intervalle de temps maximum que mod_ssl va calculer en faisant la différence entre les contenus des champs `nextUpdate` et `thisUpdate` des réponses OCSP incluses dans la négociation TLS. Pour pouvoir utiliser cette directive, `SSLUseStapling` doit être à "on".

## Directive SSLStaplingReturnResponderErrors ¶

Description: | Transmet au client les erreurs survenues lors des requêtes OCSP
Syntaxe: | `SSLStaplingReturnResponderErrors on|off`
Défaut: | `SSLStaplingReturnResponderErrors on`
Contexte: | configuration globale, serveur virtuel
Statut: | Extension
Module: | mod_ssl
Compatibilité: | Disponible si on utilise OpenSSL version 0.9.8h ou supérieure

Lorsque cette directive est activée, mod_ssl va transmettre au client les réponses concernant les requêtes OCSP échouées (comme les réponses avec un statut général autre que "successful", les réponses avec un statut de certificat autre que "good", les réponses arrivées à expiration, etc...). Lorsqu'elle est à `off`, seules les réponses avec un statut de certificat égal à "good" ou "revoked" seront incluses dans la négociation TLS. Les réponses avec un statut "revoked" sont toujours incluses quelle que soit cette définition, car supprimer une révocation connue constituerait un risque de sécurité.

## Directive SSLStaplingStandardCacheTimeout ¶

Description: | Durée de vie des réponses OCSP dans le cache
Syntaxe: | `SSLStaplingStandardCacheTimeout secondes`
Défaut: | `SSLStaplingStandardCacheTimeout 3600`
Contexte: | configuration globale, serveur virtuel
Statut: | Extension
Module: | mod_ssl
Compatibilité: | Disponible si on utilise OpenSSL version 0.9.8h ou supérieure

Cette directive permet de définir la durée de vie des réponses OCSP dans le cache configuré via la directive `SSLStaplingCache`. Elle ne s'applique qu'aux réponse valides, alors que la directive `SSLStaplingErrorCacheTimeout` s'applique aux réponses invalides ou non disponibles.

## Directive SSLStrictSNIVHostCheck ¶

Description: | Contrôle de l'accès des clients non-SNI à un serveur virtuel à base de nom.
Syntaxe: | `SSLStrictSNIVHostCheck on|off`
Défaut: | `SSLStrictSNIVHostCheck off`
Contexte: | configuration globale, serveur virtuel
Statut: | Extension
Module: | mod_ssl
Compatibilité: | Disponible depuis la version 2.2.12 d'Apache

Cette directive permet de contrôler l'accès des clients non-SNI à un serveur virtuel à base de nom. Si elle est définie à `on` dans le serveur virtuel à base de nom par défaut, les clients non-SNI ne seront autorisés à accéder à aucun serveur virtuel appartenant à cette combinaison IP/port. Par contre, si elle est définie à `on` dans un serveur virtuel quelconque, les clients non-SNI ne se verront interdire l'accès qu'à ce serveur.

Si cette directive est à `on` dans un contexte de serveur (globalement, en dehors de tout bloc `<VirtualHost>`), tous les serveurs virtuels qui ne l'outrepassent pas héritent de la configuration. Cela a le même effet que la définir à `on` dans tous les serveurs virtuels par défaut à base de nom : les clients non-SNI se verront refuser l'accès à tout serveur virtuel à base de nom.

Cette option n'est disponible que si httpd a été compilé avec une version d'OpenSSL supportant SNI.

### Exemple

    SSLStrictSNIVHostCheck on

## Directive SSLUserName ¶

Description: | Nom de la variable servant à déterminer le nom de l'utilisateur
Syntaxe: | `SSLUserName nom-var`
Contexte: | configuration globale, répertoire, .htaccess
Surcharges autorisées: | AuthConfig
Statut: | Extension
Module: | mod_ssl

Cette variable permet de définir le champ "user" de l'objet de la requête Apache. Ce champ est utilisé par des modules de plus bas niveau pour identifier l'utilisateur avec une chaîne de caractères. En particulier, l'utilisation de cette directive peut provoquer la définition de la variable d'environnement `REMOTE_USER`. La valeur de l'argument nom-var peut correspondre à toute variable d'environnement SSL.

Lorsque l'option `FakeBasicAuth` (voir SSLOptions) ou la directive `AuthBasicFake` sont activées, cette directive permet de contrôler quelle partie du certificat client est utilisée comme nom d'utilisateur. Sans la directive `SSLUserName`, `REMOTE_USER` peut ne pas être définie pour d'autres modules ou scripts CGI.

### Exemple

    SSLUserName SSL_CLIENT_S_DN_CN

## Directive SSLUseStapling ¶

Description: | Active l'ajout des réponses OCSP à la négociation TLS
Syntaxe: | `SSLUseStapling on|off`
Défaut: | `SSLUseStapling off`
Contexte: | configuration globale, serveur virtuel
Statut: | Extension
Module: | mod_ssl
Compatibilité: | Disponible si on utilise OpenSSL version 0.9.8h ou supérieure

Cette directive permet d'activer l'"Agrafage OCSP" (OCSP stapling) selon la définition de l'extension TLS "Certificate Status Request" fournie dans la RFC 6066. Si elle est activée et si le client le demande, mod_ssl va inclure une réponse OCSP à propos de son propre certificat dans la négociation TLS. Pour pouvoir activer l'Agrafage OCSP, il est nécessaire de configurer un `SSLStaplingCache`.

L'agrafage OCSP dispense le client de requérir le serveur OCSP directement ; il faut cependant noter que selon les spécifications de la RFC 6066, la réponse `CertificateStatus` du serveur ne peut inclure une réponse OCSP que pour un seul certificat. Pour les certificats de serveur comportant des certificats de CA intermédiaires dans leur chaîne (c'est un cas typique de nos jours), l'implémentation actuelle de l'agrafage OCSP n'atteint que partiellement l'objectif d' "économie en questions/réponse et en ressources". Pour plus de détails, voir la RFC 6961 (TLS Multiple Certificate Status Extension).

Lorsque l'agrafage OCSP est activé, le mutex `ssl-stapling` contrôle l'accès au cache de l'agrafage OCSP afin de prévenir toute corruption, et le mutex `sss-stapling-refresh` contrôle le raffraîchissement des réponses OCSP. Ces mutex peuvent être configurés via la directive `Mutex`.

## Directive SSLVerifyClient ¶

Description: | Niveau de vérification du certificat client
Syntaxe: | `SSLVerifyClient niveau`
Défaut: | `SSLVerifyClient none`
Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess
Surcharges autorisées: | AuthConfig
Statut: | Extension
Module: | mod_ssl

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

Les valeurs de niveau disponibles sont les suivantes :

- 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). Cette option ne peut pas être utilisée lors de l'authentification du client.

### Exemple

    SSLVerifyClient require

## Directive SSLVerifyDepth ¶

Description: | Profondeur maximale des certificats de CA pour la vérification des certificats clients
Syntaxe: | `SSLVerifyDepth nombre`
Défaut: | `SSLVerifyDepth 1`
Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess
Surcharges autorisées: | AuthConfig
Statut: | Extension
Module: | mod_ssl

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

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

### Exemple

    SSLVerifyDepth 10

## Directive SSLVHostSNIPolicy ¶

Description: | Définir la politique de compatibilité pour l'accès des clients SNI aux serveurs virtuels.
Syntaxe: | `SSLVHostSNIPolicy strict|secure|authonly|insecure`
Défaut: | `SSLVHostSNIPolicy secure`
Contexte: | configuration globale
Statut: | Extension
Module: | mod_ssl
Compatibilité: | Disponible à partir de la version 2.4.66 du serveur HTTP Apache

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

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

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

Les politiques `secure` (politique par défaut) et `authonly` comparent certains aspects spécifiques des deux serveurs virtuels, qui sont regroupés en deux catégories :

- certificat/clé de serveur ou restrictions de protocole/algorithme de chiffrement : directives qui déterminent le certificat ou la clé du serveur (`SSLCertificateKeyFile`, etc.), restrictions de protocole ou d'algorithme de chiffrement (`SSLProtocol` et `SSLCipherSuite`)
- configuration de la certification et de l'authentification du client : directives qui affectent l'authentification du client et la vérification de son certificat via TLS, telles que `SSLVerifyClient`, `SSLVerifyMode`, `SSLCACertificatePath`, `SSLSRPVerifierFile`; toute utilisation de `SSLOpenSSLConfCmd`

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

Politique utilisée | Toute incohérence dans les serveurs virtuels | Certificat/clé du serveur, ou restrictions de protocole/algorithme de chiffrement | Certification client/ configuration de l'authentification
--- | --- | --- | ---
`strict` | bloquée | bloquée | bloquée
`secure` | autorisée | bloquée | bloquée
`authonly` | autorisée | bloquée | autorisée
`insecure` | autorisée | autorisée | autorisée

### Exemple

    SSLVHostSNIPolicy authonly

Langues Disponibles: en | fr