1=pod 2 3=head1 NAME 4 5SSL_key_update, 6SSL_get_key_update_type, 7SSL_renegotiate, 8SSL_renegotiate_abbreviated, 9SSL_renegotiate_pending 10- initiate and obtain information about updating connection keys 11 12=head1 SYNOPSIS 13 14 #include <openssl/ssl.h> 15 16 int SSL_key_update(SSL *s, int updatetype); 17 int SSL_get_key_update_type(const SSL *s); 18 19 int SSL_renegotiate(SSL *s); 20 int SSL_renegotiate_abbreviated(SSL *s); 21 int SSL_renegotiate_pending(const SSL *s); 22 23=head1 DESCRIPTION 24 25SSL_key_update() schedules an update of the keys for the current TLS connection. 26If the B<updatetype> parameter is set to B<SSL_KEY_UPDATE_NOT_REQUESTED> then 27the sending keys for this connection will be updated and the peer will be 28informed of the change. If the B<updatetype> parameter is set to 29B<SSL_KEY_UPDATE_REQUESTED> then the sending keys for this connection will be 30updated and the peer will be informed of the change along with a request for the 31peer to additionally update its sending keys. It is an error if B<updatetype> is 32set to B<SSL_KEY_UPDATE_NONE>. 33 34SSL_key_update() must only be called after the initial handshake has been 35completed and TLSv1.3 or QUIC has been negotiated, at the same time, the 36application needs to ensure that the writing of data has been completed. The key 37update will not take place until the next time an IO operation such as 38SSL_read_ex() or SSL_write_ex() takes place on the connection. Alternatively 39SSL_do_handshake() can be called to force the update to take place immediately. 40 41SSL_get_key_update_type() can be used to determine whether a key update 42operation has been scheduled but not yet performed. The type of the pending key 43update operation will be returned if there is one, or SSL_KEY_UPDATE_NONE 44otherwise. 45 46SSL_renegotiate() and SSL_renegotiate_abbreviated() should only be called for 47connections that have negotiated TLSv1.2 or less. Calling them on any other 48connection will result in an error. 49 50When called from the client side, SSL_renegotiate() schedules a completely new 51handshake over an existing SSL/TLS connection. The next time an IO operation 52such as SSL_read_ex() or SSL_write_ex() takes place on the connection a check 53will be performed to confirm that it is a suitable time to start a 54renegotiation. If so, then it will be initiated immediately. OpenSSL will not 55attempt to resume any session associated with the connection in the new 56handshake. Note that some servers will respond to reneogitation attempts with 57a "no_renegotiation" alert. An OpenSSL will immediately fail the connection in 58this case. 59 60When called from the client side, SSL_renegotiate_abbreviated() works in the 61same was as SSL_renegotiate() except that OpenSSL will attempt to resume the 62session associated with the current connection in the new handshake. 63 64When called from the server side, SSL_renegotiate() and 65SSL_renegotiate_abbreviated() behave identically. They both schedule a request 66for a new handshake to be sent to the client. The next time an IO operation is 67performed then the same checks as on the client side are performed and then, if 68appropriate, the request is sent. The client may or may not respond with a new 69handshake and it may or may not attempt to resume an existing session. If 70a new handshake is started then this will be handled transparently by calling 71any OpenSSL IO function. 72 73If an OpenSSL client receives a renegotiation request from a server then again 74this will be handled transparently through calling any OpenSSL IO function. For 75a TLS connection the client will attempt to resume the current session in the 76new handshake. For historical reasons, DTLS clients will not attempt to resume 77the session in the new handshake. 78 79The SSL_renegotiate_pending() function returns 1 if a renegotiation or 80renegotiation request has been scheduled but not yet acted on, or 0 otherwise. 81 82=head1 USAGE WITH QUIC 83 84SSL_key_update() can also be used to perform a key update when using QUIC. The 85function must be called on a QUIC connection SSL object. This is normally done 86automatically when needed. Since a locally initiated QUIC key update always 87causes a peer to also trigger a key update, passing 88B<SSL_KEY_UPDATE_NOT_REQUESTED> as B<updatetype> has the same effect as passing 89B<SSL_KEY_UPDATE_REQUESTED>. 90 91The QUIC connection must have been fully established before a key update can be 92performed, and other QUIC protocol rules govern how frequently QUIC key update 93can be performed. SSL_key_update() will fail if these requirements are not met. 94 95Because QUIC key updates are always handled immediately, 96SSL_get_key_update_type() always returns SSL_KEY_UPDATE_NONE when called on a 97QUIC connection SSL object. 98 99=head1 RETURN VALUES 100 101SSL_key_update(), SSL_renegotiate() and SSL_renegotiate_abbreviated() return 1 102on success or 0 on error. 103 104SSL_get_key_update_type() returns the update type of the pending key update 105operation or SSL_KEY_UPDATE_NONE if there is none. 106 107SSL_renegotiate_pending() returns 1 if a renegotiation or renegotiation request 108has been scheduled but not yet acted on, or 0 otherwise. 109 110=head1 SEE ALSO 111 112L<ssl(7)>, L<SSL_read_ex(3)>, 113L<SSL_write_ex(3)>, 114L<SSL_do_handshake(3)> 115 116=head1 HISTORY 117 118The SSL_key_update() and SSL_get_key_update_type() functions were added in 119OpenSSL 1.1.1. 120 121=head1 COPYRIGHT 122 123Copyright 2017-2025 The OpenSSL Project Authors. All Rights Reserved. 124 125Licensed under the Apache License 2.0 (the "License"). You may not use 126this file except in compliance with the License. You can obtain a copy 127in the file LICENSE in the source distribution or at 128L<https://www.openssl.org/source/license.html>. 129 130=cut 131