.\" Automatically generated by Pod::Man 2.28 (Pod::Simple 3.28) .\" .\" Standard preamble: .\" ======================================================================== .de Sp \" Vertical space (when we can't use .PP) .if t .sp .5v .if n .sp .. .de Vb \" Begin verbatim text .ft CW .nf .ne \\$1 .. .de Ve \" End verbatim text .ft R .fi .. .\" Set up some character translations and predefined strings. \*(-- will .\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left .\" double quote, and \*(R" will give a right double quote. \*(C+ will .\" give a nicer C++. Capital omega is used to do unbreakable dashes and .\" therefore won't be available. \*(C` and \*(C' expand to `' in nroff, .\" nothing in troff, for use with C<>. .tr \(*W- .ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p' .ie n \{\ . ds -- \(*W- . ds PI pi . if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch . if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch . ds L" "" . ds R" "" . ds C` "" . ds C' "" 'br\} .el\{\ . ds -- \|\(em\| . ds PI \(*p . ds L" `` . ds R" '' . ds C` . ds C' 'br\} .\" .\" Escape single quotes in literal strings from groff's Unicode transform. .ie \n(.g .ds Aq \(aq .el .ds Aq ' .\" .\" If the F register is turned on, we'll generate index entries on stderr for .\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index .\" entries marked with X<> in POD. Of course, you'll have to process the .\" output yourself in some meaningful fashion. .\" .\" Avoid warning from groff about undefined register 'F'. .de IX .. .nr rF 0 .if \n(.g .if rF .nr rF 1 .if (\n(rF:(\n(.g==0)) \{ . if \nF \{ . de IX . tm Index:\\$1\t\\n%\t"\\$2" .. . if !\nF==2 \{ . nr % 0 . nr F 2 . \} . \} .\} .rr rF .\" ======================================================================== .\" .IX Title "fr::ssl::SSL_CTX_set_verify 3SSL" .TH fr::ssl::SSL_CTX_set_verify 3SSL "2015-01-30" "1.0.1k" "OpenSSL" .\" For nroff, turn off justification. Always turn off hyphenation; it makes .\" way too many mistakes in technical documents. .if n .ad l .nh .SH "NOM" .IX Header "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 .SH "SYNOPSIS" .IX Header "SYNOPSIS" \&\fB #include \fR .PP \&\fB void SSL_CTX_set_verify(\s-1SSL_CTX\s0 *\fR\fIctx\fR\fB, int\fR \fImode\fR\fB,\fR \fBint (*\fR\fIverify_callback\fR\fB)(int, X509_STORE_CTX *));\fR \fBvoid SSL_set_verify(\s-1SSL\s0 *s, int\fR \fImode\fR\fB,\fR \fBint (*\fR\fIverify_callback\fR\fB)(int, X509_STORE_CTX *));\fR \fBvoid SSL_CTX_set_verify_depth(\s-1SSL_CTX\s0 *\fR\fIctx\fR\fB,int\fR \fIprofondeur\fR\fB);\fR \fBvoid SSL_set_verify_depth(\s-1SSL\s0 *\fR\fIs\fR\fB, int\fR \fIprofondeur\fR\fB);\fR .PP \&\fB int verify_callback(int preverify_ok, X509_STORE_CTX *\fR\fIx509_ctx\fR\fB);\fR .SH "DESCRIPTION" .IX Header "DESCRIPTION" \&\fBSSL_CTX_set_verify\fR() définit les attributs de vérification pour \fIctx\fR à \&\fImode\fR et précise la fonction \fIverify_callback\fR à utiliser. Si aucune fonction de rappel n’est précisée, le pointeur \s-1NULL\s0 peut être utilisé pour \&\fIverify_callback\fR. .PP \&\fBSSL_CTX_set_verify\fR() définit les attributs de vérification pour \fIssl\fR à \&\fImode\fR et précise la fonction \fIverify_callback\fR à utiliser. Si aucune fonction de rappel n’est précisée, le pointeur \s-1NULL\s0 peut être utilisé pour \&\fIverify_callback\fR. Dans ce cas le dernier \fIverify_callback\fR défini précisément pour ce \fIssl\fR est conservé. Si aucun \fIrappel\fR n’était défini auparavant, le rappel par défaut pour le \fIctx\fR sous-jacent, et qui était valable au moment où \fIssl\fR a été créé avec \fBSSL_new\fR(3), est utilisé. .PP \&\fBSSL_CTX_set_verify_depth\fR() définit la \fIprofondeur\fR maximale pour la vérification de chaîne de certificats qui sera autorisée pour \fIctx\fR (consultez la section \s-1BOGUES\s0). .PP \&\fBSSL_CTX_set_verify_depth\fR() définit la \fIprofondeur\fR maximale pour la vérification de chaîne de certificats qui sera autorisée pour \fIssl\fR (consultez la section \s-1BOGUES\s0). .SH "NOTES" .IX Header "NOTES" La vérification des certificats peut être contrôlée par une suite d’opérations « ou » logiques d’attributs \fImode\fR. .IP "\s-1SSL_VERIFY_NONE\s0" 4 .IX Item "SSL_VERIFY_NONE" \&\fBMode serveur :\fR le serveur n’enverra pas de demande de certificat client au client, aussi le client n’enverra pas de certificat. .Sp \&\fBMode client :\fR 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 \s-1TLS/SSL\s0 en utilisant la fonction \&\fBSSL_get_verify_result\fR(3). L’initiation de connexion peut continuer indépendamment de la vérification du résultat. .IP "\s-1SSL_VERIFY_PEER\s0" 4 .IX Item "SSL_VERIFY_PEER" \&\fBMode serveur :\fR 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 \&\fB\s-1SSL_VERIFY_FAIL_IF_NO_PEER_CERT\s0\fR et \fB\s-1SSL_VERIFY_CLIENT_ONCE\s0\fR. .Sp \&\fBMode client :\fR le certificat du serveur est vérifié. Si la vérification échoue, l’initiation de connexion \s-1TLS/SSL\s0 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, \fB\s-1SSL_VERIFY_PEER\s0\fR est ignoré. .IP "\s-1SSL_VERIFY_FAIL_IF_NO_PEER_CERT\s0" 4 .IX Item "SSL_VERIFY_FAIL_IF_NO_PEER_CERT" \&\fBMode serveur :\fR si le client ne renvoie pas de certificat, l’initialisation de connexion \s-1TSL/SSL\s0 se termine immédiatement avec un message « handshake failure » (échec d’initialisation). Cet attribut doit être utilisé de concert avec \s-1SSL_VERIFY_PEER.\s0 .Sp \&\fBMode client :\fR mode ignoré. .IP "\s-1SSL_VERIFY_CLIENT_ONCE\s0" 4 .IX Item "SSL_VERIFY_CLIENT_ONCE" \&\fBMode serveur :\fR requête uniquement d’un certificat de client lors de la première initiation de connexion \s-1TLS/SSL.\s0 Une nouvelle demande ne doit pas être faite dans le cas d’une renégociation. Cet attribut doit être utilisé de concert avec \s-1SSL_VERIFY_PEER.\s0 .Sp \&\fBMode client :\fR mode ignoré. .PP Un seul des attributs \fImode\fR \fB\s-1SSL_VERIFY_NONE\s0\fR et \fB\s-1SSL_VERIFY_PEER\s0\fR doit être activé à tout moment. .PP 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 \&\fBSSL_CTX_set_cert_verify_callback\fR(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 \&\fIverify_callback\fR(), mais la façon dont l’information est utilisée peut être différente. .PP \&\fBSSL_CTX_set_verify_depth\fR() et \fBSSL_set_verify_depth\fR() 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 \&\fBX509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY\fR sera émis. Le compte d’erreurs est « level 0:peer certificate », « level 1: \s-1CA\s0 certificate ,> « level 2: higher level \s-1CA\s0 certificate », etc. Définir la profondeur maximale à \fB2\fR autorise les niveaux \fB0\fR, \fB1\fR et \fB2\fR. La limite de profondeur par défaut est \fB100\fR, permettant le certificat du pair plus 100 certificats de \s-1CA.\s0 .PP La fonction \fIverify_callback\fR est utilisée pour contrôler le fonctionnement lorsque l’attribut \s-1SSL_VERIFY_PEER\s0 flag est activé. Il doit être fourni par l’application et reçoit deux arguments : \fBpreverify_ok\fR indique si la vérification du certificat est demandée (\fBpreverify_ok\fR=\fB1\fR) ou non (\fBpreverify_ok\fR=\fB0\fR). \fBx509_ctx\fR est un pointeur vers le contexte complet utilisé par la vérification de la chaîne de certificats. .PP La chaîne de certificats est vérifiée en commençant par le niveau d’emboitement le plus profond (le certificat de \s-1CA\s0 racine) et progresse jusqu’au certificat de pair. À chaque niveau, les signatures et les certificats d’émetteur sont contrôlées. À chaque fois qu’une erreur de vérification est trouvée, le numéro d’erreur est stocké dans \fBx509_ctx\fR et \&\fIverify_callback\fR est appelé avec \fBpreverify_ok\fR=\fB0\fR. En utilisant les fonctions \fBX509_CTX_store_*\fR, \fIverify_callback\fR peut trouver le certificat en question et réaliser les étapes additionnelles (consultez \s-1EXEMPLES\s0). Si aucune erreur n’est trouvée pour un certificat, \fIverify_callback\fR est appelé avec \fBpreverify_ok\fR=\fB1\fR avant accéder au prochain niveau. .PP La valeur de retour de \fIverify_callback\fR détermine la stratégie de la procédure de vérification suivante. Si \fIverify_callback\fR renvoie \fB0\fR, la procédure de vérification s’arrête avec un état « échec de vérification ». Si \fB\s-1SSL_VERIFY_PEER\s0\fR est activé, un message d’échec de vérification est envoyé au pair et la connexion \s-1TLS/SSL\s0 s’arrête. Si \&\fIverify_callback\fR renvoie \fB1\fR, la procédure continue. Si \&\fIverify_callback\fR renvoie toujours \fB1\fR, l’initialisation de connexion \&\s-1TLS/SSL\s0 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 \&\fBSSL_get_verify_result\fR(3) ou en entretenant son propre stockage d’erreurs géré par \fIverify_callback\fR. .PP Si aucun \fIverify_callback\fR n’est indiqué, le rappel par défaut sera utilisé. Sa valeur de retour est identique à \fBpreverify_ok\fR, aussi toute erreur de vérification conduira à une fin de la connexion \s-1TLS/SSL,\s0 avec un message d’alerte si \fB\s-1SSL_VERIFY_PEER\s0\fR est activé. .SH "BOGUES" .IX Header "BOGUES" Dans le mode client, la vérification de chaîne n’est pas faite si l’attribut \&\fB\s-1SSL_VERIFY_PEER\s0\fR est activé, mais si \fB\s-1SSL_VERIFY_NONE\s0\fR n’est pas activé. Cela peut conduire à un fonctionnement inattendu si \&\fB\s-1SSL_VERIFY_PEER\s0\fR et \fB\s-1SSL_VERIFY_NONE\s0\fR ne sont pas utilisés comme exigé (seulement un seul actif). .PP La profondeur de vérification de certificats définie avec \&\fBSSL[_CTX]_verify_depth\fR() 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 \fBX509_V_ERR_CERT_CHAIN_TOO_LONG\fR comme peut\-être espéré. .SH "VALEURS DE RETOUR" .IX Header "VALEURS DE RETOUR" Les fonctions \fBSSL*_set_verify*\fR() ne fournissent pas d’information de diagnostic. .SH "EXEMPLES" .IX Header "EXEMPLES" Le code suivant réalise un exemple de la fonction \fIverify_callback\fR qui continuera toujours l’initiation de connexion \s-1TLS/SSL\s0 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. .PP 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. .PP Cet exemple utilise la technique « ex_data » pour stocker les données d’application dans la structure \s-1SSL\s0 ou les retrouver à partir de cette structure (consultez \fBSSL_get_ex_new_index\fR(3), \&\fBSSL_get_ex_data_X509_STORE_CTX_idx\fR(3)). .PP .Vb 10 \& ... \& 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\en", err, \& X509_verify_cert_error_string(err), depth, buf); \& } \& else if (mydata\->verbose_mode) \& { \& printf("depth=%d:%s\en", 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\en", 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 */ \& } \& } .Ve .SH "VOIR AUSSI" .IX Header "VOIR AUSSI" \&\fBssl\fR(3), \fBSSL_new\fR(3), \&\fBSSL_CTX_get_verify_mode\fR(3), \&\fBSSL_get_verify_result\fR(3), \&\fBSSL_CTX_load_verify_locations\fR(3), \&\fBSSL_get_peer_certificate\fR(3), \&\fBSSL_CTX_set_cert_verify_callback\fR(3), \&\fBSSL_get_ex_data_X509_STORE_CTX_idx\fR(3), \&\fB\f(BISSL_get_ex_new_index\fB\|(3)\fR .SH "TRADUCTION" .IX Header "TRADUCTION" La traduction de cette page de manuel est maintenue par les membres de la liste . Veuillez signaler toute erreur de traduction par un rapport de bogue sur le paquet manpages-fr-extra.