Client Auth and SSL with Seeburger AS2 adapter

[bhavesh_kantilal]

Hello All,

We are using the Seeburger AS2 adapter in our landscape and I am in the process of setting the same up and have made quite some progress in all my issues.

and I hope that you will be able to help me out.

1. Server SSL on Receiver AS2 adapter

I am sending a message from XI using the Receiver AS2 adapter to my AS2 test tool using Server SSL.

This is working perfectly fine. In my AS2 adapter I have selected HTTPS as the protocol and the message goes via SSL to the target test tool, is processed and the MDN comes back to XI perfectly.

The issue here is :

Irrespective of what is provided in the Server Certificate ( Keystore) , the message goes to my target test tool. I even left this field blank with no certificate entry and still the SSL connection was established and the message went to the target system.

Is there no validation that XI does here? I am lost what is the use of this entry Server Certificate if XI blindly accepts all SSL connections.

I am using a Decentral Adapter Engine with LoadBalancer.

2. Client Auth on Receiver AS2 Adapter

I tried to perform Client Authentication by proving my Server's private key in the AS2 adapter. The corresponding public key is loaded in my partner's Keystore.

XI error's with the error "SSL handshake failed - Bad Certificate" .

I am not sure why XI is erroring out here and I have a feeling that I have misunderstood the use of the fields in the AS2 adapter,

Server Certificate ( Keystore) and Private Key for Client Authentication.

Has anyone tried this? If further details are needed, I will be able to furnish the same.

Regards,

Bhavesh

[former_member434498]

Hi All,

Thank you for all your inputs.

After weeks of troubleshooting this issue, we have finally solved it.

Apparently the cause of the "SSL Handshake - Bad certificate error" is that the trading partner did not trust our public certificate.

The partner is using Webmethods application and after placing our public certificate on their trustedCA the connection worked fine.

[former_member434498]

Hi All,

Thank you for all your inputs.

After weeks of troubleshooting this issue, we have finally solved it.

Apparently the cause of the "SSL Handshake - Bad certificate error" is that the trading partner did not trust our public certificate.

The partner is using Webmethods application and after placing our public certificate on their trustedCA the connection worked fine.

[former_member434498]

Hi All,

Thank you for all your inputs.

After weeks of troubleshooting this issue, we have finally solved it.

Apparently the cause of the "SSL Handshake - Bad certificate error" is that the trading partner did not trust our public certificate.

The partner is using Webmethods application and after placing our public certificate on their trustedCA the connection worked fine.

[bhavesh_kantilal]

Issue was with the Environment. Had to restart my Keystore service and then things worked like a charm.

[former_member434498]

Hi Bhavesh,

Good day.

We are currently facing the same issue. We have recently renewed our private key certificate and asked our partners to install our new public key as well. The connection is working fine with our partner which use HTTP but we are encountering SSL handshake error - bad certificate with our one and only HTTPS partner.

We have double checked our SAP PI configurations (comm. channels & agreements for this partner) and all seems to be ok. Actually the connection is previously working with our old private key but it doesn't work with the new key.

Can you tell me how are you able to restart your keystore service? Where is this located? - I think this is the only task we haven't done yet.

Thank you,

Carlo

[former_member434498]

Do we still need to restart the keystore service even if the connection is working with our non-HTTPS partners?

[bhavesh_kantilal]

Hello Clemente,

On XI / PI 7.0, go to Visual Admin --> Server --> services --> keystore service will be found here.

On NWA, go to Operations --> Systems --> Start & Stop --> Java Services, search for Key* and you will find the key storage service.

Regards,

Bhavesh

[Former Member]

Hi Bhavesh,

In AS2 you encrypt the message with your partners public certificate and then you sign the message with your private certificate. An extra layer of encryption (SSL) is from my point of view not necessary.

The certificates have to be imported into the certificate store in the Visual Admin. The usage is configured in the sender agreement and/or receiver agreement.

Hope that answers some of your questions.

Regards,

Jens

[bhavesh_kantilal]

Hello Jens,

Thanks for your reply.

1. The Encryption and Signature part of the Interface is working absolutely fine and I use the same concept highlighted by you - The Sender always signs the message with his private key and encrypts with message with the partner's public key in the corresponding agreement.

2. Server SSL is also working perfectly fine, i.e, when XI initiates the connection the SSL connection is established to the partner.

3. Mutual Auth was the issue where I was getting the bad certificate issue.

To investigate further I moved the same setup to my Central Adapter Engine and all the issues I had described above seem to have vanished and things work exactly as I was expecting, ie.

The field : Server Certificate (Keystore) is used to provide the Target System's Server SSL's public Certificate.

The field : Private Key for Client Authentication is used where XI provides its own Server SSL's private key for Mutual / Client Authentication.

The problem seems to be with my Decentral Adapter engine and not my central adapter engine and so I guess,

1. I either have the incorrect certificates on my Decentral Adapter Engine.

2. I also have 2 instances of a Decentral Adapter Engine with a Webdispatcher and so maybe the 2 Visual Admin's of the 2 Decentral AE are inconsistent.

3. Maybe it was just a long day and I did something wrong

Will investigate further for the root cause but I am glad that my concepts remain intact and things do work as I expected them to work.

A blog on all this is on the cards sometime soon.

Cheers,

Bhavesh

[bhavesh_kantilal]

An extra layer of encryption (SSL) is from my point of view not necessary.

Hmm, my client is a supplier here integrating with multiple fortune Customers and so it is Customer request that rules and almost all customer insist on using,

1. Server SSL.

2. Digital Signatures for Signing and Encryption of payload.

3. There are a few customers who also request for mutual auth and so we have to do the same.

I guess it just boils down to the security policies of each individual organization which as you would know in most cases are written in stone!

Regards,

Bhavesh