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.

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.

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.

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?

This is ASF Bugzilla: the Apache Software Foundation bug system. In case
of problems with the functioning of ASF Bugzilla, please contact
bugzilla-admin@apache.org.
Please Note: this e-mail address is only for reporting problems
with ASF Bugzilla. Mail about any other subject will be silently
ignored.