You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by William Boyd <wi...@gmail.com> on 2016/11/15 00:18:31 UTC
Re: 8.5.4 to 8.5.5 SSL Issue
On Tue, Oct 25, 2016 at 2:08 AM, Kreuser, Peter <pk...@airplus.com>
wrote:
> Dear all,
>
> > On Sun, Oct 23, 2016 at 3:15 PM, Christopher Schultz <
> > chris@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 <
> > > > chris@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 <Connector>. 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
> > > >>>>
> > > >>>> <Connector port="8002" protocol="HTTP/1.1"
> > > >>>> connectionTimeout="60000" 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.<init>(PKIXParameters.java:157)
> > > >>>> at
> > > >>>> java.security.cert.PKIXBuilderParameters.<init>(
> PKIXBuilderParamete
> > > rs.
> > > >
> > > >>>>
> > > java:130)
> > > >>>>
> > > >>>>
> > > > at
> > > >>>> org.apache.tomcat.util.net.jsse.JSSEUtil.getParameters(
> JSSEUtil.jav
> > > a:3
> > > >
> > > >>>>
> > > 41)
> > > >>>>
> > > >>>>
> > > > at
> > > >>>> org.apache.tomcat.util.net.jsse.JSSEUtil.
> getTrustManagers(JSSEUtil.
> > > jav
> > > >
> > > >>>>
> > > a:273)
> > > >>>>
> > > >>>>
> > > > at
> > > >>>> org.apache.tomcat.util.net.openssl.OpenSSLUtil.
> getTrustManagers(Ope
> > > nSS
> > > >
> > > >>>>
> > > LUtil.java:93)
> > > >>>>
> > > >>>>
> > > > at
> > > >>>> org.apache.tomcat.util.net.AbstractJsseEndpoint.
> createSSLContext(Ab
> > > str
> > > >
> > > >>>>
> > > 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
> > > > <Connector>.
> > > >
> > > > Try just removing that system property and see what happens.
> > > >
> > > > -chris
> > > >>
> > > >> ------------------------------------------------------------
> ---------
> > > >>
> > > >>
> > > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > > >> For additional commands, e-mail: users-help@tomcat.apache.org
> > > >>
> > > >>
> > > > Hi Christopher,
> > > >
> > > > Thanks for the quick response.
> > > >
> > > > I tried your suggestion but when I connect to the site via https,
> > > > tomcat returns a blank page with the SSLHandshakeException in it.
> > > > I’m not entirely sure but this may be a result of our use of AXIS
> > > > for communication between WARs in the deployed application.
> > > >
> > > > 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
> > > >
> > > > The catalina log contains this stacktrace
> > > >
> > > > 2016-10-21 14:48:43,517 [ERROR] [mblinkLoginSoapInterface.java:207]
> > > > - org.apache.axis.AxisFault: ; 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 at
> > > > org.apache.axis.AxisFault.makeFault(AxisFault.java:101)
> > > > ~[axis-1.4.jar:na] at
> > > > org.apache.axis.transport.http.HTTPSender.invoke(
> HTTPSender.java:154)
> > > >
> > > >
> > > ~[axis-1.4.jar:na]
> > > > : : Caused by: 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 at
> > > > sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
> > > > ~[na:1.8.0_102] at
> > > > sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1949)
> > > > ~[na:1.8.0_102] at
> > > > sun.security.ssl.Handshaker.fatalSE(Handshaker.java:302)
> > > > ~[na:1.8.0_102] at
> > > > sun.security.ssl.Handshaker.fatalSE(Handshaker.java:296)
> > > > ~[na:1.8.0_102] at
> > > > sun.security.ssl.ClientHandshaker.serverCertificate(
> ClientHandshaker.j
> > > ava:1509)
> > > >
> > > >
> > > ~[na:1.8.0_102]
> > > > at
> > > > sun.security.ssl.ClientHandshaker.processMessage(
> ClientHandshaker.java
> > > :216)
> > > >
> > > >
> > > ~[na:1.8.0_102]
> > > > at sun.security.ssl.Handshaker.processLoop(Handshaker.java:979)
> > > > ~[na:1.8.0_102] at
> > > > sun.security.ssl.Handshaker.process_record(Handshaker.java:914)
> > > > ~[na:1.8.0_102] at
> > > > sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1062)
> > > > ~[na:1.8.0_102] at
> > > > sun.security.ssl.SSLSocketImpl.performInitialHandshake(
> SSLSocketImpl.j
> > > ava:1375)
> > > >
> > > >
> > > ~[na:1.8.0_102]
> > > > at
> > > > sun.security.ssl.SSLSocketImpl.startHandshake(
> SSLSocketImpl.java:1403)
> > > >
> > > >
> > > ~[na:1.8.0_102]
> > > > at
> > > > sun.security.ssl.SSLSocketImpl.startHandshake(
> SSLSocketImpl.java:1387)
> > > >
> > > >
> > > ~[na:1.8.0_102]
> > > > at
> > > > org.apache.axis.components.net.JSSESocketFactory.create(
> JSSESocketFact
> > > ory.java:186)
> > > >
> > > >
> > > ~[axis-1.4.jar:na]
> > > > at
> > > > org.apache.axis.transport.http.HTTPSender.getSocket(
> HTTPSender.java:19
> > > 1)
> > > >
> > > >
> > > ~[axis-1.4.jar:na]
> > > > at
> > > > org.apache.axis.transport.http.HTTPSender.writeToSocket(
> HTTPSender.jav
> > > a:404)
> > > >
> > > >
> > > ~[axis-1.4.jar:na]
> > > > at
> > > > org.apache.axis.transport.http.HTTPSender.invoke(
> HTTPSender.java:138)
> > > >
> > > >
> > > ~[axis-1.4.jar:na]
> > > > ... 38 common frames omitted Caused by:
> > > > sun.security.validator.ValidatorException: PKIX path building
> > > > failed: sun.security.provider.certpath.SunCertPathBuilderException:
> > > > unable to find valid certification path to requested target at
> > > > sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:387)
> > > >
> > > >
> > > ~[na:1.8.0_102]
> > > > at
> > > > sun.security.validator.PKIXValidator.engineValidate(
> PKIXValidator.java
> > > :292)
> > > >
> > > >
> > > ~[na:1.8.0_102]
> > > > at sun.security.validator.Validator.validate(Validator.java:260)
> > > > ~[na:1.8.0_102] at
> > > > sun.security.ssl.X509TrustManagerImpl.validate(
> X509TrustManagerImpl.ja
> > > va:324)
> > > >
> > > >
> > > ~[na:1.8.0_102]
> > > > at
> > > > sun.security.ssl.X509TrustManagerImpl.checkTrusted(
> X509TrustManagerImp
> > > l.java:229)
> > > >
> > > >
> > > ~[na:1.8.0_102]
> > > > at
> > > > sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(
> X509TrustMana
> > > gerImpl.java:124)
> > > >
> > > >
> > > ~[na:1.8.0_102]
> > > > at
> > > > sun.security.ssl.ClientHandshaker.serverCertificate(
> ClientHandshaker.j
> > > ava:1491)
> > > >
> > > >
> > > ~[na:1.8.0_102]
> > > > ... 49 common frames omitted Caused by:
> > > > sun.security.provider.certpath.SunCertPathBuilderException: unable
> > > > to find valid certification path to requested target at
> > > > sun.security.provider.certpath.SunCertPathBuilder.
> build(SunCertPathBui
> > > lder.java:141)
> > > >
> > > >
> > > ~[na:1.8.0_102]
> > > > at
> > > > sun.security.provider.certpath.SunCertPathBuilder.
> engineBuild(SunCertP
> > > athBuilder.java:126)
> > > >
> > > >
> > > ~[na:1.8.0_102]
> > > > at
> > > > java.security.cert.CertPathBuilder.build(CertPathBuilder.java:280)
> > > > ~[na:1.8.0_102] at
> > > > sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:382)
> > > >
> > > >
> > > ~[na:1.8.0_102]
> > > > ... 55 common frames omitted
> > >
> > >
> > > If you need to make outgoing TLS connections to servers with
> > > certificates not trusted by Java's stock trust store, you'll have to
> > > supply your own. Do you have anything in the trust store other than
> > > the server's key and certificate? Are you making loopback connections?
> > >
> > > I'm surprised that this either worked in the past or is failing now.
> > > I'm not sure which makes more sense. There's no particular reason why
> > > I "keystore" couldn't be used as a "truststore"... the only difference
> > > is that "keystores" usually contain keys and certs, while
> > > "truststores" usually only contain certificates.
> > >
> > > I wonder if it has something to do with the aliases used or something.
> > >
> > > If in fact using the keystore as a trust store is tripping-up Tomcat,
> > > I'd say that's a bug that needs to be fixed.
> > >
> > > Try this: whatever certificate you need to TRUST needs to be in your
> > > trust store. Try creating a new keystore that contains nothing but the
> > > certificate you expect to trust, then configure *that* as your trust
> > > store (system property), leaving the keystore as-is -- configured as
> > > Tomcat's keystore.
> > >
> > > - -chris
> > > -----BEGIN PGP SIGNATURE-----
> > > Comment: GPGTools - http://gpgtools.org
> > > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> > >
> > > iQIcBAEBCAAGBQJYDTaRAAoJEBzwKT+lPKRYFy4QAI5vHVUofkmImGCO3gth+fQ6
> > > tYk2FatDLqGk332UGZnzLbrJxPXNE+DazzPjOyaIMETFzxInY9z32ABqQqWIZRp0
> > > ItZtLPuUsQTh108UIGU1yVaEG2XhFAE90QfO63JEI5r/d6gzI+lNj6Kfv0aEMNNG
> > > dgvTxUIjBCrEzBekoEPwP3XtYZSGtr2u+CxxO+OMKNKiLLWEGQQHk/CRZjAgosPy
> > > iHsEjAQiDvkqkRaJTMyqpbx43CM/eS5X1facftvWsdYiVTsXgzwgEH3vQXLTuByw
> > > XGjH4IwFsvT92AJ/0C1FgQHcXasGF6HwYKkPMHI/s1cZWMwKmFaDT0EeMdrxC9ll
> > > EbrXui6VQi8Hf3ya5nFWRwrvlN51PshortQ7eEx2MOP7XQFeHr6i8k+5LCmeQBcQ
> > > +STseFmbSIFyUu2SjDKIDluIUWppJhGodIH84hJMj8UCtXlGbE9u2D7wIloQz1El
> > > GzJuooYP6P+Rm5PWaGuT5WNnVAfNkAJ0h9B8CRBc+KQkXYDBFlD3XFx1zL46iU+x
> > > aFWi2UqJJhNKXW3j111HP31CA77XJCHHsbJpwotqEwO3+1ChToK7WV+3tUBzax3w
> > > i8UB+b38e7y2ZlT0B2D5wHu/aPJ+Sx2w/ThJmz5wgpU7EshNkSUW1TBmz7MCFvgW
> > > fJ071CkiXAb1UnBxchZT
> > > =VMdG
> > > -----END PGP SIGNATURE-----
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > > For additional commands, e-mail: users-help@tomcat.apache.org
> > >
> > >
> > Hi Chris,
> >
> > I tested a couple things to no avail. I can confirm that I've
> successfully
> > used this configuration with JDK 1.6.0_45, 1.7.0_80, 1.8.0_102 and Tomcat
> > 6.0.10, 7.0.56, 8.5.4.
> >
> > Here's what I tested:
> >
> > 1. I recreated the keystore with the alias localhost and got the same
> > error:
> > IllegalArgumentException:
> > java.security.InvalidAlgorithmParameterException: the trustAnchors
> > parameter must be non-empty
> >
> > 2. I restored the tomcat alias, exported the certificate and set my
> system
> > property to point to that tomcat.crt file. This caused the following
> > stacktrace
> > java.lang.IllegalArgumentException: java.io.IOException: Invalid
> > keystore format
> > at
> > org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(
> AbstractJsseEndpoint.java:103)
> > at
> > org.apache.tomcat.util.net.AbstractJsseEndpoint.initialiseSsl(
> AbstractJsseEndpoint.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(
> AbstractJsseEndpoint.java:213)
> > at
> > org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:575)
> > at
> > org.apache.coyote.http11.AbstractHttp11Protocol.init(
> AbstractHttp11Protocol.java:65)
> > at
> > org.apache.catalina.connector.Connector.initInternal(Connector.java:944)
> > 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.java: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.java:62)
> > at
> > sun.reflect.DelegatingMethodAccessorImpl.invoke(
> DelegatingMethodAccessorImpl.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.io.IOException: Invalid keystore format
> > at
> > sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:658)
> > at
> > sun.security.provider.JavaKeyStore$JKS.engineLoad(JavaKeyStore.java:56)
> > at
> > sun.security.provider.KeyStoreDelegator.engineLoad(
> KeyStoreDelegator.java:224)
> > at
> > sun.security.provider.JavaKeyStore$DualFormatJKS.
> engineLoad(JavaKeyStore.java:70)
> > at java.security.KeyStore.load(KeyStore.java:1445)
> > at
> > org.apache.tomcat.util.net.SSLUtilBase.getStore(SSLUtilBase.java:136)
> > at
> > org.apache.tomcat.util.net.SSLHostConfig.getTruststore(
> SSLHostConfig.java:614)
> > at
> > org.apache.tomcat.util.net.jsse.JSSEUtil.getTrustManagers(JSSEUtil.
> java:256)
> > at
> > org.apache.tomcat.util.net.openssl.OpenSSLUtil.
> getTrustManagers(OpenSSLUtil.java:93)
> > at
> > org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(
> AbstractJsseEndpoint.java:101)
> > ... 20 more
> > 2. I tried setting the system property to point to keystore.jsk and
> tomcat
> > keystoreFile to tomcat.crt and got the same stacktrace above.
> >
> > Below are listings of my keystore.jsk and tomcat.crt file generated from
> > the JRE 8 keytool
> >
> > ------------------------------------------------------------
> -------------------------------
> > keystore.jsk
> > ------------------------------------------------------------
> -------------------------------
> > Keystore type: JKS
> > Keystore provider: SUN
> > Your keystore contains 1 entry
> > Alias name: tomcat
> > Creation date: Oct 24, 2016
> > Entry type: PrivateKeyEntry
> > Certificate chain length: 1
> > Certificate[1]:
> > Owner: CN=localhost, OU=ITS, O=xxx, L=xxx, ST=BC, C=CA
> > Issuer: CN=localhost, OU=ITS, O=xxx, L=xxx, ST=BC, C=CA
> > Serial number: 220d2cc
> > Valid from: Mon Oct 24 11:56:22 PDT 2016 until: Thu Oct 19 11:56:22 PDT
> 2017
> > Certificate fingerprints:
> > MD5: 5E:F8:3A:6F:BB:CF:5D:72:5A:A8:CE:16:7B:B6:75:61
> > SHA1: DA:86:EB:A9:4C:56:D9:6B:E4:88:
> F4:A1:4D:91:5B:BD:4F:1A:F2:16
> > SHA256:
> > 75:66:92:B3:57:0C:28:05:03:EA:BC:DE:C5:51:45:00:65:82:4C:7C:
> F4:BD:E6:90:CE:61:90:30:B2:3D:67:57
> > Signature algorithm name: SHA256withRSA
> > Version: 3
> > Extensions:
> > #1: ObjectId: 2.5.29.14 Criticality=false
> > SubjectKeyIdentifier [
> > KeyIdentifier [
> > 0000: 22 EA 63 DB 74 90 D1 F7 28 56 E9 B3 87 74 7A 14 ".c.t...(V...tz.
> > 0010: 0A 62 1A AE .b..
> > ]
> > ]
> >
> > *******************************************
> > *******************************************
> > ------------------------------------------------------------
> -------------------------------
> > tomcat.crt
> > ------------------------------------------------------------
> -------------------------------
> > Owner: CN=localhost, OU=ITS, O=xxx, L=xxx, ST=BC, C=CA
> > Issuer: CN=localhost, OU=ITS, O=xxx, L=xxx, ST=BC, C=CA
> > Serial number: 220d2cc
> > Valid from: Mon Oct 24 11:56:22 PDT 2016 until: Thu Oct 19 11:56:22 PDT
> 2017
> > Certificate fingerprints:
> > MD5: 5E:F8:3A:6F:BB:CF:5D:72:5A:A8:CE:16:7B:B6:75:61
> > SHA1: DA:86:EB:A9:4C:56:D9:6B:E4:88:
> F4:A1:4D:91:5B:BD:4F:1A:F2:16
> > SHA256:
> > 75:66:92:B3:57:0C:28:05:03:EA:BC:DE:C5:51:45:00:65:82:4C:7C:
> F4:BD:E6:90:CE:61:90:30:B2:3D:67:57
> > Signature algorithm name: SHA256withRSA
> > Version: 3
> > Extensions:
> > #1: ObjectId: 2.5.29.14 Criticality=false
> > SubjectKeyIdentifier [
> > KeyIdentifier [
> > 0000: 22 EA 63 DB 74 90 D1 F7 28 56 E9 B3 87 74 7A 14 ".c.t...(V...tz.
> > 0010: 0A 62 1A AE .b..
> > ]
> > ]
> >
> > Regards
> > Will
>
>
> I can confirm that this has happened to me too in the transition from
> 8.5.4 to 8.5.5. Over time the -Djavax.net.ssl.trustStore parameter with the
> link to the tomcat certificate store was forgotten in the setenv.sh and as
> I did not use it, I was able to just disable it.
>
> It never bothered tomcat until 8.5.5 though.
>
> Best regards
>
> Peter
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Hello,
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 +
Regards
Will
Re: 8.5.4 to 8.5.5 SSL Issue
Posted by William Boyd <wi...@gmail.com>.
On Thu, Nov 24, 2016 at 5:15 AM, Christopher Schultz <
chris@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 <
> > chris@christopherschultz.net> wrote:
> >
> > William,
> >
> > On 11/16/16 1:06 PM, William Boyd wrote:
> >>>> On Tue, Nov 15, 2016 at 2:17 PM,
> >>>> <Jo...@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-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: users-help@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@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
Re: 8.5.4 to 8.5.5 SSL Issue
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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 <
> chris@christopherschultz.net> wrote:
>
> William,
>
> On 11/16/16 1:06 PM, William Boyd wrote:
>>>> On Tue, Nov 15, 2016 at 2:17 PM,
>>>> <Jo...@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\u2019m guessing its AXIS that can\u2019t 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-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: 8.5.4 to 8.5.5 SSL Issue
Posted by William Boyd <wi...@gmail.com>.
On Tue, Nov 22, 2016 at 3:41 PM, Christopher Schultz <
chris@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, <Jo...@wellsfargo.com>
> > wrote:
> >>
> >> I haven't been following this super closely, but it sounds like
> >> there is a lot of trial and error going on so let me try to
> >> explain how the key stores and trust stores are used.
> >
> > Will: Ultimately I am trying to determine why a configuration that
> > worked since Tomcat 5, stopped working in Tomcat 8.5.5 so I can
> > explain the issue to operations. We used to be able to use the
> > same keystore for both keystoreFile in the Connector and the
> > javax.net.ssl.trustStore system property but that no longer works.
> > The only variable is Tomcat. This will affect many TEST and PROD
> > sites.
> >
> >> The system properties affect things like outgoing connections
> >> that use SSL, like https calls. javax.net.ssl.trustStore would
> >> contain the certs for the CAs that sign the backend server's
> >> cert. javax.net.ssl.keyStore would come into play if the backend
> >> uses mutual authentication/client authentication/2-way SSL. If
> >> that's required by the backend, you would put your own cert and
> >> private key in the key store. I think you can combine them all
> >> into one file, but usually they're kept separate.
> >>
> >
> > Will: Thanks, I think this explains our need for
> > javax.net.ssl.trustStore. The system I'm supporting is using axis
> > jaxrpc to communicate between WARs over HTTPS within Tomcat. These
> > connections in axis must be the reason we require
> > javax.net.ssl.trustStore.
>
> Exactly. I think one of the confusing things here has been the
> confusion in my mind between exceptions you are getting on the client
> and exceptions being thrown on the server (which, oddly enough, is a
> client).
>
> In the absence of any specific Java-level calls to set the trust store
> for a SOAP connection, Axis is going to use the system-wide trust
> store which is in fact set using the javax.net.ssl.trustStore system
> property.
>
> Nothing in Tomcat's configuration can set this for you.
>
> So why does the Tomcat upgrade seem to have broken something that's
> been working? I can think of two possibilities:
>
> 1. The system property was set in CATALINA_HOME/bin/setenv.sh in your
> old Tomcat installation, and nobody copied that file to the new
> installation. Solution: use CATALINA_BASE/bin/setenv.sh instead of
> CATALINA_HOME/bin/setenv.sh
>
> 2. The system property was set in
> CATALINA_BASE/conf/catalina.properties in your old installation and
> nobody copied that configuration to the new installation. Solution:
> look at a diff between those two config files and fix the differences
> as appropriate.
>
> >> The Tomcat connector parameters are for Tomcat's use when serving
> >> https connections to clients. I don't think they have any impact
> >> on outgoing calls. The key store would contain Tomcat's cert and
> >> private key. Likewise the trust store would contain the certs of
> >> the CA or CAs who sign your client's certs if you have mutual
> >> auth enabled. It might also be required to form the chain
> >> linking the server's cert to the CA. In that case, though, I
> >> might be inclined to putting the CA in the key store itself for
> >> simplicity. According to the docs, Tomcat will fall back to the
> >> system properties if the connector doesn't explicitly them.
> >>
> >
> > Will: Sorry I'm confused by the last bit here. Using "keytool
> > -genkeypair" I have a file containing a self-signed certificate yet
> > I now need to export, than import that cert into a separate
> > truststore in order for our servers to work. If this is to spec
> > and Tomcat it tightening up the rules I could understand.
>
> I don't think anything really changed between Tomcat 8.5.4 and
> 8.5.5... I think your configuration must have changed slightly.
>
> If you need a webapp in server A to contact server B using Axis, then
> you'll need:
>
> serverA$ keytool -genkeypair -alias X -keystore serverA.jks
> serverA$ keytool -exportcert -alias X -keystore serverA.jks \
> > trusted.crt
> serverA$ keytool -importcert -alias X -keystore truststore.jks \
> < trusted.crt
>
> Tell Tomcat on server A to use serverA.jks as its keystore. No other
> configuration is required. Specifically, setting trustStoreFile on the
> <Connector> accomplishes nothing.
>
> Tell the JVM on server B to use truststore.jks as the trust store,
> using a system property if absolutely necessary.
>
> (I *really* don't like dong this, because it sets the trust store for
> the whole JVM and everything it might need to trust. I much prefer to
> explicitly-set the trust store for a particular connection. That might
> require re-writing code which is expensive and risky, but you are
> better-off in the long-run.)
>
> If you need a webapp in server B to contact server A using Axis, thn
> you need to reverse the process above so that A trusts B's cert and B
> trusts A's cert. If both servers are using the same cert, then both
> servers only need to trust the single cert, of course.
>
> > Will: I’m guessing its AXIS that can’t find the CA in the trust
> > store. Regarding IE, I can clarify, the error occurs in a servlet
> > which returns the message to the browser.
>
> The way a client trust store works is that the client will make a
> connection and obtain the certificate chain from the server. It starts
> with the first certificate in the chain and, if it's trusted, it will
> allow the connection to be established. If not, it moves on to the
> next certificate in the chain until it either trusts a certificate or
> runs out of certificates to check for trust, at which point, it will
> fail to establish a connection.
>
> If Axis can't connect, check the trust store it's using against the
> certificate(s) being presented by the server. If they don't match, fix
> that (usually by re-building the trust store from the certificate
> presented by the server). If they do match, something weird is happening
> .
>
> > So I think I understand why I need javax.net.ssl.trustStore and
> > keystoreFile configured to get our system working. Thank you for
> > making me walk through it in more detail.
>
> So, things are in fact working again?
>
> > The question remains why does Tomcat 8.5.5 no longer allow me to
> > use a JKS file as a trustStore and raise the following exception at
> > startup?
> >
> >
> >
> > 16-Nov-2016 09:02:03.195 SEVERE [main]
> > org.apache.coyote.AbstractProtocol.init
> >
> > Failed to initialize end point associated with ProtocolHandler
> > ["https-openssl-nio-8001"]
> >
> > java.lang.IllegalArgumentException:
> > java.security.InvalidAlgorithmParameterException: the trustAnchors
> > parameter must be non-empty
>
> Which configuration was this, specifically?
>
> > 2. adding truststoreFile="C:\keystore\myAlias.cer"
>
> This isn't a keystore, so the "Invalid keystore format" error you got
> makes sense.
>
> > 3. adding truststoreFile="C:\keystore\keystore.jsk"
>
> This one? The error you are getting is probably because the keystore
> itself contains a single entry which is a key/cert combination and ...
> at this point we've reached the limit of my knowledge of keystores
> (which pretty much ends with me saying "#$%& IT!" and switching to a
> vanilla PEM-formatted certificate, etc.).
>
> By importing the certificate *only* into a separate keystore (trust
> store!) puts it into a different format which is acceptable to the
> Java API that is underlying everything, here.
>
> Why did this work before? I have absolutely no idea. I'm still
> thinking that there is a subtle change in your configuration from
> version to version (8.5.4 -> 8.5.5, right?), and that Tomcat's code
> isn't involved.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJYNNexAAoJEBzwKT+lPKRYEecQAKrAJU6+NAQMFDKGw1YESyOQ
> MTp9GUW+tXVX/v2h7ayVh8bfHPOTSZShJ1KMbdi9LQWXMNalfLaJSbaQIB6j5vNM
> E2GhoScWJ9AJ3nwiqD/knxMkXA2LEzN/z/JhqOH+RY3ql+YjDsc0v8lK9jdhjqPB
> p6nBXjDV5unD2p7HFLUoDtCVISilPLWE2o78qNVfKWM113U3eRG81P3lUyACLROV
> TthII61IQocOqwehDFzCDf0zlMnB06Mi/l5iCvQDGYfmFYh/CHDyNA4bFDin8zak
> jd9/5asTeZdEeNJ3+cU6ffjV+BVJwTPMpFRyj1hVGwLyS9FcCEBu9el2iiL+v2zQ
> 4fgRX0iXbrPvQgXDggvLE1pZoWHQNy7ONMzEEwTvCnPNLNL88VWM3WMeztWh9O6z
> TK4GClQGZcXHo3LFd1baQ8+lBsaCWF/NAYdBMwa+p4P0z9NBHf1RaBGeFBKhmY/H
> 0h7Pf8lJDPfRSlLjc6SX/U6nmyGHrCZ8LeJ3BxeTieJBcDDM2Leh8gyxacF+hFfT
> EMj8duIMgbfsBtvtQDMDxG3elQ5ZRPclkjhCSe3hVykWk7Ayx5XVd3HUOHzK6Z3E
> F4xpOgPBT5eaELpO8XqyUQL2x2M6BV6TxefXpKUw5p5PLdozbJH3C4KDTlugF3Yd
> i1X2Ubn8gAAqqBa+LMAV
> =GvhM
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Hi Christopher,
Thanks again for your input. Yes, I've managed to get it working with a
separate keystore and truststore file as you've suggested.
Ok, sanity check. I revisited this with unmodified
apache-tomcat-8.5.#-windows-x64.zip files downloaded from the distribution
site.
In this case, all I did was unpack the ZIP content and change two files;
server.xml and setclasspath.bat.
In each case I added this one line to the top of setclasspath.bat
set JAVA_OPTS=%JAVA_OPTS%
-Djavax.net.ssl.trustStore="C:\keys\keystore.jsk"
In tomcat 8.5.4 and 8.5.5 > server.xml, I updated the default connector to
this:
<Connector port="8080" protocol="HTTP/1.1"
connectionTimeout="20000"
keystoreFile="C:\keys\keystore.jsk"
keystorePass="changeit"
keyAlias="tomcat"
scheme="https"
secure="true"
SSLEnabled="true"
clientAuth="false" />
In tomcat 8.5.8 > server.xml, I updated the default connector to this:
<Connector port="8080" protocol="HTTP/1.1"
connectionTimeout="20000"
scheme="https"
secure="true"
SSLEnabled="true">
<SSLHostConfig certificateVerification="none">
<Certificate certificateKeystoreFile="C:\keys\keystore.jsk"
certificateKeystorePassword="changeit"
certificateKeyAlias="tomcat"
type="RSA" />
</SSLHostConfig>
</Connector>
On startup both tomcat 8.5.5 and 8.5.8 raise the error I've describe above:
"InvalidAlgorithmParameterException: the trustAnchors parameter must be
non-empty"
Tomcat 8.5.4 starts up without error.
Each was run in the same environment:
OS Name: Windows 7 SP1
JVM Version: 1.8.0_102-b14
Sorry for beating this to death. I had to be sure I wasn't losing my mind.
Regards,
William Boyd
Re: 8.5.4 to 8.5.5 SSL Issue
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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, <Jo...@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\u2019m guessing its AXIS that can\u2019t find the CA in the trust
> store. Regarding IE, I can clarify, the error occurs in a servlet
> which returns the message to the browser.
The way a client trust store works is that the client will make a
connection and obtain the certificate chain from the server. It starts
with the first certificate in the chain and, if it's trusted, it will
allow the connection to be established. If not, it moves on to the
next certificate in the chain until it either trusts a certificate or
runs out of certificates to check for trust, at which point, it will
fail to establish a connection.
If Axis can't connect, check the trust store it's using against the
certificate(s) being presented by the server. If they don't match, fix
that (usually by re-building the trust store from the certificate
presented by the server). If they do match, something weird is happening
.
> So I think I understand why I need javax.net.ssl.trustStore and
> keystoreFile configured to get our system working. Thank you for
> making me walk through it in more detail.
So, things are in fact working again?
> The question remains why does Tomcat 8.5.5 no longer allow me to
> use a JKS file as a trustStore and raise the following exception at
> startup?
>
>
>
> 16-Nov-2016 09:02:03.195 SEVERE [main]
> org.apache.coyote.AbstractProtocol.init
>
> Failed to initialize end point associated with ProtocolHandler
> ["https-openssl-nio-8001"]
>
> java.lang.IllegalArgumentException:
> java.security.InvalidAlgorithmParameterException: the trustAnchors
> parameter must be non-empty
Which configuration was this, specifically?
> 2. adding truststoreFile="C:\keystore\myAlias.cer"
This isn't a keystore, so the "Invalid keystore format" error you got
makes sense.
> 3. adding truststoreFile="C:\keystore\keystore.jsk"
This one? The error you are getting is probably because the keystore
itself contains a single entry which is a key/cert combination and ...
at this point we've reached the limit of my knowledge of keystores
(which pretty much ends with me saying "#$%& IT!" and switching to a
vanilla PEM-formatted certificate, etc.).
By importing the certificate *only* into a separate keystore (trust
store!) puts it into a different format which is acceptable to the
Java API that is underlying everything, here.
Why did this work before? I have absolutely no idea. I'm still
thinking that there is a subtle change in your configuration from
version to version (8.5.4 -> 8.5.5, right?), and that Tomcat's code
isn't involved.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJYNNexAAoJEBzwKT+lPKRYEecQAKrAJU6+NAQMFDKGw1YESyOQ
MTp9GUW+tXVX/v2h7ayVh8bfHPOTSZShJ1KMbdi9LQWXMNalfLaJSbaQIB6j5vNM
E2GhoScWJ9AJ3nwiqD/knxMkXA2LEzN/z/JhqOH+RY3ql+YjDsc0v8lK9jdhjqPB
p6nBXjDV5unD2p7HFLUoDtCVISilPLWE2o78qNVfKWM113U3eRG81P3lUyACLROV
TthII61IQocOqwehDFzCDf0zlMnB06Mi/l5iCvQDGYfmFYh/CHDyNA4bFDin8zak
jd9/5asTeZdEeNJ3+cU6ffjV+BVJwTPMpFRyj1hVGwLyS9FcCEBu9el2iiL+v2zQ
4fgRX0iXbrPvQgXDggvLE1pZoWHQNy7ONMzEEwTvCnPNLNL88VWM3WMeztWh9O6z
TK4GClQGZcXHo3LFd1baQ8+lBsaCWF/NAYdBMwa+p4P0z9NBHf1RaBGeFBKhmY/H
0h7Pf8lJDPfRSlLjc6SX/U6nmyGHrCZ8LeJ3BxeTieJBcDDM2Leh8gyxacF+hFfT
EMj8duIMgbfsBtvtQDMDxG3elQ5ZRPclkjhCSe3hVykWk7Ayx5XVd3HUOHzK6Z3E
F4xpOgPBT5eaELpO8XqyUQL2x2M6BV6TxefXpKUw5p5PLdozbJH3C4KDTlugF3Yd
i1X2Ubn8gAAqqBa+LMAV
=GvhM
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: 8.5.4 to 8.5.5 SSL Issue
Posted by William Boyd <wi...@gmail.com>.
On Tue, Nov 15, 2016 at 2:17 PM, <Jo...@wellsfargo.com> wrote:
>
>
> > -----Original Message-----
> > From: William Boyd [mailto:william.boyd@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 <
> > chris@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
> > > <Connector>. 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-unsubscribe@tomcat.apache.org
> > > For additional commands, e-mail: users-help@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(AbstractJsse
> > Endpoint.java:103)
> > :
> > Caused by: java.io.IOException: Invalid keystore format
> > at
> > sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:658)
> > at
> > sun.security.provider.JavaKeyStore$JKS.engineLoad(JavaKeyStore.java:56)
> > at
> > sun.security.provider.KeyStoreDelegator.engineLoad(
> KeyStoreDelegator.java:22
> > 4)
> > at
> > sun.security.provider.JavaKeyStore$DualFormatJKS.
> engineLoad(JavaKeyStore.ja
> > va:70)
> > at java.security.KeyStore.load(KeyStore.java:1445)
> > at
> > org.apache.tomcat.util.net.SSLUtilBase.getStore(SSLUtilBase.java:136)
> > ... 20 more
> >
> > 3. adding truststoreFile="C:\keystore\keystore.jsk" to my Connector and
> got the
> > following error at startup
> > 15-Nov-2016 12:45:58.625 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(AbstractJsse
> > Endpoint.java:103)
> > :
> > 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.<init>(
> PKIXParameters.java:157)
> > at
> > java.security.cert.PKIXBuilderParameters.<init>(
> PKIXBuilderParameters.java:130)
> > at
> > org.apache.tomcat.util.net.jsse.JSSEUtil.getParameters(
> JSSEUtil.java:332)
> > at
> > org.apache.tomcat.util.net.jsse.JSSEUtil.getTrustManagers(JSSEUtil.
> java:264)
> > at
> > org.apache.tomcat.util.net.openssl.OpenSSLUtil.
> getTrustManagers(OpenSSLUtil
> > .java:93)
> > at
> > org.apache.tomcat.util.net.AbstractJsseEndpoint.
> createSSLContext(AbstractJsse
> > Endpoint.java:101)
> > ... 20 more
> >
> > 4. I generated a new trustStore using “keytool -import -file
> myAlias.cer -alias
> > myAlias -keystore MyTrustStore”
> > then I adding truststoreFile="C:\keystore\MyTrustStore" to my
> Connector and
> > got the same PKIX error as 1 above.
> >
> > 5. finally I removed the truststoreFile attribute and used -
> > Djavax.net.ssl.trustStore="C:\keystore\MyTrustStore"
> > This worked...
> > Let me know if I've miss understanding your request or if there's
> something else
> > you'd like me to try.
> >
> > Regards
> > Will
>
> 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.
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.
> Also, keep your client and server straight. Is the client you're using to
> connect to Tomcat a separate process or is it an app deployed in Tomcat?
> If it's a separate process, whatever configuration you do to Tomcat will
> have no bearing on the client. Instead, if the client is java, it will
> need the trustStore and maybe the keyStore system properties set. Even if
> the client is within Tomcat, it will still need those settings to make
> outgoing https connections. The Tomcat connector config doesn't come into
> play in the case of outgoing connections.
>
Will: It appears the client is embedded in the WARs (RPC calls from one WAR
to another).
To address each of your tests:
> 1. This typically means that the CA wasn't found in the trust store,
> though I don't know what you mean that you're getting it in IE. This is a
> java message. IE will give you a different error message.
>
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.
> 2. Probably you need to do something else to your connector config to
> handle this type of file, like set the truststoreType parameter
> appropriately.
>
Will: In this test I supplied the exported cert as a trust store. I was
expecting it to fail.
> 3. Does that file actually exist? Is the file extension correct? Usually
> it's jks, not jsk.
>
Will: Yes, though oddly named, the file exists.
> 4. Same as #1.
> 5. Not sure why this worked but #1 and #4 did not.
>
Will: Most likely due to the RPC calls.
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.
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
at
org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:103)
:
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.<init>(PKIXParameters.java:157)
at
java.security.cert.PKIXBuilderParameters.<init>(PKIXBuilderParameters.java:130)
at
org.apache.tomcat.util.net.jsse.JSSEUtil.getParameters(JSSEUtil.java:332)
at
org.apache.tomcat.util.net.jsse.JSSEUtil.getTrustManagers(JSSEUtil.java:264)
at
org.apache.tomcat.util.net.openssl.OpenSSLUtil.getTrustManagers(OpenSSLUtil.java:93)
at
org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:101)
... 20 more
Regards
William
RE: 8.5.4 to 8.5.5 SSL Issue
Posted by Jo...@wellsfargo.com.
> -----Original Message-----
> From: William Boyd [mailto:william.boyd@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 <
> chris@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
> > <Connector>. 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-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@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(AbstractJsse
> Endpoint.java:103)
> :
> Caused by: java.io.IOException: Invalid keystore format
> at
> sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:658)
> at
> sun.security.provider.JavaKeyStore$JKS.engineLoad(JavaKeyStore.java:56)
> at
> sun.security.provider.KeyStoreDelegator.engineLoad(KeyStoreDelegator.java:22
> 4)
> at
> sun.security.provider.JavaKeyStore$DualFormatJKS.engineLoad(JavaKeyStore.ja
> va:70)
> at java.security.KeyStore.load(KeyStore.java:1445)
> at
> org.apache.tomcat.util.net.SSLUtilBase.getStore(SSLUtilBase.java:136)
> ... 20 more
>
> 3. adding truststoreFile="C:\keystore\keystore.jsk" to my Connector and got the
> following error at startup
> 15-Nov-2016 12:45:58.625 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(AbstractJsse
> Endpoint.java:103)
> :
> 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.<init>(PKIXParameters.java:157)
> at
> java.security.cert.PKIXBuilderParameters.<init>(PKIXBuilderParameters.java:130)
> at
> org.apache.tomcat.util.net.jsse.JSSEUtil.getParameters(JSSEUtil.java:332)
> at
> org.apache.tomcat.util.net.jsse.JSSEUtil.getTrustManagers(JSSEUtil.java:264)
> at
> org.apache.tomcat.util.net.openssl.OpenSSLUtil.getTrustManagers(OpenSSLUtil
> .java:93)
> at
> org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsse
> Endpoint.java:101)
> ... 20 more
>
> 4. I generated a new trustStore using “keytool -import -file myAlias.cer -alias
> myAlias -keystore MyTrustStore”
> then I adding truststoreFile="C:\keystore\MyTrustStore" to my Connector and
> got the same PKIX error as 1 above.
>
> 5. finally I removed the truststoreFile attribute and used -
> Djavax.net.ssl.trustStore="C:\keystore\MyTrustStore"
> This worked...
> Let me know if I've miss understanding your request or if there's something else
> you'd like me to try.
>
> Regards
> Will
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.
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.
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.
Also, keep your client and server straight. Is the client you're using to connect to Tomcat a separate process or is it an app deployed in Tomcat? If it's a separate process, whatever configuration you do to Tomcat will have no bearing on the client. Instead, if the client is java, it will need the trustStore and maybe the keyStore system properties set. Even if the client is within Tomcat, it will still need those settings to make outgoing https connections. The Tomcat connector config doesn't come into play in the case of outgoing connections.
To address each of your tests:
1. This typically means that the CA wasn't found in the trust store, though I don't know what you mean that you're getting it in IE. This is a java message. IE will give you a different error message.
2. Probably you need to do something else to your connector config to handle this type of file, like set the truststoreType parameter appropriately.
3. Does that file actually exist? Is the file extension correct? Usually it's jks, not jsk.
4. Same as #1.
5. Not sure why this worked but #1 and #4 did not.
Re: 8.5.4 to 8.5.5 SSL Issue
Posted by William Boyd <wi...@gmail.com>.
On Tue, Nov 15, 2016 at 10:50 AM, Christopher Schultz <
chris@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
> <Connector>. 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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@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
sun.security.provider.JavaKeyStore$JKS.engineLoad(JavaKeyStore.java:56)
at
sun.security.provider.KeyStoreDelegator.engineLoad(KeyStoreDelegator.java:224)
at
sun.security.provider.JavaKeyStore$DualFormatJKS.engineLoad(JavaKeyStore.java:70)
at java.security.KeyStore.load(KeyStore.java:1445)
at
org.apache.tomcat.util.net.SSLUtilBase.getStore(SSLUtilBase.java:136)
... 20 more
3. adding truststoreFile="C:\keystore\keystore.jsk" to my Connector and got
the following error at startup
15-Nov-2016 12:45:58.625 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(AbstractJsseEndpoint.java:103)
:
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.<init>(PKIXParameters.java:157)
at
java.security.cert.PKIXBuilderParameters.<init>(PKIXBuilderParameters.java:130)
at
org.apache.tomcat.util.net.jsse.JSSEUtil.getParameters(JSSEUtil.java:332)
at
org.apache.tomcat.util.net.jsse.JSSEUtil.getTrustManagers(JSSEUtil.java:264)
at
org.apache.tomcat.util.net.openssl.OpenSSLUtil.getTrustManagers(OpenSSLUtil.java:93)
at
org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:101)
... 20 more
4. I generated a new trustStore using “keytool -import -file myAlias.cer
-alias myAlias -keystore MyTrustStore”
then I adding truststoreFile="C:\keystore\MyTrustStore" to my Connector
and got the same PKIX error as 1 above.
5. finally I removed the truststoreFile attribute and used
-Djavax.net.ssl.trustStore="C:\keystore\MyTrustStore"
This worked...
Let me know if I've miss understanding your request or if there's something
else you'd like me to try.
Regards
Will
Re: 8.5.4 to 8.5.5 SSL Issue
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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
<Connector>. 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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org