Scroll to navigation

OPENSSL-CA(1SSL) OpenSSL OPENSSL-CA(1SSL)

NOM

openssl-ca - Échantillon d'application minimale d'autorité de certification

SYNOPSIS

openssl ca [-help] [-verbose] [-quiet] [-config fichier] [-name section] [-section section] [-gencrl] [-revoke fichier] [-valid fichier] [-status série] [-updatedb] [-crl_reason raison] [-crl_hold instruction] [-crl_compromise moment] [-crl_CA_compromise moment] [-crl_lastupdate moment] [-crl_nextupdate moment] [-crldays nombre] [-crlhours nombre] [-crlsec nombre] [-crlexts section] [-startdate date] [-not_before date] [-enddate date] [-not_after date] [-days param] [-md algorithme] [-policy param] [-keyfile fichier|uri] [-keyform DER|PEM|P12|ENGINE] [-key mot_de_passe] [-passin param] [-cert fichier] [-certform DER|PEM|P12] [-selfsign] [-in fichier] [-inform DER|<PEM>] [-out fichier] [-notext] [-dateopt] [-outdir répertoire] [-infiles] [-spkac fichier] [-ss_cert fichier] [-preserveDN] [-noemailDN] [-batch] [-msie_hack] [-extensions section] [-extfile section] [-subj param] [-utf8] [-sigopt nm:v] [-vfyopt nm:v] [-create_serial] [-rand_serial] [-multivalue-rdn] [-rand fichiers] [-writerand fichier] [-engine id] [-provider nom] [-provider-path chemin] [-provparam [nom:]clé=valeur] [-propquery propq] [certreq...]

DESCRIPTION

Cette commande émule une application d'autorité de certification. Voir les AVERTISSEMENTS, en particulier si vous envisagez de l'utiliser en production.

Elle génère des certificats X.509 en version 3. Sauf mention contraire, les extensions d'identifiant de clés sont incluses, comme décrit dans x509v3_config(5).

Elle peut être utilisée pour signer des requêtes de certificat (CSRs) sous plusieurs formes et pour générer des listes de révocation de certificats (CRLs). Elle maintient également une base de données textuelle des certificats traités et de leur statut. Lors de la signature de certificats, une seule requête peut être indiquée avec l'option -in, ou bien plusieurs requêtes peuvent être gérées en indiquant un ensemble de fichiers certreq après toutes les options.

Remarquez qu'il existe également des méthodes très légères pour générer des certificats : les commandes req et x509 peuvent être utilisées pour créer directement des certificats. Voir openssl-req(1) et openssl-x509(1) pour des détails.

Les descriptions des options de la commande ca sont divisées par type d'action.

OPTIONS

Afficher un message d'utilisation.
Afficher des précisions supplémentaires sur les opérations effectuées.
Afficher des précisions supplémentaires sur les opérations effectuées, ce qui peut être commode lors de l'exécution de scripts ou de redirections dans des « tubes ».
Indiquer le fichier de configuration à utiliser. Facultatif, pour une description de la valeur par défaut, voir « RÉSUMÉ DE LA COMMANDE » dans openssl(1).
Indiquer la section du fichier de configuration à utiliser (supplante default_ca dans la section ca).
Un nom de fichier en entrée contenant une seule demande de certificat (CSR, pour single certificate request) à signer par l'autorité de certification.
Le format à utiliser lors du chargement des fichiers d'entrée de requête de certificats (CSR) ; par défaut, PEM est essayé en premier. Voir openssl-format-options(1) pour des détails.
Un seul certificat autosigné à signer par l'autorité de certification.
Un fichier contenant une unique clé publique Netscape signée, un défi (challenge) et des données supplémentaires à signer par l'autorité de certification. Consultez la section FORMAT SPKAC pour des informations sur le format d’entrée et sortie demandé.
Si elle est présente, ce doit être la dernière option. Tous les paramètres suivants sont interprétés comme des noms de fichiers contenant des demandes de certificat.
Le fichier de sortie où les certificats seront dirigés. Par défaut il s'agit de la sortie standard. Les détails des certificats y seront également précisés au format PEM (sauf que -spkac utilise le format DER en sortie).
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 l'extension .pem.
Le certificat de l'autorité de certification, qui doit correspondre à -keyfile.
Le format des données dans les fichiers d'entrée de certificat ; non indiqué par défaut. Voir openssl-format-options(1) pour des de détails.
La clé privée de l'autorité de certification avec laquelle signer les demandes. Elle doit correspondre à -cert.
Le format du fichier d'entrée de la clé privée ; non indiqué par défaut. Voir openssl-format-options(1) pour des détails.
Passer les options à l'algorithme de signature pendant les opérations de signature. Les noms et les valeurs de ces options sont spécifiques à chaque algorithme et documentées dans « Paramètres de signature » de provider-signature(7).
Passer les options à l'algorithme de signature pendant les opérations de vérification de signature. Les noms et les valeurs de ces options sont spécifiques à chaque algorithme.

