Chuck, et. al. -
One final statement on this topic (promise!).
After dreaming about this for a few nights, I've come to agree with
Chuck. I don't see why, even in a multi-SSL setup, one would want to
bother with useIPVHosts=true. Seems like a bit of extra work/thought
for a problem that might not exist. Consider the following scenario,
where SSL is needed for each Hostname,:
www.mydomain1.com 127.16.1.1
www.mydomain2.com 127.16.1.2
Obviously we want the matching SSL cert delivered for each domain, when
the user needs SSL encryption. But the following server.xml should do
the trick just fine. This is assuming a standalone Tomcat 5.5
implementation. Obviously, it would be a bit different if you had an
Apache front-end and used AJP. (Non-routable IPs used for demo purposes
only.)
<Server port="8005" shutdown="SHUTDOWN">
<GlobalNamingResources>
<!-- Used by Manager webapp -->
<Resource name="UserDatabase" auth="Container"
type="org.apache.catalina.UserDatabase"
description="User database that can be updated and saved"
factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
pathname="conf/tomcat-users.xml" />
</GlobalNamingResources>
<Service name="Catalina">
<Connector port="80" maxHttpHeaderSize="8192"
maxThreads="150" minSpareThreads="25"
maxSpareThreads="75"
enableLookups="false" redirectPort="8443"
acceptCount="100"
connectionTimeout="20000" disableUploadTimeout="true" />
<Connector address="172.16.1.1" port="443" maxHttpHeaderSize="8192"
maxThreads="150" minSpareThreads="25"
maxSpareThreads="75"
enableLookups="false" disableUploadTimeout="true"
acceptCount="100" scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS"
keystoreFile="/usr/share/tomcat/mydomain1.keystore"
keystorePass="changeit" />
<Connector address="172.16.1.1" port="443" maxHttpHeaderSize="8192"
maxThreads="150" minSpareThreads="25"
maxSpareThreads="75"
enableLookups="false" disableUploadTimeout="true"
acceptCount="100" scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS"
keystoreFile="/usr/share/tomcat/mydomain2.keystore"
keystorePass="changeit" />
<Engine name="Catalina" defaultHost="localhost">
<Realm className="org.apache.catalina.realm.UserDatabaseRealm"
resourceName="UserDatabase" />
<Host name="localhost" appBase="webapps"
unpackWARs="true" autoDeploy="true"
xmlValidation="false" xmlNamespaceAware="false">
</Host>
<Host name="www.mydomain1.com" appBase="webapps"
unpackWARs="true" autoDeploy="true"
xmlValidation="false" xmlNamespaceAware="false">
<Alias>172.16.1.1</Alias>
</Host>
<Host name="www.mydomain2.com" appBase="webapps"
unpackWARs="true" autoDeploy="true"
xmlValidation="false" xmlNamespaceAware="false">
<Alias>172.16.1.2</Alias>
</Host>
</Engine>
</Service>
</Server>
I added the IP address aliases for the paranoid case where someone
insists on typing the IP address into the address bar (call me
paranoid).
The port=80 connector will handle all normal inbound traffic and route
appropriately based on host-header-string (HHS). If there is some DNS
or resolver cache snafu such that the name resolves to the wrong
address, it still ends up at the intended host, thank you Tomcat. A
non-matching HHS would route to localhost which should respond with a
"How DID you get here?" page.
For SSL requests, obviously, the request would come in on the IP address
resolved and get the SSL cert tied to that address. Tomcat would again
route based on HHS, and the user would always get the "right" host.
Under normal/correct conditions, the user would never see a certificate
warning, but in the DNS/resolver snafu case, the user will get the
mis-matched cert error, but, here's the important part, will still be at
the intended host. The traffic is still encrypted, but it is up to the
end user to decide the trust issues. However, there is an obvious
notice that something is incorrect somewhere.
Q: If usiIPVHosts=true, if there is a DNS/resolver problem, the user
would end up at an unintended host as well as get the wrong cert.
Correct? Most likely the request would fail assuming different
software/websites (except for a request to root).
Personally, I'm really liking the default for normal use. It seems more
error-resistant.
In the earlier discussions, my head was so wrapped in my unique
deployment that I wasn't seeing the theoretical clearly. I have
multiple Tomcat instances deployed per machine for various reasons
(maintenance windows, etc.), so I have to declare a port=80 connector
for each address on the box. I can't use the "all IPs" default, so the
multi-service config was created. Hosts can come & go in a particular
server.xml over time. Since all their info is in one tidy area, it makes
it easier to add and remove them without worrying about stuff being left
out or over. That's the practical aspect of my personality. It does
have the nice consequence that no matter how the user gets to the IP, it
will always be the host for that IP. Sort of a poor man's useIPVhosts.
******************************* NOTICE *********************************
This message is intended for the use of the individual or entity to which
it is addressed and may contain information that is privileged,
confidential, and exempt from disclosure under applicable law. If the
reader of this message is not the intended recipient or the employee or
agent responsible for delivering this message to the intended recipient,
you are hereby notified that any dissemination, distribution, or copying
of this communication is strictly prohibited. If you have received this
communication in error, please notify us immediately by reply or by
telephone (call us collect at 512-343-9100) and immediately delete this
message and all its attachments.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
