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
> 

Re: 8.5.4 to 8.5.5 SSL Issue

[William Boyd]

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

Re: 8.5.4 to 8.5.5 SSL Issue

[Christopher Schultz]

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

Re: 8.5.4 to 8.5.5 SSL Issue

[William Boyd]

On Tue, Nov 15, 2016 at 2:17 PM, <john.e.gr...@wellsfargo.com> wrote:

>
>
> > -Original Message-
> > From: William Boyd [mailto:william.b...@gmail.com]
> > Sent: Tuesday, November 15, 2016 3:44 PM
> > To: Tomcat Users List
> > Subject: Re: 8.5.4 to 8.5.5 SSL Issue
> >
> > On Tue, Nov 15, 2016 at 10:50 AM, Christopher Schultz <
> > ch...@christopherschultz.net> wrote:
> >
> > > -BEGIN PGP SIGNED MESSAGE-
> > > Hash: SHA256
> > >
> > > William,
> > >
> > > On 11/14/16 7:18 PM, William Boyd wrote:
> > > > First, I'd like to thank everyone for the help.
> > > >
> > > > Is it now safe to say that the behaviour we've been taking advantage
> > > > of is undocumented and will no long be supported?
> > > >
> > > > Also, for those that hit this thread and need to get HTTPS working
> > > > with a *self-signed* certificate in a dev environment...
> > > >
> > > > Here's what worked for me: 1. Copy
> > > > %JAVA_HOME%\jre\lib\security\cacerts some place (say C:\keystore) 2.
> > > > Create a *self-signed* certificate with %JAVA_HOME%\bin\keytool
> > > > -genkeypair -keyalg RSA -alias myAlias -keystore
> > > > "C:\keystore\keystore.jsk" -storepass changeit -validity 360
> > > > -keysize 2048 -dname
> > > > CN=localhost,OU=OrgUnit,O=Org,L=City,ST=State,C=Country 3. Export
> > > > the myAlias certificate with %JAVA_HOME%\bin\keytool -export -alias
> > > > myAlias -keystore C:\keystore\keystore.jsk -rfc -file
> > > > C:\keystore\myAlias.cer 4. Import the myAlias certificate into your
> > > > copy of cacerts with: %JAVA_HOME%\bin\keytool -import -alias myAlias
> > > > -keystore C:\keystore\cacerts -file C:\keystore\myAlias.cer 5. Add
> > > > this to setclasspath.bat in tomcat:
> > > > set JAVA_OPTS=%JAVA_OPTS%
> > > > -Djavax.net.ssl.trustStore="C:\keystore\cacert" 6. In server.xml,
> > > > add these attributes to the Connector element
> > > > keystoreFile="C:\keystore\keystore.jsk" keystorePass="changeit"
> > > > keyAlias="myAlias" scheme="https" secure="true" SSLEnabled="true"
> > > > clientAuth="false" sslProtocol="TLS"
> > > >
> > > > Now you should be good to go in with HTTPS in Tomcat 8.5.5 +
> > >
> > > This is exactly what I suggested, except that you set the trust store
> > > using a system property instead of using truststoreFile in the
> > > . You do not need to duplicate the JRE's trust store. You
> > > only need your own single certificate in your local truststore.
> > >
> > > Can you use keystoreFile and truststoreFile separately pointing to
> > > those files and re-check that it works? Perhaps Tomcat chokes when
> > > using the same file for both. That's what I'd like to verify.
> > >
> > > - -chris
> > > -BEGIN PGP SIGNATURE-
> > > Comment: GPGTools - http://gpgtools.org
> > > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> > >
> > >
> > iQIcBAEBCAAGBQJYK1kHAAoJEBzwKT+lPKRYa48P/jl6hWa1mj5HCnawJZ3mHbjX
> > >
> > ADdXYl45aym/E6QV/n99XYVYG2q+ZN9w0XDVP54lQhQhcgOUtCiPbTHEcYSYdwr
> > U
> > >
> > kLYMc3Ge8Jt7/zDMvem+pKYkHMvyHbspVqSujZ4uJ3Ozr9mYD89hSFgxqG0iYSE+
> > > 5c0pvz1nW4Pt1F4A/+WETkL4Y5Xrq1Vn1LSAxAZoYiU/o93nVos7etIBUO9E430+
> > > GihbhvkpS/yBitvrir/YacvWauBxpi30wR++6ZNAhpzlb+j90dk3i6iPcDO6K1f2
> > > SNeqZATJDlXyU1hEksW4UxWLhtUeekqmJEiEqqWCYxNz9lwJG9f4kILUrzsZexlu
> > >
> > FmP2o4IxWTBcgOUs5Km5DlfYwogJmlRhqQoOlg2JOpv+KIb67DX+PuY6bhGomDf
> > f
> > >
> > YQ03Y7WQcjNZ/uOIoadAkXxKRaRHmuz2KkPYwgDutOgxtJV1jNxTT3A3znGT1cW
> > N
> > >
> > yekjXHOpe2FdXnaoG0X7mTpvx5AhkHN9mRdW+5/ZBpPzUN0M7zy8oBEpLtZKfrT
> > J
> > > k40Xz70DnNxBP3XS/1w7DJ1H3/FBxNdatVVbbcJ/+lS/NiS4Gn2kMAZgrCuZrUsn
> > >
> > FdpdyCwq3VLJ2X9LVBR03rJOyPIiybANNjfhPpiEMC9uQu2ENm4A4Hm1p/cXdpo3
> > > 2J2O1AQA7tfew10t3F4K
> > > =a+Um
> > > -END PGP SIGNATURE-
> > >
> > > -
> > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > > For additional commands, e-mail: users-h...@tomcat.apache.org
> > >
> > >
> > Hi Christopher,
> >
> &g