Cela doit souvent être fourni aussi pendant la signature, car l'auto-signature d'une requête de certificat (CSR) est vérifiée par rapport à la clé publique incluse et cette vérification pourrait avoir besoin de son propre ensemble d'options.

Le mot de passe utilisé pour chiffrer la clé privée. Sur certains systèmes les paramètres de la ligne de commande sont visibles (par exemple sous UNIX avec l'utilitaire ps(1)), une certaine prudence est donc nécessaire en utilisant cette option.
La source du mot de passe de la clé et des fichiers du certificat PKCS#12. Pour plus d'informations sur le format de param, consultez la section PARAMÈTRES DE PHRASE SECRÈTE d'openssl-passphrase-options(1).
Indiquer que les certificats émis sont à signer avec la clé utilisée pour signer les demandes de certificat (donnée avec -keyfile). Les demandes de certificat signées avec une clé différente sont ignorées. Si -spkac, -ss_cert ou -gencrl sont donnés, -selfsign est ignoré.

Une des conséquences d'utiliser -selfsign est que le certificat autosigné apparaît parmi les entrées de la base de données de certificats (consultez l'option de configuration database), et utilise le même compteur de numéro de série que tous les autres certificats signés avec le même certificat autosigné.

Ne pas inclure la version texte d'un certificat dans le fichier de sortie.
Indiquer le format de sortie de la date. Les valeurs sont : rfc_822 et iso_8601. Celle par défaut est rfc_822.
Cela permet de positionner explicitement une date de début. Le format de la date est AAMMJJHHMMSSZ (comme dans une structure UTCTime d'ASN1), ou AAAAMMJJHHMMSSZ (comme dans une structure GeneralizedTime ASN1). Dans les deux formats, les secondes SS et le fuseau horaire Z doivent être présents. Sinon, vous pouvez aussi utiliser « today » (aujourd'hui).
Définir la date de fin de validité explicitement. Le format de date utilisé est AAMMJJHHMMSSZ (comme pour une structure UTCTime ASN1), ou AAAAMMJJHHMMSSZ (comme pour une structure GeneralizedTime ASN1). Dans les deux formats, les secondes SS et le fuseau horaire Z doivent être présents. Autrement, vous pouvez aussi utiliser « today ».

Cela supplante l'option -days.

La durée en jours à partir d'aujourd'hui pendant laquelle le certificat sera certifié.

Indépendamment de l'option -not_before, les jours sont toujours comptés à partir d'aujourd'hui. Si on l'utilise avec l'option -not_after/-startdate, la date d'expiration explicite prend le dessus.

L'algorithme d'empreinte à utiliser. N'importe quelle empreinte prise en charge par la commande openssl-dgst(1) peut être utilisée. Pour les algorithmes de signature qui ne prennent pas en charge une empreinte (c'est-à-dire, Ed25519 et Ed448), n'importe quel algorithme d'empreinte positionné est ignoré. Cette option s'applique aussi aux CRLs.
Cette option définit la « politique » d'autorité de certification à utiliser. Il s'agit d'une section du fichier de configuration indiquant les champs qui sont obligatoires ou qui doivent correspondre au certificat de l'autorité de certification. Consultez la section FORMAT DES POLITIQUES pour plus d'informations.
C'est une option obsolète pour faire fonctionner cette commande avec les très vieilles versions du Certificate Enrollment Control « certenr3 » d'IE. Elle utilise UniversalStrings pour presque tout. Puisque l'ancien centre de contrôle est victime de plusieurs bogues de sécurité, son utilisation est fortement déconseillée.
Normalement, l'ordre des DN d'un certificat est le même que l'ordre des champs dans la section de politique. Quand l'option est définie, l'ordre est le même que celui de la demande. C'est surtout pour la compatibilité avec l'ancien Enrollment Control d'IE qui n'acceptait les certificats que si leurs DN correspondaient à l'ordre de la demande. Ce n'est plus nécessaire avec Xenroll.
Le DN d'un certificat peut contenir le champ EMAIL s'il est présent dans le DN de la demande, cependant c'est une bonne politique de n'avoir que l'adresse électronique configurée dans l'extension altName du certificat. Quand cette option est définie, le champ EMAIL est retiré du sujet du certificat et n'est défini seulement que dans les extensions éventuellement présentes. Le mot-clé email_in_dn peut être utilisé dans le fichier de configuration pour activer ce comportement.
Activer le mode de traitement par lots. Aucune question ne sera posée et tous les certificats seront signés automatiquement.
La section du fichier de configuration contenant les extensions de certificat à ajouter lorsqu'un certificat est émis (par défaut, ce sont les x509_extensions sauf si l'option -extfile est utilisée).

