SSL_SET_CONNECT_STATE(3SSL)

📦
version 4.0.3 · 14 versions
, in ubuntu stonking

💖 SSL_SET_CONNECT_STATE — okay bestie, client mode or server mode, pick ur vibe 💖

hi hello welcome to the OpenSSL manual page SSL_SET_CONNECT_STATE(3SSL), aka the one where u tell ur SSL object whether it's the one reaching out (client, main character energy) or the one getting reached out to (server, iconic host energy). ✨

🎀 NAME 🎀

SSL_set_connect_state, SSL_set_accept_state, SSL_is_server — the lil trio of functions for manipulating and examining the client-or-server mode of an SSL object. no cap, that's literally the whole job. 💅

🌸 SYNOPSIS 🌸

#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 🦋

  • SSL_set_connect_state() — sets ssl to work in client mode. ur baby is the one dialing out. 📞
  • SSL_set_accept_state() — sets ssl to work in server mode. ur baby is the one picking up. 🫶
  • SSL_is_server() — checks if ssl is working in server mode. it's a vibe check. one question only: are u the server or not. 👑

✨ NOTES ✨

okay so context first: when the SSL_CTX object was created with SSL_CTX_new(3), it got assigned either a dedicated client method, a dedicated server method, or a generic method that can be used for both client and server connections. (and pssst — that method might have been changed later with SSL_CTX_set_ssl_version(3) or SSL_set_ssl_method(3), so don't just assume it's the same as birth.) 🍼

When u begin a new handshake, the SSL engine must know whether it should call the connect (client) routines or the accept (server) routines. and here's the thing: even though it might be totally obvious from the method u chose whether client or server mode was requested... the handshake routines must still be explicitly set. the engine does not read minds. it's giving "i need it in writing, bestie." 😭

Now the part that saves u effort, depending on what ur doing:

  • If ur using SSL_connect(3) or SSL_accept(3), the correct handshake routines are automatically set for u. slay, no extra steps. 💖
  • If ur doing a transparent negotiation using SSL_write_ex(3), SSL_write(3), SSL_read_ex(3), or SSL_read(3), then the handshake routines must be explicitly set in advance using either SSL_set_connect_state() or SSL_set_accept_state(). do it urself, no autopilot here. 🙈

And the sneaky one — the edge case that will absolutely humble u:

If SSL_is_server() is called before SSL_set_connect_state() or SSL_set_accept_state() is called (whether automatically or explicitly), the result depends on what method was used when SSL_CTX was created with SSL_CTX_new(3).

so like — what does it depend on, exactly? 🌈

  • 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.

periodt. that's the whole rule. 💅

🌟 RETURN VALUES 🌟

  • SSL_set_connect_state() and SSL_set_accept_state() do not return diagnostic information. they just do the thing and dip. no receipt, no error message, nothing. 💀
  • SSL_is_server() returns 1 if ssl is working in server mode, or 0 for client mode.

💜 SEE ALSO 💜

Copyright 2001-2017 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the "License"). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

okay that's the whole page, u ate it up fr fr 🍓 this was OpenSSL version 4.0.3, dated 2026-09-29 — mwah, go set ur connect state and be the client of ur dreams, bestie 💅💖🧚

📦 where this page comes from