RE: 8.5.4 to 8.5.5 SSL Issue

[John.E.Gregg]

> -Original Message-
> From: William Boyd [mailto:william.b...@gmail.com]
> Sent: Tuesday, November 15, 2016 3:44 PM
> To: Tomcat Users List
> Subject: Re: 8.5.4 to 8.5.5 SSL Issue
> 
> On Tue, Nov 15, 2016 at 10:50 AM, Christopher Schultz <
> ch...@christopherschultz.net> wrote:
> 
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> >
> > William,
> >
> > On 11/14/16 7:18 PM, William Boyd wrote:
> > > First, I'd like to thank everyone for the help.
> > >
> > > Is it now safe to say that the behaviour we've been taking advantage
> > > of is undocumented and will no long be supported?
> > >
> > > Also, for those that hit this thread and need to get HTTPS working
> > > with a *self-signed* certificate in a dev environment...
> > >
> > > Here's what worked for me: 1. Copy
> > > %JAVA_HOME%\jre\lib\security\cacerts some place (say C:\keystore) 2.
> > > Create a *self-signed* certificate with %JAVA_HOME%\bin\keytool
> > > -genkeypair -keyalg RSA -alias myAlias -keystore
> > > "C:\keystore\keystore.jsk" -storepass changeit -validity 360
> > > -keysize 2048 -dname
> > > CN=localhost,OU=OrgUnit,O=Org,L=City,ST=State,C=Country 3. Export
> > > the myAlias certificate with %JAVA_HOME%\bin\keytool -export -alias
> > > myAlias -keystore C:\keystore\keystore.jsk -rfc -file
> > > C:\keystore\myAlias.cer 4. Import the myAlias certificate into your
> > > copy of cacerts with: %JAVA_HOME%\bin\keytool -import -alias myAlias
> > > -keystore C:\keystore\cacerts -file C:\keystore\myAlias.cer 5. Add
> > > this to setclasspath.bat in tomcat:
> > > set JAVA_OPTS=%JAVA_OPTS%
> > > -Djavax.net.ssl.trustStore="C:\keystore\cacert" 6. In server.xml,
> > > add these attributes to the Connector element
> > > keystoreFile="C:\keystore\keystore.jsk" keystorePass="changeit"
> > > keyAlias="myAlias" scheme="https" secure="true" SSLEnabled="true"
> > > clientAuth="false" sslProtocol="TLS"
> > >
> > > Now you should be good to go in with HTTPS in Tomcat 8.5.5 +
> >
> > This is exactly what I suggested, except that you set the trust store
> > using a system property instead of using truststoreFile in the
> > . You do not need to duplicate the JRE's trust store. You
> > only need your own single certificate in your local truststore.
> >
> > Can you use keystoreFile and truststoreFile separately pointing to
> > those files and re-check that it works? Perhaps Tomcat chokes when
> > using the same file for both. That's what I'd like to verify.
> >
> > - -chris
> > -BEGIN PGP SIGNATURE-
> > Comment: GPGTools - http://gpgtools.org
> > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> >
> >
> iQIcBAEBCAAGBQJYK1kHAAoJEBzwKT+lPKRYa48P/jl6hWa1mj5HCnawJZ3mHbjX
> >
> ADdXYl45aym/E6QV/n99XYVYG2q+ZN9w0XDVP54lQhQhcgOUtCiPbTHEcYSYdwr
> U
> >
> kLYMc3Ge8Jt7/zDMvem+pKYkHMvyHbspVqSujZ4uJ3Ozr9mYD89hSFgxqG0iYSE+
> > 5c0pvz1nW4Pt1F4A/+WETkL4Y5Xrq1Vn1LSAxAZoYiU/o93nVos7etIBUO9E430+
> > GihbhvkpS/yBitvrir/YacvWauBxpi30wR++6ZNAhpzlb+j90dk3i6iPcDO6K1f2
> > SNeqZATJDlXyU1hEksW4UxWLhtUeekqmJEiEqqWCYxNz9lwJG9f4kILUrzsZexlu
> >
> FmP2o4IxWTBcgOUs5Km5DlfYwogJmlRhqQoOlg2JOpv+KIb67DX+PuY6bhGomDf
> f
> >
> YQ03Y7WQcjNZ/uOIoadAkXxKRaRHmuz2KkPYwgDutOgxtJV1jNxTT3A3znGT1cW
> N
> >
> yekjXHOpe2FdXnaoG0X7mTpvx5AhkHN9mRdW+5/ZBpPzUN0M7zy8oBEpLtZKfrT
> J
> > k40Xz70DnNxBP3XS/1w7DJ1H3/FBxNdatVVbbcJ/+lS/NiS4Gn2kMAZgrCuZrUsn
> >
> FdpdyCwq3VLJ2X9LVBR03rJOyPIiybANNjfhPpiEMC9uQu2ENm4A4Hm1p/cXdpo3
> > 2J2O1AQA7tfew10t3F4K
> > =a+Um
> > -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, I'm glad to hear I'm heading in the right direction. :)
> 
> I tested some more configuration.
> 
> Firstly, I removed the system property but retained these Connector attributes
> 
>keystoreFile="C:\keystore\keystore.jsk" keystorePass="changeit"
> keyAlias="myAlias"
>scheme="https" secure="true" SSLEnabled="true" clientAuth="false"
> sslProtocol="TLS"
> 
> Then I tried the following:
> 
> 1. adding truststoreFile="C:\keystore\cacerts"

