问题
I am facing a weird situation in communication with RabbitMQ from a client, the following are the details RabbitMQ running on Azure AKS cluster (Containerized), exposed over the internet, Traffic is routed to RabbitMQ using Azure Traffic Manager (Custom Domain), RabbitMQ is configured to support SSL - and Peer Verification is set to true, Internal (Organization) server certificate is configured to the RabbitMQ config file.
RabbitMQ Version 3.7.8
The client is deployed on BizTalk - Azure Virtual Machine, Custom adapter is build using .net to support the connection configuration on BizTalk server, the client certificate is installed on the server, and SSL configuration is done using client cert thumbprint. When BizTalk client (Written on .net) is tried to establish a connection with Rabbit Host, the server refused to connect stating Connection is forcefully closed by the server, we don't see much information in the Debug logs.
We even tried capturing TCPDUMP but not much help out of that since Rabbit is running on container. However, there is a catch, to find out what is happening around the client and Rabbit server, I built a small RabbitMQ client tool to verify the SSL connection, written on .net, and its works as a charm.
I need your help to find out the possible cause for the failure from the Client running on the BizTalk server.
Please note Non-SSL connection works perfectly fine.
回答1:
Go through the TLS troubleshoting guide (link) which will help you find the problem. As suggest in previous answer, it could be that rabbitmq is only supporting TLS 1.2 which is not enabled in .NET.
Also you can enable TLS 1.1 in rabbitmq (link) if you see it is not enabled in rabbitmq which has high probability.
回答2:
With earlier version of .Net it doesn't default to using TLS 1.2 unless you make some registry entries or you explicitly tell it to use TSL 1.2 in code, see MS16-065: Description of the TLS/SSL protocol information disclosure vulnerability (CVE-2016-0149): May 10, 2016
The .NET Framework 4.0 and the .NET Framework 4.5.x applications that are running on the .NET Framework 4.5 and later versions can switch the default protocol to TLS 1.2, TLS 1.1, and TLS 1.0 by enabling the SchUseStrongCrypto registry key. This registry key is discussed in the Suggested Actions section of the Microsoft Security Advisory 2960358 topic on the Microsoft TechNet website.
The other option is to do it via code either in a Pipeline Component or End Point Behaviour. See Encoding issue when passing URL Parameters with BizTalk WCF-WebHttp Send Port
来源：https://stackoverflow.com/questions/62458270/client-communication-to-rabbitmq-fails-using-ssl-peer-verification