On 28 August 2014 13:50, Konstantin Kolinko <knst.koli...@gmail.com> wrote:
> 2014-08-28 14:46 GMT+04:00 Javier Conti <javier.co...@gmail.com>: > > Hi all, > > > > in a Tomcat 7.0.53 container we are running an application which needs to > > use client certificates to connect to other webservices. > > This is currently done by configuring a keystore containing keys, > > certificates and CAs for the JVM (via command line arguments) as follows: > > > > -Djavax.net.ssl.keyStore=$keystore_path > > -Djavax.net.ssl.keyStorePassword=$keystore_password > > -Djavax.net.ssl.keyStoreType=jks > > -Djavax.net.ssl.trustStore=$keystore_path > > -Djavax.net.ssl.trustStorePassword=$keystore_password > > -Djavax.net.ssl.trustStoreType=jks > > > > This configuration works and requires no changes in the application code. > > However, since we have to pass those command line arguments in the > startup > > script somehow (including the password, which can be seen in the running > > process list), we are considering the various options to "cleanup" the > > configuration. In particular, we are investigating the possibility to > > configure all that in the server.xml configuration file. > > > > I've found many examples of Tomcat SSL configuration but all deal with > > configuring the "server side", not the "client side" for applications > > running inside the container. By the way, for the Connector we're using > the > > Native one with OpenSSL (and we could use x509 and RSA for the client > side > > too). > > > > Has anybody some pointers to documentation or examples? > > > > > You can configure a KeyStore and TrustStore programmatically, without > relying on system properties. Tomcat does so in its source code > (search for "import javax.net.ssl") > and tests (e.g. > test/org.apache.tomcat.util.net.TesterSupport.configureClientSsl()), > but passing those to your HTTP client depends on what client you are > using and on API of that client. > > You are not saying what client implementation you are using. It may be > better to ask on their mailing lists. > > While this could be feasible, our developers use various APIs and according to them it would be rather complicated to maintain the code should the client authentication be performed in it. However, the current implementation (a cert for the whole JVM) seems to be sufficient for our use case: we'd just like to take the password out of the command line arguments, so non privileged users performing other tasks on the servers wouldn't see it. Thanks, Javier > Best regards, > Konstantin Kolinko > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
