SSL_RENEGOTIATE(3)

💅 SSL_RENEGOTIATE(3) — Library Functions Manual ✨

okay so bestie, welcome to libssl's renegotiation club 🎀 this is the page for all three of the renegotiate girlies, and yes it's called SSL_RENEGOTIATE but it covers the whole squad. sit down, hydrate, let's go 💖

---

🌸 SYNOPSIS 🌸

the vibe check first — these live in the libssl and libcrypto libraries:

#include <openssl/ssl.h>

and the three function signatures, literally copy-paste-able:

int
SSL_renegotiate(SSL *ssl);

int
SSL_renegotiate_abbreviated(SSL *ssl);

int
SSL_renegotiate_pending(SSL *ssl);

---

🦋 DESCRIPTION 🦋

✨ SSL_renegotiate() — the client-side era

so when you call SSL_renegotiate() from the client side, it schedules a completely new handshake over an existing TLS connection. like, the connection's already there, we're just doing the handshake again for funsies (and security). ✨

the next time an I/O operation such as SSL_read() or SSL_write() takes place on the connection, a check is performed to confirm that it's a suitable time to start a renegotiation. if so, a new handshake is initiated immediately — no waiting, main character energy 🔥

👑 important-ish detail: an existing session associated with the connection is not resumed. fresh handshake, fresh session, periodt.

this function is automatically called by SSL_read(3) and SSL_write(3) whenever the renegotiation byte count set by BIO_set_ssl_renegotiate_bytes(3) or the timeout set by BIO_set_ssl_renegotiate_timeout(3) are exceeded. so lowkey it's doing this for you already 🙈

💅 SSL_renegotiate_abbreviated() — the client-side remix

when called from the client side, SSL_renegotiate_abbreviated() is similar to SSL_renegotiate() except that resuming the session associated with the current connection is attempted in the new handshake. so it's the same bop, just shortened — we're trying to pick up where we left off 🎀

🫶 server-side behavior — yes it's different, ngl

when called from the server side, SSL_renegotiate() and SSL_renegotiate_abbreviated() behave identically. they both schedule a request for a new handshake to be sent to the client ✨

the next time an I/O operation is performed, the same checks as on the client side are performed and then, if appropriate, the request is sent. the client may or may not respond with a new handshake and it may or may not attempt to resume an existing session — we don't control the client's choices, bestie, we just send the vibe 💀

if a new handshake is started, it is handled transparently during any I/O function. so you don't have to do anything extra, it just happens 😌

🌈 if you're a LibreSSL client and a server asks to renegotiate

if a LibreSSL client receives a renegotiation request from a server, it is also handled transparently during any I/O function 🧚 the client attempts to resume the current session in the new handshake. for historical reasons, DTLS clients do not attempt to resume the session in the new handshake — that's just how DTLS has always been, iykyk 💅

---

⭐ RETURN VALUES ⭐

• SSL_renegotiate() and SSL_renegotiate_abbreviated() — return 1 on success or 0 on error 🍓
• SSL_renegotiate_pending() — returns 1 if a renegotiation or renegotiation request has been scheduled but not yet acted on, or 0 otherwise 👑

---

🎀 SEE ALSO 🎀

ssl(3), SSL_do_handshake(3), SSL_num_renegotiations(3), SSL_read(3), SSL_write(3) — go read these too, they're literally the supporting cast 💜

---

🌸 HISTORY 🌸

• SSL_renegotiate() first appeared in SSLeay 0.8.0 and has been available since OpenBSD 2.4 🌈
• SSL_renegotiate_pending() first appeared in OpenSSL 0.9.7 and has been available since OpenBSD 3.2 ✨
• SSL_renegotiate_abbreviated() first appeared in OpenSSL 1.0.1 and has been available since OpenBSD 5.3 🦋

---

that's the whole page, bestie 🫶 this one's from the Debian edition, dated June 8, 2025, and honestly? iconic. go forth and renegotiate responsibly 💖✨🎀