SSL_CTX_SET_T...NAME_CALLBACK(3SSL)

📦

version 4.0.3 · 14 versions

💖 SSL_CTX_SET_T...NAME_CALLBACK(3SSL) 💖

okay bestie, pull up a chair 🫶 this is the OpenSSL manpage (section 3SSL, we're fancy like that) all about server name indication, aka SNI — the thing that lets one server answer for a whole lil family of hostnames. It covers SSL_CTX_set_tlsext_servername_callback, SSL_CTX_set_tlsext_servername_arg, SSL_get_servername_type, SSL_get_servername and SSL_set_tlsext_host_name, and honestly? the way it's got nine separate behaviour cases for SSL_get_servername() alone. main character energy. let's go ✨

🌸 NAME 🌸

SSL_CTX_set_tlsext_servername_callback, SSL_CTX_set_tlsext_servername_arg, SSL_get_servername_type, SSL_get_servername, SSL_set_tlsext_host_name — the whole crew that handles server name indication (SNI) 🎀

🌈 SYNOPSIS 🌈

#include <openssl/ssl.h>

long SSL_CTX_set_tlsext_servername_callback(SSL_CTX *ctx,
                                  int (*cb)(SSL *s, int *al, void *arg));
long SSL_CTX_set_tlsext_servername_arg(SSL_CTX *ctx, void *arg);

const char *SSL_get_servername(const SSL *s, int type);
int SSL_get_servername_type(const SSL *s);

int SSL_set_tlsext_host_name(const SSL *s, const char *name);

✨ DESCRIPTION ✨

so here's the tea 🍓 the whole job that the servername callback used to own is mostly superseded by the ClientHello callback, which you set with SSL_CTX_set_client_hello_cb(). But — and this is the important bit — even when you're already using the ClientHello callback, the servername callback is still necessary, because it's the thing that actually acknowledges the servername the client requested. no cap. 💅

SSL_CTX_set_tlsext_servername_callback() sets the application callback cb that a server uses to do whatever actions or configuration it needs based on the servername extension it received on the incoming connection. Pass cb as NULL and SNI just… isn't used. 🙈

⚠️ heads up bestie: this callback fires late in the processing of the ClientHello message. Like, after session resumption has already happened. So typically you should not call things like SSL_set_session_id_context(3) from inside it — it's too late to affect session resumption for the current handshake. 😭

The servername callback should return one of these values:

SSL_TLSEXT_ERR_OK — the servername the client asked for has been accepted. Typically a server calls SSL_set_SSL_CTX() here to set up a different configuration for the chosen servername. slay 💖
SSL_TLSEXT_ERR_ALERT_FATAL — nah, the requested servername is not accepted and the handshake gets aborted 💀. The alert value to use should be stored at the location the al parameter points to. By default that value is initialised to SSL_AD_UNRECOGNIZED_NAME.
SSL_TLSEXT_ERR_ALERT_WARNING — the servername is not accepted by the server, BUT the handshake keeps going and sends a warning alert instead. Same deal with al as for SSL_TLSEXT_ERR_ALERT_FATAL above. ⚠️ Note that TLSv1.3 does not support warning alerts, so if TLSv1.3 got negotiated, this return value is treated exactly the same as SSL_TLSEXT_ERR_NOACK. periodt.
SSL_TLSEXT_ERR_NOACK — the servername is not accepted by the server, no alerts are sent at all, and the server will not acknowledge the requested servername. 🤷

SSL_CTX_set_tlsext_servername_arg() sets a context-specific argument to be passed into the callback (via the arg parameter) for this SSL_CTX. cute lil sidecar 🎀

🦋 The many moods of `SSL_get_servername()` 🦋

The behaviour of SSL_get_servername() depends on a whole bunch of different factors. In particular, note that in TLSv1.3 the servername is negotiated in every handshake. In TLSv1.2 the servername is only negotiated on initial handshakes, not on resumption handshakes. iykyk 💫

On the client, before the handshake

If a servername has been set via a call to SSL_set_tlsext_host_name() then it will return that servername.
If one has not been set, but a TLSv1.2 resumption is being attempted and the session from the original handshake had a servername accepted by the server, then it will return that servername.
Otherwise it returns NULL.

On the client, during or after the handshake and a TLSv1.2 (or below) resumption occurred

If the session from the original handshake had a servername accepted by the server then it will return that servername.
Otherwise it returns the servername set via SSL_set_tlsext_host_name(), or NULL if it was not called.

On the client, during or after the handshake and a TLSv1.2 (or below) resumption did not occur

It will return the servername set via SSL_set_tlsext_host_name(), or NULL if it was not called.

On the server, before the handshake

The function will always return NULL before the handshake. every time. no exceptions 🫠

On the server, after the servername extension has been processed and a TLSv1.2 (or below) resumption occurred

If a servername was accepted by the server in the original handshake then it will return that servername, or NULL otherwise.

On the server, after the servername extension has been processed and a TLSv1.2 (or below) resumption did not occur

The function will return the servername requested by the client in this handshake, or NULL if none was requested.

🔔 little ordering note: the ClientHello callback occurs before a servername extension from the client is processed. The servername, certificate and ALPN callbacks occur after a servername extension from the client is processed. 🧚

SSL_get_servername_type() returns the servername type, or -1 if there's no servername present. Currently the only supported type (defined in RFC3546) is TLSEXT_NAMETYPE_host_name. 👑

SSL_set_tlsext_host_name() sets the server name indication ClientHello extension to contain the value name. The type of the server name indication extension gets set to TLSEXT_NAMETYPE_host_name (defined in RFC3546). 🦋

🎀 NOTES 🎀

Several callbacks get executed during ClientHello processing, including the ClientHello, ALPN, and servername callbacks. The order is: ClientHello callback first, then the servername callback, followed by the ALPN callback. a whole lil queue bestie 💅

The SSL_set_tlsext_host_name() function should only be called on SSL objects that will act as clients — otherwise the configured name will just be ignored. 🙈

💜 RETURN VALUES 💜

SSL_CTX_set_tlsext_servername_callback() and SSL_CTX_set_tlsext_servername_arg() both always return 1, indicating success. iconic, no notes. ✨
SSL_set_tlsext_host_name() returns 1 on success, 0 in case of error. 😭

📜 HISTORY 📜

SSL_get_servername() historically served up some unexpected results in certain corner cases 😬 — this got fixed from OpenSSL 1.1.1e.

Prior to 1.1.1e: when the client requested a servername in an initial TLSv1.2 handshake, the server accepted it, and then the client successfully resumed but set a different explicit servername in the second handshake — when called by the client it returned the servername from the second handshake. This has now been changed to return the servername requested in the original handshake. 🔥
Also prior to 1.1.1e: if the client sent a servername in the first handshake but the server did not accept it, and then a second handshake occurred where TLSv1.2 resumption was successful — when called by the server it returned the servername requested in the original handshake. This has now been changed to NULL. 💀

👑 COPYRIGHT 👑

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 it 💅💖 this was OpenSSL 4.0.3, dated 2026-09-2 — now go set that servername and slay 🦋✨

📦 where this page comes from

ubuntu stonking: libssl-doc 4.0.3-1ubuntu1 · Apache-2.0
💖 girlified by deepseek-ai/DeepSeek-V4.1-Flash on 2026-11-03: a language model's rewrite of the original, under its terms

SSL_CTX_SET_T...NAME_CALLBACK(3SSL)