Ryan Medina

Tim Holloway wrote:Tomcat does not work with "directories", unlike Apache. The  appBase directory contains WARs in either standard (xxx.war file) or exploded form (TOMCAT_HOME/webapps/xxx directory). By default, Tomcat will automatically explode WAR files.

Assuming that you didn't set up a custom context, the Tomcat server then deploys each WAR using its warfile/directory name. So TOMCAT_HOME/webapps/payroll will have the context path /payroll, TOMCAT_HOME/webapps/personnel will have the context path /personnel, and so forth, so that the basic URL for the payroll /index.jsp page would be http://localhost:8080/payroll/index.jsp.

When you set up mod_jk as a connection, you map an Apache VirtualHost to a Tomcat webapp context via jkmount. Disclaimer: It has been a LOOOONG time since I've used mod_jk and I don't remember all the details of setting it up, but basically I believe that you have to set up the destination webapp server address, port, and context in the worker definition file.

Actually, most of the mod_jk documentation I can find is quite old. For the most part, mod_proxy or mod_proxy_ajp are preferred these days. The main advantage of mod_jk seems to have been for load-balancing and that's not been an issue for me. The mod_proxy setup is much more straightforward.

If I can't get mod_jk to work properly I may try switching to mod_proxy. For mod_jk, for the mounting/appBase problem, I could just create a mount for each individual application instead of trying to use one mount for all of them. Still not sure about the SSL configuration for Tomcat, I haven't been able to find any info or docs to say if it's needed.

I'm setting up mod_jk for Apache to use with Tomcat and there are two issues I've ran into.

SSL

I have SSL enabled on Apache and all traffic is going through HTTPS, including the requests forwarded to Tomcat. Does Tomcat also need to be configured for SSL in any way or does Apache handle it completely? Everything I have found doesn't say Tomcat needs any configuration but I'm getting the following error in Tomcat which could be related.

IllegalArgumentException: Invalid character found in method name. HTTP method names must be tokens

appBase/mounting

My appBase in Tomcat is the typical "path/to/webapps" and when Apache forwards a request it naturally gives it the full path. However, since I only want to forward certain URLs to Tomcat, my JkMount looks something like "JkMount /apps/* worker1". The problem is that Tomcat will be looking for the applications in "path/to/webapps/apps/" which is not the directory the applications get deployed in. Using RewriteRule to remove the "apps" from the path I assume would cause it to not be forwarded to Tomcat. I'm not sure if there are any better solutions.

Tim Holloway wrote:If you are already running Apache, I'd suggest avoiding SSL on Tomcat. Use Apache as a reverse proxy to Tomcat, instead, using mod_proxy or mod_jk with the Coyote Apache-to-Tomcat connector (port 8009).

There are several reasons why this is better:

1. You don't have to run Tomcat as an admin user to allow it to use ports 80 and 443 - Apache does the listening for you. Much more secure that way,

2. It's easier to set up SSL for Apache than for Tomcat, Plus, Tomcat doesn't take Apache-format certs, so if your certfiles and keyfiles were issued for Apache, you'd have to convert them for Tomcat.

3. You can run all your webapps through the Apache server, both JEE and non-JEE (for example, PHP apps).

Basically, the world-to-Apache link is SSL, then the Apache proxy feeds to Tomcat via a private internal channel. The tomcat server can be on the same machine as Apache or on a different machine or you can run multiple Tomcats with Apache doing load-balancing.

So I recommend this approach instead. I use Nginx  myself these days, fronting Tomcat, backend Apache servers in containers, NodeJS and whatever else needs a web interface.

You're right, that does sound like a better approach. I didn't think about doing it that way. When doing it that way, how does Tomcat need to be configured? Everything I found pretty much only showed the configuration for Apache. For example, does Tomcat still need to be configured to listen to a specific port or does Apache have a way to directly service the requests to Tomcat?

There are a few questions I have regarding setting up SSL on Tomcat 9 as some of the things I've read have some inconsistencies and I'm also new to PKI. Ultimately, there are two things I'm trying to accomplish: enable SSL on Tomcat 9 for a secure websocket on a webserver and also locally for testing.

Tomcat Configuration

In server.xml, it already has a Connector commented out for SSL which looks like this

   <Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol"               maxThreads="150" SSLEnabled="true">        <SSLHostConfig>            <Certificate certificateKeystoreFile="conf/localhost-rsa.jks"                         type="RSA" />        </SSLHostConfig>    </Connector>

On the Tomcat's "how-to", and every other article, the Connector looks like this

   <Connector        protocol="org.apache.coyote.http11.Http11NioProtocol"        port="8443" maxThreads="200"        scheme="https" secure="true" SSLEnabled="true"        keystoreFile="${user.home}/.keystore" keystorePass="changeit"        clientAuth="false" sslProtocol="TLS"/>

I'm not sure which configuration to use, or even if there is a different protocol I should use. Also it seems that the connector is the only Tomcat configuration necessary, but let me know if I'm wrong.

Keystore

The webserver already uses SSL for HTTPS on Apache. Since it would be the same domain, would it be an issue to use the same certificate for Tomcat/WSS too? If not, Apache uses a domain.crt, domain.key, My_CA_Bundle.ca-bundle, and ca-bundle.crt.

For the local installation, I used mkcert to create a certificate for localhost which produced localhost.pem and localhost-key.pem.

Again, I'm new to PKI. I'm not sure if I need to use a Java Keystore file, if it can use a different file type, etc. Any help would be greatly appreciated.