Re: 8.5.4 to 8.5.5 SSL Issue

[William Boyd]

On Tue, Nov 15, 2016 at 10:50 AM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> William,
>
> On 11/14/16 7:18 PM, William Boyd wrote:
> > First, I'd like to thank everyone for the help.
> >
> > Is it now safe to say that the behaviour we've been taking
> > advantage of is undocumented and will no long be supported?
> >
> > Also, for those that hit this thread and need to get HTTPS working
> > with a *self-signed* certificate in a dev environment...
> >
> > Here's what worked for me: 1. Copy
> > %JAVA_HOME%\jre\lib\security\cacerts some place (say C:\keystore)
> > 2. Create a *self-signed* certificate with %JAVA_HOME%\bin\keytool
> > -genkeypair -keyalg RSA -alias myAlias -keystore
> > "C:\keystore\keystore.jsk" -storepass changeit -validity 360
> > -keysize 2048 -dname
> > CN=localhost,OU=OrgUnit,O=Org,L=City,ST=State,C=Country 3. Export
> > the myAlias certificate with %JAVA_HOME%\bin\keytool -export -alias
> > myAlias -keystore C:\keystore\keystore.jsk -rfc -file
> > C:\keystore\myAlias.cer 4. Import the myAlias certificate into your
> > copy of cacerts with: %JAVA_HOME%\bin\keytool -import -alias
> > myAlias -keystore C:\keystore\cacerts -file
> > C:\keystore\myAlias.cer 5. Add this to setclasspath.bat in tomcat:
> > set JAVA_OPTS=%JAVA_OPTS%
> > -Djavax.net.ssl.trustStore="C:\keystore\cacert" 6. In server.xml,
> > add these attributes to the Connector element
> > keystoreFile="C:\keystore\keystore.jsk" keystorePass="changeit"
> > keyAlias="myAlias" scheme="https" secure="true" SSLEnabled="true"
> > clientAuth="false" sslProtocol="TLS"
> >
> > Now you should be good to go in with HTTPS in Tomcat 8.5.5 +
>
> This is exactly what I suggested, except that you set the trust store
> using a system property instead of using truststoreFile in the
> . You do not need to duplicate the JRE's trust store. You
> only need your own single certificate in your local truststore.
>
> Can you use keystoreFile and truststoreFile separately pointing to
> those files and re-check that it works? Perhaps Tomcat chokes when
> using the same file for both. That's what I'd like to verify.
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJYK1kHAAoJEBzwKT+lPKRYa48P/jl6hWa1mj5HCnawJZ3mHbjX
> ADdXYl45aym/E6QV/n99XYVYG2q+ZN9w0XDVP54lQhQhcgOUtCiPbTHEcYSYdwrU
> kLYMc3Ge8Jt7/zDMvem+pKYkHMvyHbspVqSujZ4uJ3Ozr9mYD89hSFgxqG0iYSE+
> 5c0pvz1nW4Pt1F4A/+WETkL4Y5Xrq1Vn1LSAxAZoYiU/o93nVos7etIBUO9E430+
> GihbhvkpS/yBitvrir/YacvWauBxpi30wR++6ZNAhpzlb+j90dk3i6iPcDO6K1f2
> SNeqZATJDlXyU1hEksW4UxWLhtUeekqmJEiEqqWCYxNz9lwJG9f4kILUrzsZexlu
> FmP2o4IxWTBcgOUs5Km5DlfYwogJmlRhqQoOlg2JOpv+KIb67DX+PuY6bhGomDff
> YQ03Y7WQcjNZ/uOIoadAkXxKRaRHmuz2KkPYwgDutOgxtJV1jNxTT3A3znGT1cWN
> yekjXHOpe2FdXnaoG0X7mTpvx5AhkHN9mRdW+5/ZBpPzUN0M7zy8oBEpLtZKfrTJ
> k40Xz70DnNxBP3XS/1w7DJ1H3/FBxNdatVVbbcJ/+lS/NiS4Gn2kMAZgrCuZrUsn
> FdpdyCwq3VLJ2X9LVBR03rJOyPIiybANNjfhPpiEMC9uQu2ENm4A4Hm1p/cXdpo3
> 2J2O1AQA7tfew10t3F4K
> =a+Um
> -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, I'm glad to hear I'm heading in the right direction. :)

I tested some more configuration.

Firstly, I removed the system property but retained these Connector
attributes

   keystoreFile="C:\keystore\keystore.jsk" keystorePass="changeit"
keyAlias="myAlias"
   scheme="https" secure="true" SSLEnabled="true" clientAuth="false"
sslProtocol="TLS"

Then I tried the following:

1. adding truststoreFile="C:\keystore\cacerts" to my Connector and got the
following error in an IE11 browser
   Caught Exception (javax.net.ssl.SSLHandshakeException:
sun.security.validator.ValidatorException:
   PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException:
   unable to find valid certification path to requested target): ;
   nested exception is: javax.net.ssl.SSLHandshakeException:
sun.security.validator.ValidatorException:
   PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException:
   unable to find valid certification path to requested target

2. adding truststoreFile="C:\keystore\myAlias.cer" to my Connector and got
the following error at startup
   15-Nov-2016 12:34:57.379 SEVERE [main]
org.apache.coyote.AbstractProtocol.init
   Failed to initialize end point associated with ProtocolHandler
