Fix L<> content in manpages

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

diff --git a/doc/ssl/SSL_CTX_set_client_cert_cb.pod b/doc/ssl/SSL_CTX_set_client_cert_cb.pod
index d0df69a9bc186e10845418e6bac87ea774ec6eae..1b5f5f1a831adbb8f663924c53f2463a0960b825 100644 (file)
--- a/doc/ssl/SSL_CTX_set_client_cert_cb.pod
+++ b/doc/ssl/SSL_CTX_set_client_cert_cb.pod
@@ -29,7 +29,7 @@ using the B<x509> and B<pkey> arguments and "1" must be returned. The
 certificate will be installed into B<ssl>, see the NOTES and BUGS sections.
 If no certificate should be set, "0" has to be returned and no certificate
 will be sent. A negative return value will suspend the handshake and the
-handshake function will return immediately. L<SSL_get_error(3)|SSL_get_error(3)>
+handshake function will return immediately. L<SSL_get_error(3)>
 will return SSL_ERROR_WANT_X509_LOOKUP to indicate, that the handshake was
 suspended. The next call to the handshake function will again lead to the call
 of client_cert_cb(). It is the job of the client_cert_cb() to store information
@@ -42,7 +42,7 @@ from the client. A client certificate must only be sent, when the server
 did send the request.
 
 When a certificate was set using the
-L<SSL_CTX_use_certificate(3)|SSL_CTX_use_certificate(3)> family of functions,
+L<SSL_CTX_use_certificate(3)> family of functions,
 it will be sent to the server. The TLS standard requires that only a
 certificate is sent, if it matches the list of acceptable CAs sent by the
 server. This constraint is violated by the default behavior of the OpenSSL
@@ -56,7 +56,7 @@ If the callback function returns a certificate, the OpenSSL library
 will try to load the private key and certificate data into the SSL
 object using the SSL_use_certificate() and SSL_use_private_key() functions.
 Thus it will permanently install the certificate and key for this SSL
-object. It will not be reset by calling L<SSL_clear(3)|SSL_clear(3)>.
+object. It will not be reset by calling L<SSL_clear(3)>.
 If the callback returns no certificate, the OpenSSL library will not send
 a certificate.
 
@@ -72,7 +72,7 @@ either adding the intermediate CA certificates into the trusted
 certificate store for the SSL_CTX object (resulting in having to add
 CA certificates that otherwise maybe would not be trusted), or by adding
 the chain certificates using the
-L<SSL_CTX_add_extra_chain_cert(3)|SSL_CTX_add_extra_chain_cert(3)>
+L<SSL_CTX_add_extra_chain_cert(3)>
 function, which is only available for the SSL_CTX object as a whole and that
 therefore probably can only apply for one client certificate, making
 the concept of the callback function (to allow the choice from several
@@ -80,15 +80,15 @@ certificates) questionable.
 
 Once the SSL object has been used in conjunction with the callback function,
 the certificate will be set for the SSL object and will not be cleared
-even when L<SSL_clear(3)|SSL_clear(3)> is being called. It is therefore
-mandatory to destroy the SSL object using L<SSL_free(3)|SSL_free(3)>
+even when L<SSL_clear(3)> is being called. It is therefore
+mandatory to destroy the SSL object using L<SSL_free(3)>
 and create a new one to return to the previous state.
 
 =head1 SEE ALSO
 
-L<ssl(3)|ssl(3)>, L<SSL_CTX_use_certificate(3)|SSL_CTX_use_certificate(3)>,
-L<SSL_CTX_add_extra_chain_cert(3)|SSL_CTX_add_extra_chain_cert(3)>,
-L<SSL_get_client_CA_list(3)|SSL_get_client_CA_list(3)>,
-L<SSL_clear(3)|SSL_clear(3)>, L<SSL_free(3)|SSL_free(3)>
+L<ssl(3)>, L<SSL_CTX_use_certificate(3)>,
+L<SSL_CTX_add_extra_chain_cert(3)>,
+L<SSL_get_client_CA_list(3)>,
+L<SSL_clear(3)>, L<SSL_free(3)>
 
 =cut