Provided by: manpages-fr-extra_20151231_all 
NOM
ts - Outil d’autorité d’horodatage (client et serveur)
SYNOPSIS
openssl ts -query [-rand fichier:fichier...] [-config fichier_conf] [-data fichier_à_hacher] [-digest
octets_sign] [-md2|-md4|-md5|-sha|-sha1|-mdc2|-ripemd160|...] [-policy id_objet] [-no_nonce] [-cert] [-in
demande.tsq] [-out demande.tsq] [-text]
openssl ts -reply [-config fichier_conf] [section section_tsa] [-queryfile demande.tsq] [-passin
src_mot_de_passe] [-signer tsa_cert.pem] [-inkey privée.pem] [-chain fichier_certs.pem] [-policy
id_objet] [-in réponse.tsr] [-token_in] [-out response.tsr] [-token_out] [-text] [-engine id]
openssl ts -verify [-data fichier_à_hacher] [-digest octets_sign] [-queryfile demande.tsq] [-in
réponse.tsr] [-token_in] [-CApath chemin_cert_confiance] [-CAfile certs_confiance.pem] [-untrusted
fichier_cert.pem]
DESCRIPTION
La commande ts est une application client et serveur d’autorité d’horodatage (« Time Stamping
Authority », TSA) conforme à la RFC 3161 (protocole d'horodatage, « Time-Stamp Protocol » TSP). Une TSA
peut faire partie d'un déploiement de PKI et son rôle est de fournir des preuves à long terme de
l'existence d'une certaine donnée avant un moment donné. Voici une brève description du protocole.
1. Le client TSA calcule une valeur de hachage à sens unique pour un fichier de données et envoie le
hachage à la TSA.
2. La TSA attache la date et l'heure à la valeur de hachage reçue, les signe et envoie le jeton
d’horodatage au client. En créant ce jeton, la TSA certifie l'existence du fichier original de
données au moment où la réponse est créée.
3. Le client TSA reçoit le jeton d'horodatage et en vérifie la signature. Il vérifie également si le
jeton contient la même valeur de hachage qu'il avait envoyé à la TSA.
Une unité de données de protocole encodée DER est définie pour le transport d'une demande d'horodatage à
la TSA et une autre pour l'envoi de la réponse d'horodatage au client. La commande ts a trois fonctions
principales : créer une demande d'horodatage à partir d'un fichier de données, créer une réponse
d'horodatage à partir d'une demande et vérifier si une réponse correspond à une demande particulière ou à
un fichier de données.
Aucune prise en charge n’existe encore pour l’envoi de demandes et réponses automatiquement par HTTP ou
TCP comme suggéré dans la RFC 3161. Les utilisateurs doivent envoyer les demandes par FTP ou courrier
électronique.
OPTIONS
Création de demande d’horodatage
L’option -query peut être utilisée pour créer et afficher une demande d'horodatage avec les options
suivantes :
-rand fichier:fichier...
Les fichiers contenant des données aléatoires utilisées pour initialiser le générateur de nombres
pseudoaléatoires. Plusieurs fichiers peuvent être indiqués en utilisant le séparateur du système
d'exploitation : « ; » pour Windows, « , » pour OpenVMS et « : » pour tous les autres. (Facultatif)
-config fichier_conf
Le fichier de configuration à utiliser, cette option remplace la variable d'environnement
OPENSSL_CONF. Seule la section OID du fichier de configuration est utilisée avec la commande -query.
(Facultatif)
-data fichier_à_hacher
Le fichier de données pour lequel la demande d'horodatage doit être créée. L’entrée standard est la
valeur par défaut si aucune des options -data ou -digest n’est indiquée. (Facultatif)
-digest octets_sign
Indiquer explicitement l’empreinte du message est possible sans le fichier de données. L’empreinte
doit être indiquée au format hexadécimal, deux caractères par octet, les octets éventuellement
séparés par des deux-points (par exemple 1A:F6:01:... ou 1AF601...). Le nombre d’octets doit
correspondre à l’algorithme de signature de message utilisé. (Facultatif)
-md2|-md4|-md5|-sha|-sha1|-mdc2|-ripemd160|...
La signature de message à appliquer au fichier de données, tous les algorithmes de signature de
message pris en charge par la commande openssl dgst sont utilisables. La valeur par défaut est SHA-1.
(Facultatif)
policy id_objet
La politique attendue par le client de la TSA à utiliser pour créer le jeton d'horodatage. Soit la
notation OID avec points, soit les noms d’OID définis dans le fichier de configuration peuvent être
utilisés. Si aucune politique n’est demandée, la TSA utilisera sa propre politique par défaut.
(Facultatif)
-no_nonce
Aucun nonce n’est indiqué dans la demande si cette option est donnée. Sinon, un nonce pseudoaléatoire
de 64 bits est inclus dans la demande. Utiliser nonce est recommandé pour se protéger contre les
attaques par rejeu. (Facultatif)
-cert
La TSA devrait inclure son certificat de signature dans la réponse. (Facultatif)
-in demande.tsq
Cette option indique une demande d'horodatage précédemment créée au format DER qui sera envoyée dans
le fichier de sortie. Utile pour examiner le contenu d'une demande au format lisible. (Facultatif)
-out demande.tsq
Nom du fichier de sortie où la demande doit être écrite. La sortie standard par défaut. (Facultatif)
-text
Si cette option est indiquée, la sortie est au format texte lisible au lieu de DER. (Facultatif)
Création de réponse d’horodatage
Une réponse d’horodatage (TimeStampResp) se compose d'un état de réponse et du jeton d'horodatage
lui-même (ContentInfo), si la création du jeton a réussi. La commande -reply permet de créer une réponse
d'horodatage ou un jeton d'horodatage suivant la demande et l’affichage de la réponse ou du jeton dans un
format lisible. Si -token_out n'est pas indiqué, la sortie est toujours une réponse d'horodatage
(TimeStampResp), sinon c'est un jeton d'horodatage (ContentInfo).
-config fichier_conf
Le fichier de configuration à utiliser, cette option remplace la variable d'environnement
OPENSSL_CONF. Consultez OPTIONS DU FICHIER DE CONFIGURATION pour les variables configurables.
(Facultatif)
-spksect section
Le nom de la section du fichier de configuration contenant les paramètres pour la création de la
réponse. S'il n'est pas indiqué, la section TSA par défaut est utilisée, consultez OPTIONS DU FICHIER
DE CONFIGURATION pour plus de précisions. (Facultatif)
-queryfile demande.tsq
Le nom du fichier contenant une demande d’horodatage encodée en DER. (Facultatif)
-passin src_mot_de_passe
Indiquer la source pour la clef privée de la TSA. Consultez la section PARAMÈTRES DE PHRASE SECRÈTE
d'openssl(1).
-signer tsa_cert.pem
Le certificat de signataire de la TSA au format PEM. Le certificat de signature TSA doit avoir
exactement une utilisation de clef étendue attribuée : timeStamping. L'utilisation de la clef étendue
doit aussi être critique, sinon le certificat sera refusé. Cela remplace la variable signer_cert du
fichier de configuration. (Facultatif)
-inkey privée.pem
La clef privée du signataire de la TSA au format PEM. Cela remplace l'option signer_key du fichier de
configuration. (Facultatif)
-chain fichier_certs.pem
L’ensemble des certificats au format PEM qui seront tous inclus dans la réponse en plus du certificat
de signataire si l'option -cert a été utilisée pour la demande. Ce fichier est censé contenir la
chaîne de certificats pour le certificat de signataire à partir de ses émetteurs. La commande -reply
ne construit pas de chaîne de certificats automatiquement. (Facultatif)
policy id_objet
La politique par défaut à utiliser pour la réponse à moins que le client ne demande explicitement une
politique TSA particulière. L'OID peut être indiqué en utilisant une notation avec points ou par son
nom. Cela remplace l'option default_policy du fichier de configuration. (Facultatif)
-in réponse.tsr
Indiquer une réponse d'horodatage créée précédemment ou un jeton d'horodatage (si -token_in est
également indiquée) au format DER qui sera écrit dans le fichier de sortie. Cette option ne nécessite
pas de demande, elle est par exemple utile pour examiner le contenu d'une réponse ou d'un jeton ou
pour extraire le jeton d'horodatage d'une réponse. Si l'entrée est un jeton et la sortie une réponse
d'horodatage, une information d’état accordée (« granted ») par défaut est ajoutée au jeton.
(Facultatif)
-token_in
Cet indicateur peut être utilisé avec l'option -in et indique que l'entrée est un jeton d'horodatage
encodé DER (ContentInfo) au lieu d'une réponse d'horodatage (TimeStampResp). (Facultatif)
-out réponse.tsr
La réponse est écrite dans ce fichier. Le format et le contenu du fichier dépendent d'autres options
(consultez -text, -token_out). La valeur par défaut est la sortie standard. (Facultatif)
-token_out
La sortie est un jeton d'horodatage (ContentInfo) au lieu d’une réponse d’horodatage (TimeStampResp).
(Facultatif)
-text
Si cette option est indiquée, la sortie est au format texte lisible au lieu de DER. (Facultatif)
-engine id
Indiquer un moteur (en utilisant son identifiant unique id) forcera ts à essayer d'obtenir une
référence fonctionnelle pour le moteur indiqué et l'initialiser si nécessaire. Le moteur sera ensuite
utilisé par défaut pour tous les algorithmes disponibles. La valeur par défaut est « builtin ».
(Faclutatif)
Vérification de réponse d’horodatage
La commande -verify sert à vérifier si une réponse d'horodatage ou un jeton d'horodatage est valable et
correspond à une demande d'horodatage ou un fichier de données particuliers. La commande -verify
n'utilise pas le fichier de configuration.
-data fichier_à_hacher
La réponse ou le jeton doivent être vérifiés par rapport à fichier_à_hacher. Le fichier est haché
avec l’algorithme de signature de message indiqué dans le jeton. Les options -digest et -queryfile ne
doivent pas être indiquées avec cette option. (Facultatif)
-digest octets_sign
La réponse ou le jeton doivent être vérifiés par rapport à la signature de message indiquée par cette
option. Le nombre d'octets doit correspondre à l’algorithme de signature de message indiqué dans le
jeton. Les options -data et -queryfile ne doivent pas être indiquées avec cette option. (Facultatif)
-queryfile demande.tsq
La demande originale d’horodatage au format DER. Les options -data et -queryfile ne doivent pas être
indiquées avec cette option. (Facultatif)
-in réponse.tsr
La réponse d'horodatage à vérifier au format DER. (Obligatoire)
-token_in
Cet indicateur peut être utilisé avec l'option -in et indique que l'entrée est un jeton d'horodatage
encodé DER (ContentInfo) au lieu d'une réponse d'horodatage (TimeStampResp). (Facultatif)
-CApath chemin_cert_confiance
Le nom du répertoire contenant les certificats de l’autorité de confiance du client. Consultez
l'option similaire de verify(1) pour plus de précisions. Soit cette option, soit -CAfile doit être
indiquée. (Facultatif)
-CAfile certs_confiance.pem
Le nom du fichier contenant un ensemble de certificats autosignés de l’autorité de confiance au
format PEM. Consultez l'option similaire de verify(1) pour plus de précisions. Soit cette option,
soit -CApath doit être indiquée. (Facultatif)
-untrusted fichier_cert.pem
Ensemble de certificats supplémentaires qui ne sont pas de confiance au format PEM pouvant être
nécessaires lors de la construction de la chaîne de certificats d'un certificat de signature de la
TSA. Ce fichier doit contenir le certificat de signature TSA et tous les certificats d’autorité
intermédiaires sauf si la réponse les inclut. (Facultatif)
OPTIONS DU FICHIER DE CONFIGURATION
Les commandes -query et -reply utilisent un fichier de configuration défini par la variable
d'environnement OPENSSL_CONF. Consultez config(5) pour une description générale de la syntaxe du fichier
de configuration. La commande -query n’utilise que la section des noms symboliques d’OID et peut
fonctionner sans elle. Cependant, la commande -reply a besoin du fichier de configuration pour
fonctionner.
Quand une option de ligne de commande est équivalente à une variable, l'option est toujours prioritaire
sur les paramètres du fichier de configuration.
Section tsa, default_tsa
C’est la section principale, qui indique le nom d’une autre section contenant toutes les options pour
la commande -reply. Cette section par défaut peut être remplacée par l’option -section en ligne de
commande. (Facultatif)
oid_file
Consultez ca(1) pour la description. (Facultatif)
oid_section
Consultez ca(1) pour la description. (Facultatif)
RANDFILE
Consultez ca(1) pour la description. (Facultatif)
serial
Le nom du fichier contenant le numéro de série hexadécimal de la dernière réponse d’horodatage créée.
Ce nombre est incrémenté de 1 pour chaque réponse. Si le fichier n'existe pas au moment de la
création de réponse d'un nouveau fichier, un nouveau est créé avec le numéro de série 1.
(Obligatoire)
crypto_device
Indiquer le moteur OpenSSL qui sera défini par défaut pour tous les algorithmes disponibles. La
valeur par défaut est « builtin », vous pouvez indiquer d'autres moteurs pris en charge par OpenSSL
(par exemple, utiliser chil pour le HSM nCipher). (Facultatif)
signer_cert
Certificat de signature TSA au format PEM. Identique à l'option -signer en ligne de commande.
(Facultatif)
certs
Un fichier contenant un ensemble de certificats encodés PEM qui doivent être inclus dans la réponse.
Identique à l'option -chain en ligne de commande. (Facultatif)
signer_key
La clef privée de la TSA au format PEM. Identique à l'option -inkey en ligne de commande.
(Facultatif)
default_policy
La politique par défaut à utiliser quand la demande n'exige pas de politique. Identique à -policy en
ligne de commande. (Facultatif)
other_policies
Liste des politiques, séparées par des virgules, qui sont aussi acceptables par la TSA et utilisées
seulement si la demande indique explicitement l'une d’entre elles. (Facultatif)
digests
La liste des algorithmes de signature de message que la TSA accepte. Au moins un algorithme doit être
indiqué. (Obligatoire)
accuracy
La précision de la source de temps de la TSA en seconde, milliseconde et microseconde. Par exemple
secs:1, millisecs:500, microsecs:100. Si l'un des composants est manquant, ce champ est supposé nul.
(Facultatif)
clock_precision_digits
Indiquer le nombre maximal de chiffres pour représenter la fraction de seconde qui doit être incluse
dans champ temporel. Les zéros finaux doivent être supprimés, donc moins de chiffres pourraient être
présents ou aucune fraction de seconde du tout. Pris en charge uniquement sur les plate-formes UNIX.
La valeur maximale est 6, la valeur par défaut est 0. (Facultatif)
ordering
Si cette option est « yes », les réponses créées par cette TSA peuvent toujours être ordonnées, même
si la différence de temps entre deux réponses est inférieure à la somme de leurs précisions. « no »
par défaut. (Facultatif)
tsa_name
Si cette option est « yes », le nom d'objet de la TSA doit être inclus dans le champ de noms TSA de
la réponse. « no » par défaut. (Facultatif)
ess_cert_id_chain
Les objets SignedData créés par la TSA contiennent toujours l'identifiant de certificat du certificat
de signature dans un attribut signé (consultez la RFC 2634, « Enhanced Security Services »). Si cette
option est « yes » et que soit la variable certs, soit l'option -chain est indiquée, les identifiants
de certificat de la chaîne seront également inclus dans l’attribut SigningCertificate signé. Si cette
variable est « no », seul l'identifiant de certificat de signature est inclus. « no » par défaut.
(Facultatif)
VARIABLES D'ENVIRONNEMENT
OPENSSL_CONF contient l'emplacement du fichier de configuration et peut être modifiée par l'option
-config en ligne de commande.
EXEMPLES
Tous les exemples ci-dessous supposent que OPENSSL_CONF est défini vers un fichier de configuration
approprié, comme dans le fichier d'exemple de configuration openssl/apps/openssl.cnf.
Demande d’horodatage
Pour créer une demande d'horodatage pour design1.txt avec SHA-1 sans nonce, avec la politique et sans
certificat nécessaire dans la réponse :
openssl ts -query -data design1.txt -no_nonce \
-out design1.tsq
Pour créer une demande d'horodatage similaire en indiquant explicitement l’empreinte du message :
openssl ts -query -digest b7e5d3f93198b38379852f2c04e78d73abdd0f4b \
-no_nonce -out design1.tsq
Pour afficher le contenu de la requête précédente en format lisible :
openssl ts -query -in design1.tsq -text
Pour créer une demande d'horodatage qui comprend la signature MD-5 de design2.txt, demande le certificat
du signataire et nonce, indique un identifiant de politique (en supposant que le nom tsa_policy1 est
défini dans la section OID du fichier de configuration) :
openssl ts -query -data design2.txt -md5 \
-policy tsa_policy1 -cert -out design2.tsq
Réponse d’horodatage
Avant de créer une réponse, un certificat de signature doit être créé pour la TSA qui contient
l'extension d’utilisation de clef étendue critique timeStamping sans aucune autre extension d'utilisation
de clef. Vous pouvez ajouter la ligne « extendedKeyUsage = critical,timeStamping » à la section de
certificat utilisateur du fichier de configuration pour créer un certificat approprié. Consultez req(1),
ca(1) et x509(1) pour les instructions. Les exemples ci-dessous supposent que cacert.pem contient le
certificat de l’autorité de certification, tsacert.pem est le certificat de signature émis par cacert.pem
et tsakey.pem est la clef privée de la TSA.
Pour créer une réponse d'horodatage pour une requête :
openssl ts -reply -queryfile design1.tsq -inkey tsakey.pem \
-signer tsacert.pem -out design1.tsr
Pour utiliser les paramètres du fichier de configuration :
openssl ts -reply -queryfile design1.tsq -out design1.tsr
Pour afficher une réponse d’horodatage sur la sortie standard sous forme lisible :
openssl ts -reply -in design1.tsr -text
Pour créer un jeton d'horodatage au lieu d’une réponse d'horodatage :
openssl ts -reply -queryfile design1.tsq -out design1_token.der \
-token_out
Pour afficher un jeton d’horodatage sur la sortie standard sous forme lisible :
openssl ts -reply -in design1_token.der -token_in -text -token_out
Pour extraire le jeton d'horodatage d'une réponse :
openssl ts -reply -in design1.tsr -out design1_token.der -token_out
Pour ajouter l’information d’état « granted » (accordé) à un jeton d'horodatage créant ainsi une réponse
valable :
openssl ts -reply -in design1_token.der -token_in -out design1.tsr
Vérification d’horodatage
Pour vérifier une réponse d’horodatage par rapport à une demande :
openssl ts -verify -queryfile design1.tsq -in design1.tsr \
-CAfile cacert.pem -untrusted tsacert.pem
Pour vérifier une réponse d’horodatage qui comprend la chaîne de certificats :
openssl ts -verify -queryfile design2.tsq -in design2.tsr \
-CAfile cacert.pem
Pour vérifier un jeton d'horodatage par rapport au fichier de données d'origine :
openssl ts -verify -data design2.txt -in design2.tsr \
-CAfile cacert.pem
Pour vérifier un jeton d'horodatage par rapport à une empreinte de message :
openssl ts -verify -digest b7e5d3f93198b38379852f2c04e78d73abdd0f4b \
-in design2.tsr -CAfile cacert.pem
D’autres exemples sont aussi disponibles dans le répertoire test.
BOGUES
Les bogues et suggestions peuvent être envoyés à Zoltan Glozik <zglozik@opentsa.org>. Une liste des
problèmes connus suit.
— Pas de prise en charge d’horodatages par SMTP, mais c’est assez facile de mettre en œuvre une TSA
automatique à base de courriers électroniques avec procmail(1) et perl(1). La prise en charge du serveur
HTTP est fournie sous forme d'un module Apache séparé. La prise en charge de client HTTP est assurée par
tsget(1). Le protocole TCP/IP pur n'est pas pris en charge.
— Le fichier contenant le dernier numéro de série de la TSA n'est pas verrouillé lorsqu'il est lu ou
écrit. C’est un problème si plusieurs instances d’openssl(1) tentent de créer une réponse d'horodatage en
même temps. Ce n'est pas un problème si le module de serveur Apache est utilisé : il fait un verrouillage
correct.
— Recherchez le mot « FIXME » dans les fichiers source.
— Le code source devrait vraiment être examiné par quelqu'un d'autre.
— Plus de tests sont nécessaires, seuls quelques tests de base ont été effectués (consultez
test/testtsa).
AUTEUR
Zoltan Glozik <zglozik@opentsa.org>, projet OpenTSA (<http://www.opentsa.org>)
VOIR AUSSI
tsget(1), openssl(1), req(1), x509(1), ca(1), genrsa(1), config(5)
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 TS(1SSL)