"Peer certificate rejected by ChainVerifier" occurs for a specific endpoint

[Former Member]

Dear experts,

We have an issue with our SSL endpoints. We have installed the certificated to TrustedCAs and we have 5 different communication channells with real similar settings. 4 of them are working and only 1 of them gives the ChainVerifier error.

The endpoint of this four channels is:

https://ourendpoint.com/JUST/Fristerstreckung/FristerstreckungService.svc

The channels with this endpoint are working. And this one gives the ChainVerifiert error although it has the same host:

https://ourendpoint.com/AuthenticationService/AuthenticationServiceWcf.svc

We have installed the root certificate from https://ourendpoint.com. So I am not sure if there is something wrong with the certificate or we are doing something wrong on PO. How can we check the certificate? Is it possible in a certificate to allow everything under "/JUST" and not include "/AuthenticationService"? Could be this the issue?

And please before you post other links to threads with similar issues: I have tried to read them all and didn't find an issue with this specific problem. I am happy for any usefull input.

Thanks and Regards,

Koray

[former_member182412 · Accepted solution]

Hi Koray,

Try stop and start the channel and see, because channel caches the certificate, after you install the new certificate you need to refresh this cache by restarting the channel.

1829329 - Messages fail in PI SOAP Receiver Adapter after updating the Server Certificate

For performance reasons the SOAP adapter caches the server certificate on channel start up. Therefore when the Keystore is updated with the new certificate, the old certificate is still maintained within the cache and therefore used by the channel.

Regards,

Praveen.

[engswee · Accepted solution]

Nice sharing, Praveen. I've definitely noticed such behavior before in the past but never really knew it was related to channel caching. This info is definitely good to know.

[Former Member · Accepted solution]

thanks for the inputs. we will install XPI inspector and analyse further. channel restart was a usefull tip but didn't help. I was deleting CPACache after installing / deleting certificates. that also helped clearing the cache for the certificates

[Former Member · Accepted solution]

With further analyse we found out that the xxxx_AUTH communication channel was used in Java Mapping which was making a SOAP call using "com.sap.aii.mapping.xxxx" classes. So it was not a "classical" interface. We thought maybe this interface ignores the TrustedCA store and installed the certificate directly on JVM. Now all calls are working. Thanks for the inputs.

[former_member182412 · Accepted solution]

Hi Koray,

You might want to try this option as mentioned in below sap note.

1588148 - Trusted certificates for SOAP receiver channels

- Find the receiver SOAP channel module configuration, navigate to the module 'sap.com/com.sap.aii.af.soapadapter/XISOAPAdapterBean', and set up the following parameter:

    Module Key  = soap

    Parameter Name = trustStore

    Parameter Value = TrustedCAs

Regards,

Praveen.

[wilianoliveira · Accepted solution]

Very helpful tip.

It works for me.

Thanks.

[iaki_vila]

Hi Koray,

We had similar problem and finally it was that the endpoint had two certificates installed and sent these two certificates. Also check if your PI has more than one certificate that it can taken.

As Eng said you can debug better the problem with XPI inspector tool and his blog is extraordinary if he had published before i had saved a lot of time , also you can check the note 1799620 - Logs required for analysis of SSL related issues

Regards

[former_member186851]

Hello Koray,

The particular URL which your trying to hit might require other additional certificates.

Your webservice team must be able to help you with the required certificates.

[engswee]

Hi Koray

Have you tried using XPI inspector to look into this issue. Following is my blog on how to troubleshoot such issues.

I'd suggest you run once for the /JUST endpoint and another time for the /AuthenticationService endpoint and compare the generated XPI reports.

This is just a guess, but maybe there is a redirection to a different server for the authentication service. Running XPI inspector might hopefully give you more hints on that.

Rgds

Eng Swee