Hi Chris, Thanks for replying. This is a different 3rd party service we're connecting to, but again it's a weird one because other tools work. I've included responses below prefixed with [DMC].
Regards, Diarmuid On 1 Sep 2015 20:57, "Christopher Schultz" <ch...@christopherschultz.net> wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Diarmuid, > > On 9/1/15 1:06 PM, dmccrthy wrote: > > I am having trouble getting Tomcat to load a truststore and > > keystore. This seems to be a basic configuration issue but I can't > > figure out what the problem is. Any insights would be gratefully > > received. > > > > The scenario is: > > > > * A 3rd party web application is deployed in Tomcat * The 3rrd > > party web application is making outbound HTTPS connections to a 3rd > > party web service * Tomcat JVM parameters are configured with > > > > -Djavax.net.ssl.trustStore=d:\Tomcat_ENV1\conf\tomcat_truststore.jks > > > > > - -Djavax.net.ssl.trustStorePassword=<snip> > > -Djavax.net.ssl.keyStore=d:\Tomcat_ENV1\conf\DWCHASSMESA002_keystore.j > ks > > > > > - -Djavax.net.ssl.keyStorePassword=<snip> > > The above will all act as defaults for the Java-based HTTP(s) connectors > . > > > -Dhttps.protocols="TLSv1" > > I don't believe this setting will do anything to Tomcat... at least, > it's not documented to do so. [DMC] Using this setting fixed our previous problem whereby outgoing HTTPS connections from Tomcat experienced SSL handshake issues when the handshake involved a negotiation from TLSv1.2 to TLSv1. Forcing the handshake to use TLSv1 resolved the problem. > > Let's focus on the keystore to start, and then get client certs working. > > How many certs do you have in your keystore? Did you specify an > "alias" for the key you'd like to use for the server? [DMC] Just the client public/private key pair needed for the MA handshake. > > For my money, I'd forget the system properties and use an explicit set > of configuration parameters on my <Connector> element. Can you post > your <Connector> configuration? > > [ > Looking back at this after writing the rest of this reply: are you > trying to host an HTTPS service *at all*? [DMC] No, I just tried using a HTTPS connector to see if Tomcat would load the trustore, and it did. But our scenario is for outgoing client HTTPS connections so it doesn't help that. If not, forget about the > keystore entirely because it's not necessary even a little bit. Just > in case it helps clear-up any confusion, here are when these two > things matter: > > 1. keystore - useful in 2 separate circumstances: > a. You are setting up an HTTPS listener when you > have a server certificate. The server's certificate and private key > go into the keystore, along with any other certificates you may > need or in order to form a chain of trust from your CA (e.g. > VeriSign) down to your own key > b. You are making outgoing connections to an HTTPS service and you > need to present a client certificate to the server [DMC] We're using scenario (b) > > 2. truststore - useful in 2 separate circumstances: > a. You have an HTTPS listener and you want to validate client > certificates of clients connecting TO YOU > b. You want to make outgoing connections to an HTTPS service > and YOU WANT TO VALIDATE THE SERVER'S CERTIFICATE against the > certs in your trust store. This allows you, for example, to > connect to a server with a self-signed cert, or one signed by > a CA that Java doesn't trust out-of-the-box > > You need to be very clear about what you are trying to do because it's > about as clear as mud right now. > ] [DMC] Sorry for the ambiguity, we're using scenario (b), outgoing client connections. The server cert is signed by GeoTrust but we don't have the full CA chain in the truststore, only the server cert. > > > 1) Openssl connects with MA parameters connects with no errors > > > > openssl s_client -tls1 -connect server-dns-name:15305 -CAfile > > server-cert-with-intermediate-and-root-in-one-file.cer -cert > > client-public-key.cer -key client-private-key.key -pass > > pass:client-private-key-password > > > > New, TLSv1/SSLv3, Cipher is AES256-SHA Server public key is 2048 > > bit Secure Renegotiation IS supported Compression: NONE Expansion: > > NONE No ALPN negotiated SSL-Session: Protocol : TLSv1 Cipher : > > AES256-SHA Session-ID: > > 893D24420CC89DED5E8E0E18C3D97270C3DD04B7A4B86602D5B34FC5E58DDE8F > > Session-ID-ctx: Master-Key: > > 89ABDA0ED080567E0CB8494AC236B107B7430A5487986BE7F3B468AF81B19BC27FD9C7 > D3EBC46280B9A608E5517D447C > > > > > Key-Arg : None > > PSK identity: None PSK identity hint: None SRP username: None Start > > Time: 1441125595 Timeout : 7200 (sec) Verify return code: 0 (ok) > > Is the other client connecting with SSL instead of TLS handshake? [DMC] I'll have to double check, but the key thing I've been focusing on is that the standalone Java client logs the fact that it's loading the trustore, checking the server cert against it, and serving up the client cert. Tomcat doesn't report any of that. > > > 2) A standalone Java program with a couple of lines to open a > > HTTPS connection to the 3rd party certificate works. This uses the > > same truststore and keystore 3) SoapUI works using the same > > truststore and keystore > > SoapUI as a server or as a client? Or both? [DMC] SoapUI as a client. > > > 4) Our 3rd party vendor can connect 5) I have googled various > > phrases like "Tomcat JVM not loading truststore". There are > > hundreds of examples involving HTTPS connectors and/or > > configuration errors. However we are not using server-side > > connectors and I can't see anything wrong with the configuration. > > What's a "server-side connector"? [DMC] Sorry, I mean our Tomcat instance isn't configured to accept inbound HTTPS requests and so isn't configured with a HTTPS connector. > > > The only potential hit I found for a defect was in Tomcat 6 > > http://tomcat.10.x6.nabble.com/configured-truststore-ignored-by-tomcat > - -td4986884.html > > > > 6) I tried installing a HTTPS connector in our Tomcat client > > instance. This then shows that the truststore is being loaded, but > > it is not used by the outbound HTTPS client connections > > How are you making an outbound client connection? Haven't we been over > this just this week? Tomcat doesn't make any outgoing connections, so > if you want to use a trust store you'll have to arrange for that trust > store to be used by whatever client connection you are making (e.g. > HttpsURLConnection, Apache hc-client, etc.). [DMC] It's a different scenario to the one you helped me with earlier this week. However you did advise on this a number of months ago. I forwarded your advice on customised HttpsURLConnection etc to our vendor and they built a plugin for their application which is deployed on Tomcat. For them, when they provide the truststore and keystore JVM settings, their Tomcat logs report that the trustore and keystore are loaded and MA handshake is successful. However, frustratingly, it doesn't work in our environment. Luckily it doesn't work in *any* of our environments so I have flexibility to try anything. > > 7) Tried playing with the format of the file paths by adding double > > quotes, changing the path separator to forward or backslash, moving > > the location of the files. But this didn't make any difference. > > > > "d:\Tomcat_ENV1\DWCHASSMESA002_keystore.jks" > > d:\Tomcat_ENV1\conf\DWCHASSMESA002_keystore.jks > > d:/Tomcat_ENV1/DWCHASSMESA002_keystore.jks > > My guess is you think the system property is doing something that it > just isn't doing. [DMC] Maybe. I'll have to ask our vendor for the source code as it's black box and I don't know how they actually implemented it. That will be tricky due to IP restrictions. I was hoping that there was something obviously wrong in the JVM settings or maybe a known issue. > > - -chris > -----BEGIN PGP SIGNATURE----- > Comment: GPGTools - http://gpgtools.org > > iQIcBAEBCAAGBQJV5gMUAAoJEBzwKT+lPKRYFuEQAKM6R7c0J4XR0TZ+vlMRy2/s > 4rB4YtP/CUr/iS6Zm4yCGcwlSabTDSiZ7fLLh8NwjOIQKmx8lP8IQobTZvSq6Pgj > YdrR15EikANwDeMyiImjYIQbmNSxb0ue6qMfc6pIBmkZBsADo4r5iBhNfqmuYli+ > geeFk/LyRu9iGqb62bPisZUe1UwIhgRVEVeBrUyYSLQBVPaiYMIy30XVf+SWfojA > V6xOy8yzL7fH37GCCBlVqPfHFvcpx6UvLJxwoItZDfen78xcPePAH4cwkNpgfa0z > Yrlz8KC/VG6g5H1eHFVjsv2CuPqn/AqZ+QAog0BiM5gpFjkS0ZU0o+wuY2cSXG/O > 08jDj6j083CYgdvwaACrTsbkbMsJAF9Aqwonu88/K7tMYjsYVIzI3iqtSfuPqOrY > FJeeyD64I5ACKiDCp1YTak86dge/NOkMA5sFK9d1uYsRNKkUy1A/cUKvBTfn/xiD > DcVny2Y4mqySJwMahCpL1+avt8mlIWTekf0j0kNoMOj9yRCBU3CQywSMZBIj0oem > STOhfVyKhF5PK6o+G0p63Uu42hvoxsb8PrmLGT8F8e99G+QkuA9+yK+LuXAn7MH/ > 1FcDS7O5G/0r+Qg3F3IBC//1CPlgF19AgwEJsW9mVcDQa8YtRaVjFzw6Zzvl932+ > UIFZ7vUtQy7W7JPu/K1g > =/SGI > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org >
