Mircea Mihai Carasel wrote: > > > Solution proposed to: XX-6850 - known CAs needed in sipxconfig > truststore > > I am thinking to create a Java Main class that will receive as > parameter the location of a keystore file. > When run, all certificates from given keystore will be added to > sipXecs's keystore file (authorities.jks) > > java.security.KeyStore offers support for load/store certificates. > Also KeyStore.aliases() returns all available aliases found in the > given keystore file. > > If no keystore file will be sent as parameter, the java program will > copy all certificates found in the default jdk certificates file > (jssecacerts or cacerts) in the sipXecs's authorities.jks. > > This program will be executed by sipxconfig.sh just before > authorities.jks loading. > Also, it can be used if we will implement, at some point the UI > interface that will be used by the end user to copy certificates > from a given certificates file (proposed by Scott). > > On another thought about that - I think that there is absolutely no > problem to let sipXconfig handle default truststore adding to sipXconfig > truststore. > When sipxconfig.sh starts sipXconfig doing: > > exec $JavaCmd \ > $SystemProps \ > $JavaOpts \ > $TrustStoreOpts \ > -classpath "$Classpath" \ > org.mortbay.jetty.Server @sipxpbx.conf.dir@/sipxconfig-jetty.xml > > > It only puts TrustStore variables into JVM System properties and starts > Jetty. > > System properties variables for TrustStore are: > > -Djavax.net.ssl.trustStore=$TrustStore \ > -Djavax.net.ssl.trustStoreType=JKS \ > > -Djavax.net.ssl.trustStorePassword=changeit" > > The sipXconfig truststore is actually loaded only when needed and not by > Jetty start-up (org.mortbay.jetty.Server execution) > > So I think that we can create a dedicated Spring bean that will provide > functionality to add certificates to a truststore. We can make an > initialization task in sipXconfig that will copy default truststore > into ours. > > Any feedback is really appreciated. > Thanks, > Mircea >
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 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/
