We’re using ShinyProxy with Auth0 as an authentication provider. We received an email from Auth0 saying that requests without the TLS SNI (Server Name Identification) extension will soon fail.
We’re struggling with how to verify whether ShinyProxy’s requests to Auth0 use SNI now and how to make sure SNI is used in the future.
Is anyone else in a similar situation? Any ideas of how to verify if SNI is used?
The email we received:
End-of-Life Notice Update: Requests Without SNI will Fail
Why are you receiving this notification?
Your tenant admin account is associated with one or more tenants who may be affected by the ongoing end-of-life for HTTPS requests omitting the TLS SNI extension.
In particular, you are receiving this notification because of the following tenant(s):
ABC123
What is changing?
In October 2024, we announced that the Auth0 service would stop supporting requests omitting the SNI TLS extension in April 2025. The content of the initial announcement is available for reference in the associated support center notification.
As part of our ongoing plans, we will begin phasing out support for the previously deprecated behavior in August 2025. This next step will require Server Name Indication (SNI) in all remaining public cloud environments—including the EU and US—through a staggered brownout approach. During the brownout, 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 brownout schedule is as follows:
US
- August 12, 2025 at 14:00 UTC: Require SNI, for a planned maximum period of 4 hours (4h), in all US public cloud environments (US-1, US-3, US-4, and US-5).
- August 19, 2025 at 14:00 UTC: Require SNI, for a planned maximum period of 8 hours (8h), in all US public cloud environments (US-1, US-3, US-4, and US-5).
- August 26, 2025 at 14:00 UTC: Non-SNI support switched off permanently, in all US public cloud environments (US-1, US-3, US-4, and US-5).
EU
- Dates to be announced later
Please refer to this knowledge article for more information on the rollout.
How are you affected?
According to recent data, the tenants listed above received at least one noncompliant request, omitting the SNI TLS extension, in a 20-day period. Once the environment associated with each tenant requires SNI, such requests will fail with a TLS-related error.
Important to note that these requests without SNI may not originate from your systems or end-users. They may be associated with automated traffic from malicious bots or mostly benign bots like web crawlers.
What action do you need to take?
If you have not done so already, we recommend you review systems that integrate with any tenants listed as potentially impacted.
The following situations would be of particular relevance:
- Applications running on older software runtimes that lack SNI support or require a non-default configuration. For example, older Java or Python runtime versions.
- Traffic that flows through proxies that intercept/terminate TLS connections. For example, you have configured the tenant to have a self-managed certificate custom domain, or even if highly unadvisable, you set up a reverse proxy to act as an unsupported proxy pointing directly to your tenant’s default domain.
If you are unsure whether noncompliant requests originate from your systems, monitoring the upcoming brownouts will be crucial to identify any impacted systems.