tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konstantin Kolinko <>
Subject Re: Possible issue with Tomcat 7.0.27 SSL keystore configuration
Date Fri, 06 Jul 2012 17:43:03 GMT
2012/7/6 Arun John (arujohn) <>:
> Hi Mark,
> Thanks for your quick response.
> I should have been a little more clear. That snip was copied when I had only one key
entry in my keystore and both the passwords were the same.
> Now coming to the actual issue. As long as there is only one key in the keystore, it
works perfectly fine and I can provide different passwords for keystore and private key using
keystorePass and keyPass options and it works flawlessly. But the issue seems to be happening
when I have multiple key entries and that I store those key entries using different passwords.
Then it throws the error
> For eg :
> I have a keystore named servercerts. The keystore password is "changed"
> In the keystore, I have 3 private keys (tomcatcert, adminuicert, wscert)
> The password for tomcatcert is "fortomcat"
> The password for adminuicert is "foradminui"
> The password for wscert is "forwebserver"
> Now I configured my server.xml to be
>          <Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"
>  maxThreads="150" scheme="https" secure="true" clientAuth="false"
>  sslProtocol="TLS"  keyAlias ="adminuicert" keyPass="foradminui"
>  keystoreFile="bin/servercerts" keystorePass="changed"/>
> Then when I start my tomcat, I run into this error. To be specific, with single key entry
in the keystore everything works fine. With multiple key entries and different passwords,
it throws the error.
> Am I missing something here. Can you confirm whether it works fine in the above scenario.
I use jdk1.6.0_32 to generate the keystore.
> Regards,
> Arun
> -----Original Message-----
> From: Mark Thomas []
> Sent: Friday, July 06, 2012 3:55 PM
> To: Tomcat Users List
> Subject: Re: Possible issue with Tomcat 7.0.27 SSL keystore configuration
> On 06/07/2012 10:04, Arun John (arujohn) wrote:
>> Hi Team,
>> I am currently facing an issue with SSL configuration in Tomcat
>> 7.0.27. I have one keystore with three private keys to be used by
>> different components . The password I am using for the keystore file
>> is "changed". The requirement is such that I should be using three
>> different password for the three private keys I store in my keystore.
>> I have configured my server.xml to allow https connections, basically
>> modified the connectors.
>> <Connector port="7443" protocol="HTTP/1.1" SSLEnabled="true"
>> maxThreads="150" scheme="https" secure="true" clientAuth="false"
>> sslProtocol="TLS"  keyAlias ="adminuicert"
>> keystoreFile="bin/.keystore" keystorePass="changed"/>
> You have not specified the password for the key. Why would you expect this to work?
>> I am running into an issue here. When I configure different key
>> passwords for my private keys different from my keystore password I am
>> running into an exception saying it cannot recover the key. I have
>> attached the catalina log.  I am not finding a way to provide the
>> private key password in the server.xml

Looking at the code where exception comes from,
in JSSESocketFactory#getKeyManagers(...)
        KeyManagerFactory kmf = KeyManagerFactory.getInstance(algorithm);
        String keyPass = endpoint.getKeyPass();
        if (keyPass == null) {
            keyPass = keystorePass;
        kmf.init(ks, keyPass.toCharArray());

        kms = kmf.getKeyManagers();

The "kmf.init(..)" call to Java API fails. At this point the key alias
has not come into play yet.

Looking at implementation of the Java APIs mentioned in your
stacktrace, I should say that this is limitation of those.  This Sun
implementation of KeyManagerFactory iterates over all keys of
keystore, creating a Key for each and initializing some internal
hashtable.  As you encountered, it fails fatally if any of the keys is
not readable with the provided password.

The call to kmf.init(..) cannot be avoided, as the key manager factory
is unusable without it.

Maybe it is possible to find more clever implementation of
KeyManagerFactory somewhere that does not read the keys that it does
not need. Or a different implementation of KeyStore, that serves as a
proxy and hides unneeded keys in KeyStore#aliases() enumeration.

Anyway, the easiest workaround at this point is to use 3 different
keystores each containing a single key. The path to keystore is
configurable, as you may note.

Best regards,
Konstantin Kolinko

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message