Description of problem: In case when openssl converter for JSSE syntax doesn't know the specified cipher, the cipher isn't recognized even when it is enabled in used JVM. Version-Release number of selected component (if applicable): 6.3.0.ER10 How reproducible: always Steps to Reproduce: 1. start EAP with https connector including ssl configuration 2. set the cipher-suite to SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA (this cipher is checked to be enabled in [1] by default) Actual results: server doesn't start due BZ#1123342 causing openssl syntax parser doesn't recognized the cipher Expected results: server starts as it is valid JSSE cipher name in the running JDK Additional info: setting twice the cipher name separated by comma results in usage of JSSE without openssl syntax parser which makes the server start correctly (cipher-suite="SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA,SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA") [1] JDK 1.7 with security unlimited java version "1.7.0_51" Java(TM) SE Runtime Environment (build 1.7.0_51-b13) Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode)
So with the alias feature from the Tomcat rebase, this is supposed to be fixed once a new web build is integrated.
Should be fixed by component upgrade to 7.5.0.Beta3 1149776
Checked with EAP 6.4.0.DR6 and the issue is still valid. Note the issue is in org.apache.tomcat.util.net.jsse.JSSEUtils#resolveEnabledCipherSuite there is condition if (cipherSuites.length == 1) { // process as openssl syntax }
After looking into it a little bit more, the support for aliases doesn't fix this as no parsing is done based on the provided JSSE aliases (the JSSE aliases are only used as result of the enabled ciphers based on recognized ciphers during parsing)
Ok, I tried the reproducer, but the corresponding cipher might have been available in my OpenSSL, so the alias fixed it. Or I did something wrong.
I've a fix for it.
Created attachment 948975 [details] Fix for the issue Fix
Commited as r2527 in web. Thanks !
Verified in EAP 6.4.0.DR7