none
Strange behavior after sending messages with tls1.2 and tls1.0.

    Question

  • Hi BizTalkers,

    We applied all necessary the steps described at article   social.technet.microsoft.com/wiki/contents/articles/51476.biztalk-configure-tls-1-2-on-biztalk-server.aspx

    to force BizTalk (WCF send port) to use tls1.2 instead of tls1.0. After restarting the machine, everything works fine. Wireshark is showing us that tls1.2 is used sending a message to the external service A. So far so good.

    But after sending a message to another external service B, who is still using tls1.0, BizTalk uses tls1.0 on a subsequent send to external service A. After a host instance restart, BizTalk uses tls1.2 sending a message to external service A.   

    Does anyone face this behavior before? Is there a solution or should we implement the Custom behavior solution (which sounds like a possible workaround in this case).

    Wednesday, May 22, 2019 1:01 PM

Answers

All replies

  • Another possible work around is to put the external service B on another host instance.
    Thursday, May 23, 2019 12:01 AM
  • Hi Colin,

    Could be an alternative workaround but maybe a bit
    dangerous. New services or changes to existing ones could break the solution. Probably
    the custom behavior option is the most solid.


    Thursday, May 23, 2019 2:40 PM
  • Yes, a Custom End Point behaviour to set it works well usually.

    This blog Salesforce disabling TLS 1.0 – How to get it working for API calls via BizTalk altered a OAuth endpoint behaviour to set the TLS version.   I've later took that Salesforce OAuth endpoint behaviour and made just a TLS behaviour out of it and it has been used it for various clients.

    In this thread Could not establish secure channel for SSL/TLS with authority 'tls1test.salesforce.com it was recommended that

    "It is probably best to have one custom behaviour for TLS 1.0 and one for TLS 1.2 so you are explicit and know what you use and it fails when something changes. Make sure to not mix the different WCF behaviours in the same host as ServicePointManager is a global process setting. "

    Although I've not had any issues with different services on the same host instance.

    Friday, May 24, 2019 1:08 AM
  • Hi Colin,

    Thank’s for your reply. The problem was indeed an already installed behaviour (witch we overlooked) that was forcing tls 1.0 on a send. After hitting that service, the host was forced to use tls 1.0 on every subsequent call. So your comment not to mix up different WCF behaviours in the same host as ServicePointManager is a global process setting, makes sense.

    Wednesday, May 29, 2019 8:55 AM