SSL Sender SOAP Adapter, Server Certificate CN does not contain URL

[lisakramer]

Hi,

using a Sender SOAP Adapter to consume a third-party webservice with https we always get the Exception

SOAP: call failed: iaik.security.ssl.SSLCertificateException: Peer certificate rejected by ChainVerifier.

I already read several posts and blogs concerning similar problems, e.g.

and implemented the provided solutions (imported whole certificate chain ...)

However we face the problem, that the provided certificate does not list the url/hostname as common name. Instead the third-party shares one certificate for multiple urls listing them as

Certificate extensions:

   [critical]

   [non critical]

         SubjectAltName: dNSName:

We were informed by the third-party that they are not able to provide a certificate especially for the webservice we need which has exactly the url as common name.

Can someone help with a solution for this configuration?

Our PI is on NetWeaver 7.50 SPS 02 Release NW750EXT_02_REL.

Thanks and regards

Lisa

[markangelo_dihiansan · Accepted solution]

Hi Lisa,

You only need to import the rootCA and intermediateCA in the TrustedCA for the HTTPs without Client Authentication to work. Please remove the server cert from the trusted CA.

Regards,

Mark

[lisakramer · Accepted solution]

Hi Mark,

thanks for your support!

It tried deleting only the server cert but receive the same error.

Do I need to import the certifcates in a special manner to keep the chain in working order?

Here are some screenshot of my configuration. The language is german but I hope the content / structure is clear nevertheless.

The certificate chain as listed in IE.

The keystore of our PI, I deleted the server cert and left the two superior:

And the configuration of the sender channel in the integration builder.

Regards,

Lisa

[markangelo_dihiansan · Accepted solution]

Hi Lisa,

Can you try removing the two certs and then import the middle first and then the top second?

Regards,

Mark

[lisakramer · Accepted solution]

Hi Mark,

unfortunately it still raises the same error.

Regards,

Lisa

[markangelo_dihiansan · Accepted solution]

Hi Lisa,

Are you using propose URL or are you sending to https://host:port/XISOAPAdapter/MessageServlet?channel=p:s:c ?

Regards,

Mark

[markangelo_dihiansan · Accepted solution]

Hi Lisa,

Check OSS 2222086 - Peer certificate rejected by ChainVerifier in PI File Adapter.

I know that you are using SOAP Adapter, but the procedure for editing hostnames should be the same

Regards,

Mark

[lisakramer · Accepted solution]

Hi Mark,

thanks again for the active help!

I'm not sure, if I understand your question right, do you mean the configurated Target URL in the SOAP-Adapter?

Here I entered the URL (the same way I would write it in the adress bar of a browser).

Regards,

Lisa

[markangelo_dihiansan · Accepted solution]

Hi Lisa,

Sorry about that, I meant the configured target URL.

Regards,

Mark

[lisakramer · Accepted solution]

Hi Mark,

do you propose to delete the assigned entry for the webservice URL?

To gain access to the files on OS level I have to contact our technical support, this might take some time and I have to specify the task, they should perform.

Regards,

Lisa

[markangelo_dihiansan · Accepted solution]

Hi Lisa

No, do not delete it. You have already done everything properly e.g insert the certificates in the correct order. It will be up to Basis now to correct the hostname entries in OS.

Regards,

Mark

[Harish · Accepted solution]

Hi Lisa,

Did you tried to consume the web service from SOAP UI. As mentioned by Mark OSS note, are you maintaining any DNS/host entry in server host file.

regards,

Harish

[lisakramer · Accepted solution]

Hi Harish,

I consumed it with the command line tool cURL, this worked fine. But the tool itself does not require to upload the certificates beforehand. Instead - similar to a browser session - it downloads the certificates during the communication with the server.

As stated below, I have to contact our technical team as I do not have access to the OS level to check weather we are maintaing a DNS.

Regards,

Lisa

[lisakramer · Accepted solution]

Hi,

we have identified the issue and were able to patch it.

Additonally to your posts, the usage of the XPI-Inspector was helpful:

As you guessed in the first step, the chain was not complete. Surprisingly the PI identified an additional Root Certificate, which was not listed in the certificate chain of the browser.

Thanks again for the helpful suggestions.

Regards,

Lisa

[markangelo_dihiansan · Accepted solution]

Thank you Lisa for sharing the solution.