["https-openssl-nio-8001"]
   java.lang.IllegalArgumentException: java.io.IOException: Invalid
keystore format
at
org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:103)
   :
   Caused by: java.io.IOException: Invalid keystore format
at
sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:658)
at

Re: 8.5.4 to 8.5.5 SSL Issue

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

William,

On 11/14/16 7:18 PM, William Boyd wrote:
> First, I'd like to thank everyone for the help.
> 
> Is it now safe to say that the behaviour we've been taking
> advantage of is undocumented and will no long be supported?
> 
> Also, for those that hit this thread and need to get HTTPS working
> with a *self-signed* certificate in a dev environment...
> 
> Here's what worked for me: 1. Copy
> %JAVA_HOME%\jre\lib\security\cacerts some place (say C:\keystore) 
> 2. Create a *self-signed* certificate with %JAVA_HOME%\bin\keytool
> -genkeypair -keyalg RSA -alias myAlias -keystore
> "C:\keystore\keystore.jsk" -storepass changeit -validity 360 
> -keysize 2048 -dname
> CN=localhost,OU=OrgUnit,O=Org,L=City,ST=State,C=Country 3. Export
> the myAlias certificate with %JAVA_HOME%\bin\keytool -export -alias
> myAlias -keystore C:\keystore\keystore.jsk -rfc -file
> C:\keystore\myAlias.cer 4. Import the myAlias certificate into your
> copy of cacerts with: %JAVA_HOME%\bin\keytool -import -alias
> myAlias -keystore C:\keystore\cacerts -file
> C:\keystore\myAlias.cer 5. Add this to setclasspath.bat in tomcat: 
> set JAVA_OPTS=%JAVA_OPTS% 
> -Djavax.net.ssl.trustStore="C:\keystore\cacert" 6. In server.xml,
> add these attributes to the Connector element 
> keystoreFile="C:\keystore\keystore.jsk" keystorePass="changeit" 
> keyAlias="myAlias" scheme="https" secure="true" SSLEnabled="true" 
> clientAuth="false" sslProtocol="TLS"
> 
> Now you should be good to go in with HTTPS in Tomcat 8.5.5 +

This is exactly what I suggested, except that you set the trust store
using a system property instead of using truststoreFile in the
. You do not need to duplicate the JRE's trust store. You
only need your own single certificate in your local truststore.

Can you use keystoreFile and truststoreFile separately pointing to
those files and re-check that it works? Perhaps Tomcat chokes when
using the same file for both. That's what I'd like to verify.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJYK1kHAAoJEBzwKT+lPKRYa48P/jl6hWa1mj5HCnawJZ3mHbjX
ADdXYl45aym/E6QV/n99XYVYG2q+ZN9w0XDVP54lQhQhcgOUtCiPbTHEcYSYdwrU
kLYMc3Ge8Jt7/zDMvem+pKYkHMvyHbspVqSujZ4uJ3Ozr9mYD89hSFgxqG0iYSE+
5c0pvz1nW4Pt1F4A/+WETkL4Y5Xrq1Vn1LSAxAZoYiU/o93nVos7etIBUO9E430+
GihbhvkpS/yBitvrir/YacvWauBxpi30wR++6ZNAhpzlb+j90dk3i6iPcDO6K1f2
SNeqZATJDlXyU1hEksW4UxWLhtUeekqmJEiEqqWCYxNz9lwJG9f4kILUrzsZexlu
FmP2o4IxWTBcgOUs5Km5DlfYwogJmlRhqQoOlg2JOpv+KIb67DX+PuY6bhGomDff
YQ03Y7WQcjNZ/uOIoadAkXxKRaRHmuz2KkPYwgDutOgxtJV1jNxTT3A3znGT1cWN
yekjXHOpe2FdXnaoG0X7mTpvx5AhkHN9mRdW+5/ZBpPzUN0M7zy8oBEpLtZKfrTJ
k40Xz70DnNxBP3XS/1w7DJ1H3/FBxNdatVVbbcJ/+lS/NiS4Gn2kMAZgrCuZrUsn
FdpdyCwq3VLJ2X9LVBR03rJOyPIiybANNjfhPpiEMC9uQu2ENm4A4Hm1p/cXdpo3
2J2O1AQA7tfew10t3F4K
=a+Um
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: 8.5.4 to 8.5.5 SSL Issue

[William Boyd]

On Tue, Oct 25, 2016 at 2:08 AM, Kreuser, Peter 
wrote:

