1and1 / compositejks Goto Github PK

This appears to be caused by reusing the Stream member. When storing the X509KeyManager array in the constructor instead and creating a new Stream on demand, this is fixed.

I encountered this when using the composite manager with a secure LDAP client connection.

the real potential of the library can be unlocked by improving the configuration and therefore making it a little bit more flexible. i guess it was created for internal usage and therefore made some assumptions like 1, 2 and not passing a password to SslContextUtils.buildMergedWithSystem, which is an issue i reported in #4.

since i needed something more flexible but also liked the basics it provided (CompositeX509KeyManager and CompositeX509TrustManager), i changed the entry point by leveraging a fluent api and step-builder. the classes can be found here. entry point is here. i also used default interface methods that use predefined default values without hardcoding them (example).

exemplary usage from our project.

other code example:

SslContextBuilder.builder()
                 .keyStoreFromFile("key store path without pwd")
                 .usingProtocol("SSL")
                 .usingSunX509()
                 .usingKeyManagerPassword("key manager pwd")
                 .buildMergedWithSystemAndSetDefault();

i would love to see my changes in this official repo. if desired, i can make a PR.

I have implemented the code for Composite-JKS as described for my java client. I used Maven to add the dependency and added the SslContextUtils.mergeWithSystem(getClass().getClassLoader().getResourceAsStream("trust.jks")); statement to my java client. When I execute this statement, I receive the following error:

java.security.NoSuchAlgorithmException: SunX509 KeyManagerFactory not available
at sun.security.jca.GetInstance.getInstance(GetInstance.java:171)
at javax.net.ssl.KeyManagerFactory.getInstance(KeyManagerFactory.java:12)
at com.oneandone.compositejks.SslContextUtils.getSystemKeyManager(SslContextUtils.java:85)
at com.oneandone.compositejks.SslContextUtils.buildMergedWithSystem(SslContextUtils.java:71)
at com.oneandone.compositejks.SslContextUtils.mergeWithSystem(SslContextUtils.java:27)
at com.oneandone.compositejks.SslContextUtils.mergeWithSystem(SslContextUtils.java:41)
at com.ibm.zss.client.boundary.ZssAPIResource.(ZssAPIResource.java:43)
at com.ibm.zss.client.boundary.ZssAPIService.(ZssAPIService.java:38)
at com.ibm.zss.client.ZssAPIServiceTest.setUpBeforeClass(ZssAPIServiceTest.java:32)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
at java.lang.reflect.Method.invoke(Method.java:508)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:678)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)

I found similar issues for other projects which indicate that the problem is that the SunX509 KeyManagerFactory is not available on a system running the IBM JVM. The solution was to allow the algorithm to be configurable. (See https://code.google.com/archive/p/javapns/issues/39 and https://code.google.com/archive/p/javapns/issues/41)

Is this option already configurable for CompositeJKS or can you add this support?

Hey,

i was looking into why the maven import wasn't working and found this error when i copied the classes over manually:

I think that
getSystemTrustgetSystemKeyManagerManager(X509Algorithm, keyStore),
should be
getSystemTrustManager(X509Algorithm, null),
in SslContextUtils.

I haven't tested this extensively yet but in a nutshell, lets assume there is a KeyStore holding two entries, one of type PrivateKeyEntry and the other of trustedCertEntry. Additionally the store is protected by a password.

Retrieving the KeyStore by calling one of the methods on KeyStoreLoader that takes a password everything works as expected.

However once trying to call SslContextUtils.buildMergedWithSystem(KeyStore) the method fails due to a missing password – namely the password of the PrivateKeyEntry (which happens to be different from the store password). Here's the stack:

Exception in thread "main" java.security.UnrecoverableKeyException: Cannot recover key
    at sun.security.provider.KeyProtector.recover(KeyProtector.java:328)
    at sun.security.provider.JavaKeyStore.engineGetKey(JavaKeyStore.java:146)
    at sun.security.provider.JavaKeyStore$JKS.engineGetKey(JavaKeyStore.java:56)
    at sun.security.provider.KeyStoreDelegator.engineGetKey(KeyStoreDelegator.java:96)
    at sun.security.provider.JavaKeyStore$DualFormatJKS.engineGetKey(JavaKeyStore.java:70)
    at java.security.KeyStore.getKey(KeyStore.java:1023)
    at sun.security.ssl.SunX509KeyManagerImpl.<init>(SunX509KeyManagerImpl.java:133)
    at sun.security.ssl.KeyManagerFactoryImpl$SunX509.engineInit(KeyManagerFactoryImpl.java:70)
    at javax.net.ssl.KeyManagerFactory.init(KeyManagerFactory.java:256)
    at com.oneandone.compositejks.SslContextUtils.getSystemKeyManager(SslContextUtils.java:86)

I've fixed this locally by not using CompositeX509KeyManager but just the default system key manager. But I'm not sure if this is to your intention :). If you want I'll make a PR …

current impl inits a keymanager for the customer keystore without setting the password even though the keystore might have one. because of this, java.security.UnrecoverableKeyException: Password must not be null occurs.

in our project, we fixed this by adding a param to the method. i think it's useful to apply it here, as well.