Skip to Content

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

To report this post you need to login first.

34 Comments

You must be Logged on to comment or reply to a post.

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

    (0) 
    1. Markus Schalk 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

      (0) 
  2. 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.

    (0) 
    1. Markus Schalk 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

      (0) 
      1. 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

        (0) 
        1. Markus Schalk 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

          (0) 
          1. 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

            (0) 
            1. Markus Schalk 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

              (0) 
              1. 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

                (0) 
                1. 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

                  (0) 
                2. Markus Schalk 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

                  (0) 
                  1. 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

                    (0) 
            2. Arun Phadke

              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.

              (0) 
              1. 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

                (0) 
  3. 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

    (0) 
    1. Markus Schalk 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

      (0) 
      1. 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

        (0) 
  4. 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

    (0) 
    1. Markus Schalk 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

      (0) 
  5. 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

    (0) 
    1. Markus Schalk 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

      (0) 
  6. 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

    (0) 
    1. Markus Schalk 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

      (0) 
      1. 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

        (0) 
        1. Markus Schalk 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

          (0) 
          1. 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.

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

     

    (0) 
  8. 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

     

    (0) 
  9. 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

    (0) 
  10. Markus Schalk 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

     

    (0) 

Leave a Reply