Skip to Content
Author's profile photo Markus Schalk

Outbound support for TLS 1.1/1.2

Why use it?

The Payment Card Industry (PCI) announced SSL and TLS 1.0 as no longer secure. (Date Change for Migrating from SSL and Early TLS)

Vendors like Salesforce.com adopt PCI standards and disable SSL and TLS 1.0, so in near future we are forced to use TLS 1.1 or 1.2.

 

What’s the problem

Activating TLSv1.1 or TLSv1.2 on the client side unfortunately results in handshake failures with a certain non-marginal number of older servers.

They implement the negotiation of the SSL/TLS protocol version incorrectly (TLS protocol version intolerance).

Beside version intolerance, TLS extensions in the ClientHello handshake message can cause handshake failures with older servers not supporting that(TLS extension intolerance).

Because of that, all TLS communication has to be tested before using TLSv1.1 or TLSv1.2.

See note 510007 – Setting up SSL on Application Server ABAP for further details.

 

Outbound communication using IAIK library

Note 2284059 – Update of SSL library within NW Java server introduced new TLS versions for outbound communication using the IAIK library.

Default configuration is stored in iaik_ssl.jar in folder /usr/sap/<SID>/J21/j2ee/cluster/bin/ext/mail-activation.

iaik_ssl.jar contains a SSLContext.properties in folder iaik\security\ssl, listing the default config parameters.

SSLContext.properties 

######################################### 

#  SSLContext properties 

#  supported since ISASILK 4.4

#  Location of configuration file is iaik/security/ssl/SSLContext.properties within CLASSPATH

#  It can be redefined with system property iaik.security.ssl.configFile

#  e.g.java -Diaik.security.ssl.configFile=file:c:/java/SSLContext.properties

#

#########################################

# allowLegacyRenegotiation is set to true otherwise we cann't communicate with unpatched peers

allowLegacyRenegotiation=true

# unsecure renegotiation is disabled for SSL server but remains allowed for client SSL

server.disableRenegotiation=true

#deactivated to avoid regressions after ISASIK5.102

chainVerifier.checkExtensions=false

#avoid issues with IIS server

extension=signature_algorithms

 

Manual configuration is possible using custom config file

To enable custom configuration, one has to set the property “iaik.security.ssl.configFile”. This is possible using the ConfigTool.

 

SSLConfigFile.PNG

 

Afterwards you have to create a file having your custom properties e.g. ssl.config.

Recommendation: Copy the values known from SSLContext.properties to avoid problems.

 

Important custom parameters are listed below:

 

Parameter Example values Description
client.minProtocolVersion TLS12 Requires TLS 1.2 as minimum version for communication. Lower versions are disabled.
client.maxProtocolVersion TLS11 Limits usage of TLS to version 1.1
protocolVersions nfe.fazenda.sp.gov.br(TLS11,TLS11)

Limits communication to TLS 1.1 using domain names. First value is min and second max value. If ports other than 443 are used,

they have to be added using a colon. example.com:5443(SSL20,TLS12)

 

More options can be found in SAP Note 2284059 – Update of SSL library within NW Java server.

 

Testing outbound communication

To test communication you can use XPIInspector. Use Example 11 (Authentication, SSL & PP) or Example 50 (XI Channel) if Example 11 does not deliver any results. (Seems to happen for FTPS channels)

SSL Debug Error 

Begin IAIK Debug: 

ssl_debug(21): Starting handshake (iSaSiLk 5.104)...

ssl_debug(21): Sending v3 client_hello message to preprod.connect.elemica.com:5443, requesting version 3.3...

ssl_debug(21): Sending extensions: renegotiation_info (65281), signature_algorithms (13)

ssl_debug(21): Received alert message: Alert Fatal: unexpected message

ssl_debug(21): SSLException while handshaking: Peer sent alert: Alert Fatal: unexpected message

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

ssl_debug(21): Closing transport...

SSL Debug Success 

Begin IAIK Debug: 

ssl_debug(1): Starting handshake (iSaSiLk 4.5)...

ssl_debug(1): Sending v3 client_hello message to connect.elemica.com:5443, requesting version 3.1...

ssl_debug(1): Received v3 server_hello handshake message.

ssl_debug(1): Server selected SSL version 3.1.

ssl_debug(1): Server created new session EA:05:A1:1E:C5:04:C5:2F...

ssl_debug(1): CipherSuite selected by server: SSL_RSA_WITH_3DES_EDE_CBC_SHA

 

Solving problems

Facing any intolerance errors, try to reduce TLS Versions allowed for domain using parameter protocolVersions. To prevent that the server uses signature extensions, only possible way is to set min version to SSL20 at the moment.

 

Find channels using TLS/SSL

There is no standard way how to find all channels using TLS/SSL. Some channels can be found with the extended search of the Integration Builder using the attribute “Adapter Type”.

 

ExtendedSearch.PNG

 

This does not work for SOAP channels, therefore we used a SQL-statement to find out all SOAP channels and filtered for https in Excel.

SQL statement
 
select  a.CONTEXTID, a.OBJECTID, b.channel,        

        xmlparse(a.ATTRBTS)                      

