-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 William,
On 11/23/16 3:56 PM, William Boyd wrote: > On Tue, Nov 22, 2016 at 3:41 PM, Christopher Schultz < > ch...@christopherschultz.net> wrote: > > 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 >> >> --------------------------------------------------------------------- >> >> 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, So just to confirm: using the keystore as a trust store doesn't work, but only with Tomcat 8.5.5 and later? Can you do this to your keystore and post the results? $ keytool -list -v -keystore c:\keys\keystore.jsk - -chris -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJYNufvAAoJEBzwKT+lPKRY4twP/jqtQA4QAUwbtMITaXXG+TsY mL5dd/xHL3fJTitHRzcxIcJYaHNOz/Wx7Cy0LNSVrw5d5sl9XcyA+tEu+0W/Os/m CkHfrfLqbcQ77L6eT8rWsRZmsXiLOMb5h6TiJtgvSumhe9uzsjKp1AzOu2oVnDLa UOEcX0E9WTkSxjymeI9GFgS9NHJd4yeljscjfJOGdV3yxqjsJleWnuaV4lj10Eg8 MhPSvog/5YrI7V4+kDCkWTtEyX72zUev9yoxKZ0mrn/LBCjyWLR5BOO4a6Tpn1sg QktPJpolo3fGm0rFBENC+hz1G47PbM4FDOfYm6RMlCNP5UoOCkbE0+BUYgtQGBmR G5PCS+6w1fKIpK9/Y1Drd3SbWBPrz47/o4RahWIOlipp6qIew4wnCySp1lWtoHeM MiNXpMbLISJbVfvx6q3idresuQk51AtWdtzLvCGKIFK25jUBINjrmFhhCn3I2zyq a1XtTliDi7cRxaK6ggXbaau9PzUD8YrdhO7kpjx1dK15pvqdvYtacfuaHZSEb7LB qQC3i8NHF2AwD2OHkQUKnXaHdT4ynxl3lKf9o5H09xq4oKYZTH4c3X3Pa+a1u7Cz f5WTa5c4QsMND+DpYwRFsWiCA1NunjL0D6QtbSTCBdn6kNN7WcPnE3C8PdvZN0YW vQW8F3DSJBOCeHV/ovR4 =D+w1 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
