Bug 41051 - Keystore alias shouldn't be case sensitive
Keystore alias shouldn't be case sensitive
Status: RESOLVED FIXED
Product: Tomcat 5
Classification: Unclassified
Component: Connector:HTTP
5.0.17
PC Windows XP
: P2 normal (vote)
: ---
Assigned To: Tomcat Developers Mailing List
:
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2006-11-27 22:15 UTC by Gili
Modified: 2006-12-06 19:57 UTC (History)
0 users



Attachments
The keystore file (1.14 KB, application/octet-stream)
2006-11-28 12:26 UTC, Gili
Details
Patch to tc50x to fix case-sensitivity issues with JCEKS keystore aliases (431 bytes, patch)
2006-11-28 22:03 UTC, Chris Halstead
Details | Diff
Patch to tc55x to fix case-sensitivity issues with JCEKS keystore aliases (431 bytes, patch)
2006-11-28 22:03 UTC, Chris Halstead
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Gili 2006-11-27 22:15:58 UTC
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.
Comment 1 Chris Halstead 2006-11-28 11:06:35 UTC
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.
Comment 2 Gili 2006-11-28 12:25:46 UTC
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.
Comment 3 Gili 2006-11-28 12:26:30 UTC
Created attachment 19187 [details]
The keystore file
Comment 4 Chris Halstead 2006-11-28 22:00:50 UTC
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.
Comment 5 Chris Halstead 2006-11-28 22:01:53 UTC
ack...I meant 'keytool -list -v', not 'keygen -list -v'
Comment 6 Chris Halstead 2006-11-28 22:03:22 UTC
Created attachment 19191 [details]
Patch to tc50x to fix case-sensitivity issues with JCEKS keystore aliases
Comment 7 Chris Halstead 2006-11-28 22:03:45 UTC
Created attachment 19192 [details]
Patch to tc55x to fix case-sensitivity issues with JCEKS keystore aliases
Comment 8 Gili 2006-11-28 22:03:58 UTC
Good catch! Thanks :)
Comment 9 william.barker 2006-11-28 23:48:26 UTC
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).
Comment 10 Gili 2006-11-29 04:41:35 UTC
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?
Comment 11 Chris Halstead 2006-11-29 11:01:02 UTC
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--
Comment 12 Mark Thomas 2006-12-06 19:57:21 UTC
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.