James,

On 4/6/2020 12:53 PM, James H. H. Lampert wrote:
> Here is the situation:
> 
> We have an existing Amazon EC2 instance, running Amazon Linux 2, with an
> Apache httpd server already running our web sites (for argument's sake,
> "foo.com," "bar.com," and "baz.com."), and already getting its certs
> from Let's Encrypt, using "foo.com" as the CN, with "www.foo.com,"
> "bar.com," "www.bar.com," "baz.com," and "www.baz.com" as SANs. And it
> seems to be working quite nicely.
> 
> Now, we want to add a Tomcat server, which would then serve several
> webapp contexts at "qux.baz.com," and maybe also "corge.baz.com,"
> running behind the httpd server (which is something I've never done
> before; I've always set up Tomcat directly facing the outside world, so
> with this, I frankly haven't a clue what I'm doing).
> 
> First of all, which is currently considered the easier/better way to get
> Tomcat running behind httpd, given the above scenario? "mod_proxy," or
> "mod_jk?" Or is there something else I haven't heard of?
> 
> Second of all, I found this step-by-step procedure.
> 
>> https://preview.tinyurl.com/vwnutqj
> 
>          Is it any good?
> 
> Third, am I correct in assuming that all we need to do in order for the
> existing Let's Encrypt setup to cover the new "qux" and "corge"
> subdomains is to add them to the SANs already listed?
> 
> Finally, are there any "gotchas" I need to be concerned with?
> 
> -- 
> James H. H. Lampert
> Touchtone Corporation

I prefer mod_jk to mod_proxy for a variety of reasons. Chief among those
is its ability to change web applications on the fly (albeit with some
performance loss).

Unfortunately, there is discussion on the dev list indicating that AJP
may be deprecated in the future. Thus, mod_proxy seems to be the way to go.

I've not put together a mod_proxy_http connection before, so I thought
that I would try it on a Windows 10 Professional system with Tomcat
7.0.103 and Apache HTTPD 2.4.38 (yes, yes, I'll upgrade soon).

First of all, I think that the following is very suspicious.

<Directory /var/lib/tomcat8/webapps/>
        AllowOverride All
        Require all granted
        Options Indexes FollowSymLinks
</Directory>

This appears to establish a set of Apache HTTPD directives for the
Tomcat - served web applications. This is completely unnecessary. The
entire point of a proxy is to pass information from Apache HTTPD to
Apache Tomcat via a network protocol (in this case HTTP).

Second of all, the proxy_pass statements appear to do some rewriting.
This is in general not a good idea, since cookie paths will get munged.
You'll have to use mod_rewrite in order to straighten out cookie paths,
and you may break website links which would require rewriting. In
general, it's a very good idea to keep the path the same between Apache
HTTPD and Apache Tomcat.

At least the above is the case for mod_ajp.

Third of all, I have no idea why there's a Location directive with
"/webapps" in the configuration. Since there's no DocumentRoot for this
virtual host, I suspect it will be in reference to the parent's
(default) DocumentRoot. What that serves is a mystery to me given the
configuration fragment.

Maybe some Apache HTTPD experts on the list have some ideas.

Also note that this isn't HTTPS. Typically, an HTTPS Apache HTTPD
configuration lives in ssl.conf, and you protect HTTP access by doing a
redirect in httpd.conf to the HTTPS site.

You could terminate HTTPS on Apache HTTPD, and then connect Apache HTTPD
via HTTP to Apache Tomcat.

Also note that referencing Apache Tomcat's webapps directory in Apache
HTTPD is a VERY BAD THING. Apache HTTPD has no concept of WEB-INF or
META-INF, so it's conceivable that you could serve and expose secrets
from appname/META-INF or appname/WEB-INF. It's best to just not do this.

Given the above, I thought that I would hack together a quick and dirty
proxy configuration. Again I use mod_jk, so please let some of the more
experienced people chime in on this.

On UNIX / Linux you could also probably use UNIX sockets instead of
HTTP, HTTPS, or AJP.

# No virtual host for now
# No SSL for now

# enabling proxy and http proxy (note, you could use HTTP/2 as well)
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_http_module modules/mod_proxy_http.so

# Secure your proxy - localhost for now - this is IMPORTANT
<Proxy "*">
  Require ip 127
</Proxy>

# Map applications
# You could just use / if you're proxying all requests
# Pick the correct Apache Tomcat port

ProxyPass "/foo" "http://127.0.0.1:8080/foo";
ProxyPassReverse "/foo" "http://127.0.0.1:8080/foo";

This works on my local machine. I hope this is useful.

. . . just my two cents
/mde/

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to