Hello users@tomcat.apache.org,
The company I recently started working at does a very interesting trick in
order to facilitate SSL/TLS connections and I am baffled as to how it
actually works.
First, some background:
===================
Tomcat Version: jakarta-tomcat-5.5.9
OS: SuSE Enterprise Linux
Brief Description of the Trick:
=====================
We deploy multiple distinct (unsecure) web applications "inside" of another
(secure) web application's deployment directory in order to achieve SSL/TLS
connections without the user being nagged about Certificate/Domain name
mismatches. The reason for this I am told is that we only have one server
certificate for our one server IP address but we host multiple virtual
domains. The bosses don't want the clients/end-users getting that funny
domain name mismatch nagg window when they first go to one of our hosted web
apps.
Its true!
We have one virtual host ("secure-mydomain.com") configured in our Tomcat
instance. Its specification/declaration in server.xml is seemingly quite
normal:
<Host name="secure-mydomain.com"
appBase="/some/directory/secure-mydomain.com">
<Alias>www.secure-mydomain.com</Alias>
<Valve className="org.apache.catalina.valves.AccessLogValve"
directory="logs"
prefix="access-secure-mydomain.com-"
suffix=".log" pattern="combined"/>
</Host>
We have a server Certificate for "secure-mydomain.com" for which we have
defined a connector:
<Connector port="443"
maxHttpHeaderSize="8192"
maxThreads="200"
minSpareThreads="25"
maxSpareThreads="75"
enableLookups="false"
disableUploadTimeout="true"
acceptCount="150"
scheme="https"
secure="true"
keystoreFile="/some/other/directory/secure-mydomain.com.keystore"
keystorePass="none-of-your-beeswax"
clientAuth="false"
sslProtocol="TLS"/>
Now for the weird part. Whenever our developers create a new web app which
requires SSL/TLS, they:
1.) deploy the new web app to its own (unsecure) virtual host.
2.) copy the new web app deployment directory into the secure web app's
deployment directory (/some/directory/secure-mydomain.com/).
So, there now exists for the secure web app a directory structure such
as:
secure-mydomain.com
ROOT
WEB-INF
web.xml
new-web-app
WEB-INF
web.xml
another-new-web-app
WEB-INF
web.xml
yet-another-new-web-app
WEB-INF
web.xml
3.) replace the new (unsecure) web app's index.jsp file with one which sends
a redirect to "www.secure-mydomain.com/new-web-app/".
Voila! The user is redirected to the new web app under
secure-mydomain.com/new-web-app/ with a secure SSL/TLS connection and the
"new-web-app" seems to works fine.
I'm no expert at Tomcat or web app deployment. But I have read about the
"directory structure" of J2EE compiant web applications. It seems to me
that we are literally copying one (unsecure) web app and its entire
directory structure into another (secure) web apps directory structure. But
everything seems to work. Tomcat seems to recognize the deployment
descriptors of each new web app we copy into "secure-mydomain.com"'s
deployment directory. For each "new" web app we copy into there, the new
web apps InitParameters, Listeners, contextParameters, etc. defined in each
new web apps deployment descriptor are recognized by Tomcat. It "seems" to
work.
But how? Is it kosher to copy one web application's deployment directory
directly "into" another web application's deployment directory? Does this
violate the J2EE spec? Is it recommended practice? Can you see anything
particularly "wrong" with it?
I'd love to hear some comments as this sounds like a strange and interesting
trick to me.
--
Cheers,
Warren Killian
[EMAIL PROTECTED]
