none
BizTalk 2009 + Windows 2008 R2 + HTTPS to Apache (AS2) RRS feed

  • Question

  • Scenario:

    We are trying to send an AS2 payload to our trading partner over HTTPS.  Normally, we rely on AS2’s built-in security but this particular partner requires us to use HTTPS as well.

    Problem:

    When we attempt to send a message it fails immediately with a message in the event log indicating: “The underlying connection was closed: An unexpected error occurred on a send.”  We had tested HTTPS communication between two BizTalk instances and it worked fine but the client is not using BizTalk.  In fact, their solution has some involvement with Apache as the web server.

    Tried so far:

    In what information we could find searching around it seems that Apache may not support TLS and BizTalk’s HTTP adapter is going to attempt to use TLS … something goes wrong and the connection fails.  The solution seems to be to disable BizTalk from using TLS and instead use SSL3.0.

    We followed this article (http://www.codeproject.com/KB/security/HTTPBizTalk2009Win2008R2.aspx) and this KB article (http://support.microsoft.com/default.aspx?scid=kb;EN-US;187498) and tried to disable TLS1.0 as a client but it did not seem to change the outcome.

    Then, we ran into this article (http://blogs.msdn.com/b/amol/archive/2010/04/27/how-to-disable-ssl-2-0-in-internet-information-services-7.aspx) but have not yet ventured into it as we don’t want to mess things up too far before we checked here.

    Questions:

    1.       The partner makes no mention of requiring us to send a client certificate.  We tried putting a thumbprint in for our certificate but once again no change.  Is this required to do HTTPs with BizTalk?

    2.       Has anyone else run into HTTPS issues with BTS2009 and Win 2k8 R2?

    3.       Any ideas on how to further diagnose?

     

    Configuration:

    1.       Us

    a.       BizTalk 2009

    b.      Windows 2008 R2

    2.       Them

    a.       Some apache-server based solution

    b.      May have something to do with webMethods but we have not been able to get the full details from them (yet)

    Messaging pattern/party configuration:

    1.       EDI file comes in on a FILE receive location

    2.       We have a Send port with a filter mapping to this receiving location

    a.       Adapter is HTTP

                                                                   i.      Chunked encoding is disabled

                                                                 ii.      URL is set to their https://... Endpoint

    b.      Send handler is a 32-bit host

    c.       Send pipeline is AS2Send

    d.      Encryption certificate is set to the partner’s public key

    3.       Party config:

    a.       Send port is mapped to the party

    b.      Pretty much the defaults for the AS2 party configuration …

    c.       We are requesting an async MDN, signing and encrypting the outbound message, etc.

    Friday, October 1, 2010 8:07 PM

Answers

  • Ok.  Finally decided to give Wfetch a go to test out the HTTPs communications.  First of all, what a great and useful tool!  When I ran through a series of tests checking each security protocol (SSL, TLS, etc.) it was clear that the target server did NOT support TLS 3.1.  So I tested using SSL3 and got back an error stating that the server did not receive a client certificate.

    BINGO!  Clearly we needed to send over a client certificate so I tested once again with a client certificate and got a successful communication going in wfetch.

    Now, I went back into my BizTalk send port, configured the HTTP adapter and added in our private certificate's thumprint on the authentication tab and we finally were able to send in a message without a protocol error.

    To be clear, I did NOT need to make any of the above registry or policy changes as the servers were able to successfully renego the protocol.

    • Marked as answer by JAgostoni Thursday, October 7, 2010 3:15 PM
    Thursday, October 7, 2010 3:15 PM

All replies

  • From what you have mentioned, it sounds like something fundamental is wrong with the connection, probably due to security. Are you calling an HTTPS address like with a form or is it a web service you are calling?

    Do you know if their HTTP endpoint accepts the AS2 headers or if it is actually just an HTTP endpoint? Using AS2Send will put the AS2-To and As2-From headers on the request. This might be breaking the integration on their side if they cannot understand these headers.

    If they have not mentioned client certificates I would not expect this. This is more of a Windows centric security mechanism in my experience.

    I would ask them to tell you what configuration they have tested. You might even ask them to use Fiddler to record a sample request with their test client. This will tell you exactly what they are expecting and you can see the HTTP headers. They may also be requiring some custom HTTP header for authentication purposes.

    Thanks,


    If this answers your question, please use the "Answer" button to say so | Ben Cline
    Tuesday, October 5, 2010 6:33 PM
    Moderator
  • Thanks for the reply.  The certainly should accept the AS2 headers as that is the communication pattern we are setting up.  The partner specializes in handling things like AS2, etc. for other companies (like a modern-day VAN) and they have mentioned working with BizTalk in the past.  The mentioned a specific security patch that had caused issues in the past but that was for on older OS (Windows 2k3 I think).

    The endpoint we are calling would be your typically AS2 communication so it is not a SOAP web service but just POSTs and GETs.

    I think we are at the point where you mention: They need to monitor the HTTP communication on their side while we do the same on our side.

    I'll post back with any updates.

    Thursday, October 7, 2010 12:43 PM
  • Ok.  Finally decided to give Wfetch a go to test out the HTTPs communications.  First of all, what a great and useful tool!  When I ran through a series of tests checking each security protocol (SSL, TLS, etc.) it was clear that the target server did NOT support TLS 3.1.  So I tested using SSL3 and got back an error stating that the server did not receive a client certificate.

    BINGO!  Clearly we needed to send over a client certificate so I tested once again with a client certificate and got a successful communication going in wfetch.

    Now, I went back into my BizTalk send port, configured the HTTP adapter and added in our private certificate's thumprint on the authentication tab and we finally were able to send in a message without a protocol error.

    To be clear, I did NOT need to make any of the above registry or policy changes as the servers were able to successfully renego the protocol.

    • Marked as answer by JAgostoni Thursday, October 7, 2010 3:15 PM
    Thursday, October 7, 2010 3:15 PM