Menu

New connection to IBM Sterling, SSL common name mismatch and Authentication

Help
jll
2019-07-10
2019-07-29
  • jll

    jll - 2019-07-10

    Hi, I'm trying to configuring my second production connection with a partner who has their AS2 managed by IBM Sterling.

    Because it was Sterling, and due to the suggestion in the docs:

    http://openas2.sourceforge.net/#a_13_4__CMS_Algorithm_Protection

    I did set the

    <attribute name="remove_cms_algorithm_protection_attrib" value="true"/>

    attribute in the me-to-the-partner partnership tag.

    I'm seeing a couple of problems right off the bat.

    a) I can't use the provided partner URL because the SSL certificate in use there only has a long complicated cloud/VM-looking hostname that does not match the URL given by the partner (e.g., if I go to this URL in my browser, I get the big fat SSL warning telling you the hostname does not match the names provided in the SSL). Has anyone else dealt with this? I didn't see any settings in the manual that seemed to allow a per-partner override of this.

    I've already contacted the partner asking him about this to see why they have it configured that way, since it makes SSL somewhat less secure to have to either manually accept that certificate or just completely turn off regular SSL validation for that partner (I certainly wouldn't want to do it for my whole OpenAS2 server).

    b) When I do the next best thing, which is to try to use the actual hostname that is in the SSL cert, and connect with that (it does map to the same IP), I get this message:

    2019-07-10 10:31:19.600 ERROR AS2SenderModule: Error sending message. URL: https://na1p40.[partner name obfuscated].com/as2 ::: Response Code: 400 Bad Request ::: Response Message ...

    c) A third possible issue (though I don't think it's related to the above Response Code 400) is that the partner indicated he configured a UserID and password for the connection, but I don't see how to provide that in any OpenAS2 documentaiton, unless I just tack it on the front of the URL like:

    https://userid:password@partnerurl.com/as2

    would that be the way to handle this? Again, has anyone else had to deal with this connection based login/password auth configuration?

    In initial setup with the partner, I indicated wanting an SSL connection, but no further use of certificates (for encryption or signing of the files, e.g.).

    Thanks for any suggestions or insight anyone might be able to offer.

     
  • Christopher Broderick

    Somefeedback:
    1. There is nothing you can do here... sounds like they generated an X.509 certificate for use within AS2 and then used it for SSL - my guess is that your partner is completely confused by the difference between SSL certificates for HTTPS and X.509 certificates for Encryption and Signing within the AS2 sphere. If they want the security proided by HTTPS then you are correct, they must generate a valid certificate
    2. Could be any number of reasons for this including that you are actually hitting a proxy server that uses host name to gelgate to a backend server
    3. If you are talking about HTTP authentication the see this section in the documentation:

    7.10.  HTTP Authentication
    For partners that require HTTP authentication when connecting to their system use the following parameters in the partnership:
        • http_user – the name of the HTTP user for authentication
        • http_password – the name of the HTTP password for authentication
    For sending files this is in the partnership where the partner is the receiver.
    For asynchronous MDN the paramters must be in the partnership where the partner is the sender.
    eg.
    <attribute name="http_user" value="myhttpuser"/>
            <attribute name="http_password" value="some_secret"/>
    
     
  • jll

    jll - 2019-07-10

    Christopher, thanks for the reply.

    I had missed the documentation about http_user and _password since I was just looking at the web documentation:

    http://openas2.sourceforge.net/

    and forgot about the PDF included in the installation zip. I see those definitions there and that looks good, hopefully those will work for what the partner has configured for auth.

    As far as thinking that the partner is using a cert that should be used for encryption and signing for his SSL server, I somewhat doubt that's what's going on since this is IBM I'm dealing with and I'm sure they have thousands of AS2 partners. And it looks to me like a normal official CA-issued (this one by DigiCert SHA2 Secure Server CA) SSL cert. The problem seems to be that they're probably trying to use the same cert for multiple virtual hostnames hosted at the same cloud server (maybe?) but they only list one hostname as the subject name in the cert.

    I guess it's possible this isolated situation I'm dealing with is misconfigured, but I'll have to see when I get some feedback from the partner (I have asked about why the given hostname does not appear in the list of subject alt names in the SSL cert).

     
  • jll

    jll - 2019-07-11

    The partner got back to me today and gave me a new URL for test work that now is the messy cloud-vm-looking name that does actually show up in the SSL, so I'm working with that and now am getting a more promising looking "401 unauthorized", so that's better.

    One thing the partner pointed out was that the IBM Sterling B2B AS2 Edition software he's using required either encryption/signing of messages or userid/password for authentication.

    We covered how to do userid/password with the above settings for outbound connections.

    Is it possible to also define a userid/password for inbound connections, assuming the partner has the same requirement on his outbound connections?

     

    Last edit: jll 2019-07-11
  • Christopher Broderick

    User/pwd authentication is not part of AS2 and adds nothing to the security of the transferred message.
    Currently OpenAS2 does not support HTTP authentication for inbound connections. You could set up a proxy server in front of OpenAS2 (eg Nginx) to implement HTTP authentication for inbound.

    It is not advisable to to use AS2 without encryption and signing - that is what provides the security both for in transit data and for non-repudiation.

     
  • jll

    jll - 2019-07-11

    My main reason for not wanting to deal with message encryption/signing is to avoid unnecessary long term hassles with certification expiration and maintenance (like I have to do with my OFTP2 partners in Mendelson).

    Since the only certificates involved in my scenario should be official CA-issued certificates, each partner could in theory renew and replace their certificate without the other partner noticing anything's changed.

    You're still of course getting perfectly good transmission security, I guess there is just the additional need for some sort of authentication if for no other reason than to prevent bad actors from sending bad messages into your system (for which they may only need to know a valid AS2 ID or pair of IDs).

    Thanks for the reply, and I'll see if the partner will send to me with no additional auth. If he needs something, I guess I'll try encryption.

     
  • jll

    jll - 2019-07-23

    Still working with this partner trying to get the connection going and we're still majorly hung up on me being able to authenticate to his server sending from me to him.

    He's already been able to send to my OpenAS2 (with no authentication, just secure over the SSL connection) with no problems.

    At first I was just seeing '401 Unauthorized' errors in my logging.

    This has now happened with just plain login/password authentication (for which I've tried to use the http_user and http_password attributes), and now we've even tried adding encryption and signing as an additional form of authentication (though he seems to've left the login/password auth on there as well) and I get the same above errors.

    When I did a

    log setlevel debug

    I get a bit more detail, but the only part that seems helpful to me is this:

    2019-07-23 12:50:17.709 FINER org.apache.http.impl.auth.HttpAuthenticator: Authentication required
    2019-07-23 12:50:17.710 FINER org.apache.http.impl.auth.HttpAuthenticator: OBFUSCATED.ibmcloud.com:443 requested authentication
    2019-07-23 12:50:17.710 FINER org.apache.http.impl.auth.HttpAuthenticator: Response contains no authentication challenges

    does that give us any more detail to suggest what might be going on? The partner at IBM is saying he's not seeing my authentication attempts in logs over there (which makes me think he's not drilling down to enough of a low level detail).

    One thing I'm not seeing in these logs is any indication that my supplied http_user and http_password values are being sent/used. Any idea why that might be?

     
  • Christopher Broderick

    Suggest you use TRACE level ... should give a LOT more information about what is going on.

     
  • jll

    jll - 2019-07-29

    Just to update the record, I have now succeeded in sending a test file to this partner now, but only after we:

    a) started using signing/encryption (this partner also required only a 2048 bit key, not the 4096 that I first generated, which seems to be OpenAS2 default)

    b) he re-defined the whole partnership in his software after running into some trouble reconfiguring the existing partnership (to add signing/encryption; it seemed like his software would not let him remove the userid/password auth once it had already been added).

    This leads me to believe that OpenAS2 either doesn't interoperate properly with the userid/password authentication in this IBM Sterling AS2 product (I did not get precise version details from the partner) or there was something more mundane going on like a typo in a userid/password or somet other minor setting that was causing the simple auth to not work.

    Thanks for your help, Christopher.

     
  • Christopher Broderick

    For clarity, authentication using UserId and Password is not part of the AS2 specification.
    Thje option provided in OpenAS2 is to support HTTP authentication (aka Basic Auth) and is part of the HTTP spec (https://tools.ietf.org/html/rfc2617) not the AS2 spec (https://tools.ietf.org/html/rfc4130). To understand exactly what did not work will require understanding what kind of authentication your partner was using.

     
  • jll

    jll - 2019-07-29

    Right, I remember you mentioning something to that effect when I first brought it up. Since I've already had a lot of back and forth with this partner, I'm going to let it go with him. If this option comes up with a future partner, I may pursue it more.

    This partner did not give me a specific indication of exactly what type of authentication IBM's software was using for the userid/password option.

     

Log in to post a comment.