cancel
Showing results for 
Search instead for 
Did you mean: 

iaik.security.ssl.SSLException: Peer sent alert: Alert Fatal: handshake

wilbertkarremans
Participant

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

wilbertkarremans
Participant
0 Kudos

Hi Pranav;

Yes I found the solution for my problem which was that the server I connect to requires TLSv1.2 and nothing else. If you have a similar case, you need to install 2 patches coming from SAP Security development. I logged an incident at SAP for this. SAP provided me a temporary fix.

Best regards;

Wilbert

Former Member
0 Kudos

Hi Wilbert,

is there an official note where I can find the patches or an howto?

Thanks

Sebastian

wilbertkarremans
Participant
0 Kudos

Hi Sebastian,

As far as I know, there is no official note. I have a call (incident) at SAP which is still open. Via that incident I received the (preliminary) patch. I have applied that patch in all our PI systems. You need such a patch if TLSv1.2 security is required.

Best regards;

Wilbert

former_member198633
Contributor
0 Kudos

Hi All,

Please keep on eye on this note:

2284059 - Update of SSL library within NW Java server

This is the resolution for this problem.

Best Regards,

Peter

0 Kudos

Hi Peter,

Does that mean, PI supports TLSv1.2 on FTP adapter as well?

Thank you!

Regards,

Simran

0 Kudos

Would it be possible for you to tell us what patches you had to apply?  We are also having issues getting our interface between our PI 7.31 SP14 system to a Microsoft Azure system to work.  Getting a  handshake error on TLS 1.2, but TLS 1.0 works with them.  We do use the REST adapter.  Any and all information you can provide would be most helpful.

wilbertkarremans
Participant
0 Kudos

Hi Marlene

Our system still runs on temporary patches.

SAP replied on my incident:

The correcture is done in 7.30 starting with SP13 until now.

SAP note: 2284059 Update of SSL library within NW Java server

Hope this will help you.

Wilbert

Accepted Solutions (1)

Accepted Solutions (1)

former_member198633
Contributor
0 Kudos

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

wilbertkarremans
Participant
0 Kudos

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

former_member198633
Contributor
0 Kudos

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

wilbertkarremans
Participant
0 Kudos

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

0 Kudos

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

Answers (7)

Answers (7)

0 Kudos

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

prasam
Discoverer
0 Kudos

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

wilbertkarremans
Participant
0 Kudos

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

former_member186851
Active Contributor
0 Kudos

Hello Wilbert,

So your issue stands now in calling the SOAP over https?

you can try referring the below link

wilbertkarremans
Participant
0 Kudos

Hi Raghuraman

Yes, we call SOAP over https hence we have a SOAP receiver (not sender).

Wilbert

former_member186851
Active Contributor
0 Kudos

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

dave_komzak
Explorer
0 Kudos

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

0 Kudos

Hello Wilbert/Dave - I am also getting the same output as yours. Fail for SSLv3, TLSv1.0, TLS1.1 and OK for TLSv1.2. Waiting on response from SAP Development team.

Thanks Peter for your valuable input.

wilbertkarremans
Participant
0 Kudos

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

dave_komzak
Explorer
0 Kudos

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

0 Kudos

Hello Wilbert -

After updating the jar files, I am also getting the same error as your's "SOAP: Response message contains an error XIAdapter/HTTP/ADAPTER.HTTP_EXCEPTION - HTTP 400 Bad Requet". We are trying with user ID/ signature base authentication.

wilbertkarremans
Participant
0 Kudos

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

wilbertkarremans
Participant
0 Kudos

Hi,

I moved to SOAP Axis receiver. I moved to http 1.1
Do you also use PayPal perhaps?

Check if you need http 1.1?

If so and when you use Axis, check the module configuration like Dave gave in the screen shot.

Please me posted how you solve the HTTP 400 error.

Wilbert

Former Member
0 Kudos

