config

CONFIG(5SSL)                         OpenSSL                        CONFIG(5SSL)



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

       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 $nom ou ${nom} : 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.

       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.

CONFIGURATION DE BIBLIOTHÈQUE OPENSSL
       Depuis OpenSSL 0.9.7, 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.

       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 :

        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 caractéristiques 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 d’OBJET ASN1 all, les sous-commandes
       de l’utilitaire openssl peuvent voir les nouveaux objets ainsi que les
       applications compatibles. Par exemple :

        [nouveaux_oid]

        un_nouvel_oid = 1.2.3.4
        un_autre_oid = 1.2.3.5

       Avec OpenSSL 0.9.8, 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. Le fonctionnement réel effectué 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_moteurs]

        # 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
       utilisée, cette commande doit être la première. Par exemple :

        [section_moteurs]
        # 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 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_moteurs]

        # 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 de alg_section qui pointe vers une section
       contenant les commandes d’algorithme.

       Actuellement, la seule commande d’algorithme prise en charge est
       fips_mode dont la valeur devrait être une valeur booléenne telle que on
       ou off. Si la valeur est on, cela entreprendra l’entrée en mode FIPS. Si
       l’appel échoue ou si la bibliothèque n’est pas compatible avec FIPS, une
       erreur surviendra.

       Par exemple :

        alg_section = evp_settings

        [evp_settings]

        fips_mode = on

NOTES
       Si un fichier de configuration tente de développer une variable qui
       n'existe pas, une erreur est signalée et le fichier ne sera pas chargé.
       Cela peut se produire si une tentative de développement de variable
       d’environnement inexistante est réalisée. Par exemple, dans une version
       précédente d’OpenSSL, le fichier de configuration maître par défaut
       utilisait la valeur de HOME qui peut ne pas être définie sur les systèmes
       non UNIX et ainsi provoquer une erreur.

       Cela peut être contourné en incluant une section default 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 avant le
       développement dans le fichier de configuration. Consultez la section
       EXEMPLES pour un exemple sur la façon de procéder.

       Si une même variable est présente plusieurs fois dans la même section,
       alors elles seront toutes ignorées silencieusement sauf la dernière
       valeur. Dans certains cas, par exemple avec DN, le même champ peut se
       présenter plusieurs fois. Cela est habituellement contourné en ignorant
       tous les caractères précédant le premier ., par exemple

        1.OU="Premier OU"
        2.OU="Second OU"

EXEMPLES
       Voici un exemple de fichier de configuration utilisant certaines
       caractéristiques mentionnées précédemment.

        # 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
        truc = " 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 de configuration de la bibliothèque OpenSSL pour entrer dans le
       mode FIPS :

        # Nom_appli par défaut doit correspondre au param « nom_appli »
        # (s’il existe) fourni à CONF_modules_load_file, etc.
        openssl_conf = openssl_conf_section

        [openssl_conf_section]
        # liste de modules de configuration
        alg_section = evp_sect

        [evp_sect]
        # Défini à « yes » pour entrer dans le mode FIPS si pris en charge
        fips_mode = yes

       Remarque : dans l’exemple ci-dessus, une erreur surviendra pour les
       versions d’OpenSSL n’acceptant pas FIPS.

       Configuration de bibliothèque OpenSSL plus complexe. Ajout d’OID et ne
       pas entrer en mode FIPS :

        # Nom_appli par défaut doit correspondre au param « nom_appli »
        # (s’il existe) fourni à CONF_modules_load_file, etc.
        openssl_conf = openssl_conf_section

        [openssl_conf_section]
        # liste de modules de configuration
        alg_section = evp_sect
        oid_section = new_oids

        [evp_sect]
        # Ceci sera sans effet car le mode FIPS par défaut est non activé.
        # Défini à « yes » pour entrer dans le mode FIPS si pris en charge
        fips_mode = no

        [new_oids]
        # Nouvel OID, nom court
        newoid1 = 1.2.3.4.1
        # Nouvel OID, noms court et long
        newoid2 = New OID 2 long name, 1.2.3.4.2

       Les exemples ci-dessus peuvent être utilisés avec toute application
       prenant en charge la configuration de bibliothèque si « openssl_conf »
       est modifié pour correspondre au « nom_appli » adéquat.

       Par exemple, si le second fichier exemple ci-dessus est sauvegardé dans
       « example.cnf », alors la ligne de commande :

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

       produira :

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

       montrant que l’OID « newoid1 » a été ajouté en tant que « 1.2.3.4.1 ».

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
       ca(1), req(1), x509(1)

TRADUCTION
       La traduction de cette page de manuel est maintenue par les membres de la
       liste <debian-l10n-french AT lists DOT debian DOT org>.  Veuillez
       signaler toute erreur de traduction par un rapport de bogue sur le paquet
       manpages-fr-extra.



1.0.2a 1.0.2c                      2015-12-31                       CONFIG(5SSL)