Update ticket callback docs.

[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 d15b2a3a1a5bc9f405e69040bf41e615c6df67e2..b6ba6bb51cad421ce03aea2a8f93c3e705f4fc02 100644 (file)
--- a/doc/ssl/SSL_CTX_set_verify.pod
+++ b/doc/ssl/SSL_CTX_set_verify.pod
@@ -28,7 +28,7 @@ specifies the B<verify_callback> function to be used. If no callback function
 shall be specified, the NULL pointer can be used for B<verify_callback>. In
 this case last B<verify_callback> set specifically for this B<ssl> remains. If
 no special B<callback> was set before, the default callback for the underlying
-B<ctx> is used, that was valid at the the time B<ssl> was created with
+B<ctx> is used, that was valid at the time B<ssl> was created with
 L<SSL_new(3)|SSL_new(3)>.
 
 SSL_CTX_set_verify_depth() sets the maximum B<depth> for the certificate chain
@@ -109,8 +109,8 @@ certificates would not be present, most likely a
 X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY will be issued.
 The depth count is "level 0:peer certificate", "level 1: CA certificate",
 "level 2: higher level CA certificate", and so on. Setting the maximum
-depth to 2 allows the levels 0, 1, and 2. The default depth limit is 9,
-allowing for the peer certificate and additional 9 CA certificates.
+depth to 2 allows the levels 0, 1, and 2. The default depth limit is 100,
+allowing for the peer certificate and additional 100 CA certificates.
 
 The B<verify_callback> function is used to control the behaviour when the
 SSL_VERIFY_PEER flag is set. It must be supplied by the application and
@@ -135,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
-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>.
 
@@ -169,8 +169,8 @@ that will always continue the TLS/SSL handshake regardless of verification
 failure, if wished. The callback realizes a verification depth limit with
 more informational output.
 
-All verification errors are printed, informations about the certificate chain
-are printed on request.
+All verification errors are printed; information about the certificate chain
+is printed on request.
 The example is realized for a server that does allow but not require client
 certificates.