Why does NewSunX509 algorithm prefixes aliases with numbers

843811

After the discussion here: http://forums.sun.com/thread.jspa?threadID=5388459 and this article: http://www.ibm.com/developerworks/java/library/j-customssl/ I was able to override axis 1 socket factory to send a specific certificate from a keystore with multiple valid certificates.

But, while I was still experiencing with the code, I used the NewSUNX509 algorithm when getting an instance of the KeyManagerFactory

KeyManagerFactory.getInstance("NewSunX509");

When I did that, I could not find the alias I wanted anymore. When stepping in the code I saw that the aliases returned by

keyManager.getClientAliases(keyType, issuers);

had some numbers prefixed to them, like "8.the_alias_as_want". Since I was using String.equals() to check for the alias, it failed the verification.

I could fix that by using String.indexof() or use regular expressions to ignore the prefixed numbers, but now I start worrying how portable this code is. If each algorithm does its own alias manipulation, there's no way I can make the code generic enough to be run with any algorithm. Is there a reason why NewSunX509 adds those numbers to the aliases? It looks weird to me.

Edited by: daniel.mfreitas on May 27, 2009 11:31 AM

EJP

After that discussion I don't know why you're doing this at all, but from the source code, quoted without permission:

 * The new X509 key manager implementation. The main differences to the
 * old SunX509 key manager are:
 *  . it is based around the KeyStore.Builder API. This allows it to use
 *    other forms of KeyStore protection or password input (e.g. a
 *    CallbackHandler) or to have keys within one KeyStore protected by
 *    different keys.
 *  . it can use multiple KeyStores at the same time.
 *  . it is explicitly designed to accomodate KeyStores that change over
 *    the lifetime of the process.
 *  . it makes an effort to choose the key that matches best, i.e. one that
 *    is not expired and has the appropriate certificate extensions.
 *
 ...
    // a unique id is included to allow us to reliably cache entries
    // between the calls to getCertificateChain() and getPrivateKey()
    // even if tokens are inserted or removed

843811

I wouldn't expect you to understand why I need (or needed) to do this, as you don't know about the projects I'm working on.

I wish there is another way to achieve it, though . Caching is an implementation detail and shouldn't affect the way the public interface works, in my opinion. The client aliases do not have numbers on them.

Imagine if database vendors messed with your data to implement indexes or constraints ...

"What's your name?"
"5423.Bob."
"That's a funny name..."
"Yeah, they used WeirdDB back then."

Edited:

By the way. I just downloaded the jdk source code. I hope I can contribute in some way.

Edited by: daniel.mfreitas on May 28, 2009 7:44 AM

843811

Why don't you just use the "SunX509" implementation? It may be true the "NewSunX509" implementation has some features that are not documented as well as they should be, but you had to expect something different when you tried "New" and you figured it out for yourself anyway.

843811

I actually don't even need to use this approach anymore as we now keep only one certificate in the keystore. Now it's just a matter of learning a little bit more about the API. In the future we might need to have multiple certificates in a keystore and have to select a specific one.

It would be good if we could make caching work and still leave the alias (at least the ones obtained from the public api) untouched. By quickly looking at the code I didn't see much relation between the map where they keep the cache and the getClientAliases() method. getClientAliases() does not even look at the cache (but it seems it stores values in the cache, I might be mistaken though). Instead, the method transforms all aliases by prefixing the numbers before returning from the method call.

I'm not getting the whole picture yet. I think I will debug inside the code to see how it works and ask around to see in which scenario the cached aliases would make the difference.

Thanks for all the input. I will post my findings if I ever get there for the sake of documenting it for other who might be interested.