Skip to Content

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 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 in folder iaik\security\ssl, listing the default config parameters. 


#  SSLContext properties 

#  supported since ISASILK 4.4

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

#  It can be redefined with system property




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


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


#deactivated to avoid regressions after ISASIK5.102


#avoid issues with IIS server



Manual configuration is possible using custom config file

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




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

Recommendation: Copy the values known from 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

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.,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, 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, 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”.




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,,        


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

You must be Logged on to comment or reply to a post.
  • 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

    • 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,

    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, 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 (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:

    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 (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.

    • 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,


      • 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.


        • 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...


          • 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.


          • 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,

            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.


          • 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.


            Eng Swee

          • Dear Andrew,

            using IAIK it works with following configuration:


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


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


            There are still a lot communication partners using TLS10, therefore we defined exceptions for them using protocolVersions parameter. (E. g.,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?



          • 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.


          • 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.

          • 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?


  • For Elemica we had to use:


    The selective key:,TLS10)

    does not work

  • 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.


    • 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


  • 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

    I have a entry for 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.



    java properties.JPG
    • 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...




  • 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;





    • 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?



  • 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;





    • Hi Ian,


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


      #Defaults aus


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


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


      #deactivated to avoid regressions after ISASIK5.102


      #avoid issues with IIS server



      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.




      • 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.




        • 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.




          • 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, 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, 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: Broken pipe
            ssl_debug(6): Shutting down SSL layer...
            ssl_debug(6): Closing transport...


  • I just thought I would provide an update, as it may help others who are stuck like I was, I used 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;


    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.


  • 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.





  • 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!




  • Dear Holger,


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





  • 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 : : 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.





    • 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.




      Timothy Ong

  • 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



      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 :

      o    Cloud integration release 8.0 :

      o    Cloud integration release 7.0 :

      o    Cloud integration release 6.0 :


      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





    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:

    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.” –

    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 file and not by defining custom (


    Best regards

    J. Goerlich


    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


  • 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.



    • 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.


    • 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.


      • TLS_RSA_WITH_AES_256_CBC_SHA256
      • TLS_RSA_WITH_AES_128_CBC_SHA256
      • TLS_RSA_WITH_AES_256_GCM_SHA384
      • TLS_RSA_WITH_AES_128_GCM_SHA256