The "alias" attribute of the non-APR SSL connector seems to be case-sensitive. If I specify "classServer" for the alias I get: 28-Nov-2006 1:03:18 AM org.apache.tomcat.util.net.PoolTcpEndpoint acceptSocket SEVERE: Endpoint [SSL: ServerSocket[addr=0.0.0.0/0.0.0.0,port=0,localport=443]] ignored exception: java.net.SocketException: SSL handshake errorjavax.net.ssl.SSLException: No available certificate or key corresponds to the SSL cipher suites which are enabled. java.net.SocketException: SSL handshake errorjavax.net.ssl.SSLException: No available certificate or key corresponds to the SSL cipher suites which are enabled. at org.apache.tomcat.util.net.jsse.JSSESocketFactory.acceptSocket(JSSESocketFactory.java:113) at org.apache.tomcat.util.net.PoolTcpEndpoint.acceptSocket(PoolTcpEndpoint.java:407) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:70) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Unknown Source) Whereas if I use an alias of "classserver" (all lowercase) it works just fine. To make matters worse, the keystore was generated with an alias "classServer" so the lowercase is actually incorrect, and when you hit a webpage through SSL the certificate will indeed show "classServer" using camel-casing. My guess is that this indicates some sort of Tomcat or JDK bug. java.security.Keystore.setCertificateEntry() will actually throw an exception if one tries storing two keys whose aliases only differ by casing, which is why I say the alias has to be treated as case-insensitive. If it isn't fixable, this behavior should at least be documented in the SSL "howto" document beside the bold lettering which reminds readers that passwords are case-sensitive.
What version of JDK are you using? I've tried to repro this on both WinXP and Linux with JDK1.4.2 and JDK1.5 and both create keystore entries with downcased aliases. e.g.: C:\Documents and Settings\Chris>"c:\Program Files\Java\j2re1.4.2_13\bin\keytool. exe" -genkey -alias CamelCase -keystore keystore -keyalg RSA Produces: C:\Documents and Settings\Chris>"c:\Program Files\Java\j2re1.4.2_13\bin\keytool. exe" -list -v -keystore keystore Enter keystore password: changeit Keystore type: jks Keystore provider: SUN Your keystore contains 1 entry Alias name: camelcase Creation date: Nov 28, 2006 Entry type: keyEntry Certificate chain length: 1 Certificate[1]: Owner: CN=www.test.org, OU=Test, O="Test, Inc.", L=Seattle, ST=WA, C=US Issuer: CN=www.test.org, OU=Test, O="Test, Inc.", L=Seattle, ST=WA, C=US Serial number: 456c8054 Valid from: Tue Nov 28 10:30:44 PST 2006 until: Mon Feb 26 10:30:44 PST 2007 Certificate fingerprints: MD5: E7:D4:DA:25:0F:FD:FD:55:E7:DF:B2:21:F4:82:09:B2 SHA1: 2E:FE:63:F6:1C:0F:20:FF:96:18:20:D9:82:6D:A1:70:2A:69:C6:D2 Furthermore, specifying keyAlias="CamelCase" in the SSL connector config (TC 5.0.28 on WinXP) does not cause an error for me - the connector works fine with no complaint. I've also tested 5.0.28 and 5.5.20 on Linux (with both JDK1.4.2 and JDK1.5) with no observed problems.
I am using Java 1.6 b103. My keystore file was generated programmatically, not using keystore.exe. I'll attach it for you to try on your end. My configuration reads: keystoreFile="classServer.keystore" keystorePass="classServer" keystoreType="JCEKS" keyAlias="classserver" if you then modify keyAlias to "classServer" it gives the aforementioned exception.
Created attachment 19187 [details] The keystore file
OK, so the important part you left out of the original bug report was the keystore type. Using a JCEKS keystore I did replicate the issue. For some reason still unknown to me JSSE isn't tolerant of mismatched case in the alias name when using a JCEKS keystore (with plain old JKS seems it doesn't give a whit about case). The aliases in a JCEKS keystore are downcased internally just like in a JKS keystore, which is why changing your keyAlias to all lower case makes the problem go away (try a 'keygen -list -v' on your keystore and you'll see the alias name all lower case). I'm attaching patches for 5.0.x and 5.5.x that downcase the incoming alias name in the JSSEKeyManager constructor. This eliminates the issue in my testing.
ack...I meant 'keytool -list -v', not 'keygen -list -v'
Created attachment 19191 [details] Patch to tc50x to fix case-sensitivity issues with JCEKS keystore aliases
Created attachment 19192 [details] Patch to tc55x to fix case-sensitivity issues with JCEKS keystore aliases
Good catch! Thanks :)
It looks like then that this is a work-around for a Sun JDK bug. I have no objection to Chris' patch, other than that (since a KeyStore alias *should* be case-insensitive according to the javadocs).
It looks like someone in Sun already knows about this: http://blogs.sun.com/xuelei/entry/keystore_alias_case_sensitive_or but aside from this blog I can't find an official bug report or documentation that states they formally recognize the situation. Can you give me more information in order to report a bug with them or maybe you can file it yourself?
After thinking about this some more I'm starting to become -1 for the patch and more in favor of documenting this quirk. Universally downcasing the keyAlias input has the potential to break things down the road with keystores that may decide to support case-sensitivity. The frustrating part is that keytool generates/stores an all-lower alias regardless of what's specified case-wise at creation time, and running 'keytool -list -alias CamelCaseAliasName' finds and lists the aliased key just fine (even going so far as to display the camel-cased alias in the output): [chris@chris ~]$ keytool -list -v -keystore ./keystore -storetype JCEKS Keystore type: JCEKS Keystore provider: SunJCE Alias name: testalias Creation date: Nov 29, 2006 Entry type: keyEntry Certificate chain length: 1 --snip-- [chris@chris ~]$ keytool -list -v -keystore ./keystore -storetype JCEKS -alias TeStAlIaS Alias name: TeStAlIaS Creation date: Nov 29, 2006 Entry type: keyEntry Certificate chain length: 1 --snip--
I concur that updating the docs is the way to go. I have committed a fix to SVN and it will be included in 5.5.21 onwards.