-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 David,
On 9/8/20 03:58, David Weisgerber wrote: > I have some weird problem or bug with the HTTPS Connector. In our > product, that ships with tomcat we want to achieve the following: > > There is one keystore where the customer puts its server > certificate for HTTPs as well as (if intended) zero or one > certificate for client authentication. The certificate for client > authentication can be self-signed and the customer can setup its > own certificate authority for this. > > For this I put the following code for configuring the connector in > the server.xml:> <Connector port="8443" > protocol="org.apache.coyote.http11.Http11NioProtocol" > maxThreads="150" SSLEnabled="true" scheme="https" secure="true" > bindOnInit="false" clientAuth="false" sslProtocol="TLS" > keystoreFile="/diagdata/keystore.jks" keystorePass="custo1234" > keyAlias="main" truststoreFile="/diagdata/keystore.jks" > truststorePassword="custo1234" /> This should be okay, though it is a little unusual to use the same keystore for both "keys" and "trusted certs". Can you confirm the contents + types of everything in the keystore? > (The real clientAuth is done in the deployed application because it > is more complicated, I just need the feature to be enabled). This > gives me the following error: > org.apache.catalina.LifecycleException: Protocol handler start > failed <2> at > org.apache.catalina.connector.Connector.startInternal(Connector.java:1 038) > > <2> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) > <2> at > org.apache.catalina.core.StandardService.startInternal(StandardService .java:438) > > <2> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) > <2> at > org.apache.catalina.core.StandardServer.startInternal(StandardServer.j ava:930) > > <2> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) > <2> at > org.apache.catalina.startup.Catalina.start(Catalina.java:633) <2> > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) <2> at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeM ethodAccessorImpl.java:62) > > <2> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Deleg atingMethodAccessorImpl.java:43) > <2> at > java.base/java.lang.reflect.Method.invoke(Method.java:564) <2> > at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:343) > <2> at > org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:478) > <2>Caused by: java.lang.IllegalArgumentException: the trustAnchors > parameter must be non-empty <2> at > org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(Abstr actJsseEndpoint.java:99) > > <2> at org.apache.tomcat.util.net.AbstractJsseEndpoint.initialiseSsl(AbstractJs seEndpoint.java:71) > <2> at > org.apache.tomcat.util.net.NioEndpoint.bind(NioEndpoint.java:217) > <2> at > org.apache.tomcat.util.net.AbstractEndpoint.bindWithCleanup(AbstractEn dpoint.java:1141) > > <2> at org.apache.tomcat.util.net.AbstractEndpoint.start(AbstractEndpoint.java: 1227) > <2> at > org.apache.coyote.AbstractProtocol.start(AbstractProtocol.java:592) > > <2> at org.apache.catalina.connector.Connector.startInternal(Connector.java:103 5) > <2> ... 12 more <2>Caused by: > java.security.InvalidAlgorithmParameterException: the trustAnchors > parameter must be non-empty <2> at > java.base/java.security.cert.PKIXParameters.setTrustAnchors(PKIXParame ters.java:200) > > <2> at java.base/java.security.cert.PKIXParameters.<init>(PKIXParameters.java:1 57) > <2> at > java.base/java.security.cert.PKIXBuilderParameters.<init>(PKIXBuilderP arameters.java:130) > > <2> at org.apache.tomcat.util.net.SSLUtilBase.getParameters(SSLUtilBase.java:49 4) > <2> at > org.apache.tomcat.util.net.SSLUtilBase.getTrustManagers(SSLUtilBase.ja va:425) > > <2> at org.apache.tomcat.util.net.SSLUtilBase.createSSLContext(SSLUtilBase.java :247) > <2> at > org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(Abstr actJsseEndpoint.java:97) > > <2> ... 18 more > > The error goes away when I remove truststoreFile and > truststorePassword. Now comes the interesting part: The same > configuration works under Windows (with other paths of course) > using the Windows-Store as truststore for HTTPS connections to > other servers. The same configuration worked with Tomcat 8.5.4 and > the error just popped up from version 8.5.5. The error also seems > not to be based on the java version, I tried it with Java 8 and > Java 14. Under Windows we use Java 9... Are you really using Tomcat 8.5.4 and 8.5.5? If so, you are like 4 years out of date and there are published security vulnerabilities affecting your Tomcat version. Can you try with 8.5.latest which is currently 8.5.57? > Is this a Linux specific bug? That would be unusual, but certainly possible. Are you *sure* this works with no other changes other than: 1. Switching to Windows or 2. Switching to Tomcat 8.5.4? My guess is that the keystore is not bit-for-bit identical to your Windows or Tomcat 8.5.4 environments. > What is a trust anchor anyway? A trust anchor is a certificate which establishes trust in other certificates (which it has signed), or just to itself. Usually "trust anchors parameter must be non-empty" means that you have loaded a trust store which only contains "private keys" (which always contain a public key/certificate in a JKS file, which is really confusing) and no trusted-certificates. This would happen if you did "keytool -genkey blah blah" and didn't add any trusted certificates. If that's the problem, there are several ways to handle it: 1. Generate a dummy certificate and import it into your keystore: $ keytool -importcert -alias 'dummy' -keystore /diagdata/keystore.jks [paste cert here] 2. Export the server certificate and import it to trust itself $ keytool -exportcert -alias 'www.example.com' -rfc -keystore /diagdata/keystore.jks ====BEGIN CERTIFICATE===== blah blah blah =====END CERTIFICATE===== $ keytool -importcert -alias 'dummy' -keystore /diagdata/keystore.jks [paste cert here] 3. Import a "legitimate" certificate for client trust This is the thing you said should be "optional" for your clients. It may not be optional if Java gets really upset about it. You may want to tell your clients to use a dummy certificate if you don't feel comfortable doing it yourself. Theoretically, Tomcat could scan the trust store to see if there are any trusted certificates in there and, if not, wave its hands to make the problem go away. The problem is that maybe Tomcat doesn't know what your preferences are for fall-back plans. So, it's best to pick one of the above alternatives (or remove the trustStore-related configuration settings and allow the JVM to use the default trust store) . - -chris -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9XyDoACgkQHPApP6U8 pFijUQ/8DU5GP3iuQX2cJNkuIbKb7XwieU8ImwM4k7TI5Btj8d9eOtNqdpbinxge 5t6hhMfooY25hBC8RZDG/ZfBzdmqYUdv6sUvkf9hD+b5t5aOW7rQ8adfNnfPkO6S TaVSKbOqP5wXWg2YIvuvmHSmLZg6tJVzwJU1W52hOdnz7NsWxBxBRSJUheUaZ87i PKJcko/Km3dchTkWEV8TCTVvK0VAlpRKZIhl6D/s38z/JZ2cpzwLfTK+yB7mDRGs DbYw85tcTh3oxVaSU2V1YfX7i6GaIgtdx/N7yh5InSWP4w98VpT3odJrdc7WMc8+ 8KxP3jsS6TlPVm4r0sFeEK8adEO7ZX6l9CZ3JxIVoZbkxG/IRnZ8Oe1y7ghDRGxL wWsfKGMfri2Ijac3mpnvQLwVocrDxSPrTkBntis/r/hN+ups9Vp3WPGBP200Xg2Q InthJpId1AreiXITGrW73QoxgCcja9yS8rJ866ydH68/LiX8mN7SU5ZwuZzOQqol Q7TuwaAbQmzDezNOaa26qWFXZusQaye08mQOxaDMJoRC13oM07HeVfY8mmxw1YY6 6V2kQZf1BhsmVocUwKN1+rLRnxHYXgbJVZ1cRHc0l9XrTTOUbdpiyrVxjlTYAeQy q8RtRXwlq/Fnb/pssium9Wl1f+eJPutx26Pq77BG5k89gLXbrLc= =Dhwx -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
