On Wed, Apr 6, 2016 at 12:17 PM, Coty Sutherland <csuth...@redhat.com> wrote:
> Hi Thad, > > Hopefully I can help clear up some confusion here. I'd also suggest > watching the 8.5 connector video that markt presented here > <https://www.youtube.com/watch?v=LBSWixIwMmU> for more information on the > connector changes introduced by 8.5. I found the bits on the SSL change > particularly informative as it was my first exposure to how tomcat9 handles > TLS, if you're interested in moving to the way that tomcat 9 handles SSL > with the upgrade to 8.5. Otherwise, you can use the same Connector tags > that you had before without change (I think). > > In any case, I'll reply to your last inquiries in line below. I'm using > Tomcat 8.5.0.Beta and OpenJDK 8. > > > Are you saying that to make the second <Connector> work I must remove > either clientAuth or sslProtocol? (No, I must be mistaken--remove either/or > and Tomcat still fails to start). > > Yes; you should remove _both_ of them and move that configuration into the > SSLHostConfig. You can find the replacements for them in the docs for > clientAuth and sslProtocol here > < > https://tomcat.apache.org/tomcat-8.5-doc/config/http.html#SSL_Support_-_Connector_-_NIO_and_NIO2 > >; > I've tested this and it works for me. I believe that the reason behind this > (although I am no expert) is that tomcat is taking the old Connector > configuration that you have in place and creating a default SSLHostConfig > behind the scenes; this action causes a conflict with your defined > SSLHostConfig hence the exception about the multiple non-unique host names > and such. > > > "BTW sslProtocol is really useless." does make sense. If so, I think I'm > hearing > that I should not use the sslProtocol="TLS" attribute or the > <SSLHostConfig> element. Is that right? > > You don't need the sslProtocol attribute because you're just setting the > default value for TLS. As far as the SSLHostConfig goes, I think that's up > to you. For now, tomcat will take your old Connector configuration and > translate it behind the scenes into what it needs to function. If you do > use the SSLHostConfig tag, then you'll need to move all of the attributes > from the Connector to the SSLHostConfig that belong there; this is > basically upgrading your connector from the tomcat 8.0 syntax to tomcat 9's > syntax. > > > This confuses me. The 8.5 server.xml uses <SSLHostConfig> in its > commented examples while the 8.0 server.xml does not. And if SSL* > attributes are going away, why is <SSLHostConfig> now the example? > > Tomcat 8.5 was forked from tomcat/trunk (tomcat9), which is where that > comes from. I think that the example was left there to encourage movement > to the tomcat 9 syntax because the older connector syntax will eventually > be removed. I do notice that the ssl-howto docs still refer to the tomcat8 > syntax, so it doesn't seem like there is a unified message regarding which > one is the preferred method (they're both still correct and will work when > the hosts don't conflict). > > > And without SSL*, how do I specify the certificates in an APR connector > like this one (which is the first I got working): > > All of the SSL* attributes from the connector were migrated to the > SSLHostConfig and it's new tags. > > Let me know if any of my response was vague and I'll try and clarify. > Thank you, Coty. I think that answered my questions (the video was useful, too). So, for the record--and I hope I've labeled them correctly--I have gotten the configurations below to come up on Mac OSX 10.10.5 with Java 1.8.0_77. My OpenSSL is 1.0.2g 1 Mar 2016, and my Tomcat native library is 1.2.5, both installed with Homebrew. <!-- NIO connector with JSSE --> <Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol" maxThreads="200" SSLEnabled="true" compression="on" scheme="https" secure="true"> <UpgradeProtocol className="org.apache.coyote.http2.Http2Protocol" /> <SSLHostConfig honorCipherOrder="false"> <Certificate certificateKeystoreFile="conf/foo.jks" certificateKeystorePassword="changeit" certificateKeyAlias="tomcat" type="RSA" /> </SSLHostConfig> </Connector> <!-- NIO connector with OpenSSL --> <Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol" maxThreads="200" SSLEnabled="true" compression="on" scheme="https" secure="true"> <UpgradeProtocol className="org.apache.coyote.http2.Http2Protocol" /> <SSLHostConfig honorCipherOrder="false"> <Certificate certificateKeyFile="conf/foo-nopp.pem" certificateFile="conf/foo.pem" type="RSA" /> </SSLHostConfig> </Connector> <!-- APR/Tomcat native connector with OpenSSL --> <Connector port="8443" protocol="org.apache.coyote.http11.Http11AprProtocol" maxThreads="200" SSLEnabled="true" compression="on" scheme="https" secure="true"> <UpgradeProtocol className="org.apache.coyote.http2.Http2Protocol" /> <SSLHostConfig honorCipherOrder="false" > <Certificate certificateKeyFile="conf/foo-nopp.pem" certificateFile="conf/foo.pem" type="RSA" /> </SSLHostConfig> </Connector> Now to see if this breaks any of my apps. :) > > On Tue, Apr 5, 2016 at 4:57 PM, Thad Humphries <thad.humphr...@gmail.com> > wrote: > > > On Tue, Apr 5, 2016 at 4:25 PM, Rémy Maucherat <r...@apache.org> wrote: > > > > > 2016-04-05 15:11 GMT-05:00 Thad Humphries <thad.humphr...@gmail.com>: > > > > > > > My primary interest in Tomcat 8.5 is HTTP/2, so I must set up HTTPS > and > > > > TLS. > > > > > > > > Since I eventually must demonstrate the various HTTPS approaches to > > > others, > > > > I have tried both the APR and the NIO implementation, as well as the > > > > different <Connector> layouts in the docs ( > > > > > > > > > > > > > > http://tomcat.apache.org/tomcat-8.5-doc/ssl-howto.html#Edit_the_Tomcat_Configuration_File > > > > ), > > > > and the $CATALINA_BASE/conf/server.xml comments. I've gotten APR is > > > > working both ways, but not quite NIO. > > > > > > > > When I use the following connector for NIO (from the docs), my SSL > > works: > > > > > > > > <Connector > > > > protocol="org.apache.coyote.http11.Http11NioProtocol" > > > > port="8443" maxThreads="200" compression="on" > > > > scheme="https" secure="true" SSLEnabled="true" > > > > keystoreFile="conf/foo.jks" keystorePass="changeit" > > > > clientAuth="false" sslProtocol="TLS"> > > > > <UpgradeProtocol > > className="org.apache.coyote.http2.Http2Protocol" > > > /> > > > > </Connector> > > > > > > > > However when I try the approach in the server.xml comments, Tomcat > does > > > not > > > > start: > > > > > > > > <Connector port="8443" > > > > protocol="org.apache.coyote.http11.Http11NioProtocol" > > > > maxThreads="200" SSLEnabled="true" > > > > scheme="https" secure="true" clientAuth="false" > > > > sslProtocol="TLS"> > > > > <UpgradeProtocol > > className="org.apache.coyote.http2.Http2Protocol" > > > /> > > > > <SSLHostConfig honorCipherOrder="false"> > > > > <Certificate certificateKeystoreFile="conf/foo.jks" > > > > certificateKeystoreType="JKS" > > > > certificateKeystorePassword="changeit" > > > > certificateKeyAlias="tomcat" > > > > type="RSA" /> > > > > </SSLHostConfig> > > > > </Connector> > > > > > > > > The error at the top of catalina.out is below. I'm trying to > understand > > > > why, both for myself and so that I can explain it to others. The > > "Caused > > > > by: java.lang.IllegalArgumentException: Multiple SSLHostConfig > elements > > > > were provided for the host name [_default_]. Host names must be > > unique." > > > > has me stumped as I have only the one uncommented SSLHostConfig in > > > > server.xml. > > > > > > > > (Once I have this second <Connector> working, I must make a write-up > > for > > > > folks here, a write-up which I hope will be clearer and more direct > > than > > > > the docs. I would be happy to offer that write-up to the wiki or > docs.) > > > > > > > > > > You still have some attributes which should go into SSLHostConfig, so > you > > > have two SNI for the default host (clientAuth and sslProtocol). BTW > > > sslProtocol is really useless. > > > > > > Rémy > > > > > > > I'm sorry, I'm not following you. Are you saying that to make the second > > <Connector> work I must remove either clientAuth or sslProtocol? (No, I > > must be mistaken--remove either/or and Tomcat still fails to start). > > > > "BTW sslProtocol is really useless." does make sense. If so, I think I'm > > hearing that I should not use the sslProtocol="TLS" attribute or the > > <SSLHostConfig> > > element. Is that right? > > > > The 8.5 docs say > > "As of Tomcat 9, the majority of the SSL configuration attributes in the > > Connector are deprecated. If specified, they will be used to configure a > > SSLHostConfig and Certificate for the sslDefaultHost. Note that if an > > explicit SSLHostConfig element also exists for the sslDefaultHost then > that > > will be treated as a configuration error. It is expected that Tomcat 10 > > will drop support for the SSL configuration attributes in the Connector." > > > > This confuses me. The 8.5 server.xml uses <SSLHostConfig> in its > commented > > examples while the 8.0 server.xml does not. And if SSL* attributes are > > going away, why is <SSLHostConfig> now the example? And without SSL*, how > > do I specify the certificates in an APR connector like this one (which is > > the first I got working): > > > > <Connector > > protocol="org.apache.coyote.http11.Http11AprProtocol" > > port="8443" maxThreads="200" compression="on" > > scheme="https" secure="true" SSLEnabled="true" > > SSLCertificateFile="conf/foo.pem" > > SSLCertificateKeyFile="conf/foo-nopp.pem" > > SSLVerifyClient="none" SSLProtocol="TLSv1+TLSv1.1+TLSv1.2"> > > <UpgradeProtocol className="org.apache.coyote.http2.Http2Protocol" > /> > > </Connector> > > > > > > > > > > > > > > > 05-Apr-2016 15:32:42.642 SEVERE [main] > > > > org.apache.tomcat.util.digester.Digester.endElement End event threw > > > > exception > > > > java.lang.reflect.InvocationTargetException > > > > 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.tomcat.util.IntrospectionUtils.callMethod1(IntrospectionUtils.java:377) > > > > at > > org.apache.tomcat.util.digester.SetNextRule.end(SetNextRule.java:145) > > > > at > > org.apache.tomcat.util.digester.Digester.endElement(Digester.java:966) > > > > at > > > > > > > > > > > > > > com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(AbstractSAXParser.java:609) > > > > at > > > > > > > > > > > > > > com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanEndElement(XMLDocumentFragmentScannerImpl.java:1783) > > > > at > > > > > > > > > > > > > > com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2970) > > > > at > > > > > > > > > > > > > > com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:606) > > > > at > > > > > > > > > > > > > > com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:510) > > > > at > > > > > > > > > > > > > > com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:848) > > > > at > > > > > > > > > > > > > > com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:777) > > > > at > > > > > > > > > > > > > > com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:141) > > > > at > > > > > > > > > > > > > > com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1213) > > > > at > > > > > > > > > > > > > > com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:643) > > > > at org.apache.tomcat.util.digester.Digester.parse(Digester.java:1461) > > > > at org.apache.catalina.startup.Catalina.load(Catalina.java:578) > > > > 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.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:201) > > > > at > > > > > > > > > > > > > > org.apache.coyote.http11.AbstractHttp11Protocol.addSslHostConfig(AbstractHttp11Protocol.java:398) > > > > at > > > > > > > > > > > > > > org.apache.catalina.connector.Connector.addSslHostConfig(Connector.java:876) > > > > ... 26 more > > > > > > > > > > > > -- > > > > "Hell hath no limits, nor is circumscrib'd In one self-place; but > where > > > we > > > > are is hell, And where hell is, there must we ever be" --Christopher > > > > Marlowe, *Doctor Faustus* (v. 121-24) > > > > > > > > > > > > > > > -- > > "Hell hath no limits, nor is circumscrib'd In one self-place; but where > we > > are is hell, And where hell is, there must we ever be" --Christopher > > Marlowe, *Doctor Faustus* (v. 121-24) > > > > > > -- > Coty Sutherland, RHCSA, RHCE, JBCAA > Senior Software Engineer @ Red Hat, Inc. > 100 East Davie Street > Raleigh, NC 27606 > > Email: c...@redhat.com > IRC Nickname: coty > Office: 919-890-8303 > -- "Hell hath no limits, nor is circumscrib'd In one self-place; but where we are is hell, And where hell is, there must we ever be" --Christopher Marlowe, *Doctor Faustus* (v. 121-24)
