#1851 Keystore usage with multiple passwords

[Boris Fiuczynski]

Trying to use the SBLIM CIM client with a keystore.
The keystore was created with a password that is different from the password of the contained certificate.
This was thought to be the rather common setup but it was not possible to make it work with the SBLIM CIM client.
Looking at the SBLIM CIM client code it was found that it is only possible to have the keystore's password and the passwords of all contained certificates all the same.

org.sblim.cimclient.internal.http.HttpSocketFactory.loadKeystore()

            final KeyStore keystore = KeyStore.getInstance\(keystoreType\);
            keystore.load\(new FileInputStream\(keystorePath\), keystorePassword\);

            final KeyManagerFactory keymanagerfactory = KeyManagerFactory.getInstance\(
                    keyManagerAlgorithm, pSecurityProvider\);
            keymanagerfactory.init\(keystore, keystorePassword\);
            keyManager = keymanagerfactory.getKeyManagers\(\);

If you want to support certificates with different passwords in a keystore you would need to use this init method
public final void init(ManagerFactoryParameters spec)
together with the class javax.net.ssl.KeyStoreBuilderParameters which implements ManagerFactoryParameters as well as class that extends public abstract static class KeyStore.Builder, so one can supply all the necessary data like e.g. alias, password aso.

[Dave Blaschke]

For future consideration

[Dave Blaschke]

Classic ID #2957985

[Dave Blaschke]

Notes from Dave H:

If I went back and did it now, it does not look quite so daunting.  But unfortunately, me is swamped!
What it needs is:
The default KeyManager implementation just looks for the first keypair / server cert that will serve the purpose.  In the keystore.
You need to create your own KeyManager implementation to have control over which key is selected, if more than one.
So if you look in HttpSocketFactory.java...
The AllTrustManager, EmptyKeyManager and NoTrustManager are trivial examples of doing that.
Take EmptyKeyManager for example, since that is the one of the three that implements KeyManager (the other two: TrustManger).
there are some methods: getBlahAlias and chooseBlahAlias.
Those methods need to be implemented in a "true" implemetation of a KeyManager.  true meaning,... needs a factory, and what not.
I THINK you need to do that, vs. just the simple class Blah implements Blah.
That works for these trivial examples... which just return null for all the method calls.  But a real implementation would be.... you could probably describe it better than me.
By contrast, the KeyManager and TrustManager that do most of the work in the current implementation...  That is: the ones that are backed by the keystore & truststore files...
are using the default KeyManager & TrustManager implementations.  Simple but limited.
If you look at the loadKeystore() method, for example...
this block of code:
try {
    final KeyStore keystore = KeyStore.getInstance(keystoreType);
    fis = new FileInputStream(keystorePath);
    keystore.load(fis, keystorePassword);

    final KeyManagerFactory keymanagerfactory = KeyManagerFactory.getInstance(
                    keyManagerAlgorithm, pSecurityProvider);
    keymanagerfactory.init(keystore, keystorePassword);
    keyManager = keymanagerfactory.getKeyManagers();

That is a simple way to get a default KeyManager...
KeyManagerFactory.getInstance() actually gets the default KeyManager...
keymanagerfactory.init(keystore, keystorePassword)  inits it by loading the keystore file.
Then you have an implementation that supports all the methods... and you could call the getBlahAlias() methods on that also... but I think they will just return null... or maybe a not supported exception... I don't remember.
But if I understand correctly, the default KeyManager will not support those alias methods.
If it did, life would be simple and we could just call those methods on the existing implemention.
You might try calling those methods as a simple sanity check, make sure I'm understading this right...
But what I think we need here is:
Create a custom KeyManagerFactory, which will produce a custom implementation of KeyManager, ...
and truly implement the code behind those method calls.
Being not as well versed in Java as you... I'm not completely clear, which are the situations where one needs to create some sort of factory to produce an implementing class....
vs. when you can get away with just "class Blah implements Blah".
If the default keymanager implementation just provided this simple additional bit of functionality... it would be great.  If my understanding is correct, it does not.
But as I said, I forget what happened when I tried to call those actual methods on the default KeyManager.
I bookmarked this page as a possilbe example of how it is done:
http://javasecurity.wikidot.com/example-item-1

[Boris Fiuczynski]

Hi Dave,
I could not even remember that I had opened this bug until I was reading it.
Three years is a long time and to be honest I won't be much of a help on this bug any more.
You might want to reassign it to yourself if that is possible.

Cheers,
Boris

[Dave Blaschke]

Hi Boris - The bug is currently assigned to "nobody" since development work isn't underway (the two Daves were merely discussing possible solutions), you are receiving notifications because you are the creator all those years ago (-: Thanks.