On Tue, Nov 22, 2016 at 3:41 PM, Christopher Schultz < ch...@christopherschultz.net> wrote:
> -----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 > > Hi Christopher, Thanks again for your input. Yes, I've managed to get it working with a separate keystore and truststore file as you've suggested. Ok, sanity check. I revisited this with unmodified apache-tomcat-8.5.#-windows-x64.zip files downloaded from the distribution site. In this case, all I did was unpack the ZIP content and change two files; server.xml and setclasspath.bat. In each case I added this one line to the top of setclasspath.bat set JAVA_OPTS=%JAVA_OPTS% -Djavax.net.ssl.trustStore="C:\keys\keystore.jsk" In tomcat 8.5.4 and 8.5.5 > server.xml, I updated the default connector to this: <Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" keystoreFile="C:\keys\keystore.jsk" keystorePass="changeit" keyAlias="tomcat" scheme="https" secure="true" SSLEnabled="true" clientAuth="false" /> In tomcat 8.5.8 > server.xml, I updated the default connector to this: <Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" scheme="https" secure="true" SSLEnabled="true"> <SSLHostConfig certificateVerification="none"> <Certificate certificateKeystoreFile="C:\keys\keystore.jsk" certificateKeystorePassword="changeit" certificateKeyAlias="tomcat" type="RSA" /> </SSLHostConfig> </Connector> On startup both tomcat 8.5.5 and 8.5.8 raise the error I've describe above: "InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty" Tomcat 8.5.4 starts up without error. Each was run in the same environment: OS Name: Windows 7 SP1 JVM Version: 1.8.0_102-b14 Sorry for beating this to death. I had to be sure I wasn't losing my mind. Regards, William Boyd
