SSL_KEY_UPDATE(3ossl)

💅 SSL_KEY_UPDATE — the 3ossl manual, but make it make sense

okay so bestie, buckle up: this is the 3ossl page all about updating your connection keys and kicking off renegotiations. it's giving "glow-up for your TLS session" energy and honestly? iconic. let's get into it ✨

🌸 NAME

SSL_key_update, SSL_get_key_update_type, SSL_renegotiate, SSL_renegotiate_abbreviated, SSL_renegotiate_pending — the whole squad whose job is to initiate and obtain information about updating connection keys 🎀

✨ SYNOPSIS

#include <openssl/ssl.h>

int SSL_key_update(SSL *s, int updatetype);
int SSL_get_key_update_type(const SSL *s);

int SSL_renegotiate(SSL *s);
int SSL_renegotiate_abbreviated(SSL *s);
int SSL_renegotiate_pending(const SSL *s);

🦋 DESCRIPTION

SSL_key_update() schedules an update of the keys for the current TLS connection. like, it's on the calendar, it's in the group chat, it just hasn't happened yet, ykwim? 🗓️

so, on the updatetype parameter:

• if updatetype is set to SSL_KEY_UPDATE_NOT_REQUESTED, then the sending keys for this connection get updated and the peer is informed of the change. polite, no pressure. 💌
• if updatetype is set to SSL_KEY_UPDATE_REQUESTED, then the sending keys for this connection get updated and the peer is informed of the change plus a request for the peer to additionally update its sending keys. mutual glow-up, love that for them. 🔥
• and if updatetype is set to SSL_KEY_UPDATE_NONE? that's an error. not me setting it to none, embarrassing. 💀

okay so critical details, don't skip these bestie:

SSL_key_update() must only be called after the initial handshake has been completed and TLSv1.3 or QUIC has been negotiated, and at the same time, the application needs to ensure that the writing of data has been completed. the key update will not take place until the next time an IO operation such as SSL_read_ex() or SSL_write_ex() takes place on the connection. alternatively SSL_do_handshake() can be called to force the update to take place immediately. no cap. ⚡

SSL_get_key_update_type() is your little peek behind the curtain 🔍 — it can be used to determine whether a key update operation has been scheduled but not yet performed. the type of the pending key update operation will be returned if there is one, or SSL_KEY_UPDATE_NONE otherwise.

SSL_renegotiate() and SSL_renegotiate_abbreviated() should only be called for connections that have negotiated TLSv1.2 or less. calling them on any other connection will result in an error. read that again. periodt. 🙅‍♀️

when called from the client side, SSL_renegotiate() schedules a completely new handshake over an existing SSL/TLS connection. the next time an IO operation such as SSL_read_ex() or SSL_write_ex() takes place on the connection, a check will be performed to confirm that it is a suitable time to start a renegotiation. if so, then it will be initiated immediately. and here's the lil twist — OpenSSL will not attempt to resume any session associated with the connection in the new handshake. fresh start, she's reinventing herself 💫

when called from the client side, SSL_renegotiate_abbreviated() works in the same was as SSL_renegotiate() (yes that's the original's typo, keeping it, love her) except that OpenSSL will attempt to resume the session associated with the current connection in the new handshake. same vibe, but she's bringing her old notes. 📓

when called from the server side, SSL_renegotiate() and SSL_renegotiate_abbreviated() behave identically. they both schedule a request for a new handshake to be sent to the client. the next time an IO operation is performed, then the same checks as on the client side are performed and then, if appropriate, the request is sent. the client may or may not respond with a new handshake and it may or may not attempt to resume an existing session. it's giving "no thoughts, head empty, we'll see" 🙈. if a new handshake is started, then this will be handled transparently by calling any OpenSSL IO function.

and if an OpenSSL client receives a renegotiation request from a server, then again this will be handled transparently through calling any OpenSSL IO function. for a TLS connection the client will attempt to resume the current session in the new handshake. for historical reasons, DTLS clients will not attempt to resume the session in the new handshake. history said no 💅

SSL_renegotiate_pending() returns 1 if a renegotiation or renegotiation request has been scheduled but not yet acted on, or 0 otherwise. she's just checking if there's anything still simmering 🍓

🌈 USAGE WITH QUIC

SSL_key_update() can also be used to perform a key update when using QUIC. the function must be called on a QUIC connection SSL object. this is normally done automatically when needed — she's independent, she's got this 💁‍♀️

since a locally initiated QUIC key update always causes a peer to also trigger a key update, passing SSL_KEY_UPDATE_NOT_REQUESTED as updatetype has the exact same effect as passing SSL_KEY_UPDATE_REQUESTED. same energy, different label. 👑

the QUIC connection must have been fully established before a key update can be performed, and other QUIC protocol rules govern how frequently QUIC key update can be performed. SSL_key_update() will fail if these requirements are not met. rules are rules bestie 🚨

and because QUIC key updates are always handled immediately, SSL_get_key_update_type() always returns SSL_KEY_UPDATE_NONE when called on a QUIC connection SSL object. every time. no in-between. ⭐

🔥 RETURN VALUES

• SSL_key_update(), SSL_renegotiate() and SSL_renegotiate_abbreviated() return 1 on success or 0 on error.
• SSL_get_key_update_type() returns the update type of the pending key update operation or SSL_KEY_UPDATE_NONE if there is none.
• SSL_renegotiate_pending() returns 1 if a renegotiation or renegotiation request has been scheduled but not yet acted on, or 0 otherwise.

👀 SEE ALSO

ssl(7), SSL_read_ex(3), SSL_write_ex(3), SSL_do_handshake(3) — go read these too, iykyk 🫶

💜 HISTORY

the SSL_key_update() and SSL_get_key_update_type() functions were added in OpenSSL 1.1.1. vintage, but make it fresh 🎀

©️ COPYRIGHT

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

---

okay that's the whole page bestie, mwah 💋 — this cutie was brought to you by 3.5.0, dated 2026-09-25, and yes that's SSL_KEY_UPDATE(3ossl) signing off 🌸✨🦋