-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
William,
On 11/16/16 1:06 PM, William Boyd wrote:
> On Tue, Nov 15, 2016 at 2:17 PM, <john.e.gr...@wellsfargo.com>
> wrote:
>>
>> I haven't been following this super closely, but it sounds like
>> there is a lot of trial and error going on so let me try to
>> explain how the key stores and trust stores are used.
>
> Will: Ultimately I am trying to determine why a configuration that
> worked since Tomcat 5, stopped working in Tomcat 8.5.5 so I can
> explain the issue to operations. We used to be able to use the
> same keystore for both keystoreFile in the Connector and the
> javax.net.ssl.trustStore system property but that no longer works.
> The only variable is Tomcat. This will affect many TEST and PROD
> sites.
>
>> The system properties affect things like outgoing connections
>> that use SSL, like https calls. javax.net.ssl.trustStore would
>> contain the certs for the CAs that sign the backend server's
>> cert. javax.net.ssl.keyStore would come into play if the backend
>> uses mutual authentication/client authentication/2-way SSL. If
>> that's required by the backend, you would put your own cert and
>> private key in the key store. I think you can combine them all
>> into one file, but usually they're kept separate.
>>
>
> Will: Thanks, I think this explains our need for
> javax.net.ssl.trustStore. The system I'm supporting is using axis
> jaxrpc to communicate between WARs over HTTPS within Tomcat. These
> connections in axis must be the reason we require
> javax.net.ssl.trustStore.
Exactly. I think one of the confusing things here has been the
confusion in my mind between exceptions you are getting on the client
and exceptions being thrown on the server (which, oddly enough, is a
client).
In the absence of any specific Java-level calls to set the trust store
for a SOAP connection, Axis is going to use the system-wide trust
store which is in fact set using the javax.net.ssl.trustStore system
property.
Nothing in Tomcat's configuration can set this for you.
So why does the Tomcat upgrade seem to have broken something that's
been working? I can think of two possibilities:
1. The system property was set in CATALINA_HOME/bin/setenv.sh in your
old Tomcat installation, and nobody copied that file to the new
installation. Solution: use CATALINA_BASE/bin/setenv.sh instead of
CATALINA_HOME/bin/setenv.sh
2. The system property was set in
CATALINA_BASE/conf/catalina.properties in your old installation and
nobody copied that configuration to the new installation. Solution:
look at a diff between those two config files and fix the differences
as appropriate.
>> The Tomcat connector parameters are for Tomcat's use when serving
>> https connections to clients. I don't think they have any impact
>> on outgoing calls. The key store would contain Tomcat's cert and
>> private key. Likewise the trust store would contain the certs of
>> the CA or CAs who sign your client's certs if you have mutual
>> auth enabled. It might also be required to form the chain
>> linking the server's cert to the CA. In that case, though, I
>> might be inclined to putting the CA in the key store itself for
>> simplicity. According to the docs, Tomcat will fall back to the
>> system properties if the connector doesn't explicitly them.
>>
>
> Will: Sorry I'm confused by the last bit here. Using "keytool
> -genkeypair" I have a file containing a self-signed certificate yet
> I now need to export, than import that cert into a separate
> truststore in order for our servers to work. If this is to spec
> and Tomcat it tightening up the rules I could understand.
I don't think anything really changed between Tomcat 8.5.4 and
8.5.5... I think your configuration must have changed slightly.
If you need a webapp in server A to contact server B using Axis, then
you'll need:
serverA$ keytool -genkeypair -alias X -keystore serverA.jks
serverA$ keytool -exportcert -alias X -keystore serverA.jks \
> trusted.crt
serverA$ keytool -importcert -alias X -keystore truststore.jks \
< trusted.crt
Tell Tomcat on server A to use serverA.jks as its keystore. No other
configuration is required. Specifically, setting trustStoreFile on the
<Connector> accomplishes nothing.
Tell the JVM on server B to use truststore.jks as the trust store,
using a system property if absolutely necessary.
(I *really* don't like dong this, because it sets the trust store for
the whole JVM and everything it might need to trust. I much prefer to
explicitly-set the trust store for a particular connection. That might
require re-writing code which is expensive and risky, but you are
better-off in the long-run.)
If you need a webapp in server B to contact server A using Axis, thn
you need to reverse the process above so that A trusts B's cert and B
trusts A's cert. If both servers are using the same cert, then both
servers only need to trust the single cert, of course.
> Will: I’m guessing its AXIS that can’t find the CA in the trust
> store. Regarding IE, I can clarify, the error occurs in a servlet
> which returns the message to the browser.
The way a client trust store works is that the client will make a
connection and obtain the certificate chain from the server. It starts
with the first certificate in the chain and, if it's trusted, it will
allow the connection to be established. If not, it moves on to the
next certificate in the chain until it either trusts a certificate or
runs out of certificates to check for trust, at which point, it will
fail to establish a connection.
If Axis can't connect, check the trust store it's using against the
certificate(s) being presented by the server. If they don't match, fix
that (usually by re-building the trust store from the certificate
presented by the server). If they do match, something weird is happening
.
> So I think I understand why I need javax.net.ssl.trustStore and
> keystoreFile configured to get our system working. Thank you for
> making me walk through it in more detail.
So, things are in fact working again?
> The question remains why does Tomcat 8.5.5 no longer allow me to
> use a JKS file as a trustStore and raise the following exception at
> startup?
>
>
>
> 16-Nov-2016 09:02:03.195 SEVERE [main]
> org.apache.coyote.AbstractProtocol.init
>
> Failed to initialize end point associated with ProtocolHandler
> ["https-openssl-nio-8001"]
>
> java.lang.IllegalArgumentException:
> java.security.InvalidAlgorithmParameterException: the trustAnchors
> parameter must be non-empty
Which configuration was this, specifically?
> 2. adding truststoreFile="C:\keystore\myAlias.cer"
This isn't a keystore, so the "Invalid keystore format" error you got
makes sense.
> 3. adding truststoreFile="C:\keystore\keystore.jsk"
This one? The error you are getting is probably because the keystore
itself contains a single entry which is a key/cert combination and ...
at this point we've reached the limit of my knowledge of keystores
(which pretty much ends with me saying "#$%& IT!" and switching to a
vanilla PEM-formatted certificate, etc.).
By importing the certificate *only* into a separate keystore (trust
store!) puts it into a different format which is acceptable to the
Java API that is underlying everything, here.
Why did this work before? I have absolutely no idea. I'm still
thinking that there is a subtle change in your configuration from
version to version (8.5.4 -> 8.5.5, right?), and that Tomcat's code
isn't involved.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJYNNexAAoJEBzwKT+lPKRYEecQAKrAJU6+NAQMFDKGw1YESyOQ
MTp9GUW+tXVX/v2h7ayVh8bfHPOTSZShJ1KMbdi9LQWXMNalfLaJSbaQIB6j5vNM
E2GhoScWJ9AJ3nwiqD/knxMkXA2LEzN/z/JhqOH+RY3ql+YjDsc0v8lK9jdhjqPB
p6nBXjDV5unD2p7HFLUoDtCVISilPLWE2o78qNVfKWM113U3eRG81P3lUyACLROV
TthII61IQocOqwehDFzCDf0zlMnB06Mi/l5iCvQDGYfmFYh/CHDyNA4bFDin8zak
jd9/5asTeZdEeNJ3+cU6ffjV+BVJwTPMpFRyj1hVGwLyS9FcCEBu9el2iiL+v2zQ
4fgRX0iXbrPvQgXDggvLE1pZoWHQNy7ONMzEEwTvCnPNLNL88VWM3WMeztWh9O6z
TK4GClQGZcXHo3LFd1baQ8+lBsaCWF/NAYdBMwa+p4P0z9NBHf1RaBGeFBKhmY/H
0h7Pf8lJDPfRSlLjc6SX/U6nmyGHrCZ8LeJ3BxeTieJBcDDM2Leh8gyxacF+hFfT
EMj8duIMgbfsBtvtQDMDxG3elQ5ZRPclkjhCSe3hVykWk7Ayx5XVd3HUOHzK6Z3E
F4xpOgPBT5eaELpO8XqyUQL2x2M6BV6TxefXpKUw5p5PLdozbJH3C4KDTlugF3Yd
i1X2Ubn8gAAqqBa+LMAV
=GvhM
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
