> > 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 ? Thanks. Mircea > > How about we pre-install some root CAs in etc/sipxpbx/ssl/authorities - the > rest will just happen automagically... > D. > > _______________________________________________ > 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/ >
_______________________________________________ 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/
