on ‎2019 Jul 31 8:32 AM
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.
Request clarification before answering.
Try with the following instance profile parameters:
icm/HTTPS/client_sni_enabled = TRUE
ssl/client_ciphersuites = 150:PFS:HIGH
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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).
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I have stored the SSL Certificate already into multiple nodes that you have suggested above . No System does not have multiple instances .
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
| User | Count |
|---|---|
| 15 | |
| 9 | |
| 6 | |
| 4 | |
| 4 | |
| 4 | |
| 3 | |
| 2 | |
| 2 | |
| 2 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.