cancel
Showing results for 
Search instead for 
Did you mean: 
Read only

SSL Handshake Error

Former Member
0 Likes
4,714

I am currently using an RFC of Type " HTTP Connections to External Sever" to establish connectivity with a third party system with Target Host as Spectrum.pitneybowes.com and Path Prefix as /Soap/ .

I have installed the SSL Certificate of the above Target Host in Strust and I am able to establish connectivity.

But when I use the Sub Domain of the above mentioned Target Host i.e. microbatch.spectrum.pitneybowes.com and Path Prefix as /Soap / with the very same SSL Certificate then I am not able to establish connectivity as it throws an SSL Handshake Error.

According to the owner of the third party system the SSL Certificate is a wild character certificate which supports multiple Sub Domains of Spectrum.Pitneybowes.com and it works fine for them over the URL and other applications .

However it's not working in SAP , kindly advice.

Accepted Solutions (0)

Answers (7)

Answers (7)

SamuliKaski
Active Participant

Try with the following instance profile parameters:

icm/HTTPS/client_sni_enabled = TRUE

ssl/client_ciphersuites = 150:PFS:HIGH

SamuliKaski
Active Participant

The trace reveals SSL_ERROR_CONNECTION_LOST followed by SSSLERR_SSL_CONNECT. Your AS ABAP might not be enabled for TLS 1.2 or higher, the target server probably requires it. See SAP notes 2368112 and 510007 for details.

SamuliKaski
Active Participant
0 Likes

The target hosts might be differently configured, one requiring TLS while the other allowing SSLv3 (which is the default in SAP systems unless changed). What is the value of the instance profile parameter ssl/client_ciphersuites?

I assume you are testing the main domain and sub domain the same way, either in SM59 or in code? Testing one one way and the other another way would be silly.

You could remote to the SAP server and try the troubleshooting steps mentioned in the SAP notes.

Former Member
0 Likes

Hi Samuli

ABAP is enabled for TLS 1.2 ,however as I said prior the same certificate works with one of the target host already but it does not work for its subdomain.

SamuliKaski
Active Participant
0 Likes

In that case, I would increase the ICM trace level to 2 or even 3, reproduce, decrease the ICM trace level back to 1 and then analyze the trace. There will be a reason for the SSL handshake to fail. I assume this is a client environment? You could check with their network administrator if they have some sort of SSL decrypting firewall that might explain the SSL handshake failing (the target sees it as man-in-the-middle attack).

Former Member
0 Likes

Hi Samuli

I increased the Trace level to 3 and I am attaching the ICM Logs , however I could not correlate much to identify the issue that why the SSL Certificate is not working.

I am attaching the logs.

Thanks

Former Member
0 Likes

I have stored the SSL Certificate already into multiple nodes that you have suggested above . No System does not have multiple instances .

SamuliKaski
Active Participant
0 Likes

The 3rd party is right, their wildcard certificate is correctly setup. Their wildcard certificate has 3 parts to it: root CA, intermediate and SSL server. All 3 must be trusted by SAP. You do not specify, how exactly you are accessing the target. You may have to store the certificates in multiple nodes in STRUST: System PSE, SSL standard, SSL anonymous, etc. If your system has multiple instances, you might have to make sure all instances see the certificates either by synchronizing the instances or saving the certificates on each instance.

Former Member
0 Likes

Hey Samuli , thanks for the reply.

I have stored the SSL Certificate already into multiple nodes that you have suggested above but it still throws SSL handshake error for the Sub Domain UR and not for the Main URL.

No System does not have multiple instances that I would need to sync.