Avi Load Balancer uses the concept of parent and child virtual services for SNI virtual hosting. When the option for virtual hosting virtual service is selected on the create (through advanced mode) or edit action, the virtual service participates in the virtual hosting. The virtual hosting virtual service must be configured as either a parent or a child virtual service.
Parent Virtual Service
The parent virtual service governs the networking properties used to negotiate TCP and SSL with the client. It can also be a catch-all, if the domain name requested by the client does not exist or does not match with one of the configured child virtual services.
Configure the following properties on the parent virtual service:
- Network
-
The listener IP address, service port, network profile, and SSL profile. No networking properties are configured on the child virtual services.
- Pool
-
Optionally specify a pool for the parent virtual service. The pool will only be used if no child virtual service matches a client’s requested domain name.
- SSL Certificate
-
An SSL certificate may be configured which could either be a wildcard certificate or a specific domain name. The parent’s SSL certificate is used if the client does not send an SNI hostname TLS extension or if the TLS SNI hostname of the client does not match any of the child virtual service's domain names. If an SSL certificate with specific domain name is returned to the client, for example, in the case of sending a friendly error message, the client will receive an SSL name mismatch message. So, it is advisable to use a wildcard on the parent.
The parent virtual service receives all new client TCP connection handshakes, which are reflected in the statistics. Once a child virtual service is selected, the connection is internally handed off to a child virtual service. So subsequent metrics such as packets, concurrent connections, throughput, requests, logs and other statistics will only be recorded on the child virtual service. Similarly, the child virtual service will not have logs for the initial TCP or SSL handshakes, such as the SSL version mismatch errors, which are recorded at the parent virtual service.
The parent delegates to the child during the SNI phase of the TLS handshake.
If there is an SNI message received from the client and the SNI hostname matches the configured hostnames for any of the child virtual services, the connection switches to the child virtual service at that point. Also, all the SSL, for instance, certificate and L7 state, for instance, policies, DataScripts, and so on, of the child virtual service is applied to the HTTP request. The log ends up on the child virtual service.
If the switch to the child virtual service did not happen, the connection/ request is handled on the parent virtual service. So the SSL and L7 state of the parent get applied. The default certificate on the parent is presented to the client. Once the request is received and parsed, you can close the client-side TCP connection through no pool, pool with close action, or security policy. If you have a wildcard certificate on the parent that covers all the subdomains of the child virtual services, you can serve that from the parent and then close the connection as mentioned above.
Selection of a child virtual service is solely based on the FQDNs (Fully Qualified Domain Name) configured on the SNI child. Ensure that there are no duplicates or overlaps among the child FQDNs. Common Name or Subject Alternate Name in the virtual service certificate has no role to play in the selection of children for SNI traffic.
The vh_domain_name of the SNI child virtual service has to be explicitly added to the parent virtual service VIP’s list for DNS records to be populated correctly.
Once a child is selected (using server name TLS extension of client hello), its certificate is served on the connection and host header of further HTTP requests must match the FQDNs of one of the children, failing which, the connection would fail with virtual host error on the applog.
If connection fails to select a child, it will be served by the parent virtual service.
Child Virtual Service
The child virtual service does not have an IP address or service port. It instead points to a parent virtual service, which must be created first. The domain name field is a fully qualified name requested by the SNI-enabled client within the SSL handshake. The parent matches the client request with the child’s configured domain name. It does not match against the configured SSL certificate. The child can use a wildcard or domain specific certificate.
If no child matches the client request, the parent’s SSL certificate and pool are used. In cases where you have a TLS SNI parent with a TLS/SSL profile that supports TLS versions 1, 1.1, and 1.2, and a TLS child which has only TLS 1.2 configured, the child will continue to use TLS 1.2.
In such a setup where the parent and child virtual services use different SSL profiles, the flow for SSL handshake is as follows:
TCP handshake -> Parent virtual service
Client Hello -> Parent virtual service. The client Hello contains the SNI. So the Avi Load Balancer selects the child virtual service.
SSL profile of the child is used. Child virtual service SSL profile is used to allow or deny based on the SSL/ TLS version and select a cipher.
Child virtual service responds with a server Hello that includes the cipher and the child certificate.
Logs
The application logs option on the user interface displays SNI hostname information along with other SSL related information. The SNI information in the application logs provide more insight about the incoming requests and also help in troubleshooting various issues. When the child virtual service sees an SSL connection with SNI header, the hostname in the SNI header is recorded in the application log along with the SSL version, PFS, and cipher related information. To check for SNI-enabled virtual service related logs, navigate to , select the desired virtual service, and navigate to Logs.
When the Host header of a client request does not match the FQDN configured on the child virtual service, the request would fail with an application log on the child instead of being proxied using parent virtual service’s default Pool.
