I managed to find our more information about this issue. First of all,
what needs to be established is that this is a pure client issue, this
is why there are no tracking IDs. The client refuses to complete the
TLS handshake with Service Bus.
This is a known issue this is a known issue with the way how Microsoft
manages certificates and how they are used on non-HTTP(S) transports.
The errors occur when the endpoint that hosts the intermediate
certificates for Microsoft is unavailable or slow or cannot be reached
by the client for any reason. We are investigating a workaround for
injecting the required extra certificate into the TLS handshake for
the SBMP and AMQP transports similar to how this is done by HTTP.SYS,
so that this extra request is not needed.
The immediate workaround available is to enable
ServiceBusEnvironment.SystemConnectivity.Mode = ConnectivityMode.Https
This will force all traffic to use a WebSockets tunnel that is
protected by a prior TLS/HTTPS handshake, and that handshake carries
the required intermediate certificate. The WebSockets handshake does
impose a little extra latency as the connection is established, but
will otherwise be comparable with the regular communication mode. The
messaging protocol used through that tunnel will still be AMQP or
NetMessaging, so you should not be worried to get HTTP characteristics
when choosing this option.
This is the response from Microsoft. I'll apply this and if I don't face any problem at some period time, I will accept this as an answer. Who faces this problem, they can try this also.
Edit:
ConnectivityMode.Https is just in avaliable service bus 3. I have to use servicebus 2 because of issue on Signalr. Therefore I couldn't apply this solution.