tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Warren Killian" <warrenkill...@gmail.com>
Subject Re: Cool SSL/TLS Deployment Trick! How Does It Work?
Date Thu, 07 Aug 2008 15:04:59 GMT
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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message