SSL_SET_SHUTDOWN(3ossl)

📦 version 3.5.0, in opensuse-leap 16.0

💅 SSL_SET_SHUTDOWN — ok so hear me out, it's about shutdown state

OpenSSL manual, bestie. SSL_set_shutdown, SSL_get_shutdown — literally the two functions that let you peek at and poke the shutdown state of an SSL connection. Buckle up. 🎀

✨ SYNOPSIS ✨

#include <openssl/ssl.h>

void SSL_set_shutdown(SSL *ssl, int mode);

int SSL_get_shutdown(const SSL *ssl);

🌸 DESCRIPTION 🌸

SSL_set_shutdown() sets the shutdown state of ssl to mode. That's it. That's the whole thing. 💅

SSL_get_shutdown() returns the shutdown mode of ssl. Iconic, low-effort, does exactly what it says on the tin.

🦋 NOTES 🦋

ok so the shutdown state of an ssl connection is a bit-mask — think of it like a little set of flags living in an int, and here's what each bit means:

  • 0 — no shutdown setting yet. Nothing's happened. Blank slate era. ✨
  • SSL_SENT_SHUTDOWN — a close_notify shutdown alert was sent to the peer, the connection is being considered closed, and the session is closed and correct. Clean exit, no notes. 👑
  • SSL_RECEIVED_SHUTDOWN — a shutdown alert was received from the peer, either a normal close_notify or a fatal error. 😭

SSL_SENT_SHUTDOWN and SSL_RECEIVED_SHUTDOWN can be set at the same time. Both flags, one int, no drama. 🫶

So here's why anyone cares: the shutdown state of the connection is used to determine the state of the ssl session. If the session is still open when SSL_clear(3) or SSL_free(3) is called, it is considered bad and removed according to RFC2246. 💀 Not cute. Not the vibe.

The actual condition for a correctly closed session is SSL_SENT_SHUTDOWN — according to the TLS RFC, it's acceptable to only send the close_notify alert but to not wait for the peer's answer when the underlying connection is closed. So you don't gotta sit there waiting, bestie, that's allowed. 🙈

SSL_set_shutdown() can be used to set this state without sending a close alert to the peer — see SSL_shutdown(3). Yes, you can just… declare it so. Main character energy.

If a close_notify was received, SSL_RECEIVED_SHUTDOWN will be set. But for setting SSL_SENT_SHUTDOWN, the application must however still call SSL_shutdown(3) or SSL_set_shutdown() itself. Nobody's doing it for you, fr fr. 💅

⚠️ heads up: SSL_set_shutdown() is not supported for QUIC SSL objects. Not a thing. Don't try it. 💀

🔥 RETURN VALUES 🔥

SSL_set_shutdown() does not return diagnostic information. It just… does the thing. Void function behaviour, no feedback, no notes. 😌

SSL_get_shutdown() returns the current shutdown state as set, or based on the actual connection state.

And the QUIC 🌈 plot twist: SSL_get_shutdown() returns 0 if called on a QUIC stream SSL object. But if it's called on a QUIC connection SSL object, it returns a value with SSL_SENT_SHUTDOWN set if CONNECTION_CLOSE has been sent to the peer, and it returns a value with SSL_RECEIVED_SHUTDOWN set if CONNECTION_CLOSE has been received from the peer or the QUIC connection is fully terminated for other reasons. Two different objects, two whole different vibes. 🧚

🌟 SEE ALSO 🌟

Copyright 2001-2023 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 version 3.5.0, dated 2026-09-25, brought to you by the SSL_SET_SHUTDOWN(3ossl) girlies. slay, stay encrypted, and always send your close_notify. 💅✨

📦 where this page comes from