> Dear all,
>
> > On Sun, Oct 23, 2016 at 3:15 PM, Christopher Schultz <
> > ch...@christopherschultz.net> wrote:
> >
> > > -BEGIN PGP SIGNED MESSAGE-
> > > Hash: SHA256
> > >
> > > William,
> > >
> > > On 10/21/16 6:08 PM, William Boyd wrote:
> > > > On Fri, Oct 21, 2016 at 2:05 PM, Christopher Schultz <
> > > > ch...@christopherschultz.net> wrote:
> > > >
> > > > William,
> > > >
> > > > On 10/21/16 4:37 PM, William Boyd wrote:
> > >  Hello,
> > > 
> > >  I am attempting to upgrade from Tomcat 7 to 8.5.6. Everything
> > >  was working great until I enabled SSL with a self-signed
> > >  certificate. I am able to recreated the issue on 8.5.5. I
> > >  finally had to down graded to 8.5.4 to get SSL working with
> > >  identical configuration and cert.
> > > 
> > >  I want to be sure that this is not a known issue and that I'm
> > >  not doing something wrong before I create a bug report.
> > > 
> > >  Server version:Apache Tomcat/8.5.5 64-bit OS Name:
> > >  Windows 7 JVM Version:   1.8.0_102-b14
> > > 
> > >  The cert was generated with this command: keytool
> > >  -genkeypair -keyalg RSA -alias tomcat -keystore
> > >  "C:/keys/keystore.jsk" -storepass changeit -validity 360
> > >  -keysize 2048 -dname
> > >  CN=localhost,OU=ITS,O=Co,L=City,ST=AB,C=CA
> > > 
> > >  Configuration includes adding
> > >  -Djavax.net.ssl.trustStore=c:/keys/keystore.jsk to JAVA_OPTS
> > > >
> > > > I think this might be the problem. Tomcat doesn't use
> > > > javax.net.ssl.trustStore except as a backup in case you haven't
> > > > specified a trust store in your . You have pointed that
> > > > system property at a keystore, not a trust store. Technically,
> > > > they are the same format, but they are used for different things.
> > > >
> > > > If you need that for making your own outgoing TLS connections then
> > > > leave it in there and we'll try to get it to work, otherwise it's
> > > > just confusing and might cause Tomcat to do weird things.
> > > >
> > >  and using this connector config
> > > 
> > >   > >  connectionTimeout="6" maxThreads="200"
> > >  minSpareThreads="4" enableLookups="false" compression="on"
> > >  server="Apache" scheme="https" secure="true"
> > >  SSLEnabled="true" keystoreFile="c:/keys/keystore.jsk"
> > >  keystorePass="changeit" keyAlias="tomcat" clientAuth="false"
> > >  sslProtocol="TLS"/>
> > > >
> > > > Looks good so far.
> > > >
> > >  Here is the exception I get at startup
> > > 
> > >  13-Oct-2016 15:05:17.309 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 at
> > >  org.apache.tomcat.util.net.AbstractJsseEndpoint.
> createSSLContext(Ab
> > > str
> > > >
> > > 
> > > actJsseEndpoint.java:103)
> > > 
> > > 
> > > > at
> > >  org.apache.tomcat.util.net.AbstractJsseEndpoint.
> initialiseSsl(Abstr
> > > act
> > > >
> > > 
> > > JsseEndpoint.java:81)
> > > 
> > > 
> > > > at
> > > > org.apache.tomcat.util.net.NioEndpoint.bind(NioEndpoint.java:244)
> > >  at
> > >  org.apache.tomcat.util.net.AbstractEndpoint.init(
> AbstractEndpoint.j
> > > ava
> > > >
> > > 
> > > :866)
> > > 
> > > 
> > > > at
> > >  org.apache.tomcat.util.net.AbstractJsseEndpoint.init(
> AbstractJsseEn
> > > dpo
> > > >
> > > 
> > > int.java:213)
> > > 
> > > 
> > > > at
> > > > org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:575)
> > >  at
> > >  org.apache.coyote.http11.AbstractHttp11Protocol.init(
> AbstractHttp11
> > > Pro
> > > >
> > > 
> > > tocol.java:65)
> > > 
> > > 
> > > > at
> > > > org.apache.catalina.connector.Connector.initInternal(
> Connector.java:9
> > > >
> > > >
> > > 44)
> > >  at
> > >  org.apache.catalina.util.LifecycleBase.init(
> LifecycleBase.java:107)
> > > 
> > > 
> > > >
> > > 
> > > at
> > >  org.apache.catalina.core.StandardService.initInternal(
> StandardServi
> > > ce.
> > > >
> > > 
> > > java:549)
> > > 
> > > 
> > > > at
> > > > org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
> > > 
> > > >
> > > at
> > >  org.apache.catalina.core.StandardServer.initInternal(
> StandardServer
> > > .ja
> > > >
> > > 
> > > va:873)
> > > 
> > > 
> > > > at
> > > > org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
> > > 
> > > >
> > > at org.apache.catalina.startup.Catalina.load(Catalina.java:606) at
> > >  org.apache.catalina.startup.Catalina.load(Catalina.java:629)
> > >  at 

Re: 8.5.4 to 8.5.5 SSL Issue

[William Boyd]

