ca − application minimale de type ca

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]

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.

−config nomfichier

spécifie le nom du fichier de configuration.

−name section

spécifie la section du fichier de configuration à utiliser (remplace default_ca dans la section ca).

−in nomfichier

un nom de fichier en entrée contenant une seule demande de certificat à être signée par le CA .

−ss_cert nomfichier

un seul certificat auto-signé à être signé par le CA .

−spkac nomfichier

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.

−infiles

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.

−out nomfichier

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.

−outdir dossier

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

−cert

le fichier de certificat CA .

−keyfile nomfichier

la clé privée utilisée pour signer les certificats.

−key motdepasse

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.

−passin arg

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

−verbose

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

−notext

ne pas inclure la version texte d’un certificat dans le fichier de sortie.

−startdate date

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

−enddate date

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

−days arg

le nombre de jours que le certificat sera certifié

−md alg

la signature de message à utiliser. Les valeurs possibles incluent md5, sha1 et mdc2. Cette option s’applique également aux CRL.

−policy arg

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.

−msie_hack

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.

−preserveDN

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.

−batch

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.

−extensions section

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

−gencrl

cette options génère une CRL basée sur l’information trouvée dans le fichier d’index.

−crldays num

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 .

−crlhours num

le nombre de jours avant passage à la CRL suivante.

−revoke nomfichier

le nom de fichier contenant un certificat à retirer.

−crlexts section

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.

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.

oid_file

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.

oid_section

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.

new_certs_dir

identique à l’option de ligne de commande −outdir. On spécifie le répertoire où les nouveaux certificats seront placés. Obligatoire.

certificate

identique à −cert. On spécifie le fichier contenant le certificat CA . Obligatoire.

private_key

identique à l’option −keyfile. Le fichier contenant la clé privée CA . Obligatoire.

RANDFILE

un fichier utilisé pour lire et écrire l’information sur la racine des nombres pseudoaléatoires, ou un socket EGD (cf RAND_egd(3)).

default_days

identique à l’option −days. Le nombre de jours qu’un certificat sera certifié.

default_startdate

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.

default_enddate

identique à l’option −enddate. Soit cette option-ci soit default_days (où les équivalents en mode ligne de commande) doivent être présent.

default_crl_hours default_crl_days

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 .

default_md

identique à l’option −md. La signature de message à utiliser. Obligatoire.

database

le fichier texte - base de données - à utiliser. Obligatoire. Ce fichier doit être présent même si initialement vide.

serialfile

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.

x509_extensions

identique à −extensions.

crl_extensions

identique à −crlexts.

preserve

identique à −preserveDN

msie_hack

identique à −msie_hack

policy

identique à −policy. Obligatoire. Référez-vous à la section FORMAT DE LA POLICY pour plus d’information.

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.

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

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

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.

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

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

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

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.

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