3

(This is with Java 7.)

We are considering using javax.xml.soap.SOAPConnection and its associated stuff to do some relatively quick and dirty sending and receiving of SOAP messages.

However, the server this will be connecting uses certificates whose trust anchors are not in the default Java 7 truststore. We do not want to modify the default truststore but instead want to use a custom truststore.

If we were working at a lower level we could do stuff like getting an SSLContext, reinitializing it with the custom truststore, getting an SSLSocketFactory from it and so on.

But from what I can see in the SOAPConnection API and the APIs of associated classes there is no obvious way to change the SSLContext instance that SOAPConnection implementations use. I could change the default context but that changes things JVM-wide which is not what we want to have happen.

Are we just out of luck if we want to use SOAPConnection then? Any other libraries that will let you create SOAP requests relatively simply but let you specify the SSLContext or SSLSocketFactory to use?

QuantumMechanic
  • 13,795
  • 4
  • 45
  • 66

2 Answers2

2

Additional research shows pretty clearly that there is no way to do this within the SOAP classes -- they always use the JVM-wide defaults.

So I ended up using the approach in this answer where you make a custom trustmanager that is a composite of two trustmanagers -- one built from the default truststore and one built from the custom truststore -- and then inject that composite trustmanager into the default SSLContext.

Community
  • 1
  • 1
QuantumMechanic
  • 13,795
  • 4
  • 45
  • 66
0

Yes, it is possible. When running the java application pass trust-store/key-store details as following. Append following to your normal execution code. 

-Djavax.net.ssl.keyStore=myKS.jks -Djavax.net.ssl.keyStorePassword=123456  -Djavax.net.ssl.trustStore=myTS.jks   -Djavax.net.ssl.trustStorePassword=123456
Don Srinath
  • 1,565
  • 1
  • 21
  • 32
  • Thanks, but that doesn't really help the specific problem. As I said in my question "...but that changes things JVM-wide which is not what we want to have happen". Your proposed solution would change the truststore for the entire JVM. – QuantumMechanic Mar 12 '15 at 00:05