asked on

Problem getting Apache SSL request directed to Tomcat directory

I've just migrated an Apache/Tomcat system that has been running for years to a new 64 bit Linux OS and Apache 2.4.6 and Tomcat 8.0.23. Everything seems to have installed OK. I can access my jsp pages just fine via http, but if I use https I get a 404 error. Examining the ssl debug log shows:

[Sun Jun 07 21:40:51.604010 2015] [core:info] [pid 28702:tid 140447106541312] [client 76.181.65.196:59161] AH00128: File does not exist: /srv/httpd/htdocs/office/index.jsp

Open in new window

the /srv/httpd/htdocs folder is my DocumentRoot, not the tomcat folder. If I access this same file without SSL I get (in access_log):

76.181.65.196 - - [07/Jun/2015:21:50:49 -0400] "GET /office/index.jsp HTTP/1.1" 200 1834 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko"

Open in new window

which does access my tomcat webapps/office directory. If I use ssl to access a file in the DocumentRoot, it works fine. The problem is when I use ssl and want to access a jsp file. This used to work before the upgrade.

What's wrong?

My httpd-tomcat.conf

LoadModule    jk_module  lib64/httpd/modules/mod_jk.so

# Where to find workers.properties
# Update this path to match your conf directory location
# (put workers.properties next to httpd.conf)

JkWorkersFile /etc/httpd/workers.properties

# Where to put jk shared memory
# (Update this path to match your local state directory or logs directory)

JkShmFile     /var/log/httpd/mod_jk.shm

# Where to put jk logs
# (Update this path to match your logs directory location
# (put mod_jk.log next to access_log)

JkLogFile     /var/log/httpd/mod_jk.log

# Set the jk log level [debug/error/info]
JkLogLevel    info

# Select the timestamp log format
JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "

# Send everything for context /examples to worker named worker1 (ajp13)
JkMount  /ohprs/* worker1
JkMount  /ohprs worker1

JkMount  /office/* worker1
JkMount  /office worker1

Open in new window

My worker.properties is:

worker.list=worker1

# Set properties for worker1 (ajp13)

worker.worker1.type=ajp13
worker.worker1.host=localhost

Open in new window

arnold

Do you have worker processes defined on the SSL side to access the tomcat as you likely had on your prior setup?

Presumably you want people accessing your Apache DSL port and it internally prozying/accessing the tomcat instance for the data.

Mark

ASKER

I'm not running Tomcat standalone. I'm running under Apache. Things I've read said Tomcat doesn't need to be specially configured for SSL in such a case, but it's definitely not working for me.

Do you have worker processes defined on the SSL side ...

As far as I can tell, my config files are essentially the same, at least for Apache. There was an "allowLinking" syntax change in the Tomcat context.xml that gave me fits for a couple of hours ... where would these "worker processes" be defined on the SSL side? Isn't workers.properties sufficient?

arnold

Yes, those I had in mind.
Is tomcat accessible on the localhost?

Look at the jk_mod log to see whether that is where the issue is.

Is the tomcat actually running?

ASKER CERTIFIED SOLUTION

arnold

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

Mark

ASKER

Well, you put me on the trail of the solution. As it turns out, the JkMount directives must be in httpd-ssl.conf as well as in httpd-tomcat.conf, and it doesn't help putting the JkMounts globally in httpd.conf. See http://www.javacodegeeks.com/2012/06/apache-http-server-with-tomcat-on-ssl.html. When I put:

JkMount /ohprs/* worker1
JkMount /ohprs worker1

JkMount /office/* worker1
JkMount /office worker1

in the <VirtualHost> section of httpd-ssl.conf, it started working!!

I've checked my previous Apache/Tomcat config files and I definintely do not have these JkMounts in that httpd-ssl.conf! Looks like another major, hours-wasting change the Apache folk made. Possibly these are in some read-me or release notes somewhere, but I didn't notice. A one or two line comment in the appropriate config file would have been infinitely helpful!