{"id":2921,"date":"2019-02-22T07:19:08","date_gmt":"2019-02-22T06:19:08","guid":{"rendered":"https:\/\/www.oradba.ch\/?p=2921"},"modified":"2019-02-22T08:14:35","modified_gmt":"2019-02-22T07:14:35","slug":"oud-12c-sslhandshakeexception-with-no-cipher-suites-in-common","status":"publish","type":"post","link":"https:\/\/www.oradba.ch\/wordpress\/2019\/02\/oud-12c-sslhandshakeexception-with-no-cipher-suites-in-common\/","title":{"rendered":"OUD 12c – SSLHandshakeException with “no cipher suites in common”"},"content":{"rendered":"\r\n

Recently I’ve update the java installation of my Oracle Unified Directory (OUD) 12.2.1.0.3 to the latest release. Java 1.8.0 update 202 to be exact (p28916775_180202_Linux-x86-64.zip<\/a>). Actually a piece of cake, I’ve done this a few times in the past. My Enterprise User Security (EUS) test environment is running in Docker. A container for the database and an other one for the directory server. Updates are usually straight forward. Stop the containers, rebuild the images with the latest software \/ patches and recreate the containers. But not this time. After restarting OUD, my EUS authentication seems to be broken. When trying to log in, I did get a friendly ORA-01017<\/em> error.<\/p>\r\n

 SQL> connect blofeld\/******** ERROR: ORA-01017: invalid username\/password; logon denied Warning: You are no longer connected to ORACLE. <\/pre> The control of the OUD access log file did show a cipher error. 
 [21\/Feb\/2019:06:21:27] CONNECT conn=5 from=172.20.0.3:50376 to=172.20.0.2:1636 protocol=LDAPS [21\/Feb\/2019:06:21:27] DISCONNECT conn=5 reason="I\/O Error" msg="no cipher suites in common" <\/pre><\/p>\r\n
Groundhog Day?<\/a> Endless loop? I knew I did fix this before. So I’ve checked again the solution in MOS Note 2397791.1<\/a> <\/em> and 2304757.1<\/a><\/em>. According to my understanding the java.security<\/em> file did look ok. The required legacy ciphers has been enabled by removing 3DES_EDE_CBC<\/em> from the list of jdk.tls.disabledAlgorithms<\/em>.
I finally did several tests with different Java versions (1.8.0 update 192 and 1.8.0 update 202) and different java.security<\/em> files. In the third attempt, database authentication with EUS and OUD in combination with Java 1.8.0 Update 202 also worked. The solution was rather simple. I did use the java.security<\/em> file from java 1.8.0 update 192 rather than using the new version and enable 3DES_EDE_CBC<\/em>. Running diff on both files has uncovered the culprits.<\/p>\r\n
 diff java.security java.security_202_default 645c645 < EC keySize < 224 --- > EC keySize < 224, 3DES_EDE_CBC, anon, NULL 700c700,701 < RC4_128, RC4_40, DES_CBC, DES40_CBC --- > RC4_128, RC4_40, DES_CBC, DES40_CBC, \\ > 3DES_EDE_CBC <\/pre> Or just the lines with jdk.tls.disabledAlgorithms<\/em>. 
 jdk.tls.disabledAlgorithms=SSLv3, RC4, DES, MD5withRSA, DH keySize < 1024, \\ EC keySize < 224, 3DES_EDE_CBC, anon, NULL <\/pre> A difference due to 3DES_EDE_CBC was to be expected, since I made the comparison to the standard file java.security and there this algorithm was not yet removed. But anon, NULL<\/em><\/p>\r\n
is new. The list of disabled algorithms jdk.tls.disabledAlgorithms<\/em> has been altered in Java 1.8.0 update 202. I could have seen this myself if I had looked through the release notes<\/a> before installing the software \ud83d\ude42 . There is a java bug related to this, see JDK-8211883<\/a> Disable anon and NULL cipher suites<\/em>. The problem is now that my EUS is working again, but it will use unsecure and legacy algorithms. A proper fix of this issue has to be implemented in the LDAP \/ EUS stack of the Oracle database binaries.<\/p>\r\n
Conclusion<\/h2>\r\n
First of all do read the release notes before updating production environments \ud83d\ude42 . As always in IT, do a little change on one side can unexpectedly break something on the other side. The solution presented here can only be a workaround, because we endanger security with legacy algorithms. Oracle should soon update the LDAP \/ EUS stack in the Oracle binaries.<\/p>\r\n