-----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

Reply via email to