From tjaalton at ubuntu.com Fri Jan 11 07:44:32 2019 From: tjaalton at ubuntu.com (Timo Aaltonen) Date: Fri, 11 Jan 2019 09:44:32 +0200 Subject: [Pki-users] Problems with java11 Message-ID: Hi I've migrated Debian to use java11 in every component Dogtag needs, but while the tomcat instance seems to get up (to be configured), it can't be properly reached: 2019-01-10 18:00:30 pkispawn : INFO Checking server at https://sid1.leon.tyrell:8443/ca 2019-01-10 18:01:56 pkispawn : ERROR Server unreachable due to SSL error: ("bad handshake: SysCallError(-1, 'Unexpected EOF')",) 2019-01-10 18:01:56 configuration : ERROR Server failed to restart and there's this on catalina.out: WARNING: The JSSE TLS 1.3 implementation does not support authentication after the initial handshake and is there fore incompatible with optional client authentication SEVERE: Failed to initialize component [Connector[org.dogtagpki.tomcat.Http11NioProtocol-8443]] org.apache.catalina.LifecycleException: Protocol handler initialization failed at org.apache.catalina.connector.Connector.initInternal(Connector.java:979) at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136) at org.apache.catalina.core.StandardService.initInternal(StandardService.java:535) at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136) at org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:1060) at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136) at org.apache.catalina.startup.Catalina.load(Catalina.java:588) at org.apache.catalina.startup.Catalina.load(Catalina.java:611) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:306) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:491) Caused by: java.lang.IllegalArgumentException: Alias name [sslserver] does not identify a key entry at org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:114) at org.apache.tomcat.util.net.AbstractJsseEndpoint.initialiseSsl(AbstractJsseEndpoint.java:85) at org.apache.tomcat.util.net.NioEndpoint.bind(NioEndpoint.java:224) at org.apache.tomcat.util.net.AbstractEndpoint.bindWithCleanup(AbstractEndpoint.java:1085) at org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:1098) at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:557) at org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Protocol.java:74) at org.apache.catalina.connector.Connector.initInternal(Connector.java:976) ... 13 more Caused by: java.io.IOException: Alias name [sslserver] does not identify a key entry at org.apache.tomcat.util.net.jsse.JSSEUtil.getKeyManagers(JSSEUtil.java:248) at org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:112) ... 20 more how to fix that? If this is fixed, Dogtag might finally end up in a Debian release :) -- t From ascheel at redhat.com Mon Jan 14 16:06:43 2019 From: ascheel at redhat.com (Alexander Scheel) Date: Mon, 14 Jan 2019 11:06:43 -0500 (EST) Subject: [Pki-users] Problems with java11 In-Reply-To: References: Message-ID: <1460203995.81219092.1547482003763.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Timo Aaltonen" > To: pki-users at redhat.com > Sent: Friday, January 11, 2019 2:44:32 AM > Subject: [Pki-users] Problems with java11 > > > Hi > > I've migrated Debian to use java11 in every component Dogtag needs, but while > the tomcat instance seems to get up (to be configured), it can't be properly > reached: > > 2019-01-10 18:00:30 pkispawn : INFO Checking server at > https://sid1.leon.tyrell:8443/ca > 2019-01-10 18:01:56 pkispawn : ERROR Server unreachable due to SSL > error: ("bad handshake: SysCallError(-1, 'Unexpected EOF')",) > 2019-01-10 18:01:56 configuration : ERROR Server failed to restart > > > and there's this on catalina.out: > > WARNING: The JSSE TLS 1.3 implementation does not support authentication > after the initial handshake and is there > fore incompatible with optional client authentication > SEVERE: Failed to initialize component > [Connector[org.dogtagpki.tomcat.Http11NioProtocol-8443]] > org.apache.catalina.LifecycleException: Protocol handler initialization > failed > at > org.apache.catalina.connector.Connector.initInternal(Connector.java:979) > at > org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136) > at > org.apache.catalina.core.StandardService.initInternal(StandardService.java:535) > at > org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136) > at > org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:1060) > at > org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136) > at org.apache.catalina.startup.Catalina.load(Catalina.java:588) > at org.apache.catalina.startup.Catalina.load(Catalina.java:611) > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:306) > at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:491) > Caused by: java.lang.IllegalArgumentException: Alias name [sslserver] does > not identify a key entry > at > org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:114) > at > org.apache.tomcat.util.net.AbstractJsseEndpoint.initialiseSsl(AbstractJsseEndpoint.java:85) > at org.apache.tomcat.util.net.NioEndpoint.bind(NioEndpoint.java:224) > at > org.apache.tomcat.util.net.AbstractEndpoint.bindWithCleanup(AbstractEndpoint.java:1085) > at > org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:1098) > at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:557) > at > org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Protocol.java:74) > at > org.apache.catalina.connector.Connector.initInternal(Connector.java:976) > ... 13 more > Caused by: java.io.IOException: Alias name [sslserver] does not identify a > key entry > at > org.apache.tomcat.util.net.jsse.JSSEUtil.getKeyManagers(JSSEUtil.java:248) > at > org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:112) > ... 20 more > > how to fix that? If this is fixed, Dogtag might finally end up in a Debian > release :) > So my 2c. on this issue -- I don't have a reproducing setup at the moment but... TomcatJSS for Tomcat versions greater than 8.5 are... misnamed? :) It technically is TomcatJSSE (i.e., using Java's JSSE as the crypto backend for TLS auth in Tomcat vs. using JSS/NSS). So it appears that JSSE lacks support for optional client authentication as per the error message: > WARNING: The JSSE TLS 1.3 implementation does not support authentication > after the initial handshake and is therefore incompatible with optional > client authentication In PKI's server.xml for tomcat 8.5+, we don't currently set the clientAuth parameter, so we use the default of "want": https://github.com/dogtagpki/pki/blob/master/base/server/tomcat-8.5/conf/server.xml#L151 https://github.com/dogtagpki/tomcatjss/blob/master/src/org/apache/tomcat/util/net/jss/TomcatJSS.java#L72 You'll probably want to ship clientAuth="true" as a work around on JDK 11+ and document that clientAuth="want" will not work for the time being. On the other hand, this ~does~ require end users to set up client authentication to access the page... (edewata mentioned that you can have two separate PKI servers, one for the admin pages with clientAuth="true" and one for end entity services with clientAuth="false"). Eventually a new TomcatJSS with JSS support in Tomcat 8.5+ will be released, so this issue will be fixed as JSS/NSS should support this type of optional client authentication (but will need to be tested). (It also isn't clear whether or not JDK8 supports TLS 1.3+). -- Alex > > -- > t > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users > From tjaalton at ubuntu.com Tue Jan 15 13:22:49 2019 From: tjaalton at ubuntu.com (Timo Aaltonen) Date: Tue, 15 Jan 2019 15:22:49 +0200 Subject: [Pki-users] Problems with java11 In-Reply-To: <1460203995.81219092.1547482003763.JavaMail.zimbra@redhat.com> References: <1460203995.81219092.1547482003763.JavaMail.zimbra@redhat.com> Message-ID: <26357b78-8d91-ccd8-aee9-6a38f4aa962f@ubuntu.com> On 14.1.2019 18.06, Alexander Scheel wrote: > > > ----- Original Message ----- >> From: "Timo Aaltonen" >> To: pki-users at redhat.com >> Sent: Friday, January 11, 2019 2:44:32 AM >> Subject: [Pki-users] Problems with java11 >> >> >> Hi >> >> I've migrated Debian to use java11 in every component Dogtag needs, but while >> the tomcat instance seems to get up (to be configured), it can't be properly >> reached: >> >> 2019-01-10 18:00:30 pkispawn : INFO Checking server at >> https://sid1.leon.tyrell:8443/ca >> 2019-01-10 18:01:56 pkispawn : ERROR Server unreachable due to SSL >> error: ("bad handshake: SysCallError(-1, 'Unexpected EOF')",) >> 2019-01-10 18:01:56 configuration : ERROR Server failed to restart >> >> >> and there's this on catalina.out: >> >> WARNING: The JSSE TLS 1.3 implementation does not support authentication >> after the initial handshake and is there >> fore incompatible with optional client authentication >> SEVERE: Failed to initialize component >> [Connector[org.dogtagpki.tomcat.Http11NioProtocol-8443]] >> org.apache.catalina.LifecycleException: Protocol handler initialization >> failed >> at >> org.apache.catalina.connector.Connector.initInternal(Connector.java:979) >> at >> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136) >> at >> org.apache.catalina.core.StandardService.initInternal(StandardService.java:535) >> at >> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136) >> at >> org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:1060) >> at >> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136) >> at org.apache.catalina.startup.Catalina.load(Catalina.java:588) >> at org.apache.catalina.startup.Catalina.load(Catalina.java:611) >> at >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >> Method) >> at >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >> at >> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.base/java.lang.reflect.Method.invoke(Method.java:566) >> at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:306) >> at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:491) >> Caused by: java.lang.IllegalArgumentException: Alias name [sslserver] does >> not identify a key entry >> at >> org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:114) >> at >> org.apache.tomcat.util.net.AbstractJsseEndpoint.initialiseSsl(AbstractJsseEndpoint.java:85) >> at org.apache.tomcat.util.net.NioEndpoint.bind(NioEndpoint.java:224) >> at >> org.apache.tomcat.util.net.AbstractEndpoint.bindWithCleanup(AbstractEndpoint.java:1085) >> at >> org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:1098) >> at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:557) >> at >> org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Protocol.java:74) >> at >> org.apache.catalina.connector.Connector.initInternal(Connector.java:976) >> ... 13 more >> Caused by: java.io.IOException: Alias name [sslserver] does not identify a >> key entry >> at >> org.apache.tomcat.util.net.jsse.JSSEUtil.getKeyManagers(JSSEUtil.java:248) >> at >> org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:112) >> ... 20 more >> >> how to fix that? If this is fixed, Dogtag might finally end up in a Debian >> release :) >> > > So my 2c. on this issue -- I don't have a reproducing setup at the moment > but... > > TomcatJSS for Tomcat versions greater than 8.5 are... misnamed? :) It > technically is TomcatJSSE (i.e., using Java's JSSE as the crypto backend for > TLS auth in Tomcat vs. using JSS/NSS). > > So it appears that JSSE lacks support for optional client authentication > as per the error message: > >> WARNING: The JSSE TLS 1.3 implementation does not support authentication >> after the initial handshake and is therefore incompatible with optional >> client authentication > > In PKI's server.xml for tomcat 8.5+, we don't currently set the clientAuth > parameter, so we use the default of "want": > > https://github.com/dogtagpki/pki/blob/master/base/server/tomcat-8.5/conf/server.xml#L151 > https://github.com/dogtagpki/tomcatjss/blob/master/src/org/apache/tomcat/util/net/jss/TomcatJSS.java#L72 > > > You'll probably want to ship clientAuth="true" as a work around on JDK 11+ > and document that clientAuth="want" will not work for the time being. On the > other hand, this ~does~ require end users to set up client authentication to > access the page... Doing this (and fixing pki-migrate to not remove that setting) then resulted in this: SEVERE: End event threw exception java.lang.reflect.InvocationTargetException at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at org.apache.tomcat.util.IntrospectionUtils.callMethod1(IntrospectionUtils.java:373) at org.apache.tomcat.util.digester.SetNextRule.end(SetNextRule.java:145) at org.apache.tomcat.util.digester.Digester.endElement(Digester.java:944) at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanEndElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source) at org.apache.tomcat.util.digester.Digester.parse(Digester.java:1439) at org.apache.catalina.startup.Catalina.load(Catalina.java:566) at org.apache.catalina.startup.Catalina.load(Catalina.java:611) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:306) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:491) Caused by: java.lang.IllegalArgumentException: Multiple SSLHostConfig elements were provided for the host name [_default_]. Host names must be unique. at org.apache.tomcat.util.net.AbstractEndpoint.addSslHostConfig(AbstractEndpoint.java:248) at org.apache.tomcat.util.net.AbstractEndpoint.addSslHostConfig(AbstractEndpoint.java:203) at org.apache.coyote.http11.AbstractHttp11Protocol.addSslHostConfig(AbstractHttp11Protocol.java:542) at org.apache.catalina.connector.Connector.addSslHostConfig(Connector.java:834) ... 25 more WARNING: Unable to load server configuration from [/var/lib/pki/pki-tomcat/conf/server.xml] org.xml.sax.SAXParseException; systemId: file:/var/lib/pki/pki-tomcat/conf/server.xml; lineNumber: 188; columnNumber: 25; Error at (188, 25) : Multiple SSLHostConfig elements were provided for the host name [_default_]. Host names must be unique. at org.apache.tomcat.util.digester.Digester.createSAXException(Digester.java:1862) at org.apache.tomcat.util.digester.Digester.createSAXException(Digester.java:1894) at org.apache.tomcat.util.digester.Digester.endElement(Digester.java:947) at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanEndElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source) at org.apache.tomcat.util.digester.Digester.parse(Digester.java:1439) at org.apache.catalina.startup.Catalina.load(Catalina.java:566) at org.apache.catalina.startup.Catalina.load(Catalina.java:611) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:306) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:491) Caused by: java.lang.IllegalArgumentException: Multiple SSLHostConfig elements were provided for the host name [_default_]. Host names must be unique. at org.apache.tomcat.util.net.AbstractEndpoint.addSslHostConfig(AbstractEndpoint.java:248) at org.apache.tomcat.util.net.AbstractEndpoint.addSslHostConfig(AbstractEndpoint.java:203) at org.apache.coyote.http11.AbstractHttp11Protocol.addSslHostConfig(AbstractHttp11Protocol.java:542) at org.apache.catalina.connector.Connector.addSslHostConfig(Connector.java:834) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at org.apache.tomcat.util.IntrospectionUtils.callMethod1(IntrospectionUtils.java:373) at org.apache.tomcat.util.digester.SetNextRule.end(SetNextRule.java:145) at org.apache.tomcat.util.digester.Digester.endElement(Digester.java:944) ... 18 more SEVERE: Cannot start server. Server instance is not configured. and this is in server.xml: 182 185 188 > Eventually a new TomcatJSS with JSS support in Tomcat 8.5+ will be released, > so this issue will be fixed as JSS/NSS should support this type of optional > client authentication (but will need to be tested). Any idea when that would be? Debian 10 will be frozen in a month. -- t From edewata at redhat.com Tue Jan 15 14:46:01 2019 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 15 Jan 2019 09:46:01 -0500 (EST) Subject: [Pki-users] Problems with java11 In-Reply-To: <26357b78-8d91-ccd8-aee9-6a38f4aa962f@ubuntu.com> References: <1460203995.81219092.1547482003763.JavaMail.zimbra@redhat.com> <26357b78-8d91-ccd8-aee9-6a38f4aa962f@ubuntu.com> Message-ID: <1886433601.72448813.1547563561310.JavaMail.zimbra@redhat.com> Hi, The error message is not very helpful, but I think this error happens because the clientAuth in Connector has been replaced by certificateVerification in SSLHostConfig and they cannot be specified at the same time. See the following page: https://tomcat.apache.org/tomcat-8.5-doc/config/http.html So try removing the clientAuth and set the certificateVerification to "required". I have not tried this myself though. -- Endi S. Dewata ----- Original Message ----- > On 14.1.2019 18.06, Alexander Scheel wrote: > > > > > > ----- Original Message ----- > >> From: "Timo Aaltonen" > >> To: pki-users at redhat.com > >> Sent: Friday, January 11, 2019 2:44:32 AM > >> Subject: [Pki-users] Problems with java11 > >> > >> > >> Hi > >> > >> I've migrated Debian to use java11 in every component Dogtag needs, but > >> while > >> the tomcat instance seems to get up (to be configured), it can't be > >> properly > >> reached: > >> > >> 2019-01-10 18:00:30 pkispawn : INFO Checking server at > >> https://sid1.leon.tyrell:8443/ca > >> 2019-01-10 18:01:56 pkispawn : ERROR Server unreachable due to SSL > >> error: ("bad handshake: SysCallError(-1, 'Unexpected EOF')",) > >> 2019-01-10 18:01:56 configuration : ERROR Server failed to restart > >> > >> > >> and there's this on catalina.out: > >> > >> WARNING: The JSSE TLS 1.3 implementation does not support authentication > >> after the initial handshake and is there > >> fore incompatible with optional client authentication > >> SEVERE: Failed to initialize component > >> [Connector[org.dogtagpki.tomcat.Http11NioProtocol-8443]] > >> org.apache.catalina.LifecycleException: Protocol handler initialization > >> failed > >> at > >> org.apache.catalina.connector.Connector.initInternal(Connector.java:979) > >> at > >> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136) > >> at > >> org.apache.catalina.core.StandardService.initInternal(StandardService.java:535) > >> at > >> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136) > >> at > >> org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:1060) > >> at > >> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136) > >> at org.apache.catalina.startup.Catalina.load(Catalina.java:588) > >> at org.apache.catalina.startup.Catalina.load(Catalina.java:611) > >> at > >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > >> Method) > >> at > >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > >> at > >> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > >> at java.base/java.lang.reflect.Method.invoke(Method.java:566) > >> at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:306) > >> at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:491) > >> Caused by: java.lang.IllegalArgumentException: Alias name [sslserver] does > >> not identify a key entry > >> at > >> org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:114) > >> at > >> org.apache.tomcat.util.net.AbstractJsseEndpoint.initialiseSsl(AbstractJsseEndpoint.java:85) > >> at > >> org.apache.tomcat.util.net.NioEndpoint.bind(NioEndpoint.java:224) > >> at > >> org.apache.tomcat.util.net.AbstractEndpoint.bindWithCleanup(AbstractEndpoint.java:1085) > >> at > >> org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:1098) > >> at > >> org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:557) > >> at > >> org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Protocol.java:74) > >> at > >> org.apache.catalina.connector.Connector.initInternal(Connector.java:976) > >> ... 13 more > >> Caused by: java.io.IOException: Alias name [sslserver] does not identify a > >> key entry > >> at > >> org.apache.tomcat.util.net.jsse.JSSEUtil.getKeyManagers(JSSEUtil.java:248) > >> at > >> org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:112) > >> ... 20 more > >> > >> how to fix that? If this is fixed, Dogtag might finally end up in a Debian > >> release :) > >> > > > > So my 2c. on this issue -- I don't have a reproducing setup at the moment > > but... > > > > TomcatJSS for Tomcat versions greater than 8.5 are... misnamed? :) It > > technically is TomcatJSSE (i.e., using Java's JSSE as the crypto backend > > for > > TLS auth in Tomcat vs. using JSS/NSS). > > > > So it appears that JSSE lacks support for optional client authentication > > as per the error message: > > > >> WARNING: The JSSE TLS 1.3 implementation does not support authentication > >> after the initial handshake and is therefore incompatible with optional > >> client authentication > > > > In PKI's server.xml for tomcat 8.5+, we don't currently set the clientAuth > > parameter, so we use the default of "want": > > > > https://github.com/dogtagpki/pki/blob/master/base/server/tomcat-8.5/conf/server.xml#L151 > > https://github.com/dogtagpki/tomcatjss/blob/master/src/org/apache/tomcat/util/net/jss/TomcatJSS.java#L72 > > > > > > You'll probably want to ship clientAuth="true" as a work around on JDK 11+ > > and document that clientAuth="want" will not work for the time being. On > > the > > other hand, this ~does~ require end users to set up client authentication > > to > > access the page... > > Doing this (and fixing pki-migrate to not remove that setting) then resulted > in this: > > SEVERE: End event threw exception > java.lang.reflect.InvocationTargetException > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at > org.apache.tomcat.util.IntrospectionUtils.callMethod1(IntrospectionUtils.java:373) > at > org.apache.tomcat.util.digester.SetNextRule.end(SetNextRule.java:145) > at > org.apache.tomcat.util.digester.Digester.endElement(Digester.java:944) > at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown > Source) > at > org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanEndElement(Unknown > Source) > at > org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown > Source) > at > org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown > Source) > at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) > at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) > at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) > at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) > at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown > Source) > at org.apache.tomcat.util.digester.Digester.parse(Digester.java:1439) > at org.apache.catalina.startup.Catalina.load(Catalina.java:566) > at org.apache.catalina.startup.Catalina.load(Catalina.java:611) > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:306) > at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:491) > Caused by: java.lang.IllegalArgumentException: Multiple SSLHostConfig > elements were provided for the host name [_default_]. Host names must be > unique. > at > org.apache.tomcat.util.net.AbstractEndpoint.addSslHostConfig(AbstractEndpoint.java:248) > at > org.apache.tomcat.util.net.AbstractEndpoint.addSslHostConfig(AbstractEndpoint.java:203) > at > org.apache.coyote.http11.AbstractHttp11Protocol.addSslHostConfig(AbstractHttp11Protocol.java:542) > at > org.apache.catalina.connector.Connector.addSslHostConfig(Connector.java:834) > ... 25 more > > WARNING: Unable to load server configuration from > [/var/lib/pki/pki-tomcat/conf/server.xml] > org.xml.sax.SAXParseException; systemId: > file:/var/lib/pki/pki-tomcat/conf/server.xml; lineNumber: 188; columnNumber: > 25; Error at (188, 25) : Multiple SSLHostConfig elements were provided for > the host name [_default_]. Host names must be unique. > at > org.apache.tomcat.util.digester.Digester.createSAXException(Digester.java:1862) > at > org.apache.tomcat.util.digester.Digester.createSAXException(Digester.java:1894) > at > org.apache.tomcat.util.digester.Digester.endElement(Digester.java:947) > at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown > Source) > at > org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanEndElement(Unknown > Source) > at > org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown > Source) > at > org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown > Source) > at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) > at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) > at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) > at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) > at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown > Source) > at org.apache.tomcat.util.digester.Digester.parse(Digester.java:1439) > at org.apache.catalina.startup.Catalina.load(Catalina.java:566) > at org.apache.catalina.startup.Catalina.load(Catalina.java:611) > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:306) > at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:491) > Caused by: java.lang.IllegalArgumentException: Multiple SSLHostConfig > elements were provided for the host name [_default_]. Host names must be > unique. > at > org.apache.tomcat.util.net.AbstractEndpoint.addSslHostConfig(AbstractEndpoint.java:248) > at > org.apache.tomcat.util.net.AbstractEndpoint.addSslHostConfig(AbstractEndpoint.java:203) > at > org.apache.coyote.http11.AbstractHttp11Protocol.addSslHostConfig(AbstractHttp11Protocol.java:542) > at > org.apache.catalina.connector.Connector.addSslHostConfig(Connector.java:834) > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at > org.apache.tomcat.util.IntrospectionUtils.callMethod1(IntrospectionUtils.java:373) > at > org.apache.tomcat.util.digester.SetNextRule.end(SetNextRule.java:145) > at > org.apache.tomcat.util.digester.Digester.endElement(Digester.java:944) > ... 18 more > > SEVERE: Cannot start server. Server instance is not configured. > > > and this is in server.xml: > > 182 183 certificateVerification="optional" > 184 > trustManagerClassName="org.dogtagpki.tomcat.PKITrustManager"> > 185 186 certificateKeystoreProvider="Mozilla-JSS" > 187 certificateKeyAlias="sslserver"/> > 188 > > > Eventually a new TomcatJSS with JSS support in Tomcat 8.5+ will be > > released, > > so this issue will be fixed as JSS/NSS should support this type of optional > > client authentication (but will need to be tested). > > Any idea when that would be? Debian 10 will be frozen in a month. > > > -- > t > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users > From tjaalton at ubuntu.com Tue Jan 15 16:43:35 2019 From: tjaalton at ubuntu.com (Timo Aaltonen) Date: Tue, 15 Jan 2019 18:43:35 +0200 Subject: [Pki-users] Problems with java11 In-Reply-To: <1886433601.72448813.1547563561310.JavaMail.zimbra@redhat.com> References: <1460203995.81219092.1547482003763.JavaMail.zimbra@redhat.com> <26357b78-8d91-ccd8-aee9-6a38f4aa962f@ubuntu.com> <1886433601.72448813.1547563561310.JavaMail.zimbra@redhat.com> Message-ID: <5d7d6b5c-4c47-6f42-8c7f-cdcac7cf0347@ubuntu.com> On 15.1.2019 16.46, Endi Sukma Dewata wrote: > Hi, > > The error message is not very helpful, but I think this error > happens because the clientAuth in Connector has been replaced > by certificateVerification in SSLHostConfig and they cannot be > specified at the same time. See the following page: > https://tomcat.apache.org/tomcat-8.5-doc/config/http.html > > So try removing the clientAuth and set the certificateVerification > to "required". I have not tried this myself though. nope, still get the same -- t From edewata at redhat.com Tue Jan 15 17:25:59 2019 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 15 Jan 2019 12:25:59 -0500 (EST) Subject: [Pki-users] Problems with java11 In-Reply-To: <5d7d6b5c-4c47-6f42-8c7f-cdcac7cf0347@ubuntu.com> References: <1460203995.81219092.1547482003763.JavaMail.zimbra@redhat.com> <26357b78-8d91-ccd8-aee9-6a38f4aa962f@ubuntu.com> <1886433601.72448813.1547563561310.JavaMail.zimbra@redhat.com> <5d7d6b5c-4c47-6f42-8c7f-cdcac7cf0347@ubuntu.com> Message-ID: <135941273.72492040.1547573159253.JavaMail.zimbra@redhat.com> ----- Original Message ----- > On 15.1.2019 16.46, Endi Sukma Dewata wrote: > > Hi, > > > > The error message is not very helpful, but I think this error > > happens because the clientAuth in Connector has been replaced > > by certificateVerification in SSLHostConfig and they cannot be > > specified at the same time. See the following page: > > https://tomcat.apache.org/tomcat-8.5-doc/config/http.html > > > > So try removing the clientAuth and set the certificateVerification > > to "required". I have not tried this myself though. > > nope, still get the same > > > -- > t > Could you show me the entire Connector element and its children? Make sure all attributes replaced by SSLHostConfig have been deleted from the Connector element (see the above link). -- Endi S. Dewata From tjaalton at ubuntu.com Tue Jan 15 17:40:23 2019 From: tjaalton at ubuntu.com (Timo Aaltonen) Date: Tue, 15 Jan 2019 19:40:23 +0200 Subject: [Pki-users] Problems with java11 In-Reply-To: <135941273.72492040.1547573159253.JavaMail.zimbra@redhat.com> References: <1460203995.81219092.1547482003763.JavaMail.zimbra@redhat.com> <26357b78-8d91-ccd8-aee9-6a38f4aa962f@ubuntu.com> <1886433601.72448813.1547563561310.JavaMail.zimbra@redhat.com> <5d7d6b5c-4c47-6f42-8c7f-cdcac7cf0347@ubuntu.com> <135941273.72492040.1547573159253.JavaMail.zimbra@redhat.com> Message-ID: On 15.1.2019 19.25, Endi Sukma Dewata wrote: > ----- Original Message ----- >> On 15.1.2019 16.46, Endi Sukma Dewata wrote: >>> Hi, >>> >>> The error message is not very helpful, but I think this error >>> happens because the clientAuth in Connector has been replaced >>> by certificateVerification in SSLHostConfig and they cannot be >>> specified at the same time. See the following page: >>> https://tomcat.apache.org/tomcat-8.5-doc/config/http.html >>> >>> So try removing the clientAuth and set the certificateVerification >>> to "required". I have not tried this myself though. >> >> nope, still get the same >> >> >> -- >> t >> > > Could you show me the entire Connector element and its children? > Make sure all attributes replaced by SSLHostConfig have been > deleted from the Connector element (see the above link). I don't see what should be dropped from Connector.. -- t From edewata at redhat.com Tue Jan 15 19:03:22 2019 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 15 Jan 2019 14:03:22 -0500 (EST) Subject: [Pki-users] Problems with java11 In-Reply-To: References: <1460203995.81219092.1547482003763.JavaMail.zimbra@redhat.com> <26357b78-8d91-ccd8-aee9-6a38f4aa962f@ubuntu.com> <1886433601.72448813.1547563561310.JavaMail.zimbra@redhat.com> <5d7d6b5c-4c47-6f42-8c7f-cdcac7cf0347@ubuntu.com> <135941273.72492040.1547573159253.JavaMail.zimbra@redhat.com> Message-ID: <545838969.72507732.1547579002049.JavaMail.zimbra@redhat.com> ----- Original Message ----- > >>> The error message is not very helpful, but I think this error > >>> happens because the clientAuth in Connector has been replaced > >>> by certificateVerification in SSLHostConfig and they cannot be > >>> specified at the same time. See the following page: > >>> https://tomcat.apache.org/tomcat-8.5-doc/config/http.html > >>> > >>> So try removing the clientAuth and set the certificateVerification > >>> to "required". I have not tried this myself though. > >> > >> nope, still get the same > > > > Could you show me the entire Connector element and its children? > > Make sure all attributes replaced by SSLHostConfig have been > > deleted from the Connector element (see the above link). > > port="8443" > protocol="org.dogtagpki.tomcat.Http11NioProtocol" > SSLEnabled="true" > scheme="https" > secure="true" > connectionTimeout="80000" > keepAliveTimeout="300000" > maxHttpHeaderSize="8192" > acceptCount="100" > maxThreads="150" > minSpareThreads="25" > enableLookups="false" > disableUploadTimeout="true" > enableOCSP="false" > ocspResponderURL="http://sid1.leon.tyrell:8080/ca/ocsp" > ocspResponderCertNickname="ocspSigningCert cert-pki-ca" > ocspCacheSize="1000" > ocspMinCacheEntryDuration="7200" > ocspMaxCacheEntryDuration="14400" > ocspTimeout="10" > strictCiphers="true" > sslVersionRangeStream="tls1_1:tls1_2" > sslVersionRangeDatagram="tls1_1:tls1_2" > sslRangeCiphers="-TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,-TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA,-TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA,-TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,-TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,-TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,-TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,-TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA,-TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,-TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,+TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,+TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,-TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA,-TLS_DHE_DSS_WITH_AES_128_CBC_SHA,-TLS_DHE_DSS_WITH_AES_256_CBC_SHA,-TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA,+TLS_DHE_RSA_WITH_AES_128_CBC_SHA,+TLS_DHE_RSA_WITH_AES_256_CBC_SHA,+TLS_DHE_RSA_WITH_AES_128_CBC_SHA256,+TLS_DHE_RSA_WITH_AES_256_CBC_SHA256,+TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,-TLS_DHE_DSS_WITH_AES_128_GCM_SHA256,-TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,+TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,-TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,+TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,-TLS_RSA_WITH_AES_128_CBC_SHA256,-TLS_RSA_WITH_AES_256_CBC_SHA256,-TLS_RSA_WITH_AES_128_GCM_SHA256,-TLS_RSA_WITH_3DES_EDE_CBC_SHA,-TLS_RSA_WITH_AES_128_CBC_SHA,-TLS_RSA_WITH_AES_256_CBC_SHA,+TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,+TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,+TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,-TLS_RSA_WITH_AES_256_GCM_SHA384" > serverCertNickFile="/var/lib/pki/pki-tomcat/conf/serverCertNick.conf" > passwordFile="/var/lib/pki/pki-tomcat/conf/password.conf" > passwordClass="org.apache.tomcat.util.net.jss.PlainPasswordFile" > certdbDir="/var/lib/pki/pki-tomcat/alias"> > > certificateVerification="required" > trustManagerClassName="org.dogtagpki.tomcat.PKITrustManager"> > certificateKeystoreProvider="Mozilla-JSS" > certificateKeyAlias="sslserver"/> > > > > > > I don't see what should be dropped from Connector.. Are you getting this error: java.lang.IllegalArgumentException: Alias name [sslserver] does not identify a key entry or this error? java.lang.IllegalArgumentException: Multiple SSLHostConfig elements were provided for the host name [_default_]. Host names must be unique. If it's the first one, that means the PKCS #11 keystore (i.e. JSS keystore) cannot find the SSL server certificate. We may not have a solution since we do not support Java 11 yet. If it's the second one, that message is coming from Tomcat when validating the server.xml. Is certificateVerification the only thing you change in that file? You might want to try adding defaultSSLHostConfigName to Connector and hostName to SSLHostConfig, but I'm really not sure what's going on. See also this page: https://stackoverflow.com/questions/42135892/tomcat-8-5-server-xml-multiple-sslhostconfig-elements-were-provided-for-the-ho If you put any of these deprecated attributes in the Connector directive, tomcat assumes you are using the old way and auto creates a SSLHostConfig itself, which then conflicts with the one you are creating. -- Endi S. Dewata From dmoluguw at redhat.com Tue Jan 15 19:20:16 2019 From: dmoluguw at redhat.com (Dinesh Prasanth Moluguwan Krishnamoorthy) Date: Tue, 15 Jan 2019 14:20:16 -0500 Subject: [Pki-users] New Release: PKI-10.6.9 and JSS-4.5.2 Message-ID: Hi everyone! I'm happy to announce the next new release of PKI 10.6.9 and JSS 4.5.2. PKI 10.6.9 is now available upstream: https://github.com/dogtagpki/pki/releases/tag/v10.6.9 https://github.com/dogtagpki/jss/releases/tag/v4.5.2 Fedora 29 builds are available via the following update: https://bodhi.fedoraproject.org/updates/FEDORA-2019-7f8a0793f1 https://bodhi.fedoraproject.org/updates/FEDORA-2019-94922829c1 Fedora 28 builds are available via the following update: https://bodhi.fedoraproject.org/updates/FEDORA-2019-10739882f4 https://bodhi.fedoraproject.org/updates/FEDORA-2019-a9f84d8cf6 Fedora Rawhide builds are available in Koji. We have official COPR builds available at: https://copr.fedorainfracloud.org/coprs/g/pki/10.6/builds/ Please feel free to try it out. We would love to hear issues/feedbacks from you! Regards, Dinesh From tjaalton at ubuntu.com Tue Jan 15 19:49:50 2019 From: tjaalton at ubuntu.com (Timo Aaltonen) Date: Tue, 15 Jan 2019 21:49:50 +0200 Subject: [Pki-users] Problems with java11 In-Reply-To: <545838969.72507732.1547579002049.JavaMail.zimbra@redhat.com> References: <1460203995.81219092.1547482003763.JavaMail.zimbra@redhat.com> <26357b78-8d91-ccd8-aee9-6a38f4aa962f@ubuntu.com> <1886433601.72448813.1547563561310.JavaMail.zimbra@redhat.com> <5d7d6b5c-4c47-6f42-8c7f-cdcac7cf0347@ubuntu.com> <135941273.72492040.1547573159253.JavaMail.zimbra@redhat.com> <545838969.72507732.1547579002049.JavaMail.zimbra@redhat.com> Message-ID: <1b75a762-5f93-d87a-bc60-994e8f1573b7@ubuntu.com> On 15.1.2019 21.03, Endi Sukma Dewata wrote: > ----- Original Message ----- >>>>> The error message is not very helpful, but I think this error >>>>> happens because the clientAuth in Connector has been replaced >>>>> by certificateVerification in SSLHostConfig and they cannot be >>>>> specified at the same time. See the following page: >>>>> https://tomcat.apache.org/tomcat-8.5-doc/config/http.html >>>>> >>>>> So try removing the clientAuth and set the certificateVerification >>>>> to "required". I have not tried this myself though. >>>> >>>> nope, still get the same >>> >>> Could you show me the entire Connector element and its children? >>> Make sure all attributes replaced by SSLHostConfig have been >>> deleted from the Connector element (see the above link). >> >> > port="8443" >> protocol="org.dogtagpki.tomcat.Http11NioProtocol" >> SSLEnabled="true" >> scheme="https" >> secure="true" >> connectionTimeout="80000" >> keepAliveTimeout="300000" >> maxHttpHeaderSize="8192" >> acceptCount="100" >> maxThreads="150" >> minSpareThreads="25" >> enableLookups="false" >> disableUploadTimeout="true" >> enableOCSP="false" >> ocspResponderURL="http://sid1.leon.tyrell:8080/ca/ocsp" >> ocspResponderCertNickname="ocspSigningCert cert-pki-ca" >> ocspCacheSize="1000" >> ocspMinCacheEntryDuration="7200" >> ocspMaxCacheEntryDuration="14400" >> ocspTimeout="10" >> strictCiphers="true" >> sslVersionRangeStream="tls1_1:tls1_2" >> sslVersionRangeDatagram="tls1_1:tls1_2" >> sslRangeCiphers="-TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,-TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA,-TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA,-TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,-TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,-TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,-TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,-TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA,-TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,-TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,+TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,+TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,-TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA,-TLS_DHE_DSS_WITH_AES_128_CBC_SHA,-TLS_DHE_DSS_WITH_AES_256_CBC_SHA,-TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA,+TLS_DHE_RSA_WITH_AES_128_CBC_SHA,+TLS_DHE_RSA_WITH_AES_256_CBC_SHA,+TLS_DHE_RSA_WITH_AES_128_CBC_SHA256,+TLS_DHE_RSA_WITH_AES_256_CBC_SHA256,+TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,-TLS_DHE_DSS_WITH_AES_128_GCM_SHA256,-TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,+TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,-TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,+TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,-TLS_RSA_WITH_AES_128_CBC_SHA256,-TLS_RSA_WITH_AES_256_CBC_SHA256,-TLS_RSA_WITH_AES_128_GCM_SHA256,-TLS_RSA_WITH_3DES_EDE_CBC_SHA,-TLS_RSA_WITH_AES_128_CBC_SHA,-TLS_RSA_WITH_AES_256_CBC_SHA,+TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,+TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,+TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,-TLS_RSA_WITH_AES_256_GCM_SHA384" >> serverCertNickFile="/var/lib/pki/pki-tomcat/conf/serverCertNick.conf" >> passwordFile="/var/lib/pki/pki-tomcat/conf/password.conf" >> passwordClass="org.apache.tomcat.util.net.jss.PlainPasswordFile" >> certdbDir="/var/lib/pki/pki-tomcat/alias"> >> >> > certificateVerification="required" >> trustManagerClassName="org.dogtagpki.tomcat.PKITrustManager"> >> > certificateKeystoreProvider="Mozilla-JSS" >> certificateKeyAlias="sslserver"/> >> >> >> >> >> >> I don't see what should be dropped from Connector.. > > Are you getting this error: > > java.lang.IllegalArgumentException: Alias name [sslserver] does not identify a key > entry > > or this error? > > java.lang.IllegalArgumentException: Multiple SSLHostConfig elements were provided > for the host name [_default_]. Host names must be unique. > > If it's the first one, that means the PKCS #11 keystore (i.e. JSS keystore) cannot > find the SSL server certificate. We may not have a solution since we do not support > Java 11 yet. But I've patched Dogtag to support the new keystore, and am using JSS 4.5.1, I thought they did support Java 11.. so something is missing still then.. > If it's the second one, that message is coming from Tomcat when validating the > server.xml. Is certificateVerification the only thing you change in that file? You > might want to try adding defaultSSLHostConfigName to Connector and hostName to > SSLHostConfig, but I'm really not sure what's going on. > > See also this page: > https://stackoverflow.com/questions/42135892/tomcat-8-5-server-xml-multiple-sslhostconfig-elements-were-provided-for-the-ho > > If you put any of these deprecated attributes in the Connector directive, tomcat > assumes you are using the old way and auto creates a SSLHostConfig itself, which > then conflicts with the one you are creating. > > -- > Endi S. Dewata > -- t From edewata at redhat.com Tue Jan 15 20:39:37 2019 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 15 Jan 2019 15:39:37 -0500 (EST) Subject: [Pki-users] Problems with java11 In-Reply-To: <1b75a762-5f93-d87a-bc60-994e8f1573b7@ubuntu.com> References: <26357b78-8d91-ccd8-aee9-6a38f4aa962f@ubuntu.com> <1886433601.72448813.1547563561310.JavaMail.zimbra@redhat.com> <5d7d6b5c-4c47-6f42-8c7f-cdcac7cf0347@ubuntu.com> <135941273.72492040.1547573159253.JavaMail.zimbra@redhat.com> <545838969.72507732.1547579002049.JavaMail.zimbra@redhat.com> <1b75a762-5f93-d87a-bc60-994e8f1573b7@ubuntu.com> Message-ID: <1029669299.72524396.1547584777587.JavaMail.zimbra@redhat.com> ----- Original Message ----- > > Are you getting this error: > > > > java.lang.IllegalArgumentException: Alias name [sslserver] does not > > identify a key > > entry > > > > or this error? > > > > java.lang.IllegalArgumentException: Multiple SSLHostConfig elements were > > provided > > for the host name [_default_]. Host names must be unique. > > > > If it's the first one, that means the PKCS #11 keystore (i.e. JSS keystore) > > cannot > > find the SSL server certificate. We may not have a solution since we do not > > support > > Java 11 yet. > > But I've patched Dogtag to support the new keystore, and am using JSS > 4.5.1, I thought they did support Java 11.. so something is missing > still then.. IIUC JSS was updated so it can build with Java 11, but I don't think it has been thoroughly tested yet. The only user of JSS keystore (that I'm aware of) is Dogtag and Dogtag is still using Java 8 on Fedora. > > If it's the second one, that message is coming from Tomcat when validating > > the > > server.xml. Is certificateVerification the only thing you change in that > > file? You > > might want to try adding defaultSSLHostConfigName to Connector and hostName > > to > > SSLHostConfig, but I'm really not sure what's going on. > > > > See also this page: > > https://stackoverflow.com/questions/42135892/tomcat-8-5-server-xml-multiple-sslhostconfig-elements-were-provided-for-the-ho > > > > If you put any of these deprecated attributes in the Connector directive, > > tomcat > > assumes you are using the old way and auto creates a SSLHostConfig itself, > > which > > then conflicts with the one you are creating. -- Endi S. Dewata From tjaalton at ubuntu.com Tue Jan 15 22:01:00 2019 From: tjaalton at ubuntu.com (Timo Aaltonen) Date: Wed, 16 Jan 2019 00:01:00 +0200 Subject: [Pki-users] Problems with java11 In-Reply-To: <1029669299.72524396.1547584777587.JavaMail.zimbra@redhat.com> References: <26357b78-8d91-ccd8-aee9-6a38f4aa962f@ubuntu.com> <1886433601.72448813.1547563561310.JavaMail.zimbra@redhat.com> <5d7d6b5c-4c47-6f42-8c7f-cdcac7cf0347@ubuntu.com> <135941273.72492040.1547573159253.JavaMail.zimbra@redhat.com> <545838969.72507732.1547579002049.JavaMail.zimbra@redhat.com> <1b75a762-5f93-d87a-bc60-994e8f1573b7@ubuntu.com> <1029669299.72524396.1547584777587.JavaMail.zimbra@redhat.com> Message-ID: On 15.1.2019 22.39, Endi Sukma Dewata wrote: > ----- Original Message ----- >>> Are you getting this error: >>> >>> java.lang.IllegalArgumentException: Alias name [sslserver] does not >>> identify a key >>> entry >>> >>> or this error? >>> >>> java.lang.IllegalArgumentException: Multiple SSLHostConfig elements were >>> provided >>> for the host name [_default_]. Host names must be unique. >>> >>> If it's the first one, that means the PKCS #11 keystore (i.e. JSS keystore) >>> cannot >>> find the SSL server certificate. We may not have a solution since we do not >>> support >>> Java 11 yet. >> >> But I've patched Dogtag to support the new keystore, and am using JSS >> 4.5.1, I thought they did support Java 11.. so something is missing >> still then.. > > IIUC JSS was updated so it can build with Java 11, but I don't think it > has been thoroughly tested yet. The only user of JSS keystore (that I'm aware > of) is Dogtag and Dogtag is still using Java 8 on Fedora. Right, here's hoping it's something simple and will be fixed soonish ;) -- t