On Sun, Oct 23, 2016 at 3:15 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> William,
>
> On 10/21/16 6:08 PM, William Boyd wrote:
> > On Fri, Oct 21, 2016 at 2:05 PM, Christopher Schultz <
> > ch...@christopherschultz.net> wrote:
> >
> > William,
> >
> > On 10/21/16 4:37 PM, William Boyd wrote:
>  Hello,
> 
>  I am attempting to upgrade from Tomcat 7 to 8.5.6. Everything
>  was working great until I enabled SSL with a self-signed
>  certificate. I am able to recreated the issue on 8.5.5. I
>  finally had to down graded to 8.5.4 to get SSL working with
>  identical configuration and cert.
> 
>  I want to be sure that this is not a known issue and that I'm
>  not doing something wrong before I create a bug report.
> 
>  Server version:Apache Tomcat/8.5.5 64-bit OS Name:
>  Windows 7 JVM Version:   1.8.0_102-b14
> 
>  The cert was generated with this command: keytool
>  -genkeypair -keyalg RSA -alias tomcat -keystore
>  "C:/keys/keystore.jsk" -storepass changeit -validity 360
>  -keysize 2048 -dname
>  CN=localhost,OU=ITS,O=Co,L=City,ST=AB,C=CA
> 
>  Configuration includes adding
>  -Djavax.net.ssl.trustStore=c:/keys/keystore.jsk to JAVA_OPTS
> >
> > I think this might be the problem. Tomcat doesn't use
> > javax.net.ssl.trustStore except as a backup in case you haven't
> > specified a trust store in your . You have pointed that
> > system property at a keystore, not a trust store. Technically,
> > they are the same format, but they are used for different things.
> >
> > If you need that for making your own outgoing TLS connections then
> > leave it in there and we'll try to get it to work, otherwise it's
> > just confusing and might cause Tomcat to do weird things.
> >
>  and using this connector config
> 
>    connectionTimeout="6" maxThreads="200"
>  minSpareThreads="4" enableLookups="false" compression="on"
>  server="Apache" scheme="https" secure="true"
>  SSLEnabled="true" keystoreFile="c:/keys/keystore.jsk"
>  keystorePass="changeit" keyAlias="tomcat" clientAuth="false"
>  sslProtocol="TLS"/>
> >
> > Looks good so far.
> >
>  Here is the exception I get at startup
> 
>  13-Oct-2016 15:05:17.309 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 at
>  org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(Ab
> str
> >
> 
> actJsseEndpoint.java:103)
> 
> 
> > at
>  org.apache.tomcat.util.net.AbstractJsseEndpoint.initialiseSsl(Abstr
> act
> >
> 
> JsseEndpoint.java:81)
> 
> 
> > at
> > org.apache.tomcat.util.net.NioEndpoint.bind(NioEndpoint.java:244)
>  at
>  org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.j
> ava
> >
> 
> :866)
> 
> 
> > at
>  org.apache.tomcat.util.net.AbstractJsseEndpoint.init(AbstractJsseEn
> dpo
> >
> 
> int.java:213)
> 
> 
> > at
> > org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:575)
>  at
>  org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11
> Pro
> >
> 
> tocol.java:65)
> 
> 
> > at
> > org.apache.catalina.connector.Connector.initInternal(Connector.java:9
> >
> >
> 44)
>  at
>  org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
> 
> 
> >
> 
> at
>  org.apache.catalina.core.StandardService.initInternal(StandardServi
> ce.
> >
> 
> java:549)
> 
> 
> > at
> > org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
> 
> >
> at
>  org.apache.catalina.core.StandardServer.initInternal(StandardServer
> .ja
> >
> 
> va:873)
> 
> 
> > at
> > org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
> 
> >
> at org.apache.catalina.startup.Catalina.load(Catalina.java:606) at
>  org.apache.catalina.startup.Catalina.load(Catalina.java:629)
>  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
>  Method) at
>  sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImp
> l.j
> >
> 
> ava:62)
> 
> 
> > at
>  sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcc
> ess
> >
> 
> orImpl.java:43)
> 
> 
> > at java.lang.reflect.Method.invoke(Method.java:498)
>  at
>  org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:311)
> 
> 
> at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:494)
>  Caused by: java.security.InvalidAlgorithmParameterException:
>  the trustAnchors parameter must be non-empty at
>  

Re: 8.5.4 to 8.5.5 SSL Issue

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

William,

On 10/21/16 6:08 PM, William Boyd wrote:
> On Fri, Oct 21, 2016 at 2:05 PM, Christopher Schultz < 
> ch...@christopherschultz.net> wrote:
> 
> William,
> 
> On 10/21/16 4:37 PM, William Boyd wrote:
 Hello,
 
 I am attempting to upgrade from Tomcat 7 to 8.5.6. Everything
 was working great until I enabled SSL with a self-signed
 certificate. I am able to recreated the issue on 8.5.5. I
 finally had to down graded to 8.5.4 to get SSL working with
 identical configuration and cert.
 
 I want to be sure that this is not a known issue and that I'm
 not doing something wrong before I create a bug report.
 
 Server version:Apache Tomcat/8.5.5 64-bit OS Name: 
 Windows 7 JVM Version:   1.8.0_102-b14
 
 The cert was generated with this command: keytool
 -genkeypair -keyalg RSA -alias tomcat -keystore
 "C:/keys/keystore.jsk" -storepass changeit -validity 360
 -keysize 2048 -dname 
 CN=localhost,OU=ITS,O=Co,L=City,ST=AB,C=CA
 
 Configuration includes adding 
 -Djavax.net.ssl.trustStore=c:/keys/keystore.jsk to JAVA_OPTS
> 
> I think this might be the problem. Tomcat doesn't use 
> javax.net.ssl.trustStore except as a backup in case you haven't 
> specified a trust store in your . You have pointed that 
> system property at a keystore, not a trust store. Technically,
> they are the same format, but they are used for different things.
> 
> If you need that for making your own outgoing TLS connections then 
> leave it in there and we'll try to get it to work, otherwise it's
> just confusing and might cause Tomcat to do weird things.
> 
 and using this connector config
 
 >>> connectionTimeout="6" maxThreads="200"
 minSpareThreads="4" enableLookups="false" compression="on"
 server="Apache" scheme="https" secure="true"
 SSLEnabled="true" keystoreFile="c:/keys/keystore.jsk"
 keystorePass="changeit" keyAlias="tomcat" clientAuth="false"
 sslProtocol="TLS"/>
> 
> Looks good so far.
> 
 Here is the exception I get at startup
 
 13-Oct-2016 15:05:17.309 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 at 
 org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(Ab
str
>
 
actJsseEndpoint.java:103)
 
 
> at
 org.apache.tomcat.util.net.AbstractJsseEndpoint.initialiseSsl(Abstr
act
>
 
JsseEndpoint.java:81)
 
 
> at
> org.apache.tomcat.util.net.NioEndpoint.bind(NioEndpoint.java:244)
 at 
 org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.j
