168651Skris=pod
268651Skris
368651Skris=head1 NAME
468651Skris
568651SkrisSSL_clear - reset SSL object to allow another connection
668651Skris
768651Skris=head1 SYNOPSIS
868651Skris
968651Skris #include <openssl/ssl.h>
1068651Skris
1168651Skris int SSL_clear(SSL *ssl);
1268651Skris
1368651Skris=head1 DESCRIPTION
1468651Skris
1568651SkrisReset B<ssl> to allow another connection. All settings (method, ciphers,
1676866SkrisBIOs) are kept.
1768651Skris
1876866Skris=head1 NOTES
1976866Skris
2076866SkrisSSL_clear is used to prepare an SSL object for a new connection. While all
2176866Skrissettings are kept, a side effect is the handling of the current SSL session.
2276866SkrisIf a session is still B<open>, it is considered bad and will be removed
2376866Skrisfrom the session cache, as required by RFC2246. A session is considered open,
2476866Skrisif L<SSL_shutdown(3)|SSL_shutdown(3)> was not called for the connection
2576866Skrisor at least L<SSL_set_shutdown(3)|SSL_set_shutdown(3)> was used to
2676866Skrisset the SSL_SENT_SHUTDOWN state.
2776866Skris
28100928SnectarIf a session was closed cleanly, the session object will be kept and all
29100928Snectarsettings corresponding. This explicitly means, that e.g. the special method
30100928Snectarused during the session will be kept for the next handshake. So if the
31100928Snectarsession was a TLSv1 session, a SSL client object will use a TLSv1 client
32100928Snectarmethod for the next handshake and a SSL server object will use a TLSv1
33100928Snectarserver method, even if SSLv23_*_methods were chosen on startup. This
34100928Snectarwill might lead to connection failures (see L<SSL_new(3)|SSL_new(3)>)
35100928Snectarfor a description of the method's properties.
36100928Snectar
37100928Snectar=head1 WARNINGS
38100928Snectar
39100928SnectarSSL_clear() resets the SSL object to allow for another connection. The
40100928Snectarreset operation however keeps several settings of the last sessions
41100928Snectar(some of these settings were made automatically during the last
42237657Sjkimhandshake). It only makes sense for a new connection with the exact
43237657Sjkimsame peer that shares these settings, and may fail if that peer
44237657Sjkimchanges its settings between connections. Use the sequence
45237657SjkimL<SSL_get_session(3)|SSL_get_session(3)>;
46237657SjkimL<SSL_new(3)|SSL_new(3)>;
47237657SjkimL<SSL_set_session(3)|SSL_set_session(3)>;
48237657SjkimL<SSL_free(3)|SSL_free(3)>
49237657Sjkiminstead to avoid such failures
50237657Sjkim(or simply L<SSL_free(3)|SSL_free(3)>; L<SSL_new(3)|SSL_new(3)>
51237657Sjkimif session reuse is not desired).
52100928Snectar
5368651Skris=head1 RETURN VALUES
5468651Skris
5568651SkrisThe following return values can occur:
5668651Skris
5768651Skris=over 4
5868651Skris
59264331Sjkim=item Z<>0
6068651Skris
6168651SkrisThe SSL_clear() operation could not be performed. Check the error stack to
6268651Skrisfind out the reason.
6368651Skris
64264331Sjkim=item Z<>1
6568651Skris
6668651SkrisThe SSL_clear() operation was successful.
6768651Skris
6868651Skris=back
6968651Skris
7068651SkrisL<SSL_new(3)|SSL_new(3)>, L<SSL_free(3)|SSL_free(3)>,
7176866SkrisL<SSL_shutdown(3)|SSL_shutdown(3)>, L<SSL_set_shutdown(3)|SSL_set_shutdown(3)>,
72100928SnectarL<SSL_CTX_set_options(3)|SSL_CTX_set_options(3)>, L<ssl(3)|ssl(3)>,
73100928SnectarL<SSL_CTX_set_client_cert_cb(3)|SSL_CTX_set_client_cert_cb(3)>
7468651Skris
7568651Skris=cut
76