Voir la page de manuel de x509v3_config(5) pour des détails du format de section de l'extension.

Un fichier de configuration supplémentaire pour y lire les extensions de certificat (en utilisant la section par défaut si l'option -extensions n'est pas présente).
Remplace le nom du sujet fourni dans la requête.

Le paramètre doit être au format « /type0=valeur0/type1=valeur1/type2=... ». Les caractères spéciaux peuvent être échappés avec une contre-oblique (« \ »), les espaces vides sont conservés. Des valeurs vides sont autorisées mais le type correspondant ne sera pas inclus dans le certificat de sortie. Ne donner qu'une seule « / » aboutira à une séquence vide de RDNs (un NULL-DN). Des RDNs de plusieurs valeurs peuvent être formés en mettant un caractère « + » au lieu d'un « \ » entre les AttributeValueAssertions (AVAs) qui indiquent les membres de l'ensemble. Exemple :

"/DC=org/DC=OpenSSL/DC=users/UID=123456+CN=John Doe"

Cette option indique que les valeurs des champs doivent être interprétées comme des chaînes UTF-8. Par défaut, elles sont interprétées comme des chaînes ASCII. Cela signifie que les valeurs des champs, qu'elles soient demandées sur le terminal ou fournies par le fichier de configuration, doivent être des chaînes UTF-8 valables.
Si la lecture d'une série à partir du fichier texte tel qu'indiqué dans la configuration échoue, indiquer cette option créera une nouvelle série aléatoire à utiliser en tant que numéro de série textuel. Pour obtenir des numéros de série aléatoires, utilisez plutôt le drapeau -rand_serial ; cela ne devrait être utilisé que pour réparer des erreurs simples.
Générer un grand numéro de série à utiliser comme numéro de série. Cela supplante toute option ou toute configuration visant à utiliser un fichier de numéro de série.
Cette option est devenue obsolète et n'a pas d'effet.
Voir « Options d'état aléatoire » dans openssl(1) pour des détails.
Voir « Options de moteur » dans openssl(1). Cette option est obsolète.
Voir « Options de fournisseur » dans openssl(1), provider(7) et property(7).

OPTIONS POUR LES LISTES DE RÉVOCATIONS DE CERTIFICAT (CRL)

Cette option génère une liste de révocations de certificat basée sur les renseignements du fichier d'index.
Autoriser la valeur du champ lastUpdate de CRL à être explicitement positionnée ; si cette option n'est pas présente, le moment actuel est utilisé. Accepte les moments au format AAMMJJHHMMSSZ (comme dans une structure UTCTime ASN1) ou AAAAMMJJHHMMSSZ (comme dans une structure GeneralizedTime ASN1).
Autoriser la valeur du champ nextUpdate du CRL à être explicitement positionnée ; si cette option est présente, n'importe quelle valeur fournie par -crldays, -crlhours et -crlsec est ignorée. Accepte les moments dans le même format que -crl_lastupdate.
Le nombre de jours avant passage à la liste de révocations de certificat suivante. Ce nombre de jours, qui est décompté à partir de la date d'exécution, est à placer dans le champ nextUpdate de la liste de révocations de certificat.
Le nombre d'heures avant passage à la liste de révocations de certificat suivante.
Le nombre d'heures avant passage à la liste de révocations de certificat suivante.
Le nom du fichier contenant un certificat à révoquer.
Le nom du fichier contenant un certificat à ajouter à une entrée de certificat valable.
Afficher l’état de révocation du certificat avec le numéro de série indiqué et quitter.
Mettre à jour l’index de la base de donnée pour purger les certificats expirés.
La raison du retrait, où raison vaut : unspecified (« non précisée »), keyCompromise (« clé compromise »), CACompromise (« autorité de certification compromise »), affiliationChanged (« changement d'affiliation »), superseded (« remplacé »), cessationOfOperation (« cessation d'activité »), certificateHold (« certificat suspendu ») ou removeFromCRL (« retiré de la liste de révocations de certificat »). La casse de la raison n'a pas besoin de correspondre. L'ajout d'une raison au retrait forcera l'utilisation d'une CRL v2.

