Another alternative would be to remove the auto generation of a self-signed cert from the server runtime and require the use of the admin's favorite key management tool and we document the use of keytool or course IBM environments have keyman as an equivalent.
We would have to provide some scripting around that for standing up a test/demo environment easily. On Mon, Sep 15, 2014 at 5:19 PM, larry mccay <larry.mc...@gmail.com> wrote: > I've considered this, Vinay. > > I'm not sure the value of providing a sun based implementation given that > the classes are going away and that the implementation will not build or > run in an IBM JDK environment. > > Another option would be to shell out to an assumed installation of openssl > - I believe others in the ecosystem do this - such as Ambari. > > On Mon, Sep 15, 2014 at 5:10 PM, Vinay Shukla <vinayshu...@gmail.com> > wrote: > >> We can perhaps consider taking a provider approach and have cert >> generation >> be able to done with both providers (Sun & BouncyCastle) >> and any other impls in future? >> >> On Mon, Sep 15, 2014 at 2:06 PM, larry mccay <larry.mc...@gmail.com> >> wrote: >> >> > All - >> > >> > Pascal Oliva has filed KNOX-242 and provided a patch contribution for >> > replacing the use of the sun/oracle proprietary classes with the use of >> the >> > Bouncy Castle library. >> > >> > With reported plans from oracle to limit or block access to the old sun >> > classes it seems that we need to make a move here anyway. >> > >> > Pascal's motivation appears to be that these classes also do not exist >> in >> > the IBM JVM environment and therefore Knox does not build or run. >> > >> > I have applied his patch and have tested the server and CLI create-cert >> > behavior and it seems to work compatibly. >> > >> > I intend to commit this work later tonight unless someone can >> articulate a >> > compelling reason not to. >> > >> > thanks, >> > >> > --larry >> > >> > >
