Automatically generated by Pod::Man 5.0102 (Pod::Simple 3.45)
Standard preamble:
========================================================================
..
.... \*(C` and \*(C' are quotes in nroff, nothing in troff, for use with C<>.
. ds C` "" . ds C' "" 'br\} . ds C` . ds C' 'br\}
Escape single quotes in literal strings from groff's Unicode transform.
If the F register is >0, we'll generate index entries on stderr for
titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
entries marked with X<> in POD. Of course, you'll have to process the
output yourself in some meaningful fashion.
Avoid warning from groff about undefined register 'F'.
.. .nr rF 0 . if \nF \{\ . de IX . tm Index:\\$1\t\\n%\t"\\$2" .. . if !\nF==2 \{\ . nr % 0 . nr F 2 . \} . \} .\} .rr rF ========================================================================
Title "SSL_CTX_SET_NUM_TICKETS 3ossl"
way too many mistakes in technical documents.
The default number of tickets is 2. Following a resumption the number of tickets issued will never be more than 1 regardless of the value set via \fBSSL_set_num_tickets() or SSL_CTX_set_num_tickets(). If num_tickets is set to 0 then no tickets will be issued for either a normal connection or a resumption.
Tickets are also issued on receipt of a post-handshake certificate from the client following a request by the server using \fBSSL_verify_client_post_handshake\|(3). These new tickets will be associated with the updated client identity (i.e. including their certificate and verification status). The number of tickets issued will normally be the same as was used for the initial handshake. If the initial handshake was a full handshake then SSL_set_num_tickets() can be called again prior to calling \fBSSL_verify_client_post_handshake() to update the number of tickets that will be sent.
To issue tickets after other events (such as application-layer changes), \fBSSL_new_session_ticket() is used by a server application to request that a new ticket be sent when it is safe to do so. New tickets are only allowed to be sent in this manner after the initial handshake has completed, and only for TLS 1.3 connections. By default, the ticket generation and transmission are delayed until the server is starting a new write operation, so that it is bundled with other application data being written and properly aligned to a record boundary. If the connection was at a record boundary when \fBSSL_new_session_ticket() was called, the ticket can be sent immediately (without waiting for the next application write) by calling \fBSSL_do_handshake(). SSL_new_session_ticket() can be called more than once to request additional tickets be sent; all such requests are queued and written together when it is safe to do so and triggered by SSL_write() or \fBSSL_do_handshake(). Note that a successful return from \fBSSL_new_session_ticket() indicates only that the request to send a ticket was processed, not that the ticket itself was sent. To be notified when the ticket itself is sent, a new-session callback can be registered with \fBSSL_CTX_sess_set_new_cb\|(3) that will be invoked as the ticket or tickets are generated.
\fBSSL_CTX_get_num_tickets() and SSL_get_num_tickets() return the number of tickets set by a previous call to SSL_CTX_set_num_tickets() or \fBSSL_set_num_tickets(), or 2 if no such call has been made.
\fBSSL_CTX_get_num_tickets() and SSL_get_num_tickets() return the number of tickets that have been previously set.
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>.