2. EL 7
  3. man-pages-fr
  4. ca(1)

Scroll to navigation

CA(1) OpenSSL CA(1)

NOM

ca - Application minimale de type ca

SYNOPSIS

openssl ca [-verbose] [-config nomfichier] [-name section] [-gencrl] [-revoke fichier] [-crldays jours] [-crlhours heures] [-crlexts section] [-startdate date] [-enddate date] [-days arg] [-md arg] [-policy arg] [-keyfile arg] [-key arg] [-passin arg] [-cert fichier] [-in fichier] [-out fichier] [-notext] [-outdir dossier] [-infiles] [-spkac fichier] [-ss_cert fichier] [-preserveDN] [-batch] [-msie_hack] [-extensions section]

DESCRIPTION

La commande ca est une application CA minimale. Elle peut être utilisée pour signer des demandes de certificats sous différentes formes et génère des CRLs. D'autre part, elle maintient une liste des certificats délivrés et de leurs statuts.

Les descriptions des options sont divisées par type d'action.

OPTIONS CA

spécifie le nom du fichier de configuration.
spécifie la section du fichier de configuration à utiliser
(remplace default_ca dans la section ca).
un nom de fichier en entrée contenant une seule demande de certificat à être signée par le CA.
un seul certificat auto-signé à être signé par le CA.
un fichier contenant une unique clé publique Netscape, signé et des données supplémentaires à être signées par le CA. Référez-vous à la section NOTES pour des informations sur le formatage.
si présent, ceci doit être la dernière option, tous les arguments suivants étant interprétés comme fichiers contenant des demandes de certificats.
le fichier de sortie où seront les certificats seront dirigés, par défaut la sortie standard. Les détails des certificats y seront également précisés.
le répertoire qui contiendra les certificats. Les certificats seront écrits vers des fichiers nommés par le numéro de série en hexadécimal portant le suffixe ".pem".
le fichier de certificat CA.
la clé privée utilisée pour signer les certificats.
le mot de passe utilisé pour chiffrer la clé privée. Sur certains systèmes les arguments de la ligne de commande sont visible (p.e. Unix avec l'utilitaire 'ps') une certaine prudence est requise pour l'emploi de cette option.
la source du mot de passe de la clé. Pour plus d'informations sur le format de l'arg, référez-vous à la section ARGUMENTS DE PHRASE DE PASSE d'openssl(1).

ceci affiche des détails supplémentaires sur les opérations effectuées.

ne pas inclure la version texte d'un certificat dans le fichier de sortie.
ceci permet de définir la date de début de validité explicitement Le format de date utilisé est AAMMJJHHMMSSZ (Le même qu'une structure UTCTime ASN1).
ceci permet de définir la date de fin de validité explicitement Le format de date utilisé est AAMMJJHHMMSSZ (Le même qu'une structure UTCTime ASN1).
le nombre de jours que le certificat sera certifié
la signature de message à utiliser. Les valeurs possibles incluent md5, sha1 et mdc2. Cette option s'applique également aux CRL.
cette option définit la "policy" (NdT:police) CA à utiliser. Il s'agit d'une section du fichier de configuration spécifiant les champs qui sont obligatoires ou qui doivent correspondre au certificat CA. Référez-vous à la section FORMAT DE LA POLICY pour plus d'informations.
c'est une option permettant à ca de fonctionner avec d'anciennes versions du contrôleur d'intégration de certificats d'IE, "certenr3". De l'utilisation quasi-systématique d'UniversalStrings (chaînes de caractères universelles, NdT) s'ensuivent divers trous de sécurité et l'utilisation de cette option est ainsi fortement déconseillé. Le contrôleur plus récent,"Xenroll", n'a pas besoin de cette option.
Normalement, l'ordre DN d'un certificat est celui des champs dans la section de la policy correspondante. Avec cette option activé, l'ordre de référence est celui de la demande de certificat. Il s'agit principalement d'assurer la compatibilité avec l'ancien contrôleur d'IE qui n'accepterait que les certificats dont les DNs correspondent à l'ordre de la demande. Avec Xenroll, pas de problème.
ceci active le mode batch (NdT script ou automatique dans ce contexte). Aucune question ne sera posée et tous les certificats seront signés automatiquement.
la section du fichier de configuration contenant des extensions de certificat à ajouter lors de la génération d'un certificat. Si aucune section d'extension n'est présente, un certificat v1 sera créé, sinon, même avec un contenu vide, un certificat v3 sera créé.

OPTIONS CRL

cette options génère une CRL basée sur l'information trouvée dans le fichier d'index.
le nombre de jours avant passage à la CRL suivante. C'est-à-dire les jours à partir de maintenant à placer dans le champs nextUpdate de la CRL.
le nombre de jours avant passage à la CRL suivante.
le nom de fichier contenant un certificat à retirer.
la section du fichier de configuration contenant des extensions CRL à inclure. Si aucune section d'extension CRL n'est présente, une CRL V1 est créée, sinon, une CRL V2, même si la section en question est vide. Les extensions CRL spécifiées sont des extensions CRL et non des extensions d'entrée CRL. Remarquons que certains logiciels (p.e. Netscape) ne gèrent pas les CRLs VZ.

OPTIONS DE FICHIER DE CONFIGURATION

La section du fichier de configuration contenant des options pour ca est trouvée de la façon suivante : si l'option de ligne de commande -name est utilisée, les noms précisés sont utilisés. Autrement, la section qui sera emmené à être utilisée doit être nommé dans l'option default_ca de la section ca du fichier de configuration (ou dans la section par défaut du fichier de configuration). À part default_ca, les options suivantes sont lues directement de la section ca:
RANDFILE
preserve
msie_hack

À l'exception de RANDFILE, ceci est probablement un bogue et risque d'être modifié dans les versions futures.

De nombreuses options du fichier de configuration sont identiques à celles de la ligne de commande. Si une option est présente à la fois dans le fichier de configuration et sur la ligne de commande, la valeur de la ligne de commande est prise en compte. Une option décrit comme obligatoire doit être présent soit dans le fichier de configuration soit sur la ligne de commande.

Ceci spécifie le fichier contenant des OBJECT IDENTIFIERS (IDENTIFIANT D'OBJET) supplémentaires. Chaque ligne consiste en la forme numérique de l'identifiant d'objet suivi par des espaces puis le libellé court (short name en anglais) suivi à son tour par des espaces et finalement le libellé long.
Ceci spécifie une section du fichier de configuration contenant d'autres identifiants d'objet. Chaque ligne consiste en la forme numérique de l'identifiant d'objet suivi par des espaces puis le libellé court (short name en anglais) suivi à son tour par des espaces et finalement le libellé long.
identique à l'option de ligne de commande -outdir. On spécifie le répertoire où les nouveaux certificats seront placés. Obligatoire.
identique à -cert. On spécifie le fichier contenant le certificat CA. Obligatoire.
identique à l'option -keyfile. Le fichier contenant la clé privée CA. Obligatoire.
un fichier utilisé pour lire et écrire l'information sur la racine des nombres pseudoaléatoires, ou un socket EGD (cf RAND_egd(3)).
identique à l'option -days. Le nombre de jours qu'un certificat sera certifié.
identique à l'option -startdate. La date de début de validité du certificat. Si cette entrée est absente, la date actuelle sera utilisée.
identique à l'option -enddate. Soit cette option-ci soit default_days (où les équivalents en mode ligne de commande) doivent être présent.
identiques aux options -crlhours et -crldays. Uniquement utilisées si aucune options n'est présente sur la ligne de commande. Au moins une de ces options doit être spécifiée pour générer une CRL.
identique à l'option -md. La signature de message à utiliser. Obligatoire.
le fichier texte - base de données - à utiliser. Obligatoire. Ce fichier doit être présent même si initialement vide.
un fichier texte contenant le numéro de série suivant à utiliser en hexadécimal. Obligatoire. Ce fichier doit être présent et contenir un numéro de série valide.
identique à -extensions.
identique à -crlexts.
identique à -preserveDN
identique à -msie_hack
identique à -policy. Obligatoire. Référez-vous à la section FORMAT DE LA POLICY pour plus d'information.

FORMAT DE LA POLICY

La section policy consiste en un jeu de variables correspondants aux champs DN du certificat. Si la valeur est "match", la valeur du champ doit être identique au champ du même nom du certificat CA. Si la valeur est "supplied", il doit être présent. Si la valeur est "optional", sa présence n'est pas obligatoire. Tout champ ne figurant pas dans la section policy est supprimé à moins que l'option -preserveDN ne soit activée. Ce comportement est susceptible de subir des modifications.

FORMAT SPKAC

L'entrée à l'option de ligne de commande -spkac est une clé publique signée Netscape. Ceci provient habituellement d'une balise KEYGEN dans un formulaire HTML pour créer une nouvelle clé privée. Il est toutefois possible de créer des SPKACs en utilisant l'utilitaire spkac.

Le fichier devrait contenir la variable SPKAC à laquelle on assigne sa valeur ainsi que les éléments DN requis sous forme de paires nom-valeurs. Si besoin est d'inclure le même élément plusieurs fois, il est possible de le faire précéder par un nombre et un '.'.

EXEMPLES

Note : ces exemples supposent que l'arborescence ca est déjà en place et que les fichiers liés existent. Ceci nécessite généralement la création d'un certificat et d'une clé privée CA avec req, un fichier de numéro de série et un fichier d'index vide. Tous ces fichiers doivent être placés dans les répertoires correspondants.

Afin d'utiliser le fichier de configuration type ci-dessous, il faut créer les répertoires demoCA, demoCA/private et demoCA/newcerts. Le certificat CA sera copié vers demoCA/cacert.pem et sa clé privée vers demoCA/private/cakey.pem. Un fichier demoCA/serial sera créer contenant par exemple "01" et un fichier d'index vide demoCA/index.txt.

Signer une demande de certificat :

 openssl ca -in req.pem -out newcert.pem
Signer une demande de certificat utilisant des extensions CA : 

 openssl ca -in req.pem -extensions v3_ca -out newcert.pem
Générer une CRL 

 openssl ca -gencrl -out crl.pem
Signer des demandes diverses : 

 openssl ca -infiles req1.pem req2.pem req3.pem
Certifier un SPKAC (Netscape) : 

 openssl ca -spkac spkac.txt
Un fichier SPKAC type (lignes tronquées pour lisibilité) 

 SPKAC=MIG0MGAwXDANBgkqhkiG9w0BAQEFAANLADBIAkEAn7PDhCeV/xIxUg8V70YRxK2A5
 CN=Steve Test
 emailAddress=steve@openssl.org
 0.OU=OpenSSL Group
 1.OU=Another Group
Un fichier de configuration type avec les sections pour ca : 

 [ ca ]
 default_ca      = CA_default            # la section CA par défaut
 [ CA_default ]

 dir            = ./demoCA              # dossier principal
 database       = $dir/index.txt        # fichier index.
 new_certs_dir  = $dir/newcerts         # dossier pour nouveaux certs
 certificate    = $dir/cacert.pem       # Le certificat CA
 serial         = $dir/serial           # fichier des numéros de série
 private_key    = $dir/private/cakey.pem# clé privée CA
 RANDFILE       = $dir/private/.rand    # fichier avec nombres aléatoires
 default_days   = 365                   # durée du certificat
 default_crl_days= 30                   # délai avant CRL suivante
 default_md     = md5                   # md à utiliser

 policy         = policy_any            # policy par défaut

 [ policy_any ]
 countryName            = supplied
 stateOrProvinceName    = optional
 organizationName       = optional
 organizationalUnitName = optional
 commonName             = supplied
 emailAddress           = optional

AVERTISSEMENTS

La commande ca est capricieuse et parfois pas très confortable d'utilisation.

L'utilitaire ca a eu pour objectif initial d'être un exemple montrant comment se servir de CA. Il n'a pas été créé pour servir d'application CA complète, or quelques gens s'en servent dans ce but.

La commande ca est effectivement une commande monoutilisateur, aucun verrouillage n'est fait sur les divers fichiers, et des tentatives d'accès simultanés à un même fichier d'index produisent des résultats imprévisibles.

FICHIERS

Note : l'emplacement de tous les fichier peut changer en fonction des options de compilation, des entrées dans le fichier de configuration, des variables d'environnement où encore les options de la ligne de commande. Les valeurs ci-dessous sont les valeurs par défaut.

 /usr/local/ssl/lib/openssl.cnf - fichier de  configuration principal
 ./demoCA                       - répertoire CA principal
 ./demoCA/cacert.pem            - certificat CA
 ./demoCA/private/cakey.pem     - clé privée CA
 ./demoCA/serial                - fichier de numéros de série CA
 ./demoCA/serial.old            - fichier de sauvegarde des numéros de série CA
 ./demoCA/index.txt             - fichier d'index CA
 ./demoCA/index.txt.old         - fichier de sauvegarde d'index CA
 ./demoCA/certs                 - fichier de sortie du certificat
 ./demoCA/.rnd                  - information concernant la racine aléatoire CA

VARIABLES D'ENVIRONNEMENT

OPENSSL_CONF contient l'emplacement du fichier de configuration principal qui peut être modifié avec l'option de ligne de commande -config

RESTRICTIONS

Le fichier d'index est une partie cruciale du processus et toute corruption peut s'avérer difficile à rattraper. Bien que la reconstruction de l'index à partir des certificats délivrés et d'une CRL récente soit possible, aucune option ne permet de faire cela.

Les extensions d'entrée CRL ne peuvent être créées actuellement : seules les extensions CRL sont prises en charge.

Les nouvelles fonctionnalités de la CRL V2 telles que le support des delta CRL et des nombres CRL ne sont pas implémentées actuellement.

Même s'il est possible d'entrer et de traiter plusieurs demandes en même temps, il est impossible d'inclure plus d'un SPKAC ou certificat auto-signé.

BOGUES

L'utilisation d'une base de données texte en mémoire peut s'avérer problématique, en particulier avec un nombre important de certificats à gérer, justement du fait que cette base se trouve en mémoire.

Les extensions aux demandes de certificats sont ignorées : une sorte de "policy" devrait être incluse afin d'utiliser des extensions statiques et certaines extensions de la demande.

Il n'est pas possible de signer deux certificats ayant la même DN : ceci résulte de la structure du fichier d'index et ne peut être facilement contourné. Quelques clients S/MIME savent utiliser deux certificats avec la même DN pour des clés de signature et de chiffrement différent.

La commande ca a réellement besoin d'être revue voire réécrite soit au niveau commande soit au niveau interface (scripts perl ou GUI) pour traiter les choses proprement. Les scripts CA.sh et CA.pl aident un petit peu en ce sens.

Tout champ ne figurant pas dans la section policy est supprimé à moins que l'option -preserveDN ne soit activée. Les champs supplémentaires ne sont pas affichées lorsque l'utilisateur est demandé de certifier une demande. Ce comportement pourrait être davantage convivial et paramétrable.

L'annulation de certaines commandes en refusant de certifier un certificat peut résulter en un fichier vide.

VOIR AUSSI

req(1), spkac(1), x509(1), CA.pl(1), config(5)

21 décembre 2001 3rd Berkeley Distribution