Change Notice: Mandatory Use of SNI for HTTPS Requests

Knowledge Articles
, ,
1

Overview

Beginning April 7th, 2025, attempts to establish a TLS connection (HTTPS) targeting an endpoint associated with an Auth0 service will always require the Server Name Indication (SNI) TLS extension across all our environments.

  • SNI is an extension to the TLS protocol that allows the client to indicate the hostname to which it intends to connect at the start of the handshake process.

After global enforcement of the SNI requirement, TLS connection (HTTPS) attempts targeting service endpoints for any public cloud or private cloud environments will fail if they do not include the SNI extension.

Applies To

  • TLS Connections
  • HTTPS Requests
  • Server Name Indication (SNI)

Cause

Today, most Auth0 private cloud environments and some Auth0 public cloud environments already enforce the SNI requirement. In particular, our CA-1, JP-1, and UK-1 environments already require SNI.

Making SNI mandatory across all environments is part of Auth0’s ongoing efforts to improve security by reducing configuration variance.

Solution

In general, the following scenarios may experience an impact due to SNI becoming mandatory:

  • End-users with significantly old web browsers like Internet Explorer 6.
  • Applications running on older software runtimes that lack SNI support or require non-default configuration.
    • For example, older Java or Python runtime versions.
  • Traffic that flows through proxies that intercept/terminate TLS connections.
    • Examples include corporate proxies configured for traffic inspection or reverse proxy implementations set up as part of a self-managed certificate custom domain.

What actions are required?

If all of the tenants are located in an environment that already mandates SNI, the existing systems should not experience any change in behavior. SNI requirements should be kept in mind if the integration expands to tenants located in other environments.

It is recommended that system implementations be reviewed, particularly if they include legacy applications running on older Java/Python runtime versions or use a self-managed certificate custom domain.

Frequently Asked Questions:

Q: How to test if a tenant’s environment mandates SNI?

A: Use the openssl tool to quickly check the outcome of trying to establish a TLS connection without including SNI. As mentioned earlier, some public cloud environments already mandate the use of SNI, so the SNI requirement in any of those environments can be validated with this test.

For example, using the openssl client tool, create a request to initiate a TLS connection, without SNI, to an existing tenant in our JP-1 environment by running:

openssl s_client -connect [TENANT_NAME].jp.auth0.com:443 -noservername < /dev/null

Given that the JP-1 environment already mandates the use of SNI, the above will result in an error. When executed in Ubuntu 24.04 (OpenSSL 3.0.13 30 Jan 2024 (Library: OpenSSL 3.0.13 30 Jan 2024)), the command returned:

CONNECTED(00000003)
40C7C35EE57C0000:error:0A000410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:
../ssl/record/rec_layer_s3.c:1599:SSL alert number 40
---
no peer certificate available
---

This will result in a successful connection if the -noservername option is removed, which will result in the tool including SNI by default for this particular version of OpenSSL.

Q: How to confirm if a self-managed certificate custom domain reverse proxy uses SNI?

A: If any of the tenants have a self-managed certificate custom domain and the reverse proxy associated with it is set up to forward all request paths, it is possible to quickly check if the reverse proxy includes SNI in the requests sent to the custom domain origin.

To do this, access the path /cdn-cgi/trace through the custom domain and review the response output.

  • For example, if the custom domain is login.example.com, access the URL (https://login.example.com/cdn-cgi/trace) in a browser and confirm if the response includes a line containing sni=off. If it does, this would indicate that the requests performed by the reverse proxy configured for the custom domain fails to include the SNI extension.
1 Like