SSL_CLEAR(3)
π SSL_CLEAR(3) β like, the reset button for your SSL object
okay so this is from the Library Functions Manual, and we're talking about SSL_clear β the glow-up-reverse button that gets your SSL object ready to go again πβ¨
πΈ NAME πΈ
SSL_clear β reset an SSL object so it can do another connection, bestie
π SYNOPSIS π
library libssl libcrypto
#include <openssl/ssl.h>
int
SSL_clear(SSL *ssl);
β¨ DESCRIPTION β¨
So SSL_clear() resets ssl to allow another connection, and here's the tea: all settings are kept β the method, the ciphers, the BIOs, all of it just vibes there waiting for round two π
It's literally THE function you call to prep an SSL object for a new connection. But there's a little side quest π β while all the settings stick around, the current SSL session gets handled too. If a session is still open, it's considered bad and gets yeeted out of the session cache, because RFC 2246 said so, periodt. And a session counts as "open" if SSL_shutdown(3) was never called for the connection, or if at least SSL_set_shutdown(3) was used to set the SSL_SENT_SHUTDOWN state π«Ά
Now, if the session was closed cleanly? Different story β the session object is kept, along with all the settings that correspond to it. And that explicitly means, like, the special method used during the session sticks around for the next handshake π
So real talk: if the session was a TLSv1 session, an SSL client object will use a TLSv1 client method for the next handshake, and an SSL server object will use a TLSv1 server method β even if TLS_*_method()s were chosen on startup. And yeah, that might lead to connection failures π (peep SSL_new(3) for a description of the method's properties, iykyk).
π₯ RETURN VALUES π₯
Two possible outcomes, no in-between:
0β theSSL_clear()operation could not be performed π check the error stack to find out the reason.1β theSSL_clear()operation was successful π slay.
π¦ SEE ALSO π¦
ssl(3)SSL_CTX_set_client_cert_cb(3)SSL_CTX_set_options(3)SSL_free(3)SSL_new(3)SSL_set_shutdown(3)SSL_shutdown(3)
π HISTORY π
SSL_clear() first appeared in SSLeay 0.4.5b and has been available since OpenBSD 2.4 β truly a legacy icon π
π CAVEATS π
okay bestie, listen up because this part matters:
SSL_clear() resets the SSL object to allow for another connection. But the reset operation keeps several settings from the last session β and some of those settings were made automatically during the last handshake π It only makes sense for a new connection with the exact same peer that shares those settings, and it may fail if that peer changes its settings between connections. Not ideal, ngl.
Instead, use this sequence to avoid such failures:
SSL_get_session(3);
SSL_new(3);
SSL_set_session(3);
SSL_free(3);
Or, if session reuse isn't even the vibe you're going for, just do the simple thing:
SSL_free(3);
SSL_new(3);
π friendly reminder: keep the settings, keep the peer, keep the vibes β otherwise just start fresh, fr fr π
and that's the whole page, babes π«Ά this lil number's from Debian, dated June 8, 2025 β go forth and clear those SSL objects responsibly πΈπ β¨
π¦ where this page comes from
- alpine 3.24: libressl-doc 4.3.1-r0 Β· custom
- arch rolling: libressl 4.4.0-1 Β· ISC AND custom:OpenSSL
- Copyright (c) 2000, 2001, 2002, 2011, 2015 The OpenSSL Project
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on : a language model's rewrite of the original, under its terms