You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Warren Killian <wa...@gmail.com> on 2008/08/04 20:41:13 UTC
Cool SSL/TLS Deployment Trick! How Does It Work?
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
warrenkillian@gmail.com
Re: Cool SSL/TLS Deployment Trick! How Does It Work?
Posted by Warren Killian <wa...@gmail.com>.
Hi Patrick,
Thank you very much for the response. I was so perplexed (and ignorant)
about how this worked, that I stayed up to all hours of the morning with my
Tomcat book reading, researching and experimenting on my home system to
figure out "how" this particular deployment practice actually worked.
I was initially ignorant of what was going on. Now I may have at least a
"clue". :-)
I had originally thought that the "new-web-app" was being deployed inside
another web applications deployment directory. That is what appeared to be
happening as we just "copied" web app directories and dropped them inside
the "secure-mydomain.com" directory. As it turns out, that is not the
case. The directory which "new-web-app" (and others) is being copied (i.e.:
deployed) to is the appBase of a configured virtual host. In other words,
the application(s) being copied into this one directory are being deployed
on the virtual host. I did not realize that a virtual host could have
multiple web apps (Contexts) deployed into it. Nor did I realize that in
the absence of an explicit Context declaration for a virtual host in
server.xml that Tomcat would provide a default Context specification for the
web app automatically. That really confused me. I was seeing multiple
Contexts (web apps) being served up with no explicit Context specifications
for them in the server.xml.
Anyway, thanks for the help with this. Its really nice to (think I)
understand what is going on now. :-)
Cheers!
On Thu, Aug 7, 2008 at 10:36 AM, Patrick Markiewicz <
pmarkiewicz@sim-gtech.com> wrote:
> Hi Warren,
> It is my understanding that all tomcat does with a WAR file is
> unjar it. I.e. whatever is in the war becomes extracted into a
> particular location. Tomcat does not edit any of the files that come
> from the WAR file, it just reads those files for servlet mappings
> (web.xml) and compiler instructions (*.jsp). Hence, you could actually
> copy new-web-app.war into the secure application first, and
> www.secure-mydomain.com/new-web-app would point to the new-web-app as
> expected.
> The second part of the trick is nothing new. All you're
> basically doing is putting instructions in a separate web app to
> redirect to the secure page. I could put that on MY web page:
> <% something like
> Dispatcher.redirect(https://www.secure-mydomain.com/new-web-app/ %>
> The generated response would be 302 Moved to
> www.secure-mydomain.com/new-web-app and the user's browser would simply
> follow the Move instruction to the new location. Of course, since
> www.secure-mydomain.com has a valid certificate, there's no certificate
> error.
> There are a few caveats. The virtual web app could never use
> absolute references to its URL; www.new-web-app.com/not/the/index.jsp
> would either return 404 errors or it would not be secure. Also, if the
> webapp uses the domain name as a key into some database, the domain name
> would always be www.secure-mydomain.com and not whatever virtual host
> was defined by the webapp.
>
>
> Patrick
>
> -----Original Message-----
> From: Warren Killian [mailto:warrenkillian@gmail.com]
> Sent: Monday, August 04, 2008 2:41 PM
> To: users@tomcat.apache.org
> Subject: Cool SSL/TLS Deployment Trick! How Does It Work?
>
> 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
> warrenkillian@gmail.com
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
RE: Cool SSL/TLS Deployment Trick! How Does It Work?
Posted by Patrick Markiewicz <pm...@sim-gtech.com>.
Hi Warren,
It is my understanding that all tomcat does with a WAR file is
unjar it. I.e. whatever is in the war becomes extracted into a
particular location. Tomcat does not edit any of the files that come
from the WAR file, it just reads those files for servlet mappings
(web.xml) and compiler instructions (*.jsp). Hence, you could actually
copy new-web-app.war into the secure application first, and
www.secure-mydomain.com/new-web-app would point to the new-web-app as
expected.
The second part of the trick is nothing new. All you're
basically doing is putting instructions in a separate web app to
redirect to the secure page. I could put that on MY web page:
<% something like
Dispatcher.redirect(https://www.secure-mydomain.com/new-web-app/ %>
The generated response would be 302 Moved to
www.secure-mydomain.com/new-web-app and the user's browser would simply
follow the Move instruction to the new location. Of course, since
www.secure-mydomain.com has a valid certificate, there's no certificate
error.
There are a few caveats. The virtual web app could never use
absolute references to its URL; www.new-web-app.com/not/the/index.jsp
would either return 404 errors or it would not be secure. Also, if the
webapp uses the domain name as a key into some database, the domain name
would always be www.secure-mydomain.com and not whatever virtual host
was defined by the webapp.
Patrick
-----Original Message-----
From: Warren Killian [mailto:warrenkillian@gmail.com]
Sent: Monday, August 04, 2008 2:41 PM
To: users@tomcat.apache.org
Subject: Cool SSL/TLS Deployment Trick! How Does It Work?
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
warrenkillian@gmail.com
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org