ava
>
 
:866)
 
 
> at
 org.apache.tomcat.util.net.AbstractJsseEndpoint.init(AbstractJsseEn
dpo
>
 
int.java:213)
 
 
> at
> org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:575)
 at 
 org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11
Pro
>
 
tocol.java:65)
 
 
> at
> org.apache.catalina.connector.Connector.initInternal(Connector.java:9
>
> 
44)
 at 
 org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)


>
 
at
 org.apache.catalina.core.StandardService.initInternal(StandardServi
ce.
>
 
java:549)
 
 
> at
> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)

> 
at
 org.apache.catalina.core.StandardServer.initInternal(StandardServer
.ja
>
 
va:873)
 
 
> at
> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)

> 
at org.apache.catalina.startup.Catalina.load(Catalina.java:606) at
 org.apache.catalina.startup.Catalina.load(Catalina.java:629)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
 Method) at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImp
l.j
>
 
ava:62)
 
 
> at
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcc
ess
>
 
orImpl.java:43)
 
 
> at java.lang.reflect.Method.invoke(Method.java:498)
 at
 org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:311)

 
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:494)
 Caused by: java.security.InvalidAlgorithmParameterException:
 the trustAnchors parameter must be non-empty at 
 java.security.cert.PKIXParameters.setTrustAnchors(PKIXParameters.ja
va:
>
 
200)
 
 
> at
> java.security.cert.PKIXParameters.(PKIXParameters.java:157)
 at 
 java.security.cert.PKIXBuilderParameters.(PKIXBuilderParamete
rs.
>
 
java:130)
 
 
> at
 org.apache.tomcat.util.net.jsse.JSSEUtil.getParameters(JSSEUtil.jav
a:3
>
 
41)
 
 
> at
 

Re: 8.5.4 to 8.5.5 SSL Issue

[William Boyd]

On Fri, Oct 21, 2016 at 2:05 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> William,
>
> On 10/21/16 4:37 PM, William Boyd wrote:
> > Hello,
> >
> > I am attempting to upgrade from Tomcat 7 to 8.5.6. Everything was
> > working great until I enabled SSL with a self-signed certificate. I
> > am able to recreated the issue on 8.5.5. I finally had to down
> > graded to 8.5.4 to get SSL working with identical configuration and
> > cert.
> >
> > I want to be sure that this is not a known issue and that I'm not
> > doing something wrong before I create a bug report.
> >
> > Server version:Apache Tomcat/8.5.5 64-bit OS Name:
> > Windows 7 JVM Version:   1.8.0_102-b14
> >
> > The cert was generated with this command: keytool -genkeypair
> > -keyalg RSA -alias tomcat -keystore "C:/keys/keystore.jsk"
> > -storepass changeit -validity 360 -keysize 2048 -dname
> > CN=localhost,OU=ITS,O=Co,L=City,ST=AB,C=CA
> >
> > Configuration includes adding
> > -Djavax.net.ssl.trustStore=c:/keys/keystore.jsk to JAVA_OPTS
>
> I think this might be the problem. Tomcat doesn't use
> javax.net.ssl.trustStore except as a backup in case you haven't
> specified a trust store in your . You have pointed that
> system property at a keystore, not a trust store. Technically, they
> are the same format, but they are used for different things.
>
> If you need that for making your own outgoing TLS connections then
> leave it in there and we'll try to get it to work, otherwise it's just
> confusing and might cause Tomcat to do weird things.
>
> > and using this connector config
> >
> >  > connectionTimeout="6" maxThreads="200" minSpareThreads="4"
> > enableLookups="false" compression="on" server="Apache"
> > scheme="https" secure="true" SSLEnabled="true"
> > keystoreFile="c:/keys/keystore.jsk" keystorePass="changeit"
> > keyAlias="tomcat" clientAuth="false" sslProtocol="TLS"/>
>
> Looks good so far.
>
> > Here is the exception I get at startup
> >
> > 13-Oct-2016 15:05:17.309 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 at
> > org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(Abstr
> actJsseEndpoint.java:103)
> >
> >
> at
> > org.apache.tomcat.util.net.AbstractJsseEndpoint.initialiseSsl(Abstract
> JsseEndpoint.java:81)
> >
> >
> at org.apache.tomcat.util.net.NioEndpoint.bind(NioEndpoint.java:244)
> > at
> > org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java
> :866)
> >
> >
> at
> > org.apache.tomcat.util.net.AbstractJsseEndpoint.init(AbstractJsseEndpo
> int.java:213)
> >
> >
> at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:575)
> > at
> > org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Pro
> tocol.java:65)
> >
> >
> at org.apache.catalina.connector.Connector.initInternal(Connector.java:9
> 44)
> > at
> > org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
> >
> >
> at
> > org.apache.catalina.core.StandardService.initInternal(StandardService.
> java:549)
> >
> >
> at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
> > at
> > org.apache.catalina.core.StandardServer.initInternal(StandardServer.ja
> va:873)
> >
> >
> at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
> > at org.apache.catalina.startup.Catalina.load(Catalina.java:606) at
> > org.apache.catalina.startup.Catalina.load(Catalina.java:629) at
> > sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
> > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.j
> ava:62)
> >
> >
> at
> > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccess
> orImpl.java:43)
> >
> >
> at java.lang.reflect.Method.invoke(Method.java:498)
> > at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:311)
> > at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:494)
> > Caused by: java.security.InvalidAlgorithmParameterException: the
> > trustAnchors parameter must be non-empty at
> > java.security.cert.PKIXParameters.setTrustAnchors(PKIXParameters.java:
> 200)
> >
> >
> at java.security.cert.PKIXParameters.(PKIXParameters.java:157)
> > at
> > java.security.cert.PKIXBuilderParameters.(PKIXBuilderParameters.
> java:130)
> >
> >
> at
> > org.apache.tomcat.util.net.jsse.JSSEUtil.getParameters(JSSEUtil.java:3
> 41)
> >
> >
> at
> > org.apache.tomcat.util.net.jsse.JSSEUtil.getTrustManagers(JSSEUtil.jav
> a:273)
> >
> >
> at
> > org.apache.tomcat.util.net.openssl.OpenSSLUtil.getTrustManagers(OpenSS
> LUtil.java:93)
> >
> >
> at
> > org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(Abstr
> actJsseEndpoint.java:101)
> >
> >
> ... 20 more
>
> Tomcat is choking when trying to load the trust 

