CONFIG(5)

NOM
config - Fichiers de configuration de la bibliothèque OpenSSL CONF

DESCRIPTION
La bibliothèque OpenSSL CONF permet de lire les fichiers de configuration. Elle est utilisée pour le fichier de configuration maître openssl.cnf d’OpenSSL et dans quelques autres endroits comme les fichiers SPKAC et fichiers d'extension de certificat pour l'utilitaire x509. Les applications d’OpenSSL peuvent également utiliser la bibliothèque CONF pour leurs propres fins.

Un fichier de configuration est divisé en plusieurs sections. Chaque section commence par une ligne [ nom_section ] et se termine quand une autre section commence ou quand la fin du fichier est atteinte. Un nom de section peut contenir des caractères alphanumériques et des caractères de soulignement.

La première section d'un fichier de configuration est spéciale et est appelée la section par défaut (« default »), qui n’est généralement pas nommée et commence au début du fichier jusqu'à la première section nommée. Quand un nom est recherché, il est d'abord recherché dans une section nommée (s’il y en a une) puis dans la section par défaut.

L'environnement est projeté dans une section appelée ENV.

Des commentaires peuvent être inclus, précédés du caractère #.

D'autres fichiers peuvent être inclus avec la directive .include suivie d'un chemin. Si le chemin pointe vers un répertoire, tous les fichiers de ce répertoire dont le nom se termine par .cnf ou .conf sont inclus. L'inclusion récursive de répertoires à partir de fichier dans un répertoire de ce type n'est pas prise en charge. Cela signifie que les fichiers du répertoire inclus peuvent aussi contenir des directives .include mais seule l'inclusion de fichiers ordinaires est alors gérée. L'inclusion de répertoires n'est pas prise en charge dans les systèmes ne disposant pas de la prise en charge de POSIX IO.

Il est fortement recommandé d'utiliser des chemins absolus avec la directive .include. Les chemins sont évalués sur la base du répertoire de travail actuel de l'application, aussi, à moins que le fichier de configuration contenant la directive .include soit spécifique à l'application, l'inclusion ne fonctionnera pas comme prévu.

Il peut y avoir le caractère optionnel = et des caractères espace entre la directive .include et le chemin, ce qui peut être utile au cas où le fichier de configuration doit être chargé par les anciennes versions d'OpenSSL qui ne gèrent pas la syntaxe d'.include. Elles vont refuser de continuer à travailler avec une erreur si le caractère = est absent, mais dans le cas contraire, elles ne feront qu'ignorer l'inclusion.

Chaque section d’un fichier de configuration se compose de plusieurs paires de la forme nom=valeur.

La chaîne nom peut contenir des caractères alphanumériques ainsi que quelques symboles de ponctuation comme , . ; et _.

La chaîne valeur est composée de la chaîne qui suit le caractère = jusqu'à la fin de la ligne avec tous les espaces de début et de fin supprimés.

La chaîne valeur subit un développement de variable. Cela peut être fait en utilisant la forme $var ou ${var} : cela substituera la valeur de la variable nommée dans la présente section. Une valeur d'une autre section peut aussi être remplacée en utilisant la syntaxe $section::nom ou ${section::nom}. Avec la forme $ENV::nom, les variables d'environnement peuvent être substituées. Des valeurs peuvent aussi être attribuées aux variables d'environnement en utilisant le nom ENV::nom, cela fonctionnera si le programme recherche des variables d'environnement en utilisant la bibliothèque CONF au lieu d'appeler getenv() directement. La chaîne valeur ne doit pas avoir une longueur supérieure à 64 ko après l'expansion de la variable. Autrement, une erreur surviendra.

Certains caractères peuvent être protégés à l'aide de n'importe quel type de guillemet ou du caractère \ . Si le dernier caractère d'une ligne est \, une chaîne valeur peut être répartie sur plusieurs lignes. De plus, les suites \n, \r, \b et \t sont reconnues.

Toutes les règles d'expansion et de protection telles que décrites ci-dessus pour valeur s'appliquent aussi au chemin de la directive .include.

CONFIGURATION DE BIBLIOTHÈQUE OPENSSL
Les applications peuvent configurer automatiquement certains aspects d’OpenSSL en utilisant le fichier de configuration maître d’OpenSSL ou éventuellement un fichier de configuration alternatif. L'utilitaire openssl comprend cette fonctionnalité : une sous-commande utilise le fichier de configuration maître d’OpenSSL sauf si une option est utilisée dans la sous-commande pour utiliser un fichier de configuration alternatif.

Pour activer la configuration de bibliothèque, la section par défaut doit contenir une ligne appropriée qui pointe vers la section de configuration principale. Le nom par défaut est openssl_conf, ce qui est utilisé par l'utilitaire openssl. D'autres applications peuvent utiliser un autre nom comme MonApplication_conf. Toutes les lignes de configuration de bibliothèque apparaissent dans la section par défaut au début du fichier de configuration.

La section de configuration devrait être composée d'un ensemble de paires nom valeur contenant des informations spécifiques de configuration du module. Le nom représente le nom du module de configuration, la signification de la valeur est spécifique au module : elle peut, par exemple, représenter une autre section de configuration contenant des informations de configuration spécifiques au module. Par exemple :

 # Cela doit être dans la section par défaut  openssl_conf =
openssl_init   [openssl_init]   oid_section = nouveaux_oid
engines = section_moteurs   [nouveaux_oid]   ... nouveaux oid ...
  [section_moteurs]   ... ce qui concerne les moteurs ...

Les fonctionnalités de chaque module de configuration sont décrites ci-dessous.

  Module de configuration d'objet ASN1
Ce module a le nom de oid_section. La valeur de cette variable pointe vers une section contenant des paires nom valeur d’OID : le nom est le nom court et long d’OID, la valeur est la forme numérique de l'OID. Bien que certaines sous-commandes de l’utilitaire openssl ont déjà leur propre fonctionnalité de section d’OBJET ASN1, ce n’est pas le cas de toutes. En utilisant le module de configuration all d’OBJET ASN1, les sous-commandes de l’utilitaire openssl peuvent voir les nouveaux objets ainsi que les applications compatibles. Par exemple :

 [nouveaux_oid]   un_autre_nouveau_oid = 1.2.3.4  un_autre_oid =
1.2.3.5

La valeur peut aussi être définie au nom long suivi d'une virgule et de la forme numérique de l'OID. Par exemple :

 nomCourt = nom long d'un objet, 1.2.3.4

  Module de configuration du moteur
Ce module de configuration du MOTEUR a le nom engines. La valeur de cette variable pointe vers une section contenant des informations de configuration du moteur.

La section pointée par engines est un tableau de noms de moteur (consultez engine_id ci-dessous) et d'autres sections contenant les informations de configuration spécifiques à chaque MOTEUR.

Chaque section spécifique au MOTEUR est utilisée pour définir des algorithmes par défaut, charger dynamiquement, effectuer l'initialisation et envoyer des contrôles. L'opération réellement effectuée dépend du nom de la commande qui est le nom de la paire nom valeur. Les commandes actuellement prises en charge sont répertoriées ci-dessous.

Par exemple :

 [section_moteur]   # Configurer le MOTEUR nommé « truc »  truc =
section_truc  # Configurer le MOTEUR nommé « bidule »  bidule =
section_bidule   [section_truc]  ... commandes spécifiques au MOTEUR
« truc » ...    [section_bidule]  ... commandes spécifiques au MOTEUR
« bidule » ...

La commande engine_id est utilisée pour donner le nom du MOTEUR. Si elle est utilisée, cette commande doit être la première. Par exemple :

 [section_moteur]  # Cela devrait normalement gérer un MOTEUR nommé
« truc »   truc = section_truc   [section_truc]  # Remplacer le nom
par défaut et utiliser « montruc » à la place.   engine_id = montruc

La commande dynamic_path charge et ajoute un MOTEUR à partir du chemin donné. Elle est équivalente à l'envoi des contrôles SO_PATH avec l'argument de chemin suivi par LIST_ADD avec la valeur 2 et LOAD au MOTEUR dynamique. Si ce n'est pas le comportement voulu, des contrôles alternatifs peuvent être envoyés directement au MOTEUR dynamique en utilisant les commandes de contrôle.

La commande init détermine s'il faut initialiser le MOTEUR. Si la valeur est 0, le MOTEUR ne sera pas initialisé ; si la valeur est 1, une tentative immédiate d’initialiser le MOTEUR est réalisée. Si la commande init n'est pas présente, alors une tentative d’initialiser le MOTEUR sera effectuée après le traitement de toutes les commandes de la section.

La commande default_algorithms définit les algorithmes par défaut qu’un MOTEUR fournira en utilisant les fonctions ENGINE_set_default_string().

Si le nom ne correspond à aucun des noms de commande ci-dessus, il est supposé être une commande de contrôle envoyée au MOTEUR. La valeur de la commande est l'argument de la commande de contrôle. Si la valeur est la chaîne EMPTY, alors aucune valeur n'est envoyée à la commande.

Par exemple :

 [section_moteur]   # Configurer le MOTEUR nommé « truc »  truc =
section_truc   [section_truc]  # Charger le moteur à partir du DSO
dynamic_path = /chemin/vers/moteur_truc.so  # Un contrôle spécifique à
truc.   un_ctrl = une_valeur  # Un autre contrôle qui ne prend pas de
valeur.   autre_ctrl = EMPTY  # Fournir tous les algorithmes par défaut
 default_algorithms = ALL

  Module de configuration EVP
Ce module porte le nom alg_section qui pointe vers une section qui renferme les commandes d'algorithme.

Actuellement, la seule commande d'algorithme prise en charge est fips_mode dont la valeur peut seulement être la chaîne booléenne off. Si fips_mode est réglé à on, une erreur se produit dans la mesure où cette version de la bibliothèque ne gère pas FIPS.

  Module de configuration de SSL
Le module porte le nom ssl_conf qui pointe vers une section qui contient les configurations de SSL.

Chaque ligne de la section de configuration de SSL contient le nom de la configuration et la section qui la contient.

Chaque section de la configuration consiste en une paire commande valeur pour SSL_CONF. Chaque paire sera passée à une structure SSL_CTX ou SSL, si elle appelle SSL_CTX_config() ou SSL_config() avec le nom de configuration approprié.

Note, tous les caractères avant un point initial dans la section de configuration sont ignorés, ainsi la même commande peut être utilisée plusieurs fois.

Par exemple :

 ssl_conf = ssl_sect   [ssl_sect]   server = section_serveur
[section_serveur]   RSA.Certificate = server-rsa.pem
ECDSA.Certificate = server-ecdsa.pem  Ciphers = ALL:!RC4

La configuration par défaut nommée system_default, si elle est présente, sera appliquée à chaque création de la structure SSL_CTX.

Exemple de configuration avec le système par défaut :

 ssl_conf = ssl_sect   [ssl_sect]  system_default =
section_système_par_défaut   [section_système_par_défaut]  MinProtocol
= TLSv1.2  MinProtocol = DTLSv1.2

NOTES
Si un fichier de configuration tente de développer une variable qui n'existe pas, alors une erreur est levée et le fichier ne sera pas chargé. Cela peut arriver si une tentative est faite de développer une variable d'environnement qui n'existe pas. Par exemple, dans une version précédente d'OpenSSL, le fichier de configuration maître par défaut d'OpenSSL utilisait la valeur de HOME qui pourrait ne pas être définit sur les systèmes Unix et pourrait provoquer une erreur.

Cela peut être contourné en incluant une section par défaut pour fournir une valeur par défaut : alors, si la recherche d'environnement échoue, la valeur par défaut sera utilisée à la place. Pour que cela fonctionne correctement, la valeur par défaut doit être définie dans le fichier de configuration avant l'expansion. Consultez la section EXEMPLES pour un exemple sur la manière de procéder.

Si la même variable existe dans la même section, alors toutes les valeurs sauf la dernière sera ignorée silencieusement. Dans certaines circonstances telles qu'avec les DNS, le même champ peut apparaître plusieurs fois. Cela est habituellement contourné en ignorant tous les caractères avant le premier . par exemple.

 1.OU="Mon premier OU"  2.OU="Mon second OU"

EXEMPLES
Voici une fichier de configuration d'exemple utilisant certaines des fonctionnalités mentionnées.

 # Ceci est la section par défaut.    HOME=/temp  RANDFILE=
${ENV::HOME}/.rnd  configdir=$ENV::HOME/config   [ première_section ]
  # Contenu de la première section.    # Les guillemets permettent
des espaces au début et la fin  any = " n'importe quel nom de variable "
  bidule = une chaîne qui peut  \  s'étendre sur plusieurs lignes \
 en incluant \\ des caractères   message = Bonjour tout le monde\n
  [ deuxième_section ]   salutation = $première_section::message

L'exemple suivant montre comment développer les variables d'environnement en toute sécurité.

Soit une variable appelée tmpfile référant un nom de fichier temporaire. Le répertoire dans lequel il est placé peut être déterminé par les variables d'environnement TEMP ou TMP, mais aucune valeur ne peut leur être attribuée. Si vous incluez seulement les noms de variables d'environnement et que la variable n'existe pas, cela provoquerait une erreur lorsqu'une tentative de chargement du fichier de configuration est effectuée. En utilisant la section par défaut, les deux valeurs peuvent être recherchées avec TEMP, en priorité, et /tmp utilisé si aucune n'est définie :

 TMP=/tmp  # Valeur ci-dessus utilisée si TMP n'est pas dans
l'environnement  TEMP=$ENV::TMP  # Valeur ci-dessus utilisée si TEMP
n'est pas dans l'environnement  tmpfile=${ENV::TEMP}/tmp.nom_fichier

Exemple simple de configuration de la bibliothèque OpenSSL pour entrer dans le mode FIPS :

 # Appname par défaut : devrait correspondre au paramètre
