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