Re: 8.5.4 to 8.5.5 SSL Issue

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

William,

On 10/21/16 4:37 PM, William Boyd wrote:
> Hello,
> 
> I am attempting to upgrade from Tomcat 7 to 8.5.6. Everything was
> working great until I enabled SSL with a self-signed certificate. I
> am able to recreated the issue on 8.5.5. I finally had to down
> graded to 8.5.4 to get SSL working with identical configuration and
> cert.
> 
> I want to be sure that this is not a known issue and that I'm not
> doing something wrong before I create a bug report.
> 
> Server version:Apache Tomcat/8.5.5 64-bit OS Name:
> Windows 7 JVM Version:   1.8.0_102-b14
> 
> The cert was generated with this command: keytool -genkeypair
> -keyalg RSA -alias tomcat -keystore "C:/keys/keystore.jsk"
> -storepass changeit -validity 360 -keysize 2048 -dname
> CN=localhost,OU=ITS,O=Co,L=City,ST=AB,C=CA
> 
> Configuration includes adding 
> -Djavax.net.ssl.trustStore=c:/keys/keystore.jsk to JAVA_OPTS

I think this might be the problem. Tomcat doesn't use
javax.net.ssl.trustStore except as a backup in case you haven't
specified a trust store in your . You have pointed that
system property at a keystore, not a trust store. Technically, they
are the same format, but they are used for different things.

If you need that for making your own outgoing TLS connections then
leave it in there and we'll try to get it to work, otherwise it's just
confusing and might cause Tomcat to do weird things.

> and using this connector config
> 
>  connectionTimeout="6" maxThreads="200" minSpareThreads="4" 
> enableLookups="false" compression="on" server="Apache" 
> scheme="https" secure="true" SSLEnabled="true" 
> keystoreFile="c:/keys/keystore.jsk" keystorePass="changeit" 
> keyAlias="tomcat" clientAuth="false" sslProtocol="TLS"/>

Looks good so far.

> Here is the exception I get at startup
> 
> 13-Oct-2016 15:05:17.309 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 at 
> org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(Abstr
actJsseEndpoint.java:103)
>
> 
at
> org.apache.tomcat.util.net.AbstractJsseEndpoint.initialiseSsl(Abstract
JsseEndpoint.java:81)
>
> 
at org.apache.tomcat.util.net.NioEndpoint.bind(NioEndpoint.java:244)
> at 
> org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java
:866)
>
> 
at
> org.apache.tomcat.util.net.AbstractJsseEndpoint.init(AbstractJsseEndpo
int.java:213)
>
> 
at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:575)
> at 
> org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Pro
tocol.java:65)
>
> 
at org.apache.catalina.connector.Connector.initInternal(Connector.java:9
44)
> at
> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
>
> 
at
> org.apache.catalina.core.StandardService.initInternal(StandardService.
java:549)
>
> 
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
> at 
> org.apache.catalina.core.StandardServer.initInternal(StandardServer.ja
va:873)
>
> 
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
> at org.apache.catalina.startup.Catalina.load(Catalina.java:606) at
> org.apache.catalina.startup.Catalina.load(Catalina.java:629) at
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.j
ava:62)
>
> 
at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccess
orImpl.java:43)
>
> 
at java.lang.reflect.Method.invoke(Method.java:498)
> at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:311) 
> at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:494) 
> Caused by: java.security.InvalidAlgorithmParameterException: the 
> trustAnchors parameter must be non-empty at 
> java.security.cert.PKIXParameters.setTrustAnchors(PKIXParameters.java:
200)
>
> 
at java.security.cert.PKIXParameters.(PKIXParameters.java:157)
> at 
> java.security.cert.PKIXBuilderParameters.(PKIXBuilderParameters.
java:130)
>
> 
at
> org.apache.tomcat.util.net.jsse.JSSEUtil.getParameters(JSSEUtil.java:3
41)
>
> 
at
> org.apache.tomcat.util.net.jsse.JSSEUtil.getTrustManagers(JSSEUtil.jav
a:273)
>
> 
at
> org.apache.tomcat.util.net.openssl.OpenSSLUtil.getTrustManagers(OpenSS
LUtil.java:93)
>
> 
at
> org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(Abstr
actJsseEndpoint.java:101)
>
> 
... 20 more

Tomcat is choking when trying to load the trust managers, which is
synonymous with loading the data from the "trust store". You don't
need a "trust store", otherwise you'd have specified is in the
.

Try just removing that system property and see what happens.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird -