Server Name Indication
The Server Name Indication (SNI) application definition field is used to tell System TLS to provide limited SNI support for this application.
SNI, as defined by RFC 6066, allows TLS clients to provide to the TLS server the name of the server they are contacting. This function is used to facilitate secure connections to servers that host multiple 'virtual' servers at a single underlying network address. To use SNI in this way, as either the client or the server, gsk_attribute_set_buffer() must be used to configure SNI in the application.
If limited SNI support is needed, enter the fully qualified domain name (FQDN) for the server application. If not required, accept the default value of *NONE for the limited SNI support which does not override existing SNI application configuration.
If the application configures SNI information with gsk_attribute_set_buffer(), then the value that is set for this application definition field is appended to the end of that existing information. If the existing information is configured to be critical, then this value would also be critical. Critical means that if the client FQDN does not match a name in the server list, then the server generates a failure for the session negotiation. If no existing information exists, then the limited SNI support is not critical.
A use case for setting the limited support SNI field: Your Company is contacted by a user of your services. The user has a new security requirement that all TLS servers they communicate with provide the server SNI acknowledgement. Your server is a simple server that is used for just one service with no need for virtual server configuration.
By setting the FQDN of the server, System TLS can send the SNI server acknowledgement if asked. The server certificate that is sent is the one assigned to the application definition. Nothing is changed from the server perspective, yet the peer client satisfied their requirement.
If the client requested FQDN does not match (because this field was not set or had a different value), no server SNI acknowledgment is sent. The server continues with handshake negotiation as if no SNI request was made. The client determines whether this condition is a critical error for the session negotiation.