from ppo.sapj2ee."XI_DIRSYNCCHANNEL" a,          

     ppo.sapj2ee."XI_DIRKEYCHANNEL"  b           

where a.objectid = b.objectid                    

  and   a.msgPROT = 'SOAP'

with ur;

 

Note: We are using DB2, xmlparse is a special function there

Assigned tags

      48 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Eng Swee Yeoh
      Eng Swee Yeoh

      Hi Markus

      Thank you for sharing this. This will be very useful for the community.

      There seems to be a few missing images in the blog, can you please fix them?

      - Image under section "Manual configuration is possible using custom config file"

      - Image under section "Find channels using TLS/SSL"

      Best regards

      Eng Swee

      Author's profile photo Markus Schalk
      Markus Schalk
      Blog Post Author

      Hi Eng,

      thanks for your feedback, I added the pictures again. Hope it works now.

      Enjoyed your blog about TLS as well, thanks for sharing.

      Best regards,

      Markus

      Author's profile photo Andrew Purgert
      Andrew Purgert

      Markus,

      I notice you are trying to hit Elemica.  We are having an issue with Elemica after upgrading to NW 7.5.  I am trying to implement other ciphers, but it seems to not be taking them.

      We are getting an error on our PI side saying "Bad certificate."  Everything leads to changing the ciphers.  Have you had any luck changing the ciphers per "cipherSuite=<cipher>" or experienced "Bad certificate" before?

      XPI shows the handshake happening, but it seems to be an issue with our channel.  I can get the "Bad certificate" when in "11" I don't supply a private key view and key.

      Begin IAIK Examination:

          The default IAIK chain verifier trusts this chain.

      End IAIK Examination.

      Begin IAIK Debug:

      ssl_debug(9): Starting handshake (iSaSiLk 4.5)...

      ssl_debug(9): Sending v3 client_hello message to connect.elemica.com:5443, requesting version 3.1...

      ssl_debug(9): Received v3 server_hello handshake message.

      ssl_debug(9): Server selected SSL version 3.1.

      ssl_debug(9): Server created new session 09:11:47:3F:22:C9:85:25...

      ssl_debug(9): CipherSuite selected by server: TLS_RSA_WITH_AES_256_CBC_SHA

      ssl_debug(9): CompressionMethod selected by server: NULL

      ssl_debug(9): Server does not support secure renegotiation.

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

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

      ssl_debug(9): ServerCertChain[0]:

      ssl_debug(9):   Version: 3

      ssl_debug(9):   Serial Number: 0x5886f05a94cc307668f49ac50f920a23

      ssl_debug(9):   Signature Algorithm: SHA/RSA

      ssl_debug(9):   Issuer:  CN=VeriSign Class 3 International Server CA - G3

      ssl_debug(9):            OU=Terms of use at https://www.verisign.com/rpa (c)10

      ssl_debug(9):            OU=VeriSign Trust Network

      ssl_debug(9):            O=VeriSign\, Inc.

      ssl_debug(9):            C=US

      ssl_debug(9):   Validity:

      ssl_debug(9):     Not Before: Thu Oct 11 00:00:00 UTC 2012

      ssl_debug(9):     Not After:  Tue Oct 11 23:59:59 UTC 2016

      ssl_debug(9):   Subject: CN=connect.elemica.com

      ssl_debug(9):            OU=IT

      ssl_debug(9):            O=Elemica

      ssl_debug(9):            L=Philadelphia

      ssl_debug(9):            ST=Pennsylvania

      ssl_debug(9):            C=US

      ssl_debug(9):   Public Key: RSA, 2048 bit

      ssl_debug(9): ServerCertChain[1]:

      ssl_debug(9):   Version: 3

      ssl_debug(9):   Serial Number: 0x641be820ce020813f32d4d2d95d67e67

      ssl_debug(9):   Signature Algorithm: SHA/RSA

      ssl_debug(9):   Issuer:  CN=VeriSign Class 3 Public Primary Certification Authority - G5

      ssl_debug(9):            OU=(c) 2006 VeriSign\, Inc. - For authorized use only

      ssl_debug(9):            OU=VeriSign Trust Network

      ssl_debug(9):            O=VeriSign\, Inc.

      ssl_debug(9):            C=US

      ssl_debug(9):   Validity:

      ssl_debug(9):     Not Before: Mon Feb 08 00:00:00 UTC 2010

      ssl_debug(9):     Not After:  Fri Feb 07 23:59:59 UTC 2020

      ssl_debug(9):   Subject: CN=VeriSign Class 3 International Server CA - G3

      ssl_debug(9):            OU=Terms of use at https://www.verisign.com/rpa (c)10

      ssl_debug(9):            OU=VeriSign Trust Network

      ssl_debug(9):            O=VeriSign\, Inc.

      ssl_debug(9):            C=US

      ssl_debug(9):   Public Key: RSA, 2048 bit

      ssl_debug(9): ChainVerifier: Found a trusted certificate, returning true

      ssl_debug(9): Received certificate_request handshake message.

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

      ssl_debug(9): Accepted certificate authorities:

      <<cert Authorities>>

      ssl_debug(9): Received server_hello_done handshake message.

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

      ssl_debug(9): Sending client_key_exchange handshake...

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

      ssl_debug(9): Sending change_cipher_spec message...

      ssl_debug(9): Sending finished message...

      ssl_debug(9): Received change_cipher_spec message.

      ssl_debug(9): Received finished message.

      ssl_debug(9): Session added to session cache.

      ssl_debug(9): Handshake completed, statistics:

      ssl_debug(9): Read 16342 bytes in 3 records, wrote 2528 bytes in 5 records.

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

      ssl_debug(9): Sending alert: Alert Warning: close notify

      ssl_debug(9): Read 0 bytes in 0 records, 0 bytes net, 0 average.

      ssl_debug(9): Wrote 0 bytes in 0 records, 0 bytes net, 0 average.

      ssl_debug(9): Closing transport...

      ssl_debug(9): Closing transport...

      End IAIK Debug.

      Author's profile photo Markus Schalk
      Markus Schalk
      Blog Post Author

      Dear Andrew,

      "Bad certificate" is likely a problem regarding certificate authentication. As far as I know, you need a certificate to communicate with Elemica and they need to trust the CA and Root certificates.

      Best regards,

      Markus

      Author's profile photo Andrew Purgert
      Andrew Purgert

      Hey Markus,

      Turns out our bad certificate is coming because of the TLS extensions being sent in the client hello.  When we moved to NW 7.5, it appears that SAP Java is using the JVM not the IAIK all the time.  We are working with SAP to get our PI system to all use IAIK, but haven't been able to complete this yet.

      If I supply a certificate while connecting via XPI, it actually started working because XPI is using IAIK, but our HTTP Adapter appears to be using the SAP JVM.

      Confusing, I know.  When SAP comes back with a resolution, I will add it here.

      Andrew

      Author's profile photo Markus Schalk
      Markus Schalk
      Blog Post Author

      Dear Andrew,

      have you seen note "2229837 - REST receiver adapter is using SSL implementation provided by JDK", it seems to describe your problem. Probably the problem occurs for every adapter...

      Markus

      Author's profile photo Andrew Purgert
      Andrew Purgert

      Good find!  We have also come across that note and tried the parameters (in every place we could think since it didn't tell you exactly where to put it).

      Turns out that we - with the help of SAP - can confirm that the HTTP Adapter is using the JVM instead of IAIK.  Not sure which other adapters move that way in NW 7.5/SAPJVM 8.

      We have made some progress with our integration.  Using parameter jdk.tls.client.protocols and setting it to SSLv2Hello,SSLv3,TLSv1,TLSv1.1, TLSv1.2 has fixed our first communication error with the partner.  The partner could not handle the TLS extensions and switching back to an SSLv2Hello fixes it because extensions cannot be used.  This is set in Config Tool --> template --> instance --> VM Parameters --> System by adding the new parameter.

      Wireshark traces now show the client and server hellos happening, but we fail with a "Bad record MAC" error.  Working on this now.  Hopefully I'll have an update soon should someone else ever run into this issue.

      Andrew

      Author's profile photo Markus Schalk
      Markus Schalk
      Blog Post Author

      Dear Andrew,

      thanks for sharing! As we are planning to upgrade to 7.5 beginning 2017, this is important information. Maybe all adapters on PO 7.5 are using JVM instead of IAIK. Did you ask SAP that question?

      So you solved the problem the same way we did using IAIK, that's great! In future we will ask Elemica to update their infrastructure to be able to support up-to-date encryption (e. g. TLS1.2). Would be great if you do so too...

      We never faced the "Bad record MAC" error, hope you can fix it soon!

      Best regards

      Markus

      Author's profile photo Andrew Purgert
      Andrew Purgert

      Markus,

      We figured out what to do to fix Elemica!  The parameter jdk.tls.client.protocols needs to be set to SSLv2Hello,SSLv3,TLSv1 (essentially remove TLSv1.1 and TLSv1.2).  We have spoken with Elemica on their protocols last year when we attempted to disable some of our old ciphers and needed to leave them running.  According to them, they will be able to support TLSv1.2 in production in mid-July!

      The PI Team decided to leave the workaround in place (SFTP), so I can't tell for sure if any other problems happened with making the switch of this parameter.  It is concerning because setting the parameter this way turns off TLSv1.1 and 1.2 for outbound transmission for all partners.  This does seem to be what the default was in NW 7.4 SP 10 (where we upgraded from).  In case someone else comes across these messages with a similar problem, I wanted to have as final of a solution as I know.

      In response to your other question about every adapter using JVM, here was SAP's response: "I looked through PI code. The have the text 'Message Processing Failed due to Bad Certificate' in some situations as a general error description. So it is possible that it fails on other place in handshake but the at the end we see only this as an error. And yes, they use java's ssl and not iaik."

      So it looks like everything moved that way.  However, this may be different for add-on components like the PI B2B Add-on, so worth taking it with a grain of salt.

      Best of luck with the upgrade!  We took the plunge early to fix some errors - problems with the CPA cache was a big one.  If you have any questions on things we have hit, I can give any information we know.

      Andrew

      Author's profile photo Eng Swee Yeoh
      Eng Swee Yeoh

      Hi Andrew

      It has been very interesting following this conversation here. Thanks for sharing your experience so far.

      Regarding upgrade to 7.5, may I suggest that you blog about your experience. It would be beneficial to the wider community especially those who are also currently involved in 7.5 upgrades or planning to in the near future.

      Regards

      Eng Swee

      Author's profile photo Andrew Purgert
      Andrew Purgert

      Great idea!  I will make a note to get something out.  I'll try to get it out soon!

      Author's profile photo Markus Schalk
      Markus Schalk
      Blog Post Author

      Dear Andrew,

      using IAIK it works with following configuration:

      protocolVersions=connect.elemica.com:6443(SSL20,TLS12)

      It is important, to have the following parameter set to true, otherwise communication will not work:

      allowLegacyRenegotiation=true

      Beside that, we are forcing all new connections to use TLS12:

      client.minProtocolVersion=TLS12

      There are still a lot communication partners using TLS10, therefore we defined exceptions for them using protocolVersions parameter. (E. g. service.ariba.com(TLS10,TLS12))

      Can you please drop me a message with the contact details of Elemica regarding the topic?

      If possible, I would recommend using the IAIK configuration I described above. Which makes it easy to go for TLS12 in future and allows existing communication partners to stay on TLS10 for some time.

      I'll try to check with SAP what's going on with IAIK on 7.5...

      Any information about 7.5 would be highly appreciated. Which database are you using?

      Regards

      Markus

      Author's profile photo Andrew Purgert
      Andrew Purgert

      Hey Markus,

      If you find anything about switching back to IAIK, let me know!  I haven't been able to figure out how to get off the JVM myself to have the flexibility that the IAIK provides, such as using the protocolVersions parameter.

      I'll check with the B2B/PI Team to see if I can get a contact for Elemica for you.  I don't have the contacts myself.

      We're running MS SQL Server for our database.  Eng Swee Yeoh had a great idea to blog about it, so I am going to try to get something out soon.  I'll try to get in any "gotcha's" we came across, such as the need for Server 2012 as a minimum OS (if you're running Windows).

      If you have any specific questions before I get the blog out, let me know.

      Andrew

      Author's profile photo Former Member
      Former Member

      Hello Andrew,

      We are also facing the same issue. With this note we are not able to resolve this error. Could you please share your findings to configure TLS 1.1.

      Author's profile photo Andrew Purgert
      Andrew Purgert

      Hi Arun,

      I am guessing you upgraded to NW 7.50.  Unfortunately, I don't have anything else to add other than what I have already written.  The PI Team decided to move to an interim SFTP, so I didn't get to work further than that.

      Did you modify the parameter jdk.tls.client.protocols by setting it to SSLv2Hello,SSLv3,TLSv1 in Config Tool --> template --> instance --> VM Parameters --> System?

      What is the exact error you are seeing?

      Andrew

      Author's profile photo Former Member
      Former Member

      For Elemica we had to use:

      client.maxProtocolVersion=TLS10

      The selective key:

      protocolVersions=preprod.connect.elemica.com:6443(TLS10,TLS10)

      does not work

      Author's profile photo Sheril Sasidharan
      Sheril Sasidharan

      hi Markus, is there a way to find out what cipher suite is available in the current IAIK library without applying 2284059 ?We are on SAP PI731 and we dont have visual admin to figure out what cipher suite are available before applying note 2284059. One of our partner is upgrading their AES/DES cipher suites to newer and requesting us to make sure we have the updated cipher suites.

      Any help is appreciated.

      Thanks

      Author's profile photo Markus Schalk
      Markus Schalk
      Blog Post Author

      Hi Sheril,

      afaik the only list showing cipher suites is in note 2284059. Inofficially I heard that recent IAIK versions support the same cipher suites like CommonCryptoLib 8 (2004653) except ECDHE cipher suites in older versions.

      What exactly does your partner change? Is it about Hash-Algorithms (e. g. SHA-2). This is supported by older IAIK versions in 7.31.

      Using XPI-Inspector it is possible to find out the ISaSiLK-Version, you then can go to this website an check for details. (WARNING: Complex stuff ahead 😉 ...)

      We use example 11 in XPI Inspector and then you can see IAIK debug logs:

      Begin IAIK Debug:

      ssl_debug(409): Starting handshake (iSaSiLk 5.104)...

      Best regards

      Markus

      Author's profile photo Sheril Sasidharan
      Sheril Sasidharan

      hi Markus, thanks for your reply. Basically our partner is changing the supported cipher suits for communication. They would stop the below cipher suites

      CipherSuiteNotSupported.jpg

      And allow only the below cipher suites going forward:

      CipherSuiteSupported.jpg

      Currently we use SSL_RSA_WITH_RC4_128_SHA while communicating to this partner...found out using XPI inspector. This suite is the first in the non supported on after they change the cipher suite on their end.

      btw - the website you had in the reply does not work. Can you please repost ?

      Thanks

      Sheril

      Author's profile photo Markus Schalk
      Markus Schalk
      Blog Post Author

      Hi Sheril,

      I updated the link. It should work again.

      (Link: versions / iSaSiLk / Communication &amp;amp; Messaging Security / Products / Home - Stiftung SIC)

      Regards

      Markus

      Author's profile photo Ian Black
      Ian Black

      Hi,

      We currently have been instructed by our internal security team to disable SSLv2 and SSLv3, they have already done this to one of the webservers which broke our PI SOAP channel which we had to revert to use HTTP. I have now built a new PI sandpit system with SPS15 and the latest J2EE ENGINE SERVERCORE 7.40 SP13 PL7. I was hoping no further configuration would be required in order to talk to this server using TLS but it fails, it also turns out that the one it currently talks to is using SSLv3 as seen when using XPI_INSPECTOR

      Begin IAIK Debug:

      ssl_debug(12): Starting handshake (iSaSiLk 4.403)...

      ssl_debug(12): Sending v3 client_hello message to ABC.XYZ.COM:443, requesting version 3.1...

      ssl_debug(12): Received v3 server_hello handshake message.

      ssl_debug(12): Server selected SSL version 3.1.

      ssl_debug(12): Server created new session 4D:3F:00:00:2A:DE:48:32...

      ssl_debug(12): CipherSuite selected by server: TLS_RSA_WITH_AES_128_CBC_SHA

      ssl_debug(12): CompressionMethod selected by server: NULL

      ssl_debug(12): TLS extensions sent by the server: renegotiation_info (65281)

      ssl_debug(12): Server supports secure renegotiation.

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

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

      ssl_debug(12): ChainVerifier: Found a trusted certificate, returning true

      ssl_debug(12): Received server_hello_done handshake message.

      ssl_debug(12): Sending client_key_exchange handshake...

      ssl_debug(12): Sending change_cipher_spec message...

      ssl_debug(12): Sending finished message...

      ssl_debug(12): Received change_cipher_spec message.

      ssl_debug(12): Received finished message.

      ssl_debug(12): Session added to session cache.

      ssl_debug(12): Handshake completed, statistics:

      ssl_debug(12): Read 5405 bytes in 3 records, wrote 444 bytes in 4 records.

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

      ssl_debug(12): Sending alert: Alert Warning: close notify

      ssl_debug(12): Read 0 bytes in 0 records, 0 bytes net, 0 average.

      ssl_debug(12): Wrote 0 bytes in 0 records, 0 bytes net, 0 average.

      ssl_debug(12): Closing transport...

      ssl_debug(12): Closing transport...

      End IAIK Debug.

      I have created a file /sapmnt/PS3/global/ssl.config which contains only 1
      line;
      client.minProtocolVersion=TLS10

      I have a entry for iaik.security.ssl.configFile and I have restarted the java stack but it is still communicating using SSLv3

      java properties.JPG

      So I have 2 issues,

      1. unable to communicate with Webserver that has had SSL disbaled
      2. unable to force a TLS connection on the webserver that still works with SSL

      So I believe the only reason the second web server is working is that it is using SSL rather than TLS but I am having problem proving this.

      Regards

      Ian

      Author's profile photo Markus Schalk
      Markus Schalk
      Blog Post Author

      Dear Ian,

       

      please provide the version of the SERVERCORE component. Very likely the SAP note mentioned above is not implemented. (iSaSiLk 5.104 should be shown...)

       

      For your understanding:

      SSL 3.1 = TLS 1.0

      SSL 3.2 = TLS 1.1

      SSL 3.3 = TLS 1.2

       

      Thus you PI installation asks for TLS 1.0 communication at maximum level:

      Sending v3 client_hello message to ABC.XYZ.COM:443, requesting version 3.1...

       

      Regards

      Markus

      Author's profile photo Ian Black
      Ian Black

      Hi Markus,

       

      Where would I see iSaSiLk 5.104?

       

      I have already patched it to the latest available which is 7.40 SP13PL7 as seen below;

       

      SERVERCORE.JPG

      Regards

      Ian

      Author's profile photo Markus Schalk
      Markus Schalk
      Blog Post Author

      Dear Ian,

       

      right at the beginning of your debug log.

       

      Begin IAIK Debug:

      ssl_debug(12): Starting handshake (iSaSiLk 4.403)...

       

      Component version looks ok, that's likely not the problem.

       

      What example of XPI Inspector are you using and what did you configure in your ssl.config beside minProtocolVersion?

       

      Regards
      Markus

      Author's profile photo Ian Black
      Ian Black

      Hi Markus,

       

      I am using example 11 in the xpi_inspector. for now that is the only entry that I have in ssl.config and as you said it appears to be working, I changed it to TLS12 and in the inspector I can see 'requesting version 3.3' which as you say is actually TLS 1.2. So it appears I am speaking to one of the webservers using TLS1.2 which is good, but I Still cannot understand why I am unable to speak to the other webserver. I have tested them from the OS using openssl and this is what I am seeing.

       

      PI can currently communicate only with Pre-Prod and not QA using HTTPS;

       

      table.JPG

       

      Regards
      Ian

      Author's profile photo Markus Schalk
      Markus Schalk
      Blog Post Author

      Hi Ian,

       

      one recommendation for my side. Please include following defaults from SSLContext.properties, to prevent certain error situations:

       

      #Defaults aus SSLContext.properties

       

      # allowLegacyRenegotiation is set to true otherwise we cann't communicate with unpatched peers

      allowLegacyRenegotiation=true

      # unsecure renegotiation is disabled for SSL server but remains allowed for client SSL

      server.disableRenegotiation=true

      #deactivated to avoid regressions after ISASIK5.102

      chainVerifier.checkExtensions=false

      #avoid issues with IIS server

      extension=signature_algorithms

       

      The screen you shared shows, that ECDHE cipher suites are required by the server. PI/PO does not support those yet. That's likely why Pre-Prod falls back to SSLv3 and QA does not work.

       

      Refer my blog entry about how to figure out supported cipher suites.

      How to check supported outbound cipher suites

       

      Hint: You can use this tool to check supported server cipher suites.

      jcewww.iaik.tu-graz.ac.at/index.php/sic/Products/Communication_Messaging_Security/iSaSiLk/demo

       

      Regards,

      Markus

      Author's profile photo Ian Black
      Ian Black

      Hi Markus,

       

      Thanks for your help on this, would Pre-Prod be allowed to fall back to using SSLv3, I thought with me setting the minimum allowed to TLS1.2 it would just fail should it not be able to talk on that protocol rather than fall back to a less secure protocol.

       

      I have now added those params into the ssl.config file.

       

      Regards

      Ian

      Author's profile photo Markus Schalk
      Markus Schalk
      Blog Post Author

      Dear Ian,

       

      you are right, fall back should be forbidden in your scenario. Are you using HTTP_AAE adapter at the moment?

       

      Also did you check server side supported cipher suites?

       

      Please also share a new ssl debug trace showing the error.

       

      Regards,

      Markus

      Author's profile photo Ian Black
      Ian Black

      Hi Markus,

      The communication channel is a SOAP 1.1,


      I will speak to our windows team about cipher suites on the webserver end.

      Here is a new debug from XPI_INSPECTOR

      Here is the successful trace from pre-prod

      Begin IAIK Debug:
      ssl_debug(5): Starting handshake (iSaSiLk 5.104)...
      ssl_debug(5): Sending v3 client_hello message to ABC.PreProd.com:443, requesting version 3.3...
      ssl_debug(5): Sending extensions: renegotiation_info (65281), signature_algorithms (13)
      ssl_debug(5): Received v3 server_hello handshake message.
      ssl_debug(5): Server selected SSL version 3.3.
      ssl_debug(5): Server created new session 41:1A:00:00:22:03:75:41...
      ssl_debug(5): CipherSuite selected by server: TLS_RSA_WITH_AES_128_GCM_SHA256
      ssl_debug(5): CompressionMethod selected by server: NULL
      ssl_debug(5): TLS extensions sent by the server: renegotiation_info (65281)
      ssl_debug(5): Server supports secure renegotiation.
      ssl_debug(5): Received certificate handshake message with server certificate.
      ssl_debug(5): Server sent a 2048 bit RSA certificate, chain has 2 elements.

      Here is the failure from QA

      Begin IAIK Debug:
      ssl_debug(6): Starting handshake (iSaSiLk 5.104)...
      ssl_debug(6): Sending v3 client_hello message to ABC.QA.com:443, requesting version 3.3...
      ssl_debug(6): Sending extensions: renegotiation_info (65281), signature_algorithms (13)
      ssl_debug(6): IOException while handshaking: Connection reset
      ssl_debug(6): Sending alert: Alert Fatal: handshake failure
      ssl_debug(6): Exception sending message: java.net.SocketException: Broken pipe
      ssl_debug(6): Shutting down SSL layer...
      ssl_debug(6): Closing transport...

      Regards
      Ian.

      Author's profile photo Praveen Gandepalli
      Praveen Gandepalli

      Hi Ian,

      Why dont you open a separate question for this because this is not the right place to discuss about the problem.

      Regards,
      Praveen.

      Author's profile photo Ian Black
      Ian Black

      I just thought I would provide an update, as it may help others who are stuck like I was, I used testssl.sh to test against the webserver I was having problems connecting to, from this I was able to see the ciphers listed;

      Hexcode  Cipher Suite Name (OpenSSL)    KeyExch.   Encryption Bits
      ————————————————————————-
      x9f     DHE-RSA-AES256-GCM-SHA384      DH 1024    AESGCM     256
      xc028   ECDHE-RSA-AES256-SHA384        ECDH 256   AES        256
      xc014   ECDHE-RSA-AES256-SHA           ECDH 256   AES        256
      x9e     DHE-RSA-AES128-GCM-SHA256      DH 1024    AESGCM     128
      xc027   ECDHE-RSA-AES128-SHA256        ECDH 256   AES        128
      xc013   ECDHE-RSA-AES128-SHA           ECDH 256   AES        128

      Now non of these appear in the standard list (found in OSS Note 2284059) and the ECDHE are not supported, so I am left with two that I can add, so I create the ssl.config file detailed above and added all the standard ciphers listed in the OSS Note as well as the two below;

      cipherSuite=TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
      cipherSuite=TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

      This resolved the issue and now I get a connection, the trace shows me;

      Received v3 server_hello handshake message.
      Server selected SSL version 3.3.
      Server created new session D8:21:00:00:E0:51:2B:D0…
      CipherSuite selected by server: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
      CompressionMethod selected by server: NULL
      TLS extensions sent by the server: renegotiation_info (65281)
      Server supports secure renegotiation.
      Received certificate handshake message with server certificate.

       

      Author's profile photo Katie Doody
      Katie Doody

      Hi all, when using TLS 1.2. Do you still need a CA from a third party? We are calling a third party restful web service. The third party has told us that their other consumers did not need a certificate.

       

      Thanks,

      Katie

       

      Author's profile photo Holger Neub
      Holger Neub

      Hi Markus,

       

      this dossier saved us from a lot of trial and error iterations.

      I read there is currently no official list of all supported ciphers in the combination SAP PI 7.4 and IAIK library.

      Are you aware of such a list by now?

       

      Thank you!

       

      Regards

      Holger

      Author's profile photo Markus Schalk
      Markus Schalk
      Blog Post Author

      Dear Holger,

       

      I would like to send you a message. I think you have to follow me, so I am able to do so.

       

      Regards

      Markus

       

      Author's profile photo Former Member
      Former Member

      HI Markus,

      we implemented 2284059 note to connect to Ariba site ,its working fine after applying note.( we are using soap adapter in this case)

      But at the same time one of our partner ( FDA) upgraded their system recently and restricted to only TLS 1.2.we are using seeburger AS2 adapter in this case.

      we are getting error as : : javax.net.ssl.SSLException: Unsupported record version Unknown-0.0

      Can you please let me know how to resolve this or is there any workaround for this.. ( we are on PI 731Ehp1-sp19)

       

      As per seeburger:

      – Outgoing HTTPS connections for HTTP based SEEBURGER adapters (e.g.
      AS2, HTTP, EbXML_HTTP) and incoming/outgoing SSL/TLS connections of
      non-HTTP SEEBURGER adapters (e.g. OFTP, FTP, X400P7 etc.) are based on
      the standard security providers of the underlying Java VM (usually the
      provider “SunJSSE”).
      I.e. if those default providers do not support the protocol (e.g.
      TLSv1.2) or the cipher (e.g. TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384)
      which the communication partner requires, it is most likely that the
      connection cannot be established.
      – Standard Oracle Java VM <(><<)>= 1.6 does not support TLSv1.2 and some
      ciphers which may be supported in Oracle Java VM 1.8.

      Due to that, SEEBURGER cannot guarantee, that SEEBURGER adapters support
      TLSv1.1 or TLSv1.2, as it highly depends on the underlying Java VM
      version and vendor and existing security providers AND the protocol
      versions and ciphers the communication partner allows.

       

      Thanks

      Surya

       

      Author's profile photo Timothy-Michael K Ong
      Timothy-Michael K Ong

      Hi Surya,

       

      We updated our JVM to allow Seeburger AS2 to use TLS 1.2 (on top of the server core patch). See if patching it to 6.1.102 helps resolve your issue.

       

      Cheers!

       

      Timothy Ong

      Author's profile photo Former Member
      Former Member

      Thanks Timothy,

      We upgraded  our JVM,also updated JCE files that  resolved our issue.

       

      Author's profile photo Pablo Casanova
      Pablo Casanova

      Hi Markus,

      i get this error when integrating with ariba, the server has tls 1.2 protocol and basis team configured with as config tool java.

       

      on the tcode sm59 i get the same error (handshake failure).

       

      Any other option for check?

       

      Best Regards

       

      Author's profile photo Markus Schalk
      Markus Schalk
      Blog Post Author

       

      Hi Pablo,

       

      Good question, we faced the same problem an raised a ticket.

       

      Solution: You need to update to the latest HF# Version of AN Adapter.

      Cause: Likely Ariba Adapter did not use IAIK for TLS/SSL communication before.

       

      Following cloud integration releases now support the Transport Layer Security (TLS) protocol TLS1.1 and TLS1.2 on Ariba Network adapter for SAP NetWeaver:

      o    Cloud integration release 9.0 : AribaNetworkAdapterSAPNetweaver_vCI_9_HF8_UP.zip

      o    Cloud integration release 8.0 : AribaNetworkAdapterSAPNetweaver_vCI_8_HF17_UP.zip

      o    Cloud integration release 7.0 : AribaNetworkAdapterSAPNetweaver_vCI_7_HF23_UP.zip

      o    Cloud integration release 6.0 : AribaNetworkAdapterSAPNetweaver_vCI_6_HF36_UP.zip

       

      You also need to put some new values in the channel. I would like to upload the documents here, but I did not find an option for that? Was anyone able to do that?

      Please follow me, then I am able to send you a message.

       

      Best regards

      Markus

       

      Author's profile photo Pablo Casanova
      Pablo Casanova

      markus,

       

      i follow to you now.

       

      Best regards

       

      Author's profile photo Markus Schalk
      Markus Schalk
      Blog Post Author

      Hi Pablo,

      Sure? I am not able to see that and thus to write you a message.

      Best regards

      Markus

       

      Author's profile photo Pablo Casanova
      Pablo Casanova

      Markus,

       

      sorry , now i follow to you.

       

      Regards

      Author's profile photo Former Member
      Former Member

      Hi Markus,

       

      Im also facing the same issue ..Can you forward me the document about the Ariba Network adapter settings

       

      Thanks

      AK

       

      Author's profile photo Johannes Görlich
      Johannes Görlich

       

      Hello,

      i just found the iaik_ssl_jar in three different locations in three different versions:

      1. /usr/sap/<SID>/<instance>/j2ee/cluster/bin/ext/mail-activation-iaik/` from 2018
      2. /usr/sap/<SID>/SYS/global/security/lib/tools/ from 2017
      3. /usr/sap/DAA/SMDA97/SMDAgent/lib/iaik from 2013

      For the 1st one it is stated that it is used at least for JavaMail: https://help.sap.com/saphelp_nwpi711/helpdata/de/45/89caf2152f09b5e10000000a114a6b/frameset.htm

      For the 2nd one it is stated that it is used for remote database connections: “It enables the encrypting and decrypting of the properties file.” – https://help.sap.com/SAPHELP_NWPI71/helpdata/en/ec/9432d189c445cdacdc7e520981b4b6/frameset.htm

      I wonder why it needs these two similar libraries and why are not updated simultaniously? Anybody could put some light on this?

       

      The 3rd one belongs to Diagnostics Agent. The used TLS version there is configured by parameter -Djdk.tls.client.protocols="TLSv1.2 to the  the smdagent.properties file and not by defining custom SSLContext.properties (https://launchpad.support.sap.com/#/notes/2434357)

       

      Best regards

      J. Goerlich

      Author's profile photo Ian Black
      Ian Black

       

      Hi Markus and other experts,

      Am I right in saying that currently SAP PI (even most recent 7.5 system) still doesn't work with any of the ECDHE cipher suites, we are being told from one of the systems that we wish to talk to (lets call System X) that they are not prepared to enable anything other that an ECDHE cipher suite 🙁

      Is the only option then to introduce a reverse proxy between PI and this system X and then talk PI > non ECDHE > Reverse Proxy > ECDHE > System X

      Regards
      Ian

      Author's profile photo R. Hellemons
      R. Hellemons

      Hi Markus,

      I currently have a situation of which I'm wondering whether the Webdispatcher can be used for that.

      We have a PO system that needs to communicate with a logistics company using ECDHE cipher suites which aren't support by PO itself. Do you know if it's possible to install a Webdispatcher that uses the logistics company's URL as external server like this:

      wdisp/system_0 = SID=SEC, EXTSRV=https://<url logistics company>,https://<url logistics company>, SRCSRV=*:8102, SRCURL=/, STICKY=true

      icm/server_port_0 = PROT=HTTPS,PORT=8102

      If this would work that would means PO uses the Webdispatcher for outbound communication after which it receives a confirmation from the logistics company back to PO using the required cipher suites.

      Regards,

      Rob

      Author's profile photo Lutz Rottmann
      Lutz Rottmann

      Hi Rob, I saw this scenario (own on premise SAP Web Dispatcher in front of a remote foreign web server) working. It was implemented for exactly this reason. It is simple as long as no client certificates are involved (no mutual authentication). If there are client certificates involved, this might get complicated or impossible. You might as well use any other Reverse-Proxy software instead of SAP Web Dispatcher.

      Cheers, Lutz

      EDIT: I saw that this type of solution is kind of an official workaround of note 2538934:

      In case you are not allowed to enable additional cipher suites (different ones than ECDHE) another option can be using Apache or any other specific load balancers as a workaround. If reverse proxy mode is enabled regarding these options they can terminate the TLS connection.

       

      Author's profile photo Markus Schalk
      Markus Schalk
      Blog Post Author

      Hi Rob,

      As Lutz stated, this should be possible. I am not into the details about this.

      Remark: You could use SAP Cloud Platform Integration instead. It supports ECDHE, an we migrate to it.

      List:

      • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
      • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
      • TLS_RSA_WITH_AES_256_CBC_SHA256
      • TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
      • TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
      • TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
      • TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
      • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
      • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
      • TLS_RSA_WITH_AES_256_CBC_SHA
      • TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
      • TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
      • TLS_DHE_RSA_WITH_AES_256_CBC_SHA
      • TLS_DHE_DSS_WITH_AES_256_CBC_SHA
      • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
      • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
      • TLS_RSA_WITH_AES_128_CBC_SHA256
      • TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
      • TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
      • TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
      • TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
      • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
      • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
      • TLS_RSA_WITH_AES_128_CBC_SHA
      • TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
      • TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
      • TLS_DHE_RSA_WITH_AES_128_CBC_SHA
      • TLS_DHE_DSS_WITH_AES_128_CBC_SHA
      • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
      • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
      • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
      • TLS_RSA_WITH_AES_256_GCM_SHA384
      • TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
      • TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384
      • TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
      • TLS_DHE_DSS_WITH_AES_256_GCM_SHA384
      • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
      • TLS_RSA_WITH_AES_128_GCM_SHA256
      • TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
      • TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256
      • TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
      • TLS_DHE_DSS_WITH_AES_128_GCM_SHA256

      Regards

      Markus