SSL_CONNECT(3)

💖 NAME 💖

okay so bestie, this is the SSL_CONNECT(3) page for SSL_connect — initiate the TLS/SSL handshake with a TLS/SSL server. yes, that's the whole NAME situation, and it's giving “secure the connection before the group chat starts” energy 💅. the page itself lives in the Library Functions Manual, fr fr.

🌸 SYNOPSIS 🌸

obsessed with a clean synopsis, so here it is exactly:

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

int
SSL_connect(SSL *ssl);

🦋 DESCRIPTION 🦋

SSL_connect() kicks off the TLS/SSL handshake with a server. the communication channel must already have been set and assigned to the ssl by setting an underlying BIO. that's the setup, no skipping bestie 🫶.

the behaviour of SSL_connect() depends on the underlying BIO — literally lowkey the vibe check happens at the BIO level.

if the underlying BIO is blocking, SSL_connect() will only return once the handshake has been finished or an error occurred. no cap, it waits. iconic, patient, zero chaos.

if the underlying BIO is non-blocking, SSL_connect() will also return when the underlying BIO could not satisfy the needs of SSL_connect() to continue the handshake, indicating the problem with the return value −1. in this case a call to SSL_get_error(3) with the return value of SSL_connect() will yield SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE. the calling process then must repeat the call after taking appropriate action to satisfy the needs of SSL_connect(). the action depends on the underlying BIO: when using a non-blocking socket, nothing is to be done, but select(2) can be used to check for the required condition. when using a buffering BIO, like a BIO pair, data must be written into or retrieved out of the BIO before being able to continue. periodt ✨.

bestie, that −1 is highkey not a normal fail — it's the “come back after the BIO is ready” signal for non-blocking BIOs. the whole assignment is literally “repeat the call after appropriate action.” 🙈

🔥 RETURN VALUES 🔥

the following return values can occur, and not me listing every single one with love:

• 0 — the TLS/SSL handshake was not successful but was shut down controlled and by the specifications of the TLS/SSL protocol. call SSL_get_error(3) with the return value ret to find out the reason.
• 1 — the TLS/SSL handshake was successfully completed, and a TLS/SSL connection has been established. slay 💅.
• <0 — the TLS/SSL handshake was not successful, because either a fatal error occurred at the protocol level or a connection failure occurred. the shutdown was not clean 💀. it can also occur if action is needed to continue the operation for non-blocking BIOs. call SSL_get_error(3) with the return value ret to find out the reason.

🌈 SEE ALSO 🌈

go check out these icons, iykyk: BIO_new(3), ssl(3), SSL_accept(3), SSL_CTX_new(3), SSL_do_handshake(3), SSL_get_error(3), SSL_set_connect_state(3), SSL_shutdown(3). that's the whole squad 🫶.

🎀 HISTORY 🎀

SSL_connect() appeared in SSLeay 0.4 or earlier and has been available since OpenBSD 2.4. main character energy since forever, ngl 👑.

xoxo, this page is brought to you by Debian, dated June 8, 2025, for SSL_CONNECT(3) 💖🫶