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.
#########################################
|
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.
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)
Begin IAIK Debug:
|
Begin IAIK Debug:
|
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.
select a.CONTEXTID, a.OBJECTID, b.channel,
|
Note: We are using DB2, xmlparse is a special function there
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
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.
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
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
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
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
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
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
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
Great idea! I will make a note to get something out. I'll try to get it out soon!
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
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
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?
Andrew
For Elemica we had to use:
client.maxProtocolVersion=TLS10
The selective key:
protocolVersions=preprod.connect.elemica.com:6443(TLS10,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.
Thanks
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
hi Markus, thanks for your reply. Basically our partner is changing the supported cipher suits for communication. They would stop the below cipher suites
And allow only the below cipher suites going forward:
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
Hi Sheril,
I updated the link. It should work again.
(Link: versions / iSaSiLk / Communication &amp; Messaging Security / Products / Home - Stiftung SIC)
Regards
Markus
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
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
Dear Ian,
please provide the version of the SERVERCORE component. Very likely the SAP note mentioned above is not implemented. (
iSaSiLk5.104should be shown...)For your understanding:
SSL 3.1 = TLS 1.0SSL 3.2 = TLS 1.1SSL 3.3 = TLS 1.2Thus 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
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;
Regards
Ian
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
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;
Regards
Ian
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
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
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
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.
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.
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.
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
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
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
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
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
Thanks Timothy,
We upgraded our JVM,also updated JCE files that resolved our issue.
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 : 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
markus,
i follow to you now.
Best regards
Hi Pablo,
Sure? I am not able to see that and thus to write you a message.
Best regards
Markus
Markus,
sorry , now i follow to you.
Regards
Hi Markus,
Im also facing the same issue ..Can you forward me the document about the Ariba Network adapter settings
Thanks
AK
Hello,
i just found the iaik_ssl_jar in three different locations in three different versions:
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
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
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
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:
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:
Regards
Markus