3

I have a service A that uses 1-way SSL and also 2-way SSL to make secure requests to service B. 1-way SSL is specified by Tomcat config, I provide keystoreFile, keystorePass, enable SSL, etc. 2-way SSL is implemented using JSSE on the client (service A). I know this could be done similarly in Tomcat server.xml too (example is here: http://blog1.vorburger.ch/2006/08/setting-up-two-way-mutual-ssl-with.html).

Part of my 1-way SSL Tomcat configuration:

<Connector port="securePort"
           scheme="https"
           secure="true"
           clientAuth="false"
           sslProtocol="TLS"
           SSLEnabled="true"
           keystoreFile="keystoreFile"
           keystorePass="keystorePass"
           keystoreType="keystoreType"
           ...
/>

Is there a way to specify both 1-way and 2-way (client side) SSL for the same service in Tomcat though. The challenge here is that I'm using 2 certificates (server and client one) on the same IP. Any hints?

agerrr
  • 1,253
  • 5
  • 14
  • 24

2 Answers2

1

When service A makes SSL requests with client-authentication to service B, it's not a server, it's a client. This has nothing to do with configuring client authentication on your Tomcat server where service A is running.

How your service A picks up its keystore settings (which it uses as a client) depends on how it's implemented and which libraries it uses to make these connections. It's not particularly different from any standalone client.

It's likely that it will at least pick up the default settings via the system properties. You can set the javax.net.ssl.keyStore (and related) system properties in the container (e.g. via JAVA_OPTS in catalina.sh or .bat). These settings will however be usable by all the webapps running within your container (but these settings won't be used by your <Connector/> configuration, if you've configured a different keystore there). Affecting all the webapps in your container like this may not always be desirable.

You could also have your keystore file where your client code can load it (e.g. somewhere under WEB-INF) and load this keystore as a resource stream to initialise the SSLContext used by your client library (if your client application can use such settings). Another possible way is to pass the keystore via JNDI. All this depends on how you want to configure the deployment of your service and how its code expects to be configured.

Bruno
  • 119,590
  • 31
  • 270
  • 376
0

I hope this is your scenario

Service A ---> 1 way SSL request to an endpoint Service B ---> 2 way SSL request to an endpoint Tomcat connector configured with 2 way SSL

Since tomcat connector is configured with 2 way SSL all incoming connections will be validated for handshake; this means if there is no key for 1 way ssl endpoint, handshake will fail. To overcome this you need to import 1 way ssl endpoint certificate into truststore

Now both 1 way and 2 way SSL will work

webjockey
  • 1,647
  • 2
  • 20
  • 28