-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 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 (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. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJT61rFAAoJEBzwKT+lPKRYdocQAKIGtrNhd9Zyd/mlhf/vnQ2p DWhe4qnz0PLK+eVG0uzYkpqmDpYDGSRLho+d/HkdAmYdaQUoD61ht/RnilHQhJIJ 4AaPpxGbX1+/CGUhbrk1gIh4Clm5nnWSiGsYOjBg6ZdhJvt4QFQ4Js/aadq1ThWw eGIk5dGhL359DNE3pnkeK1CsP2Zl1ExcPaAZ3G4F1og8TpbwD9XsNgdxr8LBpUnk rhoE3AL9H4QxvPDqS7Y7nkUmvgsbr0npgTyZxGhC/R5ALRILBp5lJf1Z+ycGszNc qVRzpx3hljoiBrxdkZT12mpA4B+40eIbomxFEQgu4c8Mtj9FE7qzSBWLtkeHP7X9 dvpCrhG9BzUsbvYOlN6ITqELw5P6vzg1N39yFKTCl1qqqhpq+a10jNngrHhoTL6B vD3u19qR3XuVncl5zEsI6qJt1S7V1IvIXtheJsq1dn8OyX20XG+b/f53hCae0BNm i1a7ozXbAVC5JLepKDgFIShpHjzcpAEnyyXIjaIYAqJsD9CdvWS7+0Vw4Uucirw1 p+GMvgD8tCJ5+bYTpKo8/viqjRe9WhpRVAzUGFEqfkuvYt5lyJOisbFjmeUxXxZ8 8c1NNaVtZPxav0kG282+wtVaQaaq9VN6vIs2HEatcwwwfWIi2Byf5I5Kuq6ajpcF HvLtCyXYRjwdW+CGX1YV =Sn55 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org