Wilbert:

    Which folders do you put those 2 jar files from SAP? We put them in the /j2ee/cluster/bin/ext/mail-activation-iaik folder but still get the handshake error when trying to connect to PayPal. However, the Example 11 test in XPI_INSPECTOR shows success.

wilbertkarremans
Participant
0 Kudos

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

Former Member
0 Kudos

We are in single stack and use SOAP (Axis) connection.

Do you setup ssl/ciphersuites & ssl/client_ciphersuites parameters in the default profile?

Do you want trace from Example 11 or 50?

wilbertkarremans
Participant
0 Kudos

James

XPI_Inspector trace 11. I did use those parameters, in the default profile but I believe ther are not relevant. Do you use the 3 tph parameters in the module settings of SOAP Receiver? See the screenshot from Dave.

Wilbert

Former Member
0 Kudos

We have those 3 tph parameters in the module as Dave's suggestion. Just curious, what values of those parameters (ssl/ciphersuites & ssl/client_ciphersuites ) in the default profile? Could you share?

wilbertkarremans
Participant
0 Kudos

Hi James

Si above in this thread. 20/02/2016 10:22 AM my post.

Wilbert

Former Member
0 Kudos

Wilbert:

    Could you send me the screenshot of Module Configuration under Module tab?

0 Kudos

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

wilbertkarremans
Participant
0 Kudos

Hi James

Wilbert

wilbertkarremans
Participant
0 Kudos

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

wilbertkarremans
Participant
0 Kudos

Hi all

As promised, here the final outcome. Today I received an account with test data. Our service to PayPal sandbox with TLSv1.2 security requirements is running as before. However, still no final/official patch from SAP.

Best regards;

Wilbert

0 Kudos

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

wilbertkarremans
Participant
0 Kudos

Hi Dhirendra;

We are not using IPN from PayPal, we use another interface api-3t which is now working.If you share your e-mail address I will contact you to see what kind of questions you have.

Best regards;

Wilbert

0 Kudos

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

dave_komzak
Explorer
0 Kudos

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

wilbertkarremans
Participant
0 Kudos

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

0 Kudos

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.

wilbertkarremans
Participant
0 Kudos

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

wilbertkarremans
Participant
0 Kudos

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

engswee
Active Contributor
0 Kudos

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

former_member186851
Active Contributor
0 Kudos

Hello wilbert,

After the WS upgrade did you import the cerficiates required for new algorithm SHA-256.?

wilbertkarremans
Participant
0 Kudos

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

former_member182412
Active Contributor
0 Kudos

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.

former_member186851
Active Contributor
0 Kudos

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?

wilbertkarremans
Participant
0 Kudos

Hi Raghuraman,

There are no changes in the URL (As far as I am aware). The error message in the SOAP UI is similar: SSL/TLS Protocol alert. Handshake failure: Possibly no shared cipher.

Wilbert

wilbertkarremans
Participant
0 Kudos

Hi Praveen

I tried to restart the receiver SOAP channel. No success. Earlier today I restarted the complete PI server.

Note that I only loaded CA root certificates of VeriSign.

Wilbert

former_member186851
Active Contributor
0 Kudos

Hello Wilbert,

check the below SAP note(Question No 5)

856597

wilbertkarremans
Participant
0 Kudos

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

former_member186851
Active Contributor
0 Kudos

It should suppor Wilbert,

But your screenshot shows your using SHA-1 algorithm...

wilbertkarremans
Participant
0 Kudos

Hi Raghuraman

I assume you refer to the first screen shot.

Question is, how can I make sure sha-2 (SHA-256) is used? Is this because of incorrect policy files? Missing certificates? I don't get it.

Wilbert

former_member186851
Active Contributor
0 Kudos

Helo Wilbert,

My assumption would be missing certificate because as far as I know SHA-256 is supported.

Former Member
0 Kudos

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

wilbertkarremans
Participant
0 Kudos

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

wilbertkarremans
Participant
0 Kudos