Hi James,

I've been using this precise setup for years, first on a dedicated hosted server and recently on EC2/Linux2.  I use mod_jk.

The first step is to make sure httpd recognizes all of the domain names and subdomains.  That includes the vhost definitions of all of the domains and subdomains, either as separate virtual hosts or as host alias names.  Then, as you described, you need to make sure the certificates include all of the domain and subdomain names.  LetsEncrypt will 'expand' an existing cert if you just add another host name to the LetsEncrypt call.

You are probably doing this already.  But just for completeness.... you should  support both http://foo.com (port 80) and https://foo.com.  That way, users aren't required to enter https.  I just add a 'redirect permanent' in the port 80 vhost def to route it to https://foo.com.   Once you are 'in' with ssl into httpd at 443 the certificate work is done.  No need to set up any certificates into tomcat unless you have a specific reason to use ssl/tls between httpd and tomcat (unlikely if you running both on the same EC2).

The biggest area of concentration is setting up the url patterns that httpd will route to tomcat via mod_jk.  These are defined in httpd.conf as global or in virtual host configuration sections You can explicitly list the url patterns to send to tomcat:

   JkMount /*.json                  worker1
   JkMount /*.jsp                   worker1
   JkMount /*/*.json                worker1
   JkMount /*/FileUpload            worker1

or you can send 'all' (*) and define exceptions using JkUnMount (example; /css/*).  The mod_jk log is a lifesaver when you are setting this up.  Set the mod_jk log level to debug and see how mod_jk is deciding whether to pass a url to tomcat or pass it back to httpd for processing.

Once you get to tomcat, you just have to define all of the same host domain and subdomains in tomcat's server.xml to ensure tomcat is going to accept the requests that mod_jk has decided to send to it.

Let me know as you encounter issues.  I'll be glad to assist.

Jerry

On 4/6/2020 2: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

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to