l *note
gnutls_handshake::.  To deny a rehandshake request by the server it is
recommended to send a warning alert of type GNUTLS_A_NO_RENEGOTIATION.

Due to limitations of early protocol versions, it is required to check
whether safe renegotiation is in place, i.e., using *note
gnutls_safe_renegotiation_status::, which ensures that the server
remains the same as the initial.

To make re-authentication transparent to the application when requested
by the server, use the ‘GNUTLS_AUTO_REAUTH’ flag on the *note
gnutls_init:: call.  In that case the re-authentication will happen in
the call of *note gnutls_record_recv:: that received the
reauthentication request.

 -- Function: unsigned gnutls_safe_renegotiation_status
          (gnutls_session_t SESSION)
     SESSION: is a ‘gnutls_session_t’ type.

     Can be used to check whether safe renegotiation is being used in
     the current session.

     *Returns:* 0 when safe renegotiation is not used and non (0) when
     safe renegotiation is used.

     *Since:* 2.10.0

6.12.4.2 Server side
....................

A server which wants to instruct the client to re-authenticate, should
call *note gnutls_rehandshake:: and wait for the client to
re-authenticate.  It is recommended to only request re-handshake when
safe renegotiation is enabled for that session (see *note
gnutls_safe_renegotiation_status:: and the discussion in *note Safe
renegotiation::).  A server could also encounter the
GNUTLS_E_REHANDSHAKE error code while receiving data.  That indicates a
client-initiated re-handshake request.  In that case the server could
ignore that request, perform handshake (unsafe when done generally), or
even drop the connection.

 -- Function: int gnutls_rehandshake (gnutls_session_t SESSION)
     SESSION: is a ‘gnutls_session_t’ type.

     This function can only be called in server side, and instructs a
     TLS 1.2 or earlier client to renegotiate parameters (perform a
     handshake), by sending a hello request message.

     If this function succeeds, the calling application should call
     ‘gnutls_record_recv()’ until ‘GNUTLS_E_REHANDSHAKE’ is returned to
     clear any pending data.  If the ‘GNUTLS_E_REHANDSHAKE’ error code
     is not seen, then the handshake request was not followed by the
     peer (the TLS protocol does not require the client to do, and such
     compliance should be handled by the application protocol).

     Once the ‘GNUTLS_E_REHANDSHAKE’ error code is seen, the calling
     application should proceed to calling ‘gnutls_handshake()’ to
     negotiate the new parameters.

     If the client does not wish to renegotiate parameters he may reply
     with an alert message, and in that case the return code seen by
     subsequent ‘gnutls_record_recv()’ will be
     ‘GNUTLS_E_WARNING_ALERT_RECEIVED’ with the specific alert being
     ‘GNUTLS_A_NO_RENEGOTIATION’ .  A client may also choose to ignore
     this request.

     Under TLS 1.3 this function is equivalent to
     ‘gnutls_session_key_update()’ with the ‘GNUTLS_KU_PEER’ flag.  In
     that case subsequent calls to ‘gnutls_record_recv()’ will not
     return ‘GNUTLS_E_REHANDSHAKE’ , and calls to ‘gnutls_handshake()’
     in server side are a no-op.

     This function always fails with ‘GNUTLS_E_INVALID_REQUEST’ when
     called in client side.

     *Returns:* ‘GNUTLS_E_SUCCESS’ on success, otherwise a negative
     error code.