SSL_ACCEPT(3ossl)

πŸ’– SSL_ACCEPT(3ossl) β€” bestie's guide to waiting for the client to show up πŸ’–

okay so this is the SSL_accept page from the OpenSSL manual, and honestly? it's giving "I'll wait for you to text first" energy, except the text is a TLS/SSL handshake and the vibe is extremely serious. let's go πŸ¦‹


✨ NAME ✨

SSL_accept β€” literally just: wait for a TLS/SSL client to initiate a TLS/SSL handshake. that's the whole job. she waits. she's patient. she's booked and busy being patient. πŸ’…


🌸 SYNOPSIS 🌸

#include <openssl/ssl.h>

int SSL_accept(SSL *ssl);

one function, one pointer, no cap. include the header, call the thing. πŸŽ€


🫢 DESCRIPTION 🫢

SSL_accept() sits there and waits for a TLS/SSL client to initiate the TLS/SSL handshake. think of it like holding the door open for someone who hasn't walked up yet β€” very demure, very mindful.

but here's the tea β˜•: the communication channel must already have been set and assigned to the ssl by setting an underlying BIO. like, you cannot just show up with an empty ssl and expect her to work. no BIO, no handshake, no slay. the underlying BIO is the whole prerequisite, periodt.


🧚 NOTES 🧚

the way that SSL_accept() behaves is entirely dependent on the underlying BIO. it's giving "I match your energy" β€” lowkey true and highkey important.

  • If the underlying BIO is blocking β€” SSL_accept() will only return once the handshake has been finished or an error occurred. that's it. she commits. she stays until it's done or it's over. πŸ’€
  • If the underlying BIO is nonblocking β€” SSL_accept() will also return when the underlying BIO could not satisfy the needs of SSL_accept() to continue the handshake, and she'll indicate the problem by the return value -1. in that case, a call to SSL_get_error() with the return value of SSL_accept() will yield SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE.

so what do you do?? 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 nonblocking socket, nothing is to be done, but select() 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. πŸ“₯πŸ“€
not me reminding you that "repeat the call" is not optional, bestie. she said what she said. πŸ”₯

πŸ‘‘ RETURN VALUES πŸ‘‘

here's the vibe check on what she hands back to you:

  • 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() with the return value ret to find out the reason. 😭
  • 1 β€” the TLS/SSL handshake was successfully completed, a TLS/SSL connection has been established. ATE. iconic. we love to see it. πŸŽ‰
  • <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 if action is needed to continue the operation for nonblocking BIOs. call SSL_get_error() with the return value ret to find out the reason. 🚩

🌈 SEE ALSO 🌈

go read these next, iykyk:


Copyright 2000-2020 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 OpenSSL 3.5.9, dated 2026-09-29, and yes she really is called SSL_ACCEPT(3ossl) β€” main character energy, no notes. mwah πŸ’‹βœ¨

πŸ“¦ where this page comes from