on 01-26-2016 1:43 PM
Hello all;
From SAP PI 7.30 we call we a SOAP web-service over https. This service was running for a long time. The provider of the web-service upgraded their SSL certificates from SHA-1 signing algorithm to the stronger and more robust SHA-256. After that, we get the following error: iaik.security.ssl.SSLException: Peer sent alert: Alert Fatal: handshake. As said, just before the change the connection was working. I have added the required VeriSign CA root certificates to the Trusted CA's keystore within NWA. (VeriSign Class 3 Secure Server CA - G4 and G5) Something must be wrong. When I look into SXMB_MONI, I see something for which I don't know if it is related: encryptionAlgorithmEncryptionEncriptionSignature value DES_EDE3_CBC. I am not an expert in this, but could it be possible that this should be AES256-CBC? How to change that?
Any help or suggestion is welcome. My next step will be to install XPI Inspector to figure out what is wrong.
Wilbert
Hello Wilbert,
The error message you posted above (iaik.security.ssl.SSLException: Peer sent alert: Alert Fatal: handshake failure) is a typical symptom of the issue I mentioned in this thread: . We have to differentiate between server and client scenarios here. The notes you mentioned above (2110020 and 510007) refer to the ICM parameters and to the server scenario only. If the AS Java is the client, changing the ICM parameters make no difference because then the "SAP Java Cryptographic Toolkit" is used (not the SAP Cryptolib or the CommonCryptoLib) which only have TLS1.0 support now.
Best Regards,
Peter
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Peter,
Thank you for this valuable input. This clears my question which was in my head, since SAP note 000510007 talks about setting up SSL on AS ABAP (and not on JAVA site). However, it was SAP support (I have an open incident on this) who advised me to go through SAP note 2110020. Nevertheless, the statement within SAP note 2110020 that TLSv1.1 and TLSv1.2 are not enabled by default for outgoing connections (client side) confuses me, as you stated that the note refers to ICM parameters and to the server scenario only. Especially the words server scenario confuses me, since the notes talks about client site. Perhaps it is only for ABAP. So my focus is now on the Java Cryptographic Toolkit. I will update my incident to SAP with that specific information and ask SAP when TLSv1.2 come available in that toolkit. What I do not understand in the following. SAP PI/PO in SAP's middleware. Most recent implementation is JAVA only, that is the direction. How is it possible that mid February 2016 TLSv1.2 is not yet supported if I understand your feedback correctly? Our payment provider PayPal will switch to TLSv1.2 only on June 17, 2016. If this is not solved in time, our business processes will be in danger. Peter, do you know if a workaround is available via SAP Web Dispatcher as a Intermediary Server? Or do we have the same issue with SAP Web Dispatcher?
Regards;
Wilbert
Hello Wilbert,
The notes may not be that obvious and should be read carefully. The thing is for outgoing SSL connections, TLS1.2 is not yet supported. I cannot comment on the workarounds but that is for sure the development is in progress and this issue will be addressed by SAP Development.
To have a better understanding please check out this picture:
The left side is for version 7.1 and above, the right side is for below 7.1.
The notes you mentioned all talk about the SAP Cryptolib or CommonCryptolib. But that does not play a part here as I mentioned earlier.
If you have already created an incident, you may have the answer already or it will be answered there.
(As soon as I have more info about the ETA, I will post it here.)
Best Regards,
Peter
Hi Peter;
Again thank you for your support, that is appreciated by me.
The notes I mentioned were suggested by the SAP person who was busy with my incident. Yesterday I asked to pass my incident to SAP Development team. I just got the confirmation that they have done that. If a have any news, I will update it here.
Yesterday already I looked at the pictures you have included. That was very useful for me.
Regards;
Wilbert
Hello Peter,
I am not sure if you have seen the thread http://scn.sap.com/thread/3870902.
I have FTPS->PI->NFS(File) scenario where FTPS client is switching their SHA-1 intermediate certificate to SHA-2.
We getting "connection refused by remote host" error. As per the xpi_inspector logs, the handshake is initiated followed by the connection is closed by remote host.
The FTP client has asked us, if we support TLS1.1 version? We have SAP PI 7.31 Java only system with SAPCRYPTO-Library 5.5.5pl38.
Does this library supports TLS1.1 version for FTPS connection on sender side of PI?
Regards,
Simran
Hi Wilbert,
I do want to mention to you that the Advantco REST Adapter supports TLS 1.2.
https://www.advantco.com/product/REST
Regards,
Brandt
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Wilbert,
We are also facing the same issue while communicating with one of our clients who have moved onto TLS. (iaik.security.ssl.SSLException: Peer sent alert: Alert Fatal: handshake failure). We updated the latest crypto library files and also the profile parameters as per SAP recommendation. We have set the values to below as we need to allow both SSL and TLS communication in our landscape.
ssl/ciphersuites 721:HIGH:MEDIUM:+e3DES
ssl/client_ciphersuites 726:HIGH:MEDIUM:+e3DES
However when we are trying to send communication with the client it failed with mentioned exception. It seems like the request is still being sent out as SSL and not TLS and hence the client system is rejecting it. We have been following up with SAP for long but no luck yet to get this working. Please let me know if you get any resolution from SAP. We even tried to set the value for both parameters to 512 so that it will only allow TLS. But still it didn't worked. Can't really find a way to test if the request is being sent out as SSL or TLS.
Thanks
Pranav
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi all;
I asked SAP how I can see if our SAP PI is actually sending/supporting TLSv1.2 as a java client. The misunderstood my question, so I have to go back to them. SAP came with the suggestion to perform the ssl-hellotest using a Perl script as mentioned in SAP note 2110020.
Here is the result of my test proving that I need TLSv1.2 support.
Sandbox PayPal:
Live PayPal (move to TLSv1.2 mid June)
@Dave and Dhirendra, can you run your test and confirm that your provider also needs exclusively TLSv1.2? How do you call your provider, using SOAP over https?
Regards,
Wilbert
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello Wilbert,
The configurations are similar.
Import the required certificates in NWA key store.
Below is the SAP document for configuring SOAP Receiver adapter
Configuring the Receiver SOAP Adapter - Advanced Adapter Engine - SAP Library
Hello Wilbert,
Here is the result of our Perl test for Pay Pal sandbox which matches yours. Pay Pal is
a SOAP ( Axis ) Receiver. We use Axis because we had to force PI call to go out HTTP 1.1
We also have an OSS Message open and our management has been in touch with our
SAP sales rep.
SSLv3: record=(3,0), ClientHello=(3,0) no TLS extensions
tlstest.paypal.com:443... sending ClientHello (len=58)
FAIL: (server silently closed network connection)
TLSv1.0: record=(3,0), ClientHello=(3,1) no TLS extensions
tlstest.paypal.com:443... sending ClientHello (len=58)
FAIL: (server silently closed network connection)
TLSv1.1: record=(3,0), ClientHello=(3,2) no TLS extensions
tlstest.paypal.com:443... sending ClientHello (len=58)
FAIL: (server silently closed network connection)
TLSv1.2: record=(3,0), ClientHello=(3,3) no TLS extensions
tlstest.paypal.com:443... sending ClientHello (len=58)
OK: ServerHello.server_version=(3,3) = (TLSv1.2)
ServerHello.cs={ 0x00,0x35 } TLS_RSA_WITH_AES256_CBC_SHA
Hi Dave
Can you be so kind to share a screenshot (all settings) of the SOAP Axis receiver for PayPal sandbox. On request of SAP I have replaced 2 jar files in our SAP PI Development system. My handshake error is gone now but I experience another error: HTTP 400 BAD request in the response coming back from PayPal. Besides the TLSv1.2 requirement, PayPal also request http 1.1. Perhaps that is the reason. Note that my web service was working before for a long time.
Thanks in advance.
Wilbert
Hello Wilbert,
We have received the same jar files from SAP and have applied to our DEV environment and we believe we are now having issues with our client certificate for authentication. Do you authenticate with Pay Pal via Signature or Client Certificate? Also wondering if you applied the Server Certificate downloadable from Pay Pal https://www.paypal-knowledge.com/infocenter/index?page=content&widgetview=true&id=FAQ1772https://www.paypal-knowledge.com/infocenter/index?page=content&widgetview=true&id=FAQ1772
Regarding HTTP 1.1:
Below are the screen shots of our SOAP Axis Receiver. The 2nd pic of the Module tab is where all the changes were made to support HTTP 1.1
I hope this helps.
Regards,
Dave
Hi Dave,
Thanks to your input for SOAP Axis Receiver I have my api-3t of PayPal running. I had to move to http 1.1 as required by PayPal. I am using client certificate, make sure you use the SHA-256. I loaded 2 certificates (besides the VeriSign G5 which was loaded earlier).
If you have not deployed the XPI Inspector tool, I would advise you to deploy that.
This one you need (if you have api-3t), otherwise you need similar.
For this one I am not sure:
I believe my API is running which means I don't get any error and I get back successful response:
However, we have no data in the sandbox. I need to figure out how to do that. With the api-3t we load payment transactions (Inventory Management). In the document the 2 api operations are called TransactionSearch and GetTransactionDetails. Do you use perhaps the same api?
I am still not 100% convinced that our business process is still working. I need to get some data in.
Wilbert
Hi James;
That is the correct folder. Did you restart you PI/PO system? Do you connect via Java stack? The XPI_Inspector runs on the java stack. If you have also ABAP stack en you connect from there, you could try the notes as explained in this thread.
How do you connect? SOAP, http, http (Axis)?
Perhaps you can share the result of the trace with XPI_Inspector so I can compare.
Wilbert
Hi Wilbert - Yes, we are also trying to connect to Paypal. We are still getting "HTTP 400 Bad Request" error message when we are trying with API Signature or API Certificate. We also tried converting to SOAP AXIS but no luck. Do you know how you resolve HTTP 400 error message?
Thank you
Dhirendra
Hi Dhirendra,
I am not 100% sure if I solved it. But I don't get the error anymore, where I did get HTTP 400 before after loading the SAP patches (2 jar files). My understanding is that I got the error because I did not use http 1.1 as requested by PayPal sandbox. For this reason I changed my SOAP receiver from transport protocol HTTP and message protocol SOAP 1.1 to: transport protocol HTTP (Axis) with message protocol Axis. See also the reply I just gave to James where I shared my screenshots. The reason why I say that I am not 100% sure has to do with the fact that we have currently no test data in our PayPal sandbox account. We are working on that. As soon as we have loaded some transactions I will try to load them van SAP PI. Keep you posted.
Best regards;
Wilbert
Hi Wilbert - Thanks for the help and update. My issue is also resolved and its working fine now. The reason I was getting "HTTP 400 Bad Request" error is because we were using SOAP adapter. After changing to AXIS with the matching jar file for our SAP version, I was able to connect successfully. I do have another side question, Is your Paypal IPN interface to PI working?. Could you please provide me your email ID so that I can discuss with you offline.
Thank you
Dhirendra
Hi Dhirendra,
Hope this is working well for you now. I do want to quickly mention that the Advantco REST Adapter supports TLS - 1.2 https://www.advantco.com/product/REST.
Kind Regards,
Brandt
Hi Wilbert,
We are having the same experience with the same API provider. We are single stack 7.4 environment with Verisign G5 installed and XPI shows fatal handshake after the initial hello. Our authentication
is certificate, so are attempting to load new 2048 bit cert since our current cert is 1024. Our first attempt at converting from PEM to PCKS12 failed. We also do not want to disable SSLv3 yet. I will keep you posted of any progress, please share teh same.
Regards,
Dave
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Dave,
Join the club. This issue is annoying me.
Sure that I will update this thread when we have a solution. I also have an open incident at SAP. But if I read thread (in group for SAP NetWeaver Administrators) https://scn.sap.com/thread/3852649 I am not optimistic at the moment. Some wrote that there is currently no solution for java clients for TLSv1.2 I asked for the source of that information.
Best regards;
Wilbert
Hi Dave/Wilbert - I am also in the same boat. I am on single stack 7.4 and trying to connect to client with TLS 1.2 and getting the same error"Failed to get the input stream from socket: iaik.security.ssl.SSLException: Peer sent alert: Alert Fatal: handshake failure". I tried few different things like installing G5 cert to keystore, upgrading cryptography library per note 2110020 and setting profile parameter ssl/ciphersuite but not luck. Please update the thread once you find the solution. I will do the same. I also have message open with SAP too.
Hi all;
After some additional tests via a IE browser, I came to the conclusion that my web service on the site https://api-3t.sandbox.paypal.com/2.0/ requires TLSv1.2. When TLSv1.2 is de-selected the site cannot be reached. So at this point, my issue is not related to SHA-256 hashing. To verify that, I also tested via XPI Inspector to another URL of a bank which is using SHA-256 for signing/hashing. SAP note 2110020 tells us that protocols TLSv1.1 and TLSv1.2 are not enabled by default for outgoing connections (client side). Currently I am investigating that in combination with sap note 510007. It looks like we have to set some profile parameters like ssl/ciphersuites and ssl/client_ciphersuites. We are running SAP PI 7.30. Does anyone have experience with does parameters? Note that we don't want to disable SSLv3 (yet).
Wilbert
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi all;
We tried to implement sap notes 2110020 and 510007, unfortunately without success.
This is what we tried: (we put parameters in DEFAULT profile with R10).
We are on SAP PI 7.30 SP05, Kernel 721_EXT_REL path 600,CommonCryptoLib 8.4.41 pl40.
Test 01:
ssl/client_ciphersuites = 982:HIGH:MEDIUM:+e3DES
Restart SAP PI.
Test 02:
ssl/ciphersuites = 982:HIGH:MEDIUM:+e3DES
ssl/client_ciphersuites = 982:HIGH:MEDIUM:+e3DES
Restart SAP PI.
Test 03:
ssl/ciphersuites = HIGH:MEDIUM:+e3DES
ssl/client_ciphersuites = HIGH:MEDIUM:+e3DES
Restart SAP PI.
Best regards;
Wilbert
Hi Wilbert
XPI Inspector is really your best bet in this situation. It provides you a clear view of the certificate chain used as well as a thorough IAIK debug log as described in my blog below.
I'd suggest you execute the troubleshooting steps there and post up the results here for further analysis.
Rgds
Eng Swee
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello wilbert,
After the WS upgrade did you import the cerficiates required for new algorithm SHA-256.?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Raghuraman;
The SOAP WS support 2 types of credential sets: signature set and certificate set. We use credential set where we specify user, password and signature. To my understanding I don't need to import additional certificates besides the CA root certificates as mentioned earlier. It is possible that I miss something. In that case I need some more guidance.
When I type the URL in a browser like Chrome or IE, the handshaking is done. I tried also with SOAPUI, but so far without success. Currently I am adding a keystore for the CA certificates to SOAPUI to see if I get it working from SOAPUI.
Wilbert
Hi Wilbert,
Did you restart the soap receiver channel after the new certificate imported in NWA?
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.
Hello Wilbert,
Incase you using authentication without certificate there shouldn't be any additional setups.
Just ensure if the new user is updated then the approirate access in provided for the webservice call.
And if there is any change in URL after the Algorithm change make sure the port and URL whitelisting is done at the server level.
While testing in SOAP UI what is the error displayed?
Hi Raghuraman
I am working on the mentioned SAP note, Q5. I also installed XPI Inspector tool. I want to share the result. Our connection from PI to the webserver fails during step 1 of the handshake, sending v3 client_hello message.
My assumption is, that my JVM (SUN version 1.6) does not support SHA-2. Can someone confirm that? The SAP note mentioned by Raghuraman is related to that. Until now, we were not able to fix it.
Regards;
Wilbert
Hello Wilbert,
have you talked to the Server side? Do they see anything in their logs? If the Server interrupts the handshake than the error or mismatch must be on his side. So they'd have a better insight in what you send and what they expect.
I assume you don't see the Server certificate in XPI_Inspector, right? If not, that would also indicate that it is not (yet) a certificate issue.
Regards,
Jörg
Hi Juerg;
Indeed, I don't see the server certificate yet. I try to connect to PayPal sandbox. I am not sure if I can contact them very easily to review the server log. From another client system (non-PI) it is working.
Can some try for me using the XPI inspector using the option 11 (Authentication, SLL & PP) and post the following SSL server URL Address: https://api-3t.sandbox.paypal.com/2.0/ ? Does the handshake work?
When I connect with XPI inspector to https://api-3t.paypal.com/2.0/ if have no issue. But note that PayPal changed the signing to SHA-256 as stated earlier is this thread.
Wilbert
User | Count |
---|---|
84 | |
25 | |
12 | |
9 | |
6 | |
6 | |
5 | |
5 | |
4 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.