-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chris,
On 8/13/2014 5:32 AM, Christopher Schultz wrote: > Mark, > > On 8/13/14, 1:52 AM, Mark Eggers wrote: >> On 8/12/2014 8:45 PM, Christopher Schultz wrote: >>> Neil, > >>> On 8/12/14, 6:01 PM, Neil Aggarwal wrote: >>>> Up until now, I have always run Apache in front of Tomcat. I >>>> am wondering if I should change to using Tomcat as a >>>> standalone server. > >>>> My concern is how to use multiple virtual hosts with a single >>>> SSL instance running on the standard https port. > >>>> With httpd server, I can access my webapp using the directory >>>> name in the URL. For example, if I have an app called >>>> app1, it uses URLs that look like this: >>>> http://www.app1.com/app1/index.html >>>> https://ssl.example.com/app1/index.html > >>>> If I have another app, it would use urls like this: >>>> http://www.app2.com/app2/index.html >>>> https://ssl.example.com/app2/index.html > >>>> This is because mod_jk will forward anything with the app >>>> name as the first part of the URL to Tomcat. > >>>>> From what I am reading in the documentation, Tomcat uses >>>>> the hostname >>>> to determine the webapp to use. That won't work since they >>>> need to use the same hostname in ssl mode. > >>> Tomcat uses both hostname + path to determine where the request >>> should go: if you have multiple virtual hosts, then /foo >>> might map to two different virtual hosts depending upon the >>> Host header (or URL, which generally agree with each other). > >>> The only complication TLS adds is that a certificate often only >>> has one single hostname in it, and the server can only bind to >>> "all interfaces" on a single port (e.g. 443) a single time. >>> Thus, administrators often have to pick a certificate that will >>> work for everyone. > >>> As you have mentioned, SNI offers a way around this: the client >>> can notify the server which host they are attempting to >>> contact and the server can reply with the preferred certificate >>> for that host. I don't believe Tomcat has direct support for >>> SNI, though Java 7+ should be able to handle it if the server >>> software (Tomcat in this case) is capable. I haven't looked >>> into how it can be done, but at this point, Tomcat should >>> probably include this feature, at least for JSSE. > >>> There are other ways to get around this, including using >>> wildcard TLS certificates, binding to different network >>> interfaces to get s unique interface/port combination for each >>> certificate, etc. > >>> Tomcat /can/ be used, here, but it currently takes some >>> creativity. > >>> -chris > > >> Chris, > >> Does Java 7 have server side support for SNI? I had this >> discussion on the list a while back, and I think we came to the >> conclusion that SNI was not supported. I'll have to dig through >> my archives and the public archives to make sure I'm not >> mistaken. > >> Ah no - server side SNI is not available until Java 8. I don't >> know if Tomcat 8 can take advantage of that or not (haven't >> looked at the code). However Tomcat 7 plus Java 7 equals no >> server side SNI. > > > It looks like it's possible to hack it, but it looks like a > non-trivial effort: > http://stackoverflow.com/questions/15100386/java-support-for-server-name-indication-sni-in-server-role > > This looks more like a POC than something that would be supportable in a production environment. The second link indicates as much. > (See the links in the first answer) > >> You're stuck with fronting Tomcat with something like Apache >> HTTPD and using a SAN cert. This is what we currently do in >> production. Later versions of Apache HTTPD support SSL named >> virtual hosts (with a little care). > > Yeah, I read the prior correspondence between you and markt and > saw that was your conclusion. A second problem with Tomcat is the > lack of support for SNI through tcnative/APR/OpenSSL. At some > point, maybe I'll try to figure out how to do SNI with OpenSSL and > do all the plumbing through the Java code. > That would be really interesting and useful. It won't solve my original constraint (browser / OS combinations that don't support SNI), but it would position me to move to a Tomcat-only stack when that requirement is relaxed. > -chris . . . just my two cents /mde/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (MingW32) iQEcBAEBAgAGBQJT64cqAAoJEEFGbsYNeTwt+08IAJC6RbIEwoO7mva3sRap6TVu swTKNJ/6xb6Uq8dB1hLSnNOhO5fLpcB6BJTl6DTEUhIJzt5rFJDRFFu5GMvutWal 3jo9zDKbaOCXKtuCh46B+K412Z8k55v1Ru7PQT63L7ecjAb/Fh/u0sUDVIqCMHlH 2uexD+AQKqnIZHYuI/IUIH+oMWLE+De2BjHWNW2ZD66rAAAZDsFVsMLoYSTunWkk QpHFjDSU0L0Q4Bkuuwq3EL3QNEwuwhM/n4ugsTQZDKmvasVKWHSvC09UvjH9YPSl hhqJuap7id3eIO20GyOGjcPoWx9ansud3pnWQWumzWFTkPXXJSqsdilApYMqgJA= =svyu -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
