bn_mul_recursive doesn't handle all cases correctly, which results in

[oweals/openssl.git] / doc / ssl / SSL_CTX_set_verify.pod

diff --git a/doc/ssl/SSL_CTX_set_verify.pod b/doc/ssl/SSL_CTX_set_verify.pod
index fc0b76118fd168ae43dcd4485e932838ccc2eaaa..ca8d81b82c818d08f209c73a98ebd7def83ac257 100644 (file)
--- a/doc/ssl/SSL_CTX_set_verify.pod
+++ b/doc/ssl/SSL_CTX_set_verify.pod
@@ -59,14 +59,14 @@ The handshake will be continued regardless of the verification result.
 
 B<Server mode:> the server sends a client certificate request to the client.
 The certificate returned (if any) is checked. If the verification process
 
 B<Server mode:> the server sends a client certificate request to the client.
 The certificate returned (if any) is checked. If the verification process

-fails as indicated by B<verify_callback>, the TLS/SSL handshake is
+fails, the TLS/SSL handshake is

 immediately terminated with an alert message containing the reason for
 the verification failure.
 The behaviour can be controlled by the additional
 SSL_VERIFY_FAIL_IF_NO_PEER_CERT and SSL_VERIFY_CLIENT_ONCE flags.
 
 B<Client mode:> the server certificate is verified. If the verification process
 immediately terminated with an alert message containing the reason for
 the verification failure.
 The behaviour can be controlled by the additional
 SSL_VERIFY_FAIL_IF_NO_PEER_CERT and SSL_VERIFY_CLIENT_ONCE flags.
 
 B<Client mode:> the server certificate is verified. If the verification process

-fails as indicated by B<verify_callback>, the TLS/SSL handshake is
+fails, the TLS/SSL handshake is

 immediately terminated with an alert message containing the reason for
 the verification failure. If no server certificate is sent, because an
 anonymous cipher is used, SSL_VERIFY_PEER is ignored.
 immediately terminated with an alert message containing the reason for
 the verification failure. If no server certificate is sent, because an
 anonymous cipher is used, SSL_VERIFY_PEER is ignored.


@@ -92,6 +92,15 @@ B<Client mode:> ignored
 Exactly one of the B<mode> flags SSL_VERIFY_NONE and SSL_VERIFY_PEER must be
 set at any time.
 
 Exactly one of the B<mode> flags SSL_VERIFY_NONE and SSL_VERIFY_PEER must be
 set at any time.
 

+The actual verification procedure is performed either using the built-in
+verification procedure or using another application provided verification
+function set with
+L<SSL_CTX_set_cert_verify_callback(3)|SSL_CTX_set_cert_verify_callback(3)>.
+The following descriptions apply in the case of the built-in procedure. An
+application provided procedure also has access to the verify depth information
+and the verify_callback() function, but the way this information is used
+may be different.
+

 SSL_CTX_set_verify_depth() and SSL_set_verify_depth() set the limit up
 to which depth certificates in a chain are used during the verification
 procedure. If the certificate chain is longer than allowed, the certificates
 SSL_CTX_set_verify_depth() and SSL_set_verify_depth() set the limit up
 to which depth certificates in a chain are used during the verification
 procedure. If the certificate chain is longer than allowed, the certificates


@@ -126,9 +135,9 @@ process is immediately stopped with "verification failed" state. If
 SSL_VERIFY_PEER is set, a verification failure alert is sent to the peer and
 the TLS/SSL handshake is terminated. If B<verify_callback> returns 1,
 the verification process is continued. If B<verify_callback> always returns
 SSL_VERIFY_PEER is set, a verification failure alert is sent to the peer and
 the TLS/SSL handshake is terminated. If B<verify_callback> returns 1,
 the verification process is continued. If B<verify_callback> always returns

-1, the TLS/SSL handshake will never be terminated because of this application
-experiencing a verification failure. The calling process can however
-retrieve the error code of the last verification error using
+1, the TLS/SSL handshake will not be terminated with respect to verification
+failures and the connection will be established. The calling process can
+however retrieve the error code of the last verification error using

 L<SSL_get_verify_result(3)|SSL_get_verify_result(3)> or by maintaining its
 own error storage managed by B<verify_callback>.
 
 L<SSL_get_verify_result(3)|SSL_get_verify_result(3)> or by maintaining its
 own error storage managed by B<verify_callback>.
 


@@ -226,7 +235,7 @@ L<SSL_get_ex_data_X509_STORE_CTX_idx(3)|SSL_get_ex_data_X509_STORE_CTX_idx(3)>).
      * At this point, err contains the last verification error. We can use
      * it for something special
      */
      * At this point, err contains the last verification error. We can use
      * it for something special
      */

-    if (!preverify_ok && (err == X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT)
+    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);
     {
       X509_NAME_oneline(X509_get_issuer_name(ctx->current_cert), buf, 256);
       printf("issuer= %s\n", buf);


@@ -278,6 +287,7 @@ L<SSL_CTX_get_verify_mode(3)|SSL_CTX_get_verify_mode(3)>,
 L<SSL_get_verify_result(3)|SSL_get_verify_result(3)>,
 L<SSL_CTX_load_verify_locations(3)|SSL_CTX_load_verify_locations(3)>,
 L<SSL_get_peer_certificate(3)|SSL_get_peer_certificate(3)>,
 L<SSL_get_verify_result(3)|SSL_get_verify_result(3)>,
 L<SSL_CTX_load_verify_locations(3)|SSL_CTX_load_verify_locations(3)>,
 L<SSL_get_peer_certificate(3)|SSL_get_peer_certificate(3)>,

+L<SSL_CTX_set_cert_verify_callback(3)|SSL_CTX_set_cert_verify_callback(3)>,

 L<SSL_get_ex_data_X509_STORE_CTX_idx(3)|SSL_get_ex_data_X509_STORE_CTX_idx(3)>,
 L<SSL_get_ex_new_index(3)|SSL_get_ex_new_index(3)>
 
 L<SSL_get_ex_data_X509_STORE_CTX_idx(3)|SSL_get_ex_data_X509_STORE_CTX_idx(3)>,
 L<SSL_get_ex_new_index(3)|SSL_get_ex_new_index(3)>