.\" -*- mode: troff; coding: utf-8 -*- .\" Automatically generated by Pod::Man 5.01 (Pod::Simple 3.43) .\" .\" 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 .. .\" \*(C` and \*(C' are quotes in nroff, nothing in troff, for use with C<>. .ie n \{\ . ds C` "" . ds C' "" 'br\} .el\{\ . 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 >0, 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 "SSL_CTX_SET_CERT_VERIFY_CALLBACK 3SSL" .TH SSL_CTX_SET_CERT_VERIFY_CALLBACK 3SSL 2024-02-03 3.1.5 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 NAME SSL_CTX_set_cert_verify_callback \- set peer certificate verification procedure .SH SYNOPSIS .IX Header "SYNOPSIS" .Vb 1 \& #include \& \& void SSL_CTX_set_cert_verify_callback(SSL_CTX *ctx, \& int (*callback)(X509_STORE_CTX *, void *), \& void *arg); .Ve .SH DESCRIPTION .IX Header "DESCRIPTION" \&\fBSSL_CTX_set_cert_verify_callback()\fR sets the verification callback function for \&\fIctx\fR. SSL objects that are created from \fIctx\fR inherit the setting valid at the time when \fBSSL_new\fR\|(3) is called. .SH NOTES .IX Header "NOTES" When a peer certificate has been received during a SSL/TLS handshake, a verification function is called regardless of the verification mode. If the application does not explicitly specify a verification callback function, the built-in verification function is used. If a verification callback \fIcallback\fR is specified via \&\fBSSL_CTX_set_cert_verify_callback()\fR, the supplied callback function is called instead with the arguments callback(X509_STORE_CTX *x509_store_ctx, void *arg). The argument \fIarg\fR is specified by the application when setting \fIcallback\fR. By setting \fIcallback\fR to NULL, the default behaviour is restored. .PP \&\fIcallback\fR should return 1 to indicate verification success and 0 to indicate verification failure. In server mode, a return value of 0 leads to handshake failure. In client mode, the behaviour is as follows. All values, including 0, are ignored if the verification mode is \fBSSL_VERIFY_NONE\fR. Otherwise, when the return value is less than or equal to 0, the handshake will fail. .PP In client mode \fIcallback\fR may also call the \fBSSL_set_retry_verify\fR\|(3) function on the \fBSSL\fR object set in the \fIx509_store_ctx\fR ex data (see \&\fBSSL_get_ex_data_X509_STORE_CTX_idx\fR\|(3)) and return 1. This would be typically done in case the certificate verification was not yet able to succeed. This makes the handshake suspend and return control to the calling application with \fBSSL_ERROR_WANT_RETRY_VERIFY\fR. The app can for instance fetch further certificates or cert status information needed for the verification. Calling \fBSSL_connect\fR\|(3) again resumes the connection attempt by retrying the server certificate verification step. This process may even be repeated if need be. .PP In any case a viable verification result value must be reflected in the \fBerror\fR member of \fIx509_store_ctx\fR, which can be done using \fBX509_STORE_CTX_set_error\fR\|(3). This is particularly important in case the \fIcallback\fR allows the connection to continue (by returning 1). Note that the verification status in the store context is a possibly durable indication of the chain's validity! This gets recorded in the SSL session (and thus also in session tickets) and the validity of the originally presented chain is then visible on resumption, even though no chain is presented int that case. Moreover, the calling application will be informed about the detailed result of the verification procedure and may elect to base further decisions on it. .PP Within \fIx509_store_ctx\fR, \fIcallback\fR has access to the \fIverify_callback\fR function set using \fBSSL_CTX_set_verify\fR\|(3). .SH "RETURN VALUES" .IX Header "RETURN VALUES" \&\fBSSL_CTX_set_cert_verify_callback()\fR does not return a value. .SH WARNINGS .IX Header "WARNINGS" Do not mix the verification callback described in this function with the \&\fBverify_callback\fR function called during the verification process. The latter is set using the \fBSSL_CTX_set_verify\fR\|(3) family of functions. .PP Providing a complete verification procedure including certificate purpose settings etc is a complex task. The built-in procedure is quite powerful and in most cases it should be sufficient to modify its behaviour using the \fBverify_callback\fR function. .SH BUGS .IX Header "BUGS" \&\fBSSL_CTX_set_cert_verify_callback()\fR does not provide diagnostic information. .SH "SEE ALSO" .IX Header "SEE ALSO" \&\fBssl\fR\|(7), \fBSSL_CTX_set_verify\fR\|(3), \&\fBX509_STORE_CTX_set_error\fR\|(3), \&\fBSSL_get_verify_result\fR\|(3), \&\fBSSL_set_retry_verify\fR\|(3), \&\fBSSL_CTX_load_verify_locations\fR\|(3) .SH COPYRIGHT .IX Header "COPYRIGHT" Copyright 2001\-2022 The OpenSSL Project Authors. All Rights Reserved. .PP Licensed under the Apache License 2.0 (the "License"). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at .