cancel
Showing results for 
Search instead for 
Did you mean: 

SSLException while handshaking: Peer sent alert: Alert Fatal: decrypt error

0 Kudos

Hello everybody,

I am tryining to establish a connection from SAP PI 7.0 to an external web service that requires SSL with client authentication. I am using the SOAP adapter for that. The private key of us and the public key of the web service were installed in the VA in the TrustedCAs view. In the corresponding receiver channel configuration I have ticked "Configure Certificate Authetication" and selected appropriate entries in "Keystore Entry" and "Keystore View".

Whenever I send a message through the channel I am getting though an error during the SSL handshake: Decrypt error.

Below is the SSL debug log

ssl_debug(15): Sending v3 client_hello message to services.bloomberg.com:443, requesting version 3.1...

ssl_debug(15): Received v3 server_hello handshake message.

ssl_debug(15): Server selected SSL version 3.1.

ssl_debug(15): Server created new session 81:ED:F8:61:3B:51:8E:70...

ssl_debug(15): CipherSuite selected by server: TLS_RSA_WITH_AES_256_CBC_SHA

ssl_debug(15): CompressionMethod selected by server: NULL

ssl_debug(15): Server does not supports secure renegotiation.

ssl_debug(15): Received certificate handshake message with server certificate.

ssl_debug(15): Server sent a 2048 bit RSA certificate, chain has 3 elements.

ssl_debug(15): ChainVerifier: No trusted certificate found, OK anyway.

ssl_debug(15): Received certificate_request handshake message.

ssl_debug(15): Accepted certificate types: RSA, DSA

ssl_debug(15): Accepted certificate authorities:

ssl_debug(15):   CN=XXXXXXXXXXXXXXXXXXXXXXXX

ssl_debug(15):   CN=VeriSign Class 3 International Server CA - G3,OU=Terms of use at https://www.verisign.com/rpa (c)10,OU=VeriSign Trust Network,O=VeriSign, Inc.,C=US

ssl_debug(15):   CN=VeriSign Class 3 Public Primary Certification Authority - G5,OU=(c) 2006 VeriSign, Inc. - For authorized use only,OU=VeriSign Trust Network,O=VeriSign, Inc.,C=US

ssl_debug(15): Received server_hello_done handshake message.

ssl_debug(15): Sending certificate handshake message with RSA client certificate...

ssl_debug(15): Sending client_key_exchange handshake...

ssl_debug(15): Sending certificate_verify handshake message...

ssl_debug(15): Sending change_cipher_spec message...

ssl_debug(15): Sending finished message...

ssl_debug(15): Received alert message: Alert Fatal: decrypt error

ssl_debug(15): SSLException while handshaking: Peer sent alert: Alert Fatal: decrypt error

ssl_debug(15): Shutting down SSL layer...

My first assumption was that it might be caused by missing public key of other side's server in the TrustedCAs view. Now I have assured that we have this key installed (although I am currious why there is still the "ChainVerifier: No trusted certificate found" message in the log).

Does somebody have an idea what could cause this SSL handshake failure?

Best regards,

Maxim

Accepted Solutions (0)

Answers (2)

Answers (2)

Former Member
0 Kudos

Hi,

I believe the SOAP header carries the encryption information. Did you by any chance skipping the SOAP header?

0 Kudos

Hello Naresh,

we do not come that far. The systems were not able to exchange any soap message yet as the connection attempt fails while doing the TLS handshake.

BR

M

VijayKonam
Active Contributor
0 Kudos

Hi,

Did you use the correct public key? It looks like the server is sending back the error that, it can not decrypt the message sent by your server.

Did you try with any other keystore other than the TrustedCAs?

VJ.

0 Kudos

Hello VJ,

Yes, I am also under impression that our PI does not recongnize the public key but I do not know how to check it. Is there a way to see somewhere (for example in the default trace of NWA) which certificate the server has sent to us?

Best regards,

M

0 Kudos

The XPI inspector gave more understanding of the situation. It shows which certificates the remote server is sending, which client certificate is used for authentication and many other topics. Interesting enough the XPI inspector shows that PI trusts the server key whereas the NWA log at the very same time tells that it doesn't. I have posted an OSS message asking to explain why there is this discrepancy.