On Thu, 2009-10-29 at 23:48 +0200, Mircea Mihai Carasel wrote:
> 
>         
>         
>         There is no guarantee on when and how truststore is accessed.
>         Different JVM
>         can probably do it in a different ways. I'd rather not rely on
>         the fact
>         that it can be changed after process is started.
>         
>         Besides sipXconfig is not the only application that is using
>         sipXecs java
>         truststore. Ranga externalized truststore creation and we
>         should not mess
>         with it. Or mess with Ranga ;-)
>         
>         There is something to be said about having all CAs a single
>         place and
>         treated equally. I think we should just treat sipXecs java
>         truststore a
>         specific format in which java services consume trusted CA
>         certs. It's
>         content should be always consistent with what we have in
>         etc/sipxpbx/ssl/authorities
> 
> I think I found a reasonable solution to match all goals
> The sipXconfig TrustStore: authorities.jks gets created when
> initial-config script is run. 
> On the back-end initial-config runs gen-ssl-keys.sh that  actually
> creates authorities.jks
> The Tapestry InitialConfigService runs initial-config script,  that
> generates certificates, authorities.jks. Here we can safely add
> our code that copies the default CAs right after initial-config script
> run
> 
> Also, initial-config script is responsible with certificates
> generation for all locations in the cluster, so all locations will
> have a complete authorities.jks
> 
> What do you think - is that a reasonable solution ?

The certificates can be changed or added to at any time after the
initial installation.

Can we please have someone research how to get java applications to
import the certificates and authorities directly from the crt and key
files without all this conversion to truststore and keystore business?
I just do not believe that there isn't a way to do this.



_______________________________________________
sipx-dev mailing list [email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
sipXecs IP PBX -- http://www.sipfoundry.org/

Reply via email to