Re: 8.5.4 to 8.5.5 SSL Issue

[William Boyd]

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,
>   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  accomplishes nothing.
> >
> > Tell the JVM on server B to use 

Re: 8.5.4 to 8.5.5 SSL Issue

[Christopher Schultz]

-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,
  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  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
>