TLS/SSL Certificates Connected Without a Specified SNI

TLS/SSL Certificate connections without a Server Name Indication (SNI) are rejected since the TLS handshake failed and it resulted in an untrustworthy connection. Learn how TLS/SSL Certificates data is observed.

To prevent having to use untrustworthy certificates in a situation where a client connects without specifying an SNI, please consider the following options:

• Recommended. Configure services in a way that aborts the TLS handshake before presenting a certificate. This is what Cloudflare currently does on its systems (e.g., connecting to a Cloudflare IP address without specifying a SNI results in a TLS Error 40 - No certificates are presented).

  This option may not be easily implemented in some software applications.

• If there is a business requirement to allow non-SNI TLS connections, ensure the network service displays a valid signed TLS certificate. Since the connection is being made directly to an IP address (without an SNI specified), this would have to be a certificate that contains the IP address in its Subject Alternative Name (SAN). Since issuing certificates for IP addresses is an uncommon practice, there’s no penalty for an organization that shows a valid and trustworthy certificate, even if its Common Name or Subject Alternative Names do not contain its IP address.
• If you are an application owner, ensure all TLS certificates are trustworthy.
• Present a valid and trusted certificate as an alternative.

Refer to the following resources for how to specify a default certificate for TLS connections that do not specify an SNI:

• Kubernetes Ingress
• Traefik Proxy