The short answer is: No. It's basically the same problem as having multiple sites sharing an IP address. In the SSL protocol, the server (aka Tomcat) has to send the cert very early on in the handshake. In particular, *before* the browser has sent the request headers (there is no point in the browser sending potentially sensitive info until it has decided to trust you :). Tomcat (or any other SSL-enabled server) simply doesn't have access to the information it needs to do this at the time it needs to make a decision.
"Jeff Skubick" <[EMAIL PROTECTED]> wrote in message 002601c2ce30$85c7c890$0800290a@sasi">news:002601c2ce30$85c7c890$0800290a@sasi... Suppose a webapp, "foo.war", is deployed to a single standalone Tomcat instance, installed in c:\tomcat, on a single host whose IP address is 1.2.3.4. There are a half-dozen hostnames that resolve to 1.2.3.4, including www.foo.com, www.bar.net, and www.boom.org. No distinction is made among the various hostnames... virtual hosting isn't being used. As long as the user makes a request to a hostname that resolves to 1.2.3.4, Tomcat is happy to serve the request. Is there any way to associate three SSL certificates with it -- one for www.foo.com, one for www.bar.net, and one for www.boom.org, so that requests to https://www.foo.com/foo/page.jsp, https://www.bar.net/foo/page.jsp, and https://www.boom.org/foo/page.jsp will all satisfy both Tomcat *AND* the browser? Note that I'm specifically *NOT* trying to have multiple different sites sharing the same IP address with different hostnames. I know SSL doesn't support that. What I'm trying to do is ensure that regardless of what hostname is used to access the https page, the browser will be presented with a valid certificate so it won't gripe about the certificate's name not matching the site's hostname. I know that the usual obstacle lies with the request header itself being encrypted. However, if that's still the case, why couldn't Tomcat just iterate through all the plausible keys available to it, one at a time, in descending order of likelihood, until it finds one that decrypts it into a valid request & then send the reply with THAT one? To give a real-world analogy, it would kind of be like when a friend asks you to watch his house while he's out of town, hands you a ring with a dozen keys that all look alike, and you have to try them one at a time until you find the one that fits and unlocks the door... Yeah, it would increase the load on the server for requests to that one page, but seeing how the only thing on the entire site that's actually SSL is the login page and the actual number of possible hostnames/keys is fairly small, the performance penalty of brute force doesn't seem like all that big of a deal. Thanks! --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
