Cloud Platform
This is an IBM Automation portal for Cloud Platform products. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).
Shape the future of IBM!
We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:
Search existing ideas
Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,
Post your ideas
Post an idea.
Get feedback from the IBM team and other customers to refine your idea.
Follow the idea through the IBM Ideas process.
Specific links you will want to bookmark for future use
Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.
IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.
ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.
Hi Mohammed,
You can specify a comma-separated list of protocols in the ssl.client.properties file, e.g. com.ibm.ssl.protocol=TLSv1.3,TLSv1.2 . The JDK will attempt to communicate with the higher level of the protocol if the server can support it, otherwise it will fall back on the earlier protocol version.
If this particular client should only ever communicate with servers that support TLSv1.3, you could simply supply com.ibm.ssl.protocol=TLSv1.3. This will cause the client to only attempt to use TLSv1.3. If the client ever attempted to connect to a server that doesn't support TLSv1.3, the client connection would fail by design, which might help you avoid connecting to a less-secure server / identify a server that needs to be upgraded to support TLSv1.3.
Under profiles properties you also have ssl.client.properties and we normally update the com.ibm.ssl.protocol=<protocol>. So when you define both TLS1.3 and TLS1.2 in custom then what should be updated for this property ? Kindly advise
This support has been added to WebSphere Application Server 8.5.5.21 and 9.0.5.11. For details on how to configure multiple protocols, see Step 14 on the following page:
https://www.ibm.com/docs/en/was-nd/8.5.5?topic=sc-creating-ssl-configuration
For example, you can create a "Custom protocol list" that contains both TLS 1.3 and TLS 1.2, allowing TLS 1.3 communication for clients that support it while also providing the ability to fall back to TLS 1.2 for other clients.
Should be a very high priority as TLS1.3 is now becoming more accepted and competing Application Servers have this current functionality.
Is there anything I could also consider in due consideration to this. I continue to observe the floatation on this inspite of environmental priorities. Didn't realise until this morning, this was moved to Idea Portal from the list of prioritized RFE from previous year.
It is imperative that a multiple JVMs within a WAS cell can use both TLS 1.3 SSL protocol with a 'fallback' capability to TLS 1.2
the current implementation approach recommended by IBM (as per https://www.ibm.com/support/pages/node/6421519 and https://www.ibm.com/support/pages/node/1077951 ) should enhanced as is it is unusable for a cell with a large number of nodes.
Agreed that backward compatibility is a top priority.
also need on WAS 9.0.
Across all platforms. Thanks, Abhishek
I concur. Thanks. Abhishek Kumar.