En pratique, removeFromCRL n'est pas particulièrement utile parce qu'elle n'est utilisée que pour les listes de révocations de certificat « delta », qui ne sont pas mises en œuvre pour l'instant.

Définir le code de raison de révocation d'une liste de révocations de certificat à certificateHold et l'instruction de suspension à instruction qui doit être un OID. Même si n'importe quel OID peut être utilisé, seuls holdInstructionNone (dont l'utilisation est déconseillée par la RFC 5280), holdInstructionCallIssuer ou holdInstructionReject seront normalement utilisés.
Définir la raison de révocation à keyCompromise et la date de la compromission à moment. moment doit être au format GeneralizedTime, c'est-à-dire AAAAMMDDHHMMSSZ.
Il s'agit de la même chose que crl_compromise, mais la raison de révocation est définie à CACompromise.
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 sera créée, même si la section en question est vide. Les extensions CRL indiquées sont des extensions CRL et non des extensions d'entrée CRL. Remarquez que certains logiciels (par exemple Netscape) ne gèrent pas les CRL V2. Consultez la page de manuel de x509v3_config(5) pour obtenir des précisions sur le format de section d'extensions.

OPTIONS DU FICHIER DE CONFIGURATION

La section du fichier de configuration contenant des options pour cette commande est trouvée de la façon suivante : si l'option de ligne de commande -name est utilisée, elle précise le nom de la section à utiliser. Autrement, la section qui sera utilisée est celle mentionnée par 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 dans la section ca :
RANDFILE
preserve
msie_hack

