08f8933fa3
podlators 2.5.0 has switched to dying on POD syntax errors. This means
that a bunch of long-standing erroneous POD in the openssl documentation
now leads to fatal errors from pod2man, halting installation.
Unfortunately POD constraints mean that you have to sort numeric lists
in ascending order if they start with 1: you cannot do 1, 0, 2 even if
you want 1 to appear first. I've reshuffled such (alas, I wish there
were a better way but I don't know of one).
(cherry picked from commit 5cc2707742)
73 lines
2.3 KiB
Text
73 lines
2.3 KiB
Text
=pod
|
|
|
|
=head1 NAME
|
|
|
|
SSL_connect - initiate the TLS/SSL handshake with an TLS/SSL server
|
|
|
|
=head1 SYNOPSIS
|
|
|
|
#include <openssl/ssl.h>
|
|
|
|
int SSL_connect(SSL *ssl);
|
|
|
|
=head1 DESCRIPTION
|
|
|
|
SSL_connect() initiates the TLS/SSL handshake with a server. The communication
|
|
channel must already have been set and assigned to the B<ssl> by setting an
|
|
underlying B<BIO>.
|
|
|
|
=head1 NOTES
|
|
|
|
The behaviour of SSL_connect() depends on the underlying BIO.
|
|
|
|
If the underlying BIO is B<blocking>, SSL_connect() will only return once the
|
|
handshake has been finished or an error occurred.
|
|
|
|
If the underlying BIO is B<non-blocking>, SSL_connect() will also return
|
|
when the underlying BIO could not satisfy the needs of SSL_connect()
|
|
to continue the handshake, indicating the problem by the return value -1.
|
|
In this case a call to SSL_get_error() with the
|
|
return value of SSL_connect() will yield B<SSL_ERROR_WANT_READ> or
|
|
B<SSL_ERROR_WANT_WRITE>. The calling process then must repeat the call after
|
|
taking appropriate action to satisfy the needs of SSL_connect().
|
|
The action depends on the underlying BIO. When using a non-blocking socket,
|
|
nothing is to be done, but select() can be used to check for the required
|
|
condition. When using a buffering BIO, like a BIO pair, data must be written
|
|
into or retrieved out of the BIO before being able to continue.
|
|
|
|
=head1 RETURN VALUES
|
|
|
|
The following return values can occur:
|
|
|
|
=over 4
|
|
|
|
=item 0
|
|
|
|
The TLS/SSL handshake was not successful but was shut down controlled and
|
|
by the specifications of the TLS/SSL protocol. Call SSL_get_error() with the
|
|
return value B<ret> to find out the reason.
|
|
|
|
=item 1
|
|
|
|
The TLS/SSL handshake was successfully completed, a TLS/SSL connection has been
|
|
established.
|
|
|
|
=item E<lt>0
|
|
|
|
The TLS/SSL handshake was not successful, because a fatal error occurred either
|
|
at the protocol level or a connection failure occurred. The shutdown was
|
|
not clean. It can also occur of action is need to continue the operation
|
|
for non-blocking BIOs. Call SSL_get_error() with the return value B<ret>
|
|
to find out the reason.
|
|
|
|
=back
|
|
|
|
=head1 SEE ALSO
|
|
|
|
L<SSL_get_error(3)|SSL_get_error(3)>, L<SSL_accept(3)|SSL_accept(3)>,
|
|
L<SSL_shutdown(3)|SSL_shutdown(3)>, L<ssl(3)|ssl(3)>, L<bio(3)|bio(3)>,
|
|
L<SSL_set_connect_state(3)|SSL_set_connect_state(3)>,
|
|
L<SSL_do_handshake(3)|SSL_do_handshake(3)>,
|
|
L<SSL_CTX_new(3)|SSL_CTX_new(3)>
|
|
|
|
=cut
|