On Thu, Nov 24, 2016 at 5:15 AM, Christopher Schultz < ch...@christopherschultz.net> wrote:
> -----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 > > Christopher, Correct: Once I set the javax.net.ssl.trustStore system property with the keystore I used in the server.xml, I get an error on startup and I can no longer reach https://localhost:8080/ on Tomcat 8.5.5+. This has worked on tomcat 5, 6, 7 up to 8.5.4. I've worked with all these version within the last 4 years. Here's my keystore listing Keystore type: JKS Keystore provider: SUN Your keystore contains 1 entry Alias name: tomcat Creation date: Nov 18, 2016 Entry type: PrivateKeyEntry Certificate chain length: 1 Certificate[1]: Owner: CN=localhost, OU=BBB, O=CO, L=City, ST=B, C=C Issuer: CN=localhost, OU=BBB, O=CO, L=City, ST=B, C=C Serial number: 1e6b3c7f Valid from: Fri Nov 18 09:51:21 PST 2016 until: Mon Nov 13 09:51:21 PST 2017 Certificate fingerprints: MD5: 8B:17:26:6C:BE:A0:A1:96:F9:72:11:4C:75:C3:74:39 SHA1: FC:A2:F9:0C:96:8E:8F:7C:6E:32:99:E9:A2:E2:DC:36:42:4F:A1:DC SHA256: 9F:DC:ED:1F:83:F7:62:25:C9:BE:EB:CA:0B:A1:37:0B:3F:80:4E:78:08:35:6A:D0:B2:B9:A9:E1:5F:D9:C9:7D Signature algorithm name: SHA256withRSA Version: 3 Extensions: #1: ObjectId: 2.5.29.14 Criticality=false SubjectKeyIdentifier [ KeyIdentifier [ 0000: BF D4 C6 24 AA 1E 65 43 8F 06 82 FA 3E F8 10 37 ...$..eC....>..7 0010: E0 36 7A C5 .6z. ] ] ******************************************* ******************************************* Regards Will
