grpc_ssl_server_name

Enables the use of the server name in gRPC SSL handshake to match against the Server Name Indication (SNI).

Syntaxgrpc_ssl_server_name on | off;
Defaultoff
Contexthttp, server, location
Argumentsflag

Description

The grpc_ssl_server_name directive is used in NGINX configurations to enable the inclusion of the server name in the SSL handshake for gRPC connections. This allows NGINX to fulfill the Server Name Indication (SNI) requirement of the client, which aids in correctly routing the connection to the appropriate backend server based on the hostname specified. When this directive is enabled, the server can serve multiple SSL sites on the same IP address, each differentiated by their respective domain names.

The directive can be specified in various contexts including http, server, and location, providing flexibility in its application throughout the configuration file. By setting this directive to 'on', the NGINX server will utilize the server name included in the gRPC request for its SSL configuration, thereby allowing it to correctly select the appropriate set of SSL certificates that match the domain name. It is particularly useful in environments where multiple gRPC services are hosted on the same server.

It is important to note that having grpc_ssl_server_name enabled may require careful management of your SSL certificates to ensure they are configured correctly for SNI. If multiple domains are in use, ensure that they are properly secured with valid SSL certificates for reliable communication. This feature emphasizes interoperability with gRPC clients that expect SNI support to function effectively.

Config Example

server {
    listen 443 ssl;
    grpc_ssl_server_name on;
    ssl_certificate /path/to/certificate.pem;
    ssl_certificate_key /path/to/key.pem;
}

Ensure that the correct SSL certificates are installed and configured for each server name to avoid handshake failures.

If using a Load Balancer in front of NGINX, verify that it supports SNI and forwards the server name correctly.

This directive is not supported in pure HTTP contexts, only in https-enabled configurations.

← Back to all directives