SSL_ACCEPT(3)

💅 SSL_accept(3) — wait for a TLS/SSL client to initiate a TLS/SSL handshake 💅

okay so this page is straight out of the Library Functions Manual, and it is giving “server-side waiting era” ✨. The function is SSL_accept(), and it is literally the move where you wait for a TLS/SSL client to initiate the TLS/SSL handshake. No cap.

---

✨ NAME

SSL_accept — wait for a TLS/SSL client to initiate a TLS/SSL handshake 🫶

🌸 SYNOPSIS

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

int
SSL_accept(SSL *ssl);

💖 DESCRIPTION

okay bestie, here is the vibe: SSL_accept() waits for a TLS/SSL client to initiate the TLS/SSL handshake. But first — and this is important — the communication channel must already have been set and assigned to the ssl object by setting an underlying BIO. Like, you cannot just show up with no BIO and expect the handshake to slay. 🙈

The behaviour of SSL_accept() depends on the underlying BIO.

• If the underlying BIO is blocking, SSL_accept() will only return once the handshake has been finished or an error occurred. So it sits there, patient main character style, until something happens. ⭐
• If the underlying BIO is non-blocking, SSL_accept() will also return when the underlying BIO could not satisfy the needs of SSL_accept() to continue the handshake, indicating the problem by the return value −1. In this case a call to SSL_get_error(3) with the return value of SSL_accept() 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_accept(). 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. 🌀

🎀 RETURN VALUES

The following return values can occur:

• 0 — The TLS/SSL handshake was not successful, but it was shut down in a controlled way 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 a fatal error occurred either at the protocol level or a connection failure occurred. The shutdown was not clean. It can also occur of action is need 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 these out too, bestie:

• BIO_new(3)
• ssl(3)
• SSL_connect(3)
• SSL_CTX_new(3)
• SSL_do_handshake(3)
• SSL_get_error(3)
• SSL_set_connect_state(3)
• SSL_shutdown(3)

👑 HISTORY

SSL_accept() appeared in SSLeay 0.4 or earlier and has been available since OpenBSD 2.4. iconic longevity behaviour, honestly. 🌈

---

later, bestie! 💜 this page came from the Debian version dated June 8, 2025, and the footer says SSL_ACCEPT(3) — mwah! 🎀