SSL_EXTENSION_SUPPORTED(3ossl)
π NAME π
okay bestie, this is the SSL_EXTENSION_SUPPORTED(3ossl) page from OpenSSL, and it's all about custom TLS extension handling. the main characters are:
SSL_extension_supportedSSL_custom_ext_add_cb_exSSL_custom_ext_free_cb_exSSL_custom_ext_parse_cb_exSSL_CTX_add_custom_extSSL_CTX_add_client_custom_extSSL_CTX_add_server_custom_extcustom_ext_add_cbcustom_ext_free_cbcustom_ext_parse_cb
π SYNOPSIS π
here's the exact code, no cap:
#include <openssl/ssl.h>
typedef int (*SSL_custom_ext_add_cb_ex)(SSL *s, unsigned int ext_type,
unsigned int context,
const unsigned char **out,
size_t *outlen, X509 *x,
size_t chainidx, int *al,
void *add_arg);
typedef void (*SSL_custom_ext_free_cb_ex)(SSL *s, unsigned int ext_type,
unsigned int context,
const unsigned char *out,
void *add_arg);
typedef int (*SSL_custom_ext_parse_cb_ex)(SSL *s, unsigned int ext_type,
unsigned int context,
const unsigned char *in,
size_t inlen, X509 *x,
size_t chainidx, int *al,
void *parse_arg);
int SSL_CTX_add_custom_ext(SSL_CTX *ctx, unsigned int ext_type,
unsigned int context,
SSL_custom_ext_add_cb_ex add_cb,
SSL_custom_ext_free_cb_ex free_cb,
void *add_arg,
SSL_custom_ext_parse_cb_ex parse_cb,
void *parse_arg);
typedef int (*custom_ext_add_cb)(SSL *s, unsigned int ext_type,
const unsigned char **out,
size_t *outlen, int *al,
void *add_arg);
typedef void (*custom_ext_free_cb)(SSL *s, unsigned int ext_type,
const unsigned char *out,
void *add_arg);
typedef int (*custom_ext_parse_cb)(SSL *s, unsigned int ext_type,
const unsigned char *in,
size_t inlen, int *al,
void *parse_arg);
int SSL_CTX_add_client_custom_ext(SSL_CTX *ctx, unsigned int ext_type,
custom_ext_add_cb add_cb,
custom_ext_free_cb free_cb, void *add_arg,
custom_ext_parse_cb parse_cb,
void *parse_arg);
int SSL_CTX_add_server_custom_ext(SSL_CTX *ctx, unsigned int ext_type,
custom_ext_add_cb add_cb,
custom_ext_free_cb free_cb, void *add_arg,
custom_ext_parse_cb parse_cb,
void *parse_arg);
int SSL_extension_supported(unsigned int ext_type);
β¨ DESCRIPTION β¨
okay so SSL_CTX_add_custom_ext() is the main-character function here: it adds a custom extension for a TLS/DTLS client or server, for all supported protocol versions, with extension type ext_type and callbacks add_cb, free_cb, and parse_cb (peep the EXTENSION CALLBACKS section below π
). the context value tells it which messages and under what conditions the extension gets added/parsed β see EXTENSION CONTEXTS below.
SSL_CTX_add_client_custom_ext() adds a custom extension for a TLS/DTLS client with extension type ext_type and callbacks add_cb, free_cb, and parse_cb. it's similar to SSL_CTX_add_custom_ext() except it only applies to clients, uses the older style of callbacks, and implicitly sets the context value to:
SSL_EXT_TLS1_2_AND_BELOW_ONLY | SSL_EXT_CLIENT_HELLO
| SSL_EXT_TLS1_2_SERVER_HELLO | SSL_EXT_IGNORE_ON_RESUMPTION
SSL_CTX_add_server_custom_ext() adds a custom extension for a TLS/DTLS server with extension type ext_type and callbacks add_cb, free_cb, and parse_cb. it's similar to SSL_CTX_add_custom_ext() except it only applies to servers, uses the older style of callbacks, and implicitly sets the context value to the same thing as SSL_CTX_add_client_custom_ext() above.
the ext_type parameter corresponds to the extension_type field of RFC5246 et al. it is not a NID. in all cases the extension type must not be handled by OpenSSL internally, or an error occurs. periodt.
SSL_extension_supported() returns 1 if the extension ext_type is handled internally by OpenSSL, and 0 otherwise.
π EXTENSION CALLBACKS π
the callback add_cb is called to send custom extension data that gets included in various TLS messages. ext_type is set to the extension type being added, and add_arg is set to the value from when the extension handler was added. when you're using the new style callbacks, the context parameter tells you which message is currently being constructed β for example, for the ClientHello it will be set to SSL_EXT_CLIENT_HELLO.
if the application wants to include the extension ext_type, it should set *out to the extension data, set *outlen to the length of the extension data, and return 1.
if add_cb does not want to include the extension, it must return 0.
if add_cb returns -1, a fatal handshake error occurs using the TLS alert value specified in *al. π
when constructing the ClientHello, if add_cb is set to NULL, a zero length extension is added for ext_type. for all other messages, if add_cb is set to NULL, then no extension is added.
when constructing a Certificate message, the callback will be called for each certificate in the message. the x parameter indicates the current certificate, and the chainidx parameter indicates the position of the certificate in the message. the first certificate is always the end entity certificate and has a chainidx value of 0. the certificates are in the order that they were received in the Certificate message.
for all messages except the ServerHello and EncryptedExtensions, every registered add_cb is always called to see if the application wants to add an extension (as long as all requirements of the specified context are met).
for the ServerHello and EncryptedExtension messages, every registered add_cb is called once if and only if the requirements of the specified context are met and the corresponding extension was received in the ClientHello. that is, if no corresponding extension was received in the ClientHello, then add_cb will not be called.
if an extension is added (that is, add_cb returns 1), free_cb is called (if it is set) with the value of out set by the add callback. it can be used to free up any dynamic extension data set by add_cb. since out is constant (to permit use of constant data in add_cb), applications may need to cast away const to free the data.
the callback parse_cb receives data for TLS extensions. it is only called if the extension is present and relevant for the context (see EXTENSION CONTEXTS below).
the extension data consists of inlen bytes in the buffer in for the extension ext_type.
if the message being parsed is a TLSv1.3 compatible Certificate message, then parse_cb will be called for each certificate contained within the message. the x parameter indicates the current certificate, and the chainidx parameter indicates the position of the certificate in the message. the first certificate is always the end entity certificate and has a chainidx value of 0.
if parse_cb considers the extension data acceptable, it must return 1. if it returns 0 or a negative value, a fatal handshake error occurs using the TLS alert value specified in *al.
the buffer in is a temporary internal buffer which will not be valid after the callback returns. don't be weird about it, bestie.
π¦ EXTENSION CONTEXTS π¦
an extension context defines which messages and under which conditions an extension should be added or expected. the context is built up by doing a bitwise OR of multiple pre-defined values together. the valid context values are:
SSL_EXT_TLS_ONLYβ the extension is only allowed in TLSSSL_EXT_DTLS_ONLYβ the extension is only allowed in DTLSSSL_EXT_TLS_IMPLEMENTATION_ONLYβ the extension is allowed in DTLS, but there's only a TLS implementation available (so it gets ignored in DTLS)SSL_EXT_SSL3_ALLOWEDβ extensions are not typically defined for SSLv3. setting this value will allow the extension in SSLv3. applications will not typically need to use thisSSL_EXT_TLS1_2_AND_BELOW_ONLYβ the extension is only defined for TLSv1.2/DTLSv1.2 and below. servers will ignore this extension if it is present in the ClientHello and TLSv1.3 is negotiatedSSL_EXT_TLS1_3_ONLYβ the extension is only defined for TLS1.3 and above. servers will ignore this extension if it is present in the ClientHello and TLSv1.2 or below is negotiatedSSL_EXT_IGNORE_ON_RESUMPTIONβ the extension will be ignored during parsing if a previous session is being successfully resumedSSL_EXT_CLIENT_HELLOβ the extension may be present in the ClientHello messageSSL_EXT_TLS1_2_SERVER_HELLOβ the extension may be present in a TLSv1.2 or below compatible ServerHello messageSSL_EXT_TLS1_3_SERVER_HELLOβ the extension may be present in a TLSv1.3 compatible ServerHello messageSSL_EXT_TLS1_3_ENCRYPTED_EXTENSIONSβ the extension may be present in an EncryptedExtensions messageSSL_EXT_TLS1_3_HELLO_RETRY_REQUESTβ the extension may be present in a HelloRetryRequest messageSSL_EXT_TLS1_3_CERTIFICATEβ the extension may be present in a TLSv1.3 compatible Certificate messageSSL_EXT_TLS1_3_NEW_SESSION_TICKETβ the extension may be present in a TLSv1.3 compatible NewSessionTicket messageSSL_EXT_TLS1_3_CERTIFICATE_REQUESTβ the extension may be present in a TLSv1.3 compatible CertificateRequest message
fr fr, the context must include at least one message value (otherwise the extension will never be used).
π NOTES
okay so real talk about add_arg and parse_arg, bestie: you can set those parameters to arbitrary values, and those values get passed straight to the corresponding callbacks. Theyβre literally your little carry-on bags π β you could use them to stash the extension data you received in a convenient structure, or to pass along the extension data you want added or freed when adding extensions. iconic.
Now the β¨dramaβ¨ rules, because TLS does not play:
- If the same custom extension
ext_typeis received multiple times, a fataldecode_erroralert is sent and the handshake aborts. π - If a custom extension is received in a
ServerHello/EncryptedExtensionsmessage that was not sent in theClientHello, a fatalunsupported_extensionalert is sent and the handshake is aborted. π¨ - The
ServerHello/EncryptedExtensionsadd_cbcallback is only called if the corresponding extension was received in theClientHello.
This is compliant with the TLS specifications, no cap. And the whole point is super clean: each callback gets called at most once, and an application can never send unsolicited extensions. main character energy with boundaries π
π«Ά RETURN VALUES
SSL_CTX_add_custom_ext(),SSL_CTX_add_client_custom_ext(), andSSL_CTX_add_server_custom_ext()return1for success and0for failure.- A failure can happen if you try to add the same
ext_typemore than once, if you try to use an extension type thatβs handled internally by OpenSSL, or if some internal error occurs β for example, a memory allocation failure. π SSL_extension_supported()returns1if the extensionext_typeis handled internally by OpenSSL, and0otherwise.
π SEE ALSO
πΈ HISTORY
The SSL_CTX_add_custom_ext() function was added in OpenSSL 1.1.1. a whole era β¨
Β©οΈ COPYRIGHT
Copyright 2014-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 tea, bestie βπ¦ this page is source/version 3.5.0, dated 2026-09-25, and itβs filed under SSL_EXTENSION_SUPPORTED(3ossl) β slay, go forth and TLS responsibly π
π¦ where this page comes from
- opensuse-leap 16.0: openssl-3-doc 3.5.0-160000.11.1 Β· Apache-2.0
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on : a language model's rewrite of the original, under its terms