SSL_SET_CONNECT_STATE(3)

💅 SSL_SET_CONNECT_STATE(3) — bestie's guide to telling your SSL object who it is

okay so this is a page from the Library Functions Manual for libssl (that's the libcrypto family too, iykyk) and honestly it's short but it's important ✨

---

🌸 NAME 🌸

SSL_set_connect_state, SSL_set_accept_state, SSL_is_server — the trio that prepares your SSL object to work in client mode or server mode 🫶

---

🎀 SYNOPSIS 🎀

library “libssl” libcrypto #include <openssl/ssl.h>

void
SSL_set_connect_state(SSL *ssl);

void
SSL_set_accept_state(SSL *ssl);

int
SSL_is_server(const SSL *ssl);

---

✨ DESCRIPTION ✨

so here's the vibe check on each one:

• SSL_set_connect_state() — sets ssl to work in client mode. you're the one reaching out, bestie 💖
• SSL_set_accept_state() — sets ssl to work in server mode. you're the one getting reached out to, main character energy 👑
• SSL_is_server() — checks whether ssl is set to server mode. just a little "who am i" moment 💅

now the context — because context is everything, fr fr:

When the SSL_CTX object was created with SSL_CTX_new(3), it was either assigned a dedicated client method, a dedicated server method, or a generic method that can be used for both client and server connections. (and yes, the method might have been changed later with SSL_CTX_set_ssl_version(3) or SSL_set_ssl_method(3) — plot twist optional 🌀)

When beginning a new handshake, the SSL engine must know whether it must call the connect (client) or accept (server) routines. Even though it may be clear from the method chosen whether client or server mode was requested, the handshake routines must be explicitly set. like, no assumptions, okay? 😭

Here's the part where it actually matters:

When using the SSL_connect(3) or SSL_accept(3) routines, the correct handshake routines are automatically set. slay, no effort needed ✨

When performing a transparent negotiation using SSL_write(3) or SSL_read(3), the handshake routines must be explicitly set in advance using either SSL_set_connect_state() or SSL_set_accept_state(). no auto-pilot here, you have to say it 🗣️

and now the spicy edge case 🌶️ — if SSL_is_server() is called before SSL_set_connect_state() or SSL_set_accept_state() was called either automatically or explicitly, the result depends on what method was used when the SSL_CTX was created. If a generic method or a dedicated server method was passed to SSL_CTX_new(3), SSL_is_server() returns 1; otherwise, it returns 0. so like... it's giving "it depends" 🙈

---

🔥 RETURN VALUES 🔥

SSL_is_server() returns 1 if ssl is set to server mode or 0 if it is set to client mode. simple as that, periodt 💀

---

🦋 SEE ALSO 🦋

• ssl(3)
• SSL_accept(3)
• SSL_connect(3)
• SSL_CTX_new(3)
• SSL_CTX_set_ssl_version(3)
• SSL_do_handshake(3)
• SSL_new(3)
• SSL_read(3)
• SSL_write(3)

go read them, they're all iconic in their own way 🌈

---

💜 HISTORY 💜

SSL_set_connect_state() and SSL_set_accept_state() first appeared in SSLeay 0.6.0 and have been available since OpenBSD 2.4. ancient. legendary. still here 🏛️

SSL_is_server() first appeared in OpenSSL 1.0.2 and has been available since OpenBSD 6.3. the newer baby of the family 🍓

---

and that's the whole page, bestie 🧚 this one came from the Debian edition, dated June 8, 2025, and it lives at SSL_SET_CONNECT_STATE(3) — go forth and set your connect state responsibly 💖✨🎀