SSL_KEY_UPDATE(3ossl)

πŸ’– NAME πŸ’–

SSL_key_update, SSL_get_key_update_type, SSL_renegotiate, SSL_renegotiate_abbreviated, SSL_renegotiate_pending β€” the little squad of functions that kick off a connection-key glow-up and let you peek at what's queued up πŸŽ€


✨ 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() is the one that schedules an update of the keys for the current TLS connection. She doesn't do it right this second β€” she puts it on the calendar, bestie. πŸ“…

So here's the vibe check on updatetype:

  • If updatetype is set to SSL_KEY_UPDATE_NOT_REQUESTED, then the sending keys for this connection get updated and the peer is told about the change.
  • If updatetype is set to SSL_KEY_UPDATE_REQUESTED, then the sending keys for this connection get updated and the peer is told about the change plus politely asked to update its own sending keys too.
  • Setting updatetype to SSL_KEY_UPDATE_NONE? 🚫 That's an error. Not the move.
Big rule alert πŸ”₯ 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 make sure the writing of data has been completed. Yes, all of that at once. She's high maintenance but she's worth it πŸ’…

The key update won't actually take place until the next time an IO operation β€” like SSL_read_ex() or SSL_write_ex() β€” happens on the connection. Or, if you're impatient (same), you can call SSL_do_handshake() to force the update to take place immediately. ⚑

SSL_get_key_update_type() is the nosy bestie who tells you whether a key update operation has been scheduled but not yet performed. It returns the type of the pending key update operation if there is one, or SSL_KEY_UPDATE_NONE otherwise. Simple as. ✨


SSL_renegotiate() and SSL_renegotiate_abbreviated() β€” okay so these two are ONLY for connections that have negotiated TLSv1.2 or less. Calling them on any other connection will result in an error. They do not play about that boundary. πŸ›‘

Client side tea β˜•:

  • 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() takes place on the connection, a check is performed to confirm it's a suitable time to start a renegotiation. If it is, then it's initiated immediately. OpenSSL will not attempt to resume any session associated with the connection in the new handshake. Also, heads up: some servers will respond to renegotiation attempts with a "no_renegotiation" alert. And an OpenSSL will immediately fail the connection in that case. πŸ’€
  • SSL_renegotiate_abbreviated() works in the same way as SSL_renegotiate(), except that OpenSSL will attempt to resume the session associated with the current connection in the new handshake. πŸ¦‹

Server side tea β˜•:

  • 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, 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 is started, then it will be handled transparently by calling any OpenSSL IO function. 🫢

And if an OpenSSL client receives a renegotiation request from a server? Again, this is 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 really said "not today" on that one. πŸ™ˆ

SSL_renegotiate_pending() returns 1 if a renegotiation or renegotiation request has been scheduled but not yet acted on, or 0 otherwise. Iconic little yes/no machine. πŸ‘‘


🌈 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. And 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 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 a QUIC key update can be performed. SSL_key_update() will fail if these requirements are not met. 🚨

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. It literally cannot be anything else. periodt. πŸ’…


⭐ 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)


πŸ’œ HISTORY πŸ’œ

The SSL_key_update() and SSL_get_key_update_type() functions were added in OpenSSL 1.1.1. Baby girl has been around. πŸ‘‘


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


okay that's the whole page, bestie, you ate that 🫢 this was the SSL_KEY_UPDATE(3ossl) page from OpenSSL 3.5.9, dated 2026-09-29 β€” mwah, go update your keys responsibly πŸ’–βœ¨

πŸ“¦ where this page comes from