“Remote server returned error: (400) Bad request” occurs when using Microsoft® BizTalk 2013 Accelerator for RosettaNet to communicate with partner via SSL in BizTalk Server 2013

  • Article

“Remote server returned error: (400) Bad request” occurs when using Microsoft® BizTalk 2013 Accelerator for RosettaNet to communicate with partner via SSL in BizTalk Server 2013

 

Recently one of my customer complained that they could not send messages to their partner when using Microsoft® BizTalk 2013 Accelerator for RosettaNet while they were able to do it via Microsoft® BizTalk Accelerator for RosettaNet 3.0 in BizTalk Server 2004. Nothing seemed to be changed as they simply copied settings from BizTalk Server 2004 to the new version, and they used the same certificate for SSL on both environment. However, we got the “Remote server returned error: (400) Bad request” on BizTalk Server 2013 while it was working on BizTalk Server 2004.

 

Via network trace, we managed to see when server side returned Cipher Change Spec and Encrypted Handshake Message, client side (BizTalk Server 2013) finished the connection.

 

But what could cause the abrupt disconnection? Obviously checking certificate was the first priority as the failure was on SSL part. We then reviewed the relevant certificate for HTTPS communication, and surprisingly found the certificate was a self-signed one which was provided by their partner while self-signed certificate is usually not recommended in PROD environment. As no more clue could be found through network trace, we captured some diagnostic data to move forward.

 

Further investigation indicated that there was indeed something to do with the self-signed certificate as the diagnostic trace displayed the remote certificate was invalid. We reviewed the source code of Microsoft.Solutions.BTARN.RNIFSend.RNIFSend, to see under what conditions the certificate invalidation information could be reported when sending messages. It will fail under either of below two conditions:

 

  1. The certificate is not correctly installed in Local machine\Trust Root Certification Authorities store.
  2. The certificate is a self-signed one.

However, when we compared the relevant logic in Microsoft® BizTalk Accelerator for RosettaNet 3.0 with the logic in Microsoft® BizTalk 2013 Accelerator for RosettaNet, the former didn’t contain self-signed certificate verification procedure. This explained why the same settings worked well in BizTalk Server 2004 while failed in BizTalk Server 2013.

 

Once we ensure none of above conditions were met in BizTalk Server 2013, messages could be sent out to partner successfully.

 

Thanks & Regards,

Rachel Huang