Provided by: manpages-fr-extra_20151231_all 
NOM
SSL_CTX_set_verify, SSL_set_verify, SSL_CTX_set_verify_depth, SSL_set_verify_depth - Définir les
paramètres de vérification du certificat du pair
SYNOPSIS
#include <openssl/ssl.h>
void SSL_CTX_set_verify(SSL_CTX *ctx, int mode,
int (*verify_callback)(int, X509_STORE_CTX *));
void SSL_set_verify(SSL *s, int mode,
int (*verify_callback)(int, X509_STORE_CTX *));
void SSL_CTX_set_verify_depth(SSL_CTX *ctx,int profondeur);
void SSL_set_verify_depth(SSL *s, int profondeur);
int verify_callback(int preverify_ok, X509_STORE_CTX *x509_ctx);
DESCRIPTION
SSL_CTX_set_verify() définit les attributs de vérification pour ctx à mode et précise la fonction
verify_callback à utiliser. Si aucune fonction de rappel n’est précisée, le pointeur NULL peut être
utilisé pour verify_callback.
SSL_CTX_set_verify() définit les attributs de vérification pour ssl à mode et précise la fonction
verify_callback à utiliser. Si aucune fonction de rappel n’est précisée, le pointeur NULL peut être
utilisé pour verify_callback. Dans ce cas, le dernier verify_callback défini précisément pour ce ssl est
conservé. Si aucun rappel n’était défini auparavant, le rappel par défaut pour le ctx sous-jacent, et qui
était valable au moment où ssl a été créé avec SSL_new(3), est utilisé.
SSL_CTX_set_verify_depth() définit la profondeur maximale pour la vérification de chaîne de certificats
qui sera autorisée pour ctx (consultez la section BOGUES).
SSL_CTX_set_verify_depth() définit la profondeur maximale pour la vérification de chaîne de certificats
qui sera autorisée pour ssl (consultez la section BOGUES).
NOTES
La vérification des certificats peut être contrôlée par une suite d’opérations « ou » logiques
d’attributs mode.
SSL_VERIFY_NONE
Mode serveur : le serveur n’enverra pas de demande de certificat client au client, aussi le client
n’enverra pas de certificat.
Mode client : s’il n’utilise pas un algorithme de chiffrement anonyme (fonctionnement par défaut), le
serveur enverra un certificat qui sera contrôlé. Le résultat du processus de vérification de
certificat peut être contrôlé après l’initiation de connexion TLS/SSL en utilisant la fonction
SSL_get_verify_result(3). L’initiation de connexion peut continuer indépendamment de la vérification
du résultat.
SSL_VERIFY_PEER
Mode serveur : le serveur demande un certificat au client. Le certificat renvoyé (le cas échéant) est
vérifié. Si la vérification échoue, l’initiation de connexion TLS/SSl se termine immédiatement avec
un message d’alerte contenant le pourquoi de l’échec de vérification. Le comportement peut être
contrôlé par les attributs additionnels SSL_VERIFY_FAIL_IF_NO_PEER_CERT et SSL_VERIFY_CLIENT_ONCE.
Mode client : le certificat du serveur est vérifié. Si la vérification échoue, l’initiation de
connexion TLS/SSL se termine immédiatement avec un message d’alerte contenant le pourquoi de l’échec
de vérification. Si aucun certificat de serveur est envoyé, à cause de l’utilisation d’un algorithme
de chiffrement anonyme, SSL_VERIFY_PEER est ignoré.
SSL_VERIFY_FAIL_IF_NO_PEER_CERT
Mode serveur : si le client ne renvoie pas de certificat, l’initialisation de connexion TSL/SSL se
termine immédiatement avec un message « handshake failure » (échec d’initialisation). Cet attribut
doit être utilisé de concert avec SSL_VERIFY_PEER.
Mode client : mode ignoré.
SSL_VERIFY_CLIENT_ONCE
Mode serveur : requête uniquement d’un certificat de client lors de la première initiation de
connexion TLS/SSL. Une nouvelle demande ne doit pas être faite dans le cas d’une renégociation. Cet
attribut doit être utilisé de concert avec SSL_VERIFY_PEER.
Mode client : mode ignoré.
Un seul des attributs mode SSL_VERIFY_NONE et SSL_VERIFY_PEER doit être activé à tout moment.
La véritable procédure de vérification est réalisée en utilisant la procédure de vérification interne ou
une autre application fournissant une fonction de vérification définie avec
SSL_CTX_set_cert_verify_callback(3). Les descriptions suivantes s’appliquent dans le cas d’une procédure
interne. Une procédure fournie par une application a aussi accès à l’information de profondeur de
vérification et à la fonction verify_callback(), mais la façon dont l’information est utilisée peut être
différente.
SSL_CTX_set_verify_depth() et SSL_set_verify_depth() définissent la limite supérieure de profondeur
jusqu’à laquelle les certificats dans une chaîne sont utilisés pendant la procédure de vérification. Si
la chaîne de certificats est plus grande que celle autorisée, les certificats après la limite sont
ignorés. Les messages d’erreur ne tiennent pas compte des certificats au-dessus la limite, plus
vraisemblablement un X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY sera émis. Le compte d’erreurs est
« level 0:peer certificate », « level 1: CA certificate ,> « level 2: higher level CA certificate », etc.
Définir la profondeur maximale à 2 autorise les niveaux 0, 1 et 2. La limite de profondeur par défaut
est 100, permettant le certificat du pair plus 100 certificats de CA.
La fonction verify_callback est utilisée pour contrôler le fonctionnement lorsque l’attribut
SSL_VERIFY_PEER flag est activé. Il doit être fourni par l’application et reçoit deux arguments :
preverify_ok indique si la vérification du certificat est demandée (preverify_ok=1) ou non
(preverify_ok=0). x509_ctx est un pointeur vers le contexte complet utilisé par la vérification de la
chaîne de certificats.
La chaîne de certificats est vérifiée en commençant par le niveau d’emboitement le plus profond (le
certificat de CA racine) et progresse jusqu’au certificat de pair. À chaque niveau, les signatures et les
certificats d’émetteur sont contrôlés. À chaque fois qu’une erreur de vérification est trouvée, le numéro
d’erreur est stocké dans x509_ctx et verify_callback est appelé avec preverify_ok=0. En utilisant les
fonctions X509_CTX_store_*, verify_callback peut trouver le certificat en question et réaliser les étapes
additionnelles (consultez EXEMPLES). Si aucune erreur n’est trouvée pour un certificat, verify_callback
est appelé avec preverify_ok=1 avant accéder au prochain niveau.
La valeur de retour de verify_callback détermine la stratégie de la procédure de vérification suivante.
Si verify_callback renvoie 0, la procédure de vérification s’arrête avec un état « échec de
vérification ». Si SSL_VERIFY_PEER est activé, un message d’échec de vérification est envoyé au pair et
la connexion TLS/SSL s’arrête. Si verify_callback renvoie 1, la procédure continue. Si verify_callback
renvoie toujours 1, l’initialisation de connexion TLS/SSL ne sera pas achevée en ce qui concerne les
erreurs de connexion et la connexion sera établie. Le processus demandeur peut cependant retrouver le
code d’erreur de la dernière vérification en utilisant SSL_get_verify_result(3) ou en entretenant son
propre stockage d’erreurs géré par verify_callback.
Si aucun verify_callback n’est indiqué, le rappel par défaut sera utilisé. Sa valeur de retour est
identique à preverify_ok, aussi toute erreur de vérification conduira à une fin de la connexion TLS/SSL,
avec un message d’alerte si SSL_VERIFY_PEER est activé.
BOGUES
Dans le mode client, la vérification de chaîne n’est pas faite si l’attribut SSL_VERIFY_PEER est activé,
mais si SSL_VERIFY_NONE n’est pas activé. Cela peut conduire à un fonctionnement inattendu si
SSL_VERIFY_PEER et SSL_VERIFY_NONE ne sont pas utilisés comme exigé (seulement un seul actif).
La profondeur de vérification de certificats définie avec SSL[_CTX]_verify_depth() arrête la vérification
à une certaine profondeur. Le message d’erreur fourni sera celui d’une chaîne de certificats incomplète
et non X509_V_ERR_CERT_CHAIN_TOO_LONG comme peut être espéré.
VALEURS DE RETOUR
Les fonctions SSL*_set_verify*() ne fournissent pas d’information de diagnostic.
EXEMPLES
Le code suivant réalise un exemple de la fonction verify_callback qui continuera toujours l’initiation de
connexion TLS/SSL indépendamment d’erreur de vérification, si voulu. Le rappel réalise une vérification
avec limite de profondeur et avec le maximum d’informations.
Toutes les erreurs de vérification sont affichées ; l’information sur la chaîne de certificats est
affichée sur demande. Cet exemple concerne un serveur qui autorise mais ne demande pas de certificat
client.
Cet exemple utilise la technique « ex_data » pour stocker les données d’application dans la structure SSL
ou les retrouver à partir de cette structure (consultez SSL_get_ex_new_index(3),
SSL_get_ex_data_X509_STORE_CTX_idx(3)).
...
typedef struct {
int verbose_mode;
int verify_depth;
int always_continue;
} mydata_t;
int mydata_index;
...
static int verify_callback(int preverify_ok, X509_STORE_CTX *ctx)
{
char buf[256];
X509 *err_cert;
int err, depth;
SSL *ssl;
mydata_t *mydata;
err_cert = X509_STORE_CTX_get_current_cert(ctx);
err = X509_STORE_CTX_get_error(ctx);
depth = X509_STORE_CTX_get_error_depth(ctx);
/*
* Extraire le pointeur vers l’objet SSL de la connexion
* actuellement traitée et les données spécifiques à
* l’application stockées dans cet objet.
*/
ssl = X509_STORE_CTX_get_ex_data(ctx,
SSL_get_ex_data_X509_STORE_CTX_idx());
mydata = SSL_get_ex_data(ssl, mydata_index);
X509_NAME_oneline(X509_get_subject_name(err_cert), buf, 256);
/*
* Chaîne de certificats trop longue. La profondeur limite définie
* par SSL_CTX_set_verify_depth() est en principe « limit+1 » aussi
* si la condition « depth>verify_depth » est satisfaite, la limite
* est dépassée et la journalisation de cette erreur doit être
* faite. Cela doit être fait ici parce que l’erreur CHAIN_TOO_LONG
* ne peut être trouvée explicitement ; les seules erreurs
* introduites par des certificats additionnels sont journalisées.
*/
if (depth > mydata->verify_depth) {
preverify_ok = 0;
err = X509_V_ERR_CERT_CHAIN_TOO_LONG;
X509_STORE_CTX_set_error(ctx, err);
}
if (!preverify_ok) {
printf("verify error:num=%d:%s:depth=%d:%s\n", err,
X509_verify_cert_error_string(err), depth, buf);
}
else if (mydata->verbose_mode)
{
printf("depth=%d:%s\n", depth, buf);
}
/*
* À ce moment, err contient la dernière erreur de vérification.
* Ce peut être utilisé pour un but particulier
*/
if (!preverify_ok && (err == X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT))
{
X509_NAME_oneline(X509_get_issuer_name(ctx->current_cert),
buf, 256);
printf("issuer= %s\n", buf);
}
if (mydata->always_continue)
return 1;
else
return preverify_ok;
}
...
mydata_t mydata;
...
mydata_index = SSL_get_ex_new_index(0, "mydata index",
NULL, NULL, NULL);
...
SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER|SSL_VERIFY_CLIENT_ONCE,
verify_callback);
/*
* Permettre à verify_callback de capturer l’erreur de verify_depth
* pour obtenir une erreur appropriée dans le journal.
*/
SSL_CTX_set_verify_depth(verify_depth + 1);
/*
* Définir les données spécifiques au SSL dans « mydata » et les
* stocker dans la structure SSL.
*/
mydata.verify_depth = verify_depth; ...
SSL_set_ex_data(ssl, mydata_index, &mydata);
...
SSL_accept(ssl); /* Vérification d’une réussite omise pour clarté */
if (peer = SSL_get_peer_certificate(ssl))
{
if (SSL_get_verify_result(ssl) == X509_V_OK)
{
/* Le client a envoyé un certificat valable */
}
}
VOIR AUSSI
ssl(3), SSL_new(3), SSL_CTX_get_verify_mode(3), SSL_get_verify_result(3),
SSL_CTX_load_verify_locations(3), SSL_get_peer_certificate(3), SSL_CTX_set_cert_verify_callback(3),
SSL_get_ex_data_X509_STORE_CTX_idx(3), SSL_get_ex_new_index(3)
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 fr::ssl::SSL_CTX_set_verify(3SSL)