WCF Relay listeners that still negotiate TLS 1.0 can stop passing traffic through Azure Relay. The symptom appears on the sender, which connected successfully before and now fails every call with System.ServiceModel.EndpointNotFoundException: None of the connected listeners accepted the connection within the allowed timeout. If you run a WCF Relay listener on the .NET Framework, and especially one built against an older version of the WindowsAzure.ServiceBus package or Microsoft.ServiceBus.dll, it is worth checking how it negotiates TLS.

Azure Relay Hybrid Connections are not affected and need no action. They use HTTP and WebSockets through the Microsoft.Azure.Relay package, a different stack from the WCF Relay path described here.

What is happening

TLS 1.0 and TLS 1.1 are deprecated. We retired them across Azure services, and have since retired them at the operating system level as well. That operating system change is why a listener that had run until now can fail going forward.

These failures come from a listener that still asks for TLS 1.0, which older .NET Framework defaults, application configuration, registry settings, or startup code can all cause. Relay requires TLS 1.2 or later and rejects the handshake.

Where that rejection lands decides what the sender sees. A listener registers with Relay once, when it opens. Relay then asks that registered listener to open a separate rendezvous connection for each sender that arrives, and each of those is a new connection with its own handshake.

In this case the rendezvous connection is the one that fails. Relay tries each registered listener until it runs out, none of them accepts, and the sender gets None of the connected listeners accepted the connection within the allowed timeout. The same failure can also surface as a timeout, when the sender's timeout elapses before Relay has finished trying the registered listeners.

A listener whose handshake fails when it opens never registers at all. On a persistent relay the sender then gets There are no listeners connected for the endpoint. On a dynamic relay, which is the default for the WCF Relay bindings, the endpoint exists only while a listener is connected, so the sender gets Endpoint does not exist.

All three arrive as EndpointNotFoundException, so the message text is what tells them apart, and all three are what the sender sees when the listener is the side still on TLS 1.0. The side that pins the protocol sees the failure directly instead. The trace below is a sender's, and a listener's differs in its lower frames, so search on the message rather than the frames:

Exception Type: System.IO.IOException
Authentication failed because the remote party has closed the transport stream.

Server stack trace:
at System.Net.Security.SslState.InternalEndProcessAuthentication(LazyAsyncResult lazyResult)
at System.Net.Security.SslState.EndProcessAuthentication(IAsyncResult result)
at Microsoft.ServiceBus.Messaging.IteratorAsyncResult`1.StepCallback(IAsyncResult result)
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at Microsoft.ServiceBus.Common.AsyncResult.End[TAsyncResult](IAsyncResult result)
at Microsoft.ServiceBus.SecureSocketUtil.<>c.<InitiateSecureClientUpgradeIfNeededAsync>b__3_1(IAsyncResult a)
at System.Threading.Tasks.TaskFactory`1.FromAsyncCoreLogic(IAsyncResult iar, Func`2 endFunction, Action`1 endAction, Task`1 promise, Boolean requiresSynchronization)

Relay closes the connection when the handshake offers only TLS 1.0 or 1.1, so it surfaces as a closed stream rather than a protocol mismatch.

A sender that pins the protocol fails on its own connection to Relay, before Relay looks for a listener at all, so this exception is all it gets and none of the three messages appear. Whichever side logs it, the trace points at how that application negotiates TLS.

Recommended actions

Start with whichever application pinned the protocol, which is usually the listener. That change is scoped to the one application and is normally enough to resolve this. Check whether it sets a TLS or SSL version explicitly in code or configuration, and if it does, remove the explicit setting so the operating system chooses the protocol, or set TLS 1.2 or later.

The quickest change is configuration-only. Two AppContext switches in the application configuration file put that application back on a supported protocol, and both go in a single semicolon-delimited value attribute:

<configuration>
  <runtime>
    <AppContextSwitchOverrides value="Switch.System.Net.DontEnableSchUseStrongCrypto=false;Switch.System.Net.DontEnableSystemDefaultTlsVersions=false" />
  </runtime>
</configuration>

Rebuilding against a current .NET Framework resolves it as well. Where startup code is easier to change than configuration, setting ServiceBusEnvironment.SystemConnectivity.Mode to ConnectivityMode.Https and ServicePointManager.SecurityProtocol to SecurityProtocolType.Tls12 moves the connection to HTTPS and TLS 1.2. Applications that target .NET Framework 3.5 and use TCP transport security are pinned to SSL 3.0 and TLS 1.0, so those need to be retargeted.

Where the application cannot be changed, the same behavior can be set for the whole machine through two registry values, SchUseStrongCrypto and SystemDefaultTlsVersions, added as DWORD 1 under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319 and HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319, using v2.0.50727 in place of v4.0.30319 for .NET Framework 3.5. Both values must be created, and they apply to every .NET Framework application on the machine, so treat this as the fallback. The .NET Framework TLS best practices guidance covers both approaches in full.

Once the change is in place, restart the application and confirm that the listener and sender both connect. The call that previously failed should complete as soon as the Relay connection negotiates a supported TLS version.

For more about the service itself, see the Azure Relay overview, the Azure Relay API overview, and the Azure Relay port settings.

Help and support

If you have questions, get answers from community experts in Microsoft Q&A or GitHub. If you have a support plan and you need technical help, create a support request.