SSL_SET_CONNECT_STATE(3ossl)
β¨ SSL_SET_CONNECT_STATE(3ossl) β¨
okay bestie, welcome to the 3ossl manual, OpenSSL edition π this one is short and sweet and it's literally just about telling your SSL object whether it's the client or the server, because apparently it can't figure that out on its own. no cap.
πΈ NAME πΈ
SSL_set_connect_state, SSL_set_accept_state, SSL_is_server β 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()β setssslto work in client mode. she's the one reaching out, main character energy β¨SSL_set_accept_state()β setssslto work in server mode. she's the one getting asked, and she's ready πSSL_is_server()β checks ifsslis working in server mode. vibe check π«Ά
π₯ 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 works for both client and server connections. (and lowkey that method might have been changed later with SSL_CTX_set_ssl_version(3) or SSL_set_ssl_method(3), so keep that in mind.)
when you're beginning a new handshake, the SSL engine must know whether it should call the connect (client) routines or the accept (server) routines. even though the method you chose might make it super obvious whether client or server mode was requested, the handshake routines still have to be explicitly set. like, it just won't guess. π
now here's the part where it gets convenient: when you use the SSL_connect(3) or SSL_accept(3) routines, the correct handshake routines are set automatically. slay. β¨
but when you're doing 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(). no auto-magic there, bestie, you have to say it yourself π
and if you call SSL_is_server() before SSL_set_connect_state() or SSL_set_accept_state() has been called (whether 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), SSL_is_server() returns 1; otherwise, it returns 0. so it's giving "it depends" π¦
β RETURN VALUES β
SSL_set_connect_state() and SSL_set_accept_state() do not return diagnostic information. they're void, they just do the thing and leave. iconic, honestly. π
SSL_is_server() returns 1 if ssl is working in server mode, or 0 for client mode. simple as that. π
π§ 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)
go read those too, iykyk π
π COPYRIGHT π
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 π you ate this one fr fr
this was OpenSSL 3.5.9, dated 2026-09-29, and the manual page is SSL_SET_CONNECT_STATE(3ossl) β mwah, go set some connect states, you've got this ππΈβ¨
π¦ where this page comes from
- fedora 43: openssl-devel 1:3.5.9-1.fc43 Β· Apache-2.0
- fedora 43: openssl-devel 1:3.5.9-1.fc43 Β· Apache-2.0
- fedora 44: openssl-devel 1:3.5.9-1.fc44 Β· Apache-2.0
- fedora 44: openssl-devel 1:3.5.9-1.fc44 Β· Apache-2.0
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms