SSL_SET_CONNECT_STATE(3ossl)

📦
version 15.1 · 2 versions
, in freebsd 15.1

🌸 SSL_SET_CONNECT_STATE 💅 (that's the 3ossl manual, bestie)

okay so real talk, this is THE page for telling an SSL object whether it's the client or the server in the relationship, and also for asking it which one it thinks it is. main character energy for handshakes, honestly.

✨ NAME ✨

SSL_set_connect_state, SSL_set_accept_state, SSL_is_server — literally the functions for manipulating and examining the client or server mode of an SSL object 🎀

🦋 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. slay, you're the one reaching out 🫶
  • SSL_set_accept_state() — sets ssl to work in server mode. you're the one being reached out to, iconic 👑
  • SSL_is_server() — checks if ssl is working in server mode. a little vibe check, if you will ✨

🔥 NOTES 🔥

so 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 yeah, that method might have been changed later with SSL_CTX_set_ssl_version(3) or SSL_set_ssl_method(3) — no cap.)

when you're beginning a new handshake, the SSL engine has to 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 still must be explicitly set. like, the engine is not a mind reader, bestie 😭

when you're using the SSL_connect(3) or SSL_accept(3) routines, the correct handshake routines are automatically set — love that for you 💅

ok but when performing a transparent negotiation using SSL_write_ex(3), SSL_write(3), SSL_read_ex(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(). not optional. not automatic. do it. 🙈

and here's the messy part — if SSL_is_server() is called before SSL_set_connect_state() or SSL_set_accept_state() is called (either automatically or explicitly), the result depends on what method was used when the SSL_CTX was created with SSL_CTX_new(3). 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. it's giving "it depends" and honestly that's just how it is 🦋

⭐ RETURN VALUES ⭐

  • SSL_set_connect_state() and SSL_set_accept_state() do not return diagnostic information. they just do the thing, no receipts 💀
  • SSL_is_server() returns 1 if ssl is working in server mode, or 0 for client mode. two moods only 🌈

🌸 SEE ALSO 🌸

ssl(7), SSL_new(3), SSL_CTX_new(3), SSL_connect(3), SSL_accept(3), SSL_write_ex(3), SSL_write(3), SSL_read_ex(3), SSL_read(3), SSL_do_handshake(3), SSL_CTX_set_ssl_version(3)

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

and that's the whole page, bestie 🫶 this was 3.5.6, dated 2026-04-07 — go forth and set your connect state responsibly 💜

📦 where this page comes from