Last Updated: May 15, 2025
Overview
The general end-of-life date for the ability to omit the Server Name Indication (SNI) TLS extension when initiating a TLS request to service endpoints via Auth0 canonical domains was April 29, 2025. The SNI extension was already historically required for requests associated with some public and most private cloud environments. The planned schedule to require SNI in outstanding environments is the following:
- April 29, 2025, at 16:00 UTC - require SNI in outstanding private cloud environments and EU-1, EU-2, and AU-1 public cloud environments.
- (date pending) - require SNI, for a planned maximum period of one hour, in all US public cloud environments (US-1, US-3, US-4, and US-5).
The SNI requirement on EU-1 and EU-2, which was initially enforced, was reverted on April 30, at 08:00 UTC, to mitigate the impact across a small number of tenants.
To move forward with enforcing the SNI requirement while attempting to potentially reduce the level of impact if some systems still actively depend on initiating requests without SNI, we will be performing stages of enforcement where the service will require SNI for a defined time window. At the end of that period, we will restore the previous behavior and repeat this process several times before the definitive requirement of SNI. This article will receive updates as additional information on subsequent stages becomes available.
In tenants located in environments where SNI is required, attempts to initiate a TLS connection that omits the SNI TLS extension to service endpoints associated with a tenant within that environment will result in an error.
The service does not support toggling the SNI requirement on a per-tenant basis; once a given environment requires SNI all Auth0 domains associated with tenants within that environment will experience the same behavior, and it is not possible to opt out individual tenants from the overall requirement.
The most commonly impacted scenarios by the SNI requirement are the following:
- End users using significantly old web browsers to access web applications that redirect to Universal Login for authentication or perform programmatic Authentication API requests from client-side code.
- Server-side applications or systems running on older versions of programming language runtimes that either do not support SNI or do not include it by default.
- Reverse proxies implemented in the context of a self-managed certificate custom domain.
Applies To
- Networking
- Server Name Indication (SNI)
- End of Life (EOL)
Cause
The introduction of the SNI requirement for environments that historically did not require it is a planned breaking change originally announced on October 29, 2024. The information provided as part of the original announcement is available in the respective Dashboard and Support Center notification.
Solution
Any system performing (TLS/HTTPS) requests targeting an Auth0 domain associated with a service endpoint must include the SNI extension when establishing the TLS connection.
Achieving the above may require switching to newer versions of web browsers or programming language runtimes. If the errors arise in requests targeting a self-managed certificate custom domain, the reverse proxy configuration must ensure that the request sent to the origin domain includes SNI. For example, if the reverse proxy uses Fastly, SNI is configured as part of the Fastly host (origin) configuration.