SSL_CTX_SET_...AME_CALLBACK(3ossl)

💖 NAME 💖

okay bestie, gather round, this page is all about server name indication (SNI) and it covers these absolute icons:

• SSL_CTX_set_tlsext_servername_callback
• SSL_CTX_set_tlsext_servername_arg
• SSL_get_servername_type
• SSL_get_servername
• SSL_set_tlsext_host_name

like, they handle server name indication (SNI). that's the whole vibe. ✨

---

🌸 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, const int type);
int SSL_get_servername_type(const SSL *s);

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

---

🦋 DESCRIPTION 🦋

so, real talk: the servername callback is mostly been replaced by the ClientHello callback, which you set with SSL_CTX_set_client_hello_cb(). it's giving "the new girl is here" 💅. BUT — and this is important — even when you're using the ClientHello callback, the servername callback is still necessary so you can acknowledge the servername the client asked for. no skipping it, bestie.

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 that came in with the incoming connection. when cb is NULL, SNI is just... not used. okay?

⚠️ heads up: this callback happens late in the processing of the ClientHello message. specifically, it fires after session resumption has already happened. so like, typically you should NOT be calling functions like SSL_set_session_id_context(3) in there, because it is way too late to affect the session resumption for the current handshake. the moment has passed, bestie 😭.

the servername callback should return one of these values:

• SSL_TLSEXT_ERR_OK — this one says "yes, the servername the client asked for is accepted." typically a server will call SSL_set_SSL_CTX() inside the callback to set up a different configuration for the servername it just picked. main character behavior honestly. 👑
• SSL_TLSEXT_ERR_ALERT_FATAL — here the servername the client requested is not accepted, and the handshake gets aborted. the value of the alert to use should be stored in the location that the al parameter of the callback points to. by default, that value is initialised to SSL_AD_UNRECOGNIZED_NAME.
• SSL_TLSEXT_ERR_ALERT_WARNING — if you return this, the servername is not accepted by the server. however, the handshake keeps going and sends a warning alert instead. the alert value should be stored in the location pointed to by the al parameter, same as for SSL_TLSEXT_ERR_ALERT_FATAL above. note that TLSv1.3 does not support warning alerts, so if TLSv1.3 has been negotiated then this return value gets treated exactly the same way as SSL_TLSEXT_ERR_NOACK. rude but true.
• SSL_TLSEXT_ERR_NOACK — this return value means the servername is not accepted by the server. no alerts are sent, and the server will not acknowledge the requested servername. silent treatment fr fr.

SSL_CTX_set_tlsext_servername_arg() sets a context-specific argument that gets passed into the callback (via the arg parameter) for this SSL_CTX. it's like slipping your callback a little note. 🎀

---

🫶 the many moods of SSL_get_servername() 🫶

the behaviour of SSL_get_servername() depends on a 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. okay so now, scenario by scenario:

• 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. always. 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.

also, bestie, the ordering lore: 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. keep that timeline straight and you're golden. ✨

---

SSL_get_servername_type() returns the servername type, or -1 if no servername is present. currently the only supported type (defined in RFC3546) is TLSEXT_NAMETYPE_host_name. that's it, that's the whole list.

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 is 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 locked in, no cap:

1. the ClientHello callback is executed first
2. then the servername callback
3. followed by the ALPN callback

🚨 also important: 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. it's giving "wrong audience" 🙈.

---

🌈 RETURN VALUES 🌈

• SSL_CTX_set_tlsext_servername_callback() and SSL_CTX_set_tlsext_servername_arg() both always return 1, indicating success. always winning.
• SSL_set_tlsext_host_name() returns 1 on success, 0 in case of error.

---

🔥 SEE ALSO 🔥

ssl(7), SSL_CTX_set_alpn_select_cb(3), SSL_get0_alpn_selected(3), SSL_CTX_set_client_hello_cb(3)

go read those next, bestie, they're all connected iykyk.

---

⭐ HISTORY ⭐

SSL_get_servername() historically gave some unexpected results in certain corner cases. that has been fixed starting from OpenSSL 1.1.1e. glow-up achieved. 🦋

before 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. plot twist resolved.

also before 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. the audacity of the old behavior honestly 😭.

---

👑 COPYRIGHT 👑

Copyright 2017-2026 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>.

---

okay that's the whole page, you ate it, periodt 💖 this was the SSL_CTX_SET_...AME_CALLBACK page from the OpenSSL manual, version 3.5.9, dated 2026-09-29. go forth and slay your handshakes, bestie 🎀✨