"nom_application" (s'il existe)   # fourni à CONF_modules_load_file et
d'autres   openssl_conf = section_conf_openssl
[section_conf_openssl]  # Liste des modules de la configuration
alg_section = section_evp   [section_evp]  # Régler à « yes » pour
entrer dans le mode FIPS s'il est pris en charge  fips_mode = yes

Note : dans l'exemple ci-dessus vous aurez une erreur dans les versions d'OpenSSL qui ne gèrent pas FIPS.

Exemple simple de configuration de la bibliothèque OpenSSL pour faire de TLS 1.2 et DTLS les versions respectives minimales par défaut du système de TLS et DTLS :

 # Section primaire pour openssl (y compris libssl)   openssl_conf =
section_conf_par_défaut   [section_conf_par_défaut]  # Seule la
configuration du "ssl module" est spécifiée  ssl_conf = section_ssl
[section_ssl]  system_default = section_système_par_défaut
[section_système_par_défaut]  MinProtocol = TLSv1.2  MinProtocol =
DTLSv1.2

Le protocole minimal de TLS est appliqué aux objets SSL_CTX basés sur TLS et le protocole minimale de DTLS est appliqué à ceux qui sont basés du DTLS. Il en est de même pour les versions maximales définies par MaxProtocol.

Configuration plus complexe de la bibliothèque OpenSSL. Ajouter OID sans entrer dans le mode FIPS :

 # Appname par défaut : devrait correspondre au paramètre
"nom_application" (s'il existe)   # fourni à CONF_modules_load_file et
d'autres   openssl_conf = section_conf_openssl
[section_conf_openssl]  # Liste des modules de la configuration
alg_section = section_evp  oid_section = nouveaux_oid   [section_evp]
 # Cela n'aura pas d'effet dans la mesure où le mode FIPS est off par
défaut.   # Régler à « yes » pour entrer dans le mode FIPS s'il est pris
en charge  fips_mode = no   [nouveaux_oid]  # Nouveau OID, nom court
seulement  nouveau_oid1 = 1.2.3.4.1  # Nouveau OID, nom court et nom
long  nouveau_oid2 = Nouveau OID 2 nom long, 1.2.3.4.2

Les exemples ci-dessus peuvent être utilisés avec toutes les applications qui gèrent la configuration de bibliothèque si "openssl_conf" est modifié pour correspondre au "nom_application" approprié.

Par exemple, si le second fichier d'exemple ci-dessus est enregistré sous le nom de "exemple.cnf " alors la ligne de commande :

 OPENSSL_CONF=exemple.cnf openssl asn1parse -genstr OID:1.2.3.4.1

produira :

 0:d=0 hl=2 l= 4 prim: OBJECT :nouveau_oid1

montrant que le "nouveau_oid1" OID a été ajouté en tant que "1.2.3.4.1".

ENVIRONNEMENT

OPENSSL_CONF
    Le moteur vers le fichier de configuration. Ignoré dans les programmes set-user-ID et set-group-ID.

OPENSSL_ENGINES
    Le moteur vers le fichier des moteurs. Ignoré dans les programmes set-user-ID et set-group-ID.

BOGUES
Actuellement, aucun moyen ne permet d'inclure des caractères à l'aide de la forme octale \nnn. Les chaînes sont toutes terminées par NULL, donc NULL ne peut pas faire partie de la valeur.

La protection n'est pas tout à fait correcte : si vous voulez utiliser des suites comme \n, vous ne pouvez pas utiliser de guillemets de protection sur la même ligne.

Les fichiers sont chargés en une seule passe. Cela signifie qu’un développement de variable ne fonctionnera que si les variables référencées sont définies précédemment dans le fichier.

VOIR AUSSI
x509(1), req(1), ca(1)

COPYRIGHT
Copyright 2000-2020 Les auteurs du projet OpenSSL. Tous droits réservés.

Sous licence OpenSSL (la "Licence"). Vous ne pouvez utiliser ce fichier que conformément avec la Licence. Vous trouverez une copie dans le fichier LICENSE de la distribution de la source ou à l'adresse <https://www.openssl.org/source/license.html>.

TRADUCTION
La traduction française de cette page de manuel a été créée par arne, tv, Montanes David <montanes.david@gmail.com>, Nicolas François <nicolas.francois@centraliens.net>, David Prévot <david@tilapin.org>, Celia Boudjemai <celisou2008@gmail.com> et Jean-Pierre Giraud <jean-pierregiraud@neuf.fr>

Cette traduction est une documentation libre ; veuillez vous reporter à la GNU General Public License version 3 (https://www.gnu.org/licenses/gpl-3.0.html) concernant les conditions de copie et de distribution. Il n'y a aucune RESPONSABILITÉ LÉGALE.

Si vous découvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un message à debian-l10n-french@lists.debian.org.