Error while SSL handshake with EDIINT


Can any one of you tell me what is the exact meaning of the error
“Deliver failed: iaik.Security.ssl,SSLException:Server certificate rejected by chain verifier”?

Would also like to explain my scenario in which I got this error. We are exchaging EDIINT data with an external gateway. They are sending Signed and Encrypted EDIINT data to us, for which we deliver MDN signal back to them.

Initially it was failing with the above errror while processing EDIINT data (Received from gateway)iteself and showing as “Authentication failed”. (Both errors I can see)

When verified, I found that the certificate which are defined for partner (Gateway) profile in TN are not of client, its our certificate. Then I changed them to Partner certs and tested again. Not it authenticated successfully and processed EDIINT and prepared MDN.

But now while sending this MDN it is again failing with same error “Rejected by chain verifier”.

Can I assume that the same mapping(wrong cert map, we corrected above) at gateway end might be causing this issue or it is failing at my end itself?

Appreciate your quick reply.


Please verify you are using the most updated certificates of partner and partner has installed your certificates properly as well.

I believe you are using EDIINT AS2 for sending and receiving the file. Now you have configured partner’s certificate at your end for Authenticating them but when you send the MDN back to partner then you are connecting to them and if you have to send the MDN back to partner using https url then you have to copy the customer server’s certificate (public key) entire chain to you server CA cert location. As IS do the server verification before delivering the data. The error which you are getting is purely because IS is not able to find correct certificate to authenticate the destination server.

Hi Vikas,

Yes, we do use EDIINT As2 protocal. Just now I verified my IS folders and found that my partner CA and root certificate are properly placed on IS CA folder with .der extension. But in the IS Certs folder I could see the mail digital certificate as .cer extension. Is this causing the issue?

If we change it now to .der extn, then we need to restart the server again?


Hi Vikas, I even changed partner certificate to .der extention and tried again. But still, I faced the same error.

“Unable to send MDN” in activity log and error as
Delivery Failed: Server certificate rejected by ChainVerifier"

We are using immediate delivery service, to send MDN to partner. I did debug on this service till “http” service. EVrything is coming in pipeline (https url, mimeheaders etc.) and after executing this http service, it threw the above error.

We also notified the partner on this to check if they received any request from my server, waiting for reply, but before that I want to be clear at my end without any issue.

Appreciate your help.


Please check the below mentioned steps.

  1. CA and Root means same. First you need to ask your partner to provide their server certificate with complete chain. Do not think whatever certificate you have configured for SSL handshake is going to be same when you are connecting to them. There server certificate may be different. Check with them explicitly.
  2. IS does not support .cer extension. It only supports .der as per my knowledge.
  3. No need to wait for customer’s reply. I am sure they would have not received the MDN from your server as while connecting to them you received the SSL handshake error. Only at their server log they would have seen hit from your server.

Hi Vikas,

Thanks for your reply. I will get confirmation on the partner certificates.

Before that I have few queries for you. As you said, while sending MDN back to partner server, it checks for the right certificate on my server first and do authentication, if not found, then it gets fail with this error. In this scenario, will the partner really get this request logged in their server?

Also please correct me if am worng on below.

I installed partner certificate in Trading Network Partner`s profile Security tab under both “Sign/Verify” and “encrypt/dectypt” tabs. and my profile security tab I installed my certificate on both the tabs. Is this configuration is right or need any correction.



  1. Customer’s server log should have entry for your successful/unsuccessful connection.
  2. You need to copy customer’s server certificate to your CAcert location and then restart the server. It will not consider certificates from TN.


  1. Customer’s server log should have entry for your successful/unsuccessful connection.
  2. You need to copy customer’s server certificate to your CAcert location and then restart the server. It will not consider certificates from TN for outbound connection.

Your Issue resolved ??

Hi Vikas,

Yes, I reolved it yesterday. When I contacted partner, they confirmed that they were using different SSL certificate for authentication. But when I replaced the new one with the certificate we already have, then again I faced the authentication issue, but this time while processing EDIINT payload itself. (not at delivering MDN)

So I replaced the old certificate again in TN , and I just imported the new SSL certificate on IS Certs page(Old one is already imported). Then it started working fine for both EDIINT and MDN msgs.

So, I realised, that we need both certificates to process EDI data with partner. (Old one is for authnetication and process payload(decrypting) of EDIINT and other to pass the authentication while delivering MDN to partner.

This is the first time, I noticed that two certs for SSL handsake. Can you plz provide yor comment if any?

Hi ,
Good to hear that issue got resolved.
As i’ve told you that customer may use different certificate for inbound / outbound SSL and you are doing both kind of transactions with customer then you should had not tried with removing SSL cert for EDIINT data. Anyhow now thumb rule if customer is using different certificates for inbound and outbound then both SSL cert should be registered on your IS.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.