À l'exception de RANDFILE, c'est probablement un bogue et devrait être modifié dans les prochaines versions.

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écrite comme obligatoire doit être présente soit dans le fichier de configuration soit sur la ligne de commande (si c'est possible).

Indiquer le fichier contenant des IDENTIFIANTS D'OBJET supplémentaires. Chaque ligne est constituée de la forme numérique de l'identifiant d'objet suivie d'un espace puis du libellé court suivi à son tour d'un espace et finalement du libellé long.
Indiquer une section du fichier de configuration contenant d'autres identifiants d'objet. Chaque ligne est constituée du libellé court de l'identifiant d'objet suivi de = et de la forme numérique. Le libellé court et le libellé long sont identiques quand cette option est utilisée.
Identique à l'option de ligne de commande -outdir. Elle indique le répertoire où les nouveaux certificats seront placés. Obligatoire.
Identique à -cert. Elle indique le fichier contenant le certificat de l'autorité de certification. Obligatoire.
Identique à l'option -keyfile. Le fichier contenant la clef privée de l'autorité de certification. Obligatoire.
Au démarrage, le fichier indiqué est chargé dans le générateur de nombre aléatoire, à la fin, 256 octets y seront écrits (Remarque : l'utilisation d'un RANDFILE n'est plus nécessaire, voir la section « HISTORIQUE »).
Identique à l'option -days. La durée en jour pendant laquelle le certificat sera certifié.
Identique à l'option -startdate. La date de début de validité du certificat. Si cette option est absente, la date actuelle sera utilisée.
Identique à l'option -enddate. Soit cette option, soit default_days (où les équivalents en ligne de commande) doivent être présents.
Identiques aux options -crlhours et -crldays. Uniquement utilisées si aucune des options n'est présente sur la ligne de commande. Au moins une de ces options doit être indiquée pour générer une liste de révocations de certificat.
Identique à l'option -md. Obligatoire, sauf si l'algorithme de signature n'exige pas d'empreinte (c'est-à-dire Ed25519 et Ed448).
Le fichier texte (base de données) à utiliser. Obligatoire. Ce fichier doit être présent même s'il est initialement vide.
Si la valeur yes est donnée, les entrées valables de certificat dans la base de données doivent avoir des sujets uniques. Si la valeur no est donnée, plusieurs entrées valables de certificat peuvent avoir le même sujet. La valeur par défaut est yes, par compatibilité avec les plus anciennes versions d'OpenSSL (avant 0.9.8). Cependant, pour faciliter le remplacement des certificats d'autorité de certification, l'utilisation de la valeur no est recommandée, en particulier si combinée avec l'option -selfsign de la ligne de commande.

Remarquez qu'il est valable, dans certaines circonstances, pour des certificats à créer, de ne pas avoir de sujet. S'il y a plusieurs certificats sans sujet, cela ne compte pas comme un doublon.

Un fichier texte contenant le prochain numéro de série à utiliser en hexadécimal. Obligatoire. Ce fichier doit être présent et contenir un numéro de série valable.
Un fichier texte contenant le prochain numéro de liste de révocations de certificat à utiliser en hexadécimal. Le numéro ne sera inséré dans les listes de révocations de certificat que si le fichier existe. Si ce fichier est présent, il doit contenir un numéro valable de liste de révocations de certificat.
Solution de repli à l'option -extensions.
Solution de repli à l'option -crlexts.
Identique à -preserveDN
Identique à -noemailDN. Si vous voulez que le champ EMAIL soit supprimé du DN du certificat, définissez-le simplement à « no ». S'il n'est pas présent, le champ EMAIL sera permis dans le DN du certificat par défaut.
Identique à -msie_hack
Identique à -policy. Obligatoire. Consultez la section FORMAT DES POLITIQUES pour plus de renseignements.
Ces options permettent au format utilisé d'afficher les précisions du certificat lors de la demande de confirmation de signature à l'utilisateur. Tous les paramètres pris en charge par les options -nameopt et -certopt des utilitaires x509 peuvent être utilisés ici, sauf que no_signame et no_sigdump sont définis de façon permanente et ne peuvent pas être désactivés (parce que le certificat n'a pas été signé à ce moment, donc la signature du certificat ne peut pas être affichée).

Par commodité, les valeurs ca_default sont acceptées par les deux pour produire une sortie raisonnable.

Si aucune option n'est présente, le format utilisé dans les versions précédentes d'OpenSSL est utilisé. L'utilisation de l'ancien format est fortement déconseillée, parce qu'il n'affiche que les champs mentionnés dans la section policy, ne gère pas correctement les types de chaîne multicaractère et n'affiche pas les extensions.

Déterminer la façon de traiter les extensions des demandes de certificat. Si définie à none, ou si cette option n'est pas présente, alors les extensions sont ignorées et ne sont pas copiées vers le certificat. Si définie à copy, toutes les extensions présentes dans la demande qui ne sont pas déjà présentes sont copiées vers le certificat. Si définie à copyall, toutes les extensions de la demande sont copiées vers le certificat : si l'extension est déjà présente dans le certificat, elle est d'abord supprimée. Consultez la section AVERTISSEMENTS avant d'utiliser cette option.

L'utilisation principale de cette option est de permettre à une demande de certificat de fournir des valeurs pour certaines extensions comme subjectAltName.

FORMAT DES POLITIQUES

La section policy consiste en un jeu de variables qui correspondent 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 de l'autorité de certification. 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é silencieusement, à moins que l'option -preserveDN ne soit activée, mais c'est plus une bizarrerie qu'un comportement attendu.

FORMAT SPKAC

L'entrée fournie à la ligne de commande -spkac est une clef publique signée Netscape et un défi. Cela provient habituellement d'une balise KEYGEN dans un formulaire HTML pour créer une nouvelle clef privée. Il est toutefois possible de créer des SPKAC en utilisant l'utilitaire openssl-spkac(1).

Le fichier devrait contenir la variable SPKAC avec la valeur de la clé SPARK ainsi que les éléments DN 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 « . ».

Lors du traitement du format SPKAC, la sortie est au format DER si l’attribut -out est utilisé, mais au format PEM si elle est envoyée vers la sortie standard ou que l’attribut -outdir est utilisé.

EXEMPLES

Note : ces exemples supposent que l'arborescence de cette commande est déjà en place et que les fichiers liés existent. Cela nécessite généralement la création d'un certificat et d'une clé privée pour l'autorité de certification avec openssl-req(1), 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/prive et demoCA/nouvcerts. Le certificat de l'autorité de certification doit être copié dans demoCA/cacert.pem et sa clé privée dans demoCA/prive/clefca.pem. Un fichier demoCA/serie doit être créé contenant par exemple « 01 » et un fichier d'index vide doit être créé dans demoCA/index.txt.

Signer une demande de certificat :



 openssl ca -in dem.pem -out nouvcert.pem

Signer une demande de certificat SM2 :

 openssl ca -in sm2.csr -out sm2.crt -md sm3 \
         -sigopt "distid:1234567812345678" \
         -vfyopt "distid:1234567812345678"

Signer une demande de certificat utilisant des extensions d'autorité de certification :



 openssl ca -in dem.pem -extensions v3_ca -out nouvcert.pem

Générer une liste de révocations de certificat :



 openssl ca -gencrl -out crl.pem

Signer plusieurs demandes :



 openssl ca -infiles dem1.pem dem2.pem dem3.pem

Certifier un SPKAC Netscape :



 openssl ca -spkac spkac.txt

Un fichier SPKAC type (lignes tronquées pour la lisibilité) :



 SPKAC=MIG0MGAwXDANBgkqhkiG9w0BAQEFAANLADBIAkEAn7PDhCeV/xIxUg8V70YRxK2A5


 CN=Steve Test


 emailAddress=steve@openssl.org


 0.OU=Groupe OpenSSL


 1.OU=Un autre groupe

Un fichier de configuration type avec les sections adéquates pour cette commande :



 [ ca ]


 default_ca      = CA_default            # La section autorité de certification par défaut


 [ CA_default ]


 dir            = ./demoCA              # répertoire racine


 database       = $dir/index.txt        # fichier d'index.


 new_certs_dir  = $dir/nouvcerts        # nouveau rép des certif


 certificate    = $dir/cacert.pem       # Le certif de l'autorité de certif


 serial         = $dir/serial           # n° de série du fichier


 #rand_serial    = yes                  # pour les numéros de série aléatoires


 private_key    = $dir/prive/cléca.pem  # clé privée de l'autorité de certification


 default_days   = 365                   # combien de temps certifier


 default_crl_days= 30                   # combien de temps avant la CRL suivante


 default_md     = sha256                # md à utiliser


 policy         = policy_any            # politique par défaut


 email_in_dn    = no                    # Ne pas ajouter d'email au DN du certif


 


 name_opt       = ca_default            # Option d'affichage du nom du sujet


 cert_opt       = ca_default            # Option d'affichage du certificat


 copy_extensions = none                 # Ne pas copier les extensions depuis la requête


 [ policy_any ]


 countryName            = supplied


 stateOrProvinceName    = optional


 organizationName       = optional


 organizationalUnitName = optional


 commonName             = supplied


 emailAddress           = optional

FICHIERS

Note : l'emplacement de tous les fichiers peut changer en fonction des options de compilation, des entrées dans le fichier de configuration, des variables d'environnement ou des 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 maître


 ./demoCA                       - répertoire principal de la CA


 ./demoCA/cacert.pem            - certificat de la CA


 ./demoCA/private/cakey.pem     - clef privée de la CA


 ./demoCA/serial                - fichier des numéros de série de la CA


 ./demoCA/serial.old            - sauvegarde de ./demoCA/serial


 ./demoCA/index.txt             - base de données en texte de la CA


 ./demoCA/index.txt.old         - sauvegarde de ./demoCA/index.txt


 ./demoCA/certs                 - fichier de sortie du certificat

RESTRICTIONS

Le fichier d'index est une partie cruciale du processus et toute corruption peut s'avérer difficile à rattraper. Bien qu'il soit possible théoriquement de reconstruire l'index à partir des certificats délivrés et d'une liste de révocations de certificat récente, aucune option ne permet de faire cela.

Les fonctionnalités des CRL V2 telles que la prise en charge des delta CRL ne sont pas géré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 autosigné.

BOGUES

Cette commande est capricieuse et parfois peu facile d'utilisation.

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.

Cette commande a réellement besoin d'être réécrite ou les fonctionnalités nécessaires devraient être fournies par une commande ou une interface pour permettre à des utilitaires plus orientés utilisateurs de traiter les choses correctement. Le script CA.pl aide un petit peu mais pas beaucoup.

Tous les champs d'une demande qui ne sont pas présents dans la politique sont supprimés silencieusement. Cela n'arrive pas si l'option -preserveDN est utilisée. Pour renforcer l'absence du champ EMAIL dans le DN, conformément aux suggestions des RFC, quelque soit le contenu du sujet de la demande, l'option -noemailDN peut être utilisée. Le comportement devrait être plus simple et configurable.

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

AVERTISSEMENTS

Cette commande a été, à l'origine, conçue pour servir d'exemple sur la manière de faire les choses dans une autorité de certification. Son code n'a pas une qualité de production. Il n'avait pas vocation à être utilisé comme un exemple complet d’autorité de certification, cependant certains l'utilisent pour ce faire, au moins en interne. Si vous le faites, vous devez accorder un soin particulier à sécuriser correctement la/les clé(s) privée(s) utilisée(s) pour signer des certificats. Nous vous recommandons de les conserver sur un support de stockage externe et sécurisé tel qu'une carte SD ou un HSM et d'y accéder à l'aide d'un fournisseur de chiffrement ou un moteur convenable.

Cette commande est en fait une commande mono-utilisateur, aucun verrouillage n'est fait sur les divers fichiers, et des tentatives d’exécuter plus d’une commande openssl ca sur la même base de données peuvent produire des résultats imprévisibles.

L'option copy_extensions devrait être utilisée avec précaution. Un risque de sécurité est possible si le soin nécessaire n'est pas accordé. Par exemple, si une demande de certificat contient une extension basicConstraints avec CA:TRUE et que la valeur copy_extensions est définie à copyall et que l'utilisateur ne s'en rend pas compte quand le certificat est affiché, alors cela fournira au demandeur un certificat d'autorité de certification valable. Cette situation peut être évitée en positionnant copy_extensions à copy et en incluant basicConstraints avec CA:FALSE dans le fichier de configuration. Alors, si la requête contient une extension basicConstraints, elle sera ignorée.

Il est aussi conseillé d'inclure les valeurs pour les autres extensions comme keyUsage pour éviter qu'une demande ne fournisse ses propres valeurs.

Des restrictions supplémentaires peuvent être ajoutées au certificat de l'autorité de certification lui-même. Par exemple si le certificat de l'autorité de certification contient :



 basicConstraints = CA:TRUE, pathlen:0

alors même si un certificat est émis avec CA:TRUE, il ne sera pas valable.

HISTORIQUE

Depuis OpenSSL 1.1.1, le programme suit la RFC5280. En particulier, la période de validité d'un certificat (indiquée par -startdate, -enddate et -days) et le moment de la dernière/prochaine mise à jour de la CRL (indiqué par -crl_lastupdate, -crl_nextupdate, -crldays, -crlhours et -crlsec) sera encodée en UTCTime si les dates sont antérieures à l'année 2049 (comprise) et en GeneralizedTime si les dates sont en l'année 2050 ou au-delà.

OpenSSL 1.1.1 a introduit un nouveau générateur d'aléas (CSPRNG) avec une amélioration du mécanisme d'initialisation. Le nouveau mécanisme d'initialisation n'oblige plus à définir un RANDFILE pour sauvegarder et restaurer l'aléa. Cette option est conservée principalement pour des raisons de rétro-compatibilité.

L'option -section a été ajoutée à OpenSSL 3.0.0.

L'option -multivalue-rdn est devenue obsolète dans OpenSSL 3.0.0 et elle n'a aucun effet.

L’option -engine est obsolète depuis OpenSSL 3.0.

Depuis OpenSSL 3.2, les certificats générés portent la version X.509 version 3 et les extensions d'identifiant de clés sont incluses par défaut.

VOIR AUSSI


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

COPYRIGHT

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

Sous licence Apache 2.0 (la « Licence »). Vous ne pouvez utiliser ce fichier que conformément à la Licence. Vous trouverez une copie dans le fichier LICENSE de la distribution du 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 stolck, Nicolas François <nicolas.francois@centraliens.net>, David Prévot <david@tilapin.org> et Jean-Philippe MENGUAL <jpmengual@debian.org>

Cette traduction est une documentation libre ; veuillez vous reporter à la GNU General Public License version 3 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.

29 septembre 2026 3.6.5