SSL_SET_CONNECT_STATE(3ossl)

πŸ“¦ version 3.5.0, in opensuse-leap 16.0

πŸ’… SSL_set_connect_state, SSL_set_accept_state, SSL_is_server β€” the client-or-server era, explained πŸŽ€

Okay bestie, so this is <pink>SSL_SET_CONNECT_STATE(3ossl)</pink>, part of the OpenSSL family ✨ β€” and it's literally the page that answers "am I the client or am I the server?" for an SSL object. Short page, huge main character energy. Let's go 🫢


🌸 NAME 🌸

SSL_set_connect_state, SSL_set_accept_state, SSL_is_server β€” the functions for manipulating and examining the client-or-server mode of an SSL object. That's the whole vibe check: set it to client, set it to server, or ask which one it's doing πŸ’–


πŸ¦‹ 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);

Three little lines. One of them returns void and one of them returns an int. Don't mix them up, iykyk 😭


✨ DESCRIPTION ✨

  • SSL_set_connect_state() β€” sets ssl to work in client mode. You're the one reaching out, periodt πŸ’…
  • SSL_set_accept_state() β€” sets ssl to work in server mode. You're the one being reached out to, crown on πŸ‘‘
  • SSL_is_server() β€” checks if ssl is working in server mode. Just a peek, no changes πŸ”

🧚 NOTES 🧚

So here's the lore. 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 lowkey, that method might have been changed afterwards, with SSL_CTX_set_ssl_version(3) or SSL_set_ssl_method(3).) 🌈

Now β€” when you're beginning a new handshake, the SSL engine must know whether it has to call the connect (client) routines or the accept (server) routines. And here's the thing bestie, because this trips people up: 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. No assuming, no vibes-only. Explicit. 😀

When you use SSL_connect(3) or SSL_accept(3), the correct handshake routines get set automatically for you. Slay, no extra work πŸ’–

But when you're doing a transparent negotiation with SSL_write_ex(3), SSL_write(3), SSL_read_ex(3), or SSL_read(3), you have to set the handshake routines explicitly, in advance, using either SSL_set_connect_state() or SSL_set_accept_state(). Those functions don't read your mind, bestie. 🫢

🚨 If SSL_is_server() is called before SSL_set_connect_state() or SSL_set_accept_state() is called β€” whether that happens automatically or explicitly β€” the result depends on what method was used when SSL_CTX was created with SSL_CTX_new(3). Specifically: if a generic method or a dedicated server method was passed to SSL_CTX_new(3), then SSL_is_server() returns 1; otherwise, it returns 0. So order of operations is literally everything here πŸ’€

πŸ“ RETURN VALUES πŸ“

SSL_set_connect_state() and SSL_set_accept_state() do not return diagnostic information. That's it, that's the return value. They just do the thing and dip πŸ™ˆ

SSL_is_server() returns 1 if ssl is working in server mode, or 0 for client mode. Binary. Iconic. 🌟


πŸ’œ 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)

The whole friend group, fr fr πŸŽ€


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>. Legally required reading, but make it fashion πŸ’…


And that's the page, bestie!! 🌸 Signing off with the receipts: this is from 3.5.0, dated 2026-09-25, and it's SSL_SET_CONNECT_STATE from the 3ossl manual. Go set your states. Explicitly. 😌✨

πŸ“¦ where this page comes from