SSL_KEY_UPDATE(3ossl)

📦
version 15.1 · 2 versions
, in freebsd 15.1

💅 SSL_KEY_UPDATE — the "let's get new keys bestie" page ✨

ok so this is the 3ossl manual page, and it's literally all about rotating your TLS connection keys and (the old-school way) kicking off renegotiations. stay with me, it's not as much as it looks 🫶

🌸 NAME 🌸

SSL_key_update, SSL_get_key_update_type, SSL_renegotiate, SSL_renegotiate_abbreviated, SSL_renegotiate_pending — the whole squad that kicks off a key update and/or tells you what's going on with 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 a key update for the TLS connection you're currently vibing on. so like:

  • if updatetype is SSL_KEY_UPDATE_NOT_REQUESTED, the sending keys for this connection get updated and the peer gets told about the change. that's it, that's the whole thing 💅
  • if updatetype is SSL_KEY_UPDATE_REQUESTED, the sending keys for this connection get updated, the peer gets told about the change, and you also ask the peer to update its sending keys too. mutual glow-up ✨
  • if updatetype is SSL_KEY_UPDATE_NONE — that's an error, bestie. don't do that. 😭
ok important: SSL_key_update() must ONLY be called after the initial handshake has been completed AND TLSv1.3 or QUIC has been negotiated. at the same time, the application needs to make sure that the writing of data has been completed. the key update will not take place until the next time an IO operation like SSL_read_ex() or SSL_write_ex() happens on the connection. alternatively you can call SSL_do_handshake() to force the update to take place immediately 🔥

SSL_get_key_update_type() is your little gossip source — it tells you whether a key update operation has been scheduled but not yet performed. if there is a pending one, you get its type back; otherwise you get SSL_KEY_UPDATE_NONE. iykyk 👑

okay now the renegotiation girlies. SSL_renegotiate() and SSL_renegotiate_abbreviated() should only be called for connections that have negotiated TLSv1.2 or less. calling them on anything else will result in an error. no cap 🫠

when you're calling from the client side:

SSL_renegotiate() schedules a completely new handshake over an existing SSL/TLS connection. the next time an IO operation like SSL_read_ex() or SSL_write_ex() happens on the connection, a check gets performed to confirm it's a suitable time to start a renegotiation. if it is, then it gets initiated immediately. OpenSSL will not attempt to resume any session associated with the connection in the new handshake (fresh start energy, main character behavior). note that some servers will respond to renegotiation attempts with a "no_renegotiation" alert — and an OpenSSL will immediately fail the connection in this case. rip 💀

SSL_renegotiate_abbreviated() works in the same way as SSL_renegotiate() from the client side, except that OpenSSL will attempt to resume the session associated with the current connection in the new handshake. so like, same but with the old session lore carried over 🦋

when you're calling 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, 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. if a new handshake does start, it gets handled transparently by calling any OpenSSL IO function. slay, no extra work for you 🌈

and if an OpenSSL client receives a renegotiation request from a server, again this gets 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 is like that sometimes 🙈)

SSL_renegotiate_pending() returns 1 if a renegotiation or renegotiation request has been scheduled but not yet acted on, or 0 otherwise. simple as 🍓

🦋 USAGE WITH QUIC 🦋

SSL_key_update() can also be used to perform a key update when you're on QUIC. the function must be called on a QUIC connection SSL object. this is normally done automatically when needed, so you usually don't have to lift a finger 💅

here's the cute twist: 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 same effect as passing SSL_KEY_UPDATE_REQUESTED. same vibe, 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 a QUIC key update can be performed. SSL_key_update() will fail if these requirements are not met. so like, read the room (and the protocol rules) first 😤

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. iconique but predictable 🎀

💜 RETURN VALUES 💜

  • SSL_key_update(), SSL_renegotiate() and SSL_renegotiate_abbreviated() return 1 on success or 0 on error. that's the whole range, bestie 🔥
  • SSL_get_key_update_type() returns the update type of the pending key update operation, or SSL_KEY_UPDATE_NONE if there isn't one.
  • 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, they're the supporting cast 🫶

👑 HISTORY 👑

the SSL_key_update() and SSL_get_key_update_type() functions were added in OpenSSL 1.1.1. so if you're on something older… yeah. upgrade era 💀

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

ok that's the whole page bestie, you ate 💅✨ this was OpenSSL 3.5.6, dated 2026-04-07, and it's the SSL_KEY_UPDATE(3ossl) page — go update some keys, periodt 🌸🦋💖

📦 where this page comes from