System Property java.vendor changed between Java 11 and Java 17

[c-koell]

Hi..

I don't know where the best place is to bring that up so i try it here :-)

We are using Openliberty with IBM Semeru Runtime (OpenJ9) and db2jcc4 driver. After switching from java11 to java 17 we have seen following exception. Interne Ausnahme: java.sql.SQLException: Unsupported protocolSSL_TLSv2 It was really strange so we tried to find what the reason was for that.

The Exception comes from the driver and in it the classes are obfuscated. so not easy but after digging deeper and deeper i have found that in the com.ibm.db2.jcc.t4.w.class the VM Vendor name was checked. w.txt

With Java11 the java.vendor System-Property is "International Business Machines Corporation". So the driver used the SSLSocket.getEnabledProtocols() values for SSLScoket.setEnabledProtocols().

With Java17 the java.vendor System-Property is "IBM Corporation" and the driver uses "SSL_TLSv2" for SSLScoket.setEnabledProtocols() In sun.security.ssl.SSLSocketImpl the value will be validated and in sun.security.ssl.ProtocolVersion the value "SSL_TLSv2" is missing.

So this is one part of the problem. The trigger of the problem is the different java.vendor value :-) If i set a dummy value to java.vendor under java17 the jdbc connection works fine again.

I hope anyone can bring this to the right people within the ibm universe ...

[mstoodle]

Hi, the setting of the vendor property is something that's in flux. We've been documenting how this property is set since we first released Semeru Runtimes (Aug 2021) because we knew it was changing.

You can see the release notes for each release specifically mentions the vendor string: https://www.ibm.com/support/pages/semeru-runtimes-release-notes/.

With the April update release, coming shortly, both 11 and 17 (and 18, which should also be released by then) will consistently report the java vendor as "IBM Corporation".

[mstoodle]

I'll try to find the jdbc driver owners to highlight the change.

[pshipton]

The release notes at https://www.ibm.com/support/pages/semeru-runtimes-release-notes/ are wrong for Java 17. Java 17 has always used "IBM Corporation". The release note only applies to 8 & 11.

[davehobbs]

Release notes have been corrected for Version 17. The initial note for the first release, 17.0.1, says 'For Version 17 the java.vendor system property is set to "IBM Corporation".'

[c-koell]

Hi @mstoodle. Any news from the owners of the jdbc driver ? The only workaround for us at the moment is to set a java.vendor what is realy not good :-)

[mstoodle]

Hi @c-koell I agree with your assessment, though you may not have any other options until this is resolved :( . I have been discussing with them. I'll see if I can get them to engage directly here.

[BabitaSonavane]

Hi @mstoodle , @c-koell , I have tested the scenario myself and checked the code, It is confirmed that there is no issue with the java vendor. The actual issue is with sslVersion which is set by default to SSL_TLSv2 for IBM JDKs and db2 server configuration need to update it as it supports TLSv11. Please use the below command to avoid the problem you are facing. db2 update dbm cfg using SSL_VERSIONS TLSV12 or java/JDBC application you have to set the sslVersion property to TLSv1.1.

Regards Babita.

[kolmisra]

Hi, As mentioned above the workaround is to set the correct sslVersion JCC property to make this work.

If the SSL version is to be decided by default by the JCC driver then the current issue surfaced.

Old IBM JDK are marked java vendor as "IBM Corporation", based on the vendor driver decides what protocol to use. There is a difference between the IBM JDK and Open JDK implementation. As JDK 11 and JDK 17 are based on the Open JDK behavior and doesn't follow the older IBM JDK behavior caused this issue.

Let me put the JDK API what we use to identify the SSL protocol for IBM and non-IBM java. If Java team can confirm the checks for JDK 11 and JDK 17 so that we can design accordingly. If IBM Semeru team agree to set the code flow same as OpenJDK for IBM JDK 11 and JDK 17 then we can plan accordingly. If not and if there are any new support added for IBM JDk11 and JDK 17 please provide the details so that the same can be implemented.

For IBM JDK the by default the protocol decided based on below logic. Why the protocol "SSL_TLSv2" selected can be cleared looking below logic. As JDK 11 and JDK 17 doesnt support JSSEFIPS and sp800-131 caused the code to select "SSL_TLSv2" by default. And the sockets setEnabledProtocols or sslContext created based on "SSL_TLSv2". Where as for NON-IBM JDK the sockets setEnabledProtocols set as JDK default or sslContext created based on "SSL"

For IBM JDK String FIPS = System.getProperty ("com.ibm.jsse2.JSSEFIPS"); String sp800131=System.getProperty ("com.ibm.jsse2.sp800-131"); String[] protocol = new String[1]; if(sp800131 !=null && sp800131.equalsIgnoreCase ("strict")) protocol[0]= "TLSv1.2" ; else if (FIPS != null && FIPS.equalsIgnoreCase ("TRUE")) protocol[0]= "TLS" ; else if(isTLSV2Supported()) //javax.net.ssl.SSLContext.getInstance("TLSv1.2"); protocol[0]= "SSL_TLSv2"; else protocol[0]= "SSL_TLS"; return protocol;

For OpenJDK/NON- IBM JDK the logic of protocol selection is "SSL" default sslContext = javax.net.ssl.SSLContext.getInstance ("SSL");

or it sets the same protocol what it gets from socket protocol = socket.getEnabledProtocols(); socket.setEnabledProtocols (protocol);

[c-koell]

@kolmisra thanks for your detailed description. I see it the same way. @BabitaSonavane the problem is not the ssl handshake. The driver tries to set the wrong protocol on the socket. Therefore a java.sql.SQLException: Unsupported protocolSSL_TLSv2 will be thrown from the java runtime.

I have tried the workaround and set the sslVersion=TLSv1.2 and all works fine again. I hope you will fix the default bahaviour so a java upgrade will not break existing configurations.

[kolmisra]

@c-koell , regarding the fix in default behavior are we in an agreement that the protocol set should be like the OpenJDK when it comes to IBM JDK 11 and JDK 17 ? If yes will plan to change the code accordingly.

[c-koell]

@kolmisra yes from my point of view there should be no difference between OpenJDK and IBM JDK Semeru.

[kolmisra]

Thanks . Current workaround is to set the sslVersion property. I will fix jcc to support the JDK behavior same as OpenJDK.

[AdamBrousseau]

Cross posting It appears New Relic checks java.vendor too https://discuss.newrelic.com/t/feature-idea-java-new-relic-agent-doesnt-work-with-openj9-17/170671/7 Users are now failing using 11.0.15 too.

com.newrelic ERROR: Unable to start the New Relic Agent. Your application will continue to run but it will not be monitored.
java.lang.NoClassDefFoundError: com.newrelic.agent.bridge.datastore.RecordSql

User was able to use the workaround.

[pshipton]

This is the workaround referred by the previous comment https://github.com/eclipse-openj9/openj9/issues/14950#issuecomment-1105797810. You can have multiple -javaagent arguments, this one should be first.

[Randy-Unicom]

We are having the same problem with the JCC driver when moving to IBM Semeru 11.0.16.0 from IBM Semeru 11.014.1. The same work arounds work for the issue we see, both the -javaagent work around and the setting of sslVersion=TLSv1.2.

@kolmisra When will a fix be ready for the JCC driver? Our product embeds both the JCC driver and IBM Semeru, so this poses an issue for our upcoming fix pack... We can certainly document the work around, but a fix would be much better.

[kolmisra]

This is already fixed for 11.5.8.0 Release. The release is planned on 19th Oct. You can update the driver once its released.