https to https internal port via proxy

[Burton]

I was upgrading our internal HTML5 app to use SSL and my proxy pass htaccess files no longer work.

I am running tomcat which has its own SSL setup and running on port 8080. On the same server the HTML5 app lives on 443 (was 80 before the switch)


Example of htaccess file before it broke.

Options +FollowSymLinks
RewriteEngine on 
RewriteRule ^proxy/findaid(.*)$http://example.com:8080/proxy/findaid$1[P]

This is what it looks like now

Options +FollowSymLinks
RewriteEngine on 
RewriteCond %{HTTPS} on
RewriteRule ^proxy/findaid(.*)$https://example.com:8080/proxy/findaid$1[P]

Going to [example.com...] will throw a internal server error 500


Behavior I have noticed.

When changing the options to [R=301,L] it will simply redirect to the :8080 port.
So going to [example.com...] will send you to [example.com:8080...]

The problem is I have to pass it via [p] proxy or the HTML5 code will not be able to communicate with it without me setting up another layer of PHP for it to filter through. Using [R=301,L] i get back an internal uncaught error which can be expressed in chromes console by appending :8080 on example.com within the call. At this point I get an OPTIONS [example.com...] Resource failed to load. (The call is really a GET call, never a POST call, CORS cannot fix this as my api doesn't support it)

As mentioned before when using [p] I will simply get an internal server error 500 returned.

If I remove the SSL on tomcat and then forward via htaccess to http://example.com/proxy/findaid$1 then it will work every time. But obviously this isn't secure.

To do another test I also tried to use proxy [p] to direct the user to
a known SSL test page and this also produced an internal server error 500.


Other Notes
Tomcat and apache2 both have different certificates setup, if this is relevant at all. Both sites have been 'accepted' prior to testing.

[phranque]

do you know if that 500 status code was thrown by the front-end server or by the proxy server?
if you got a 500 Internal Server Error response you will almost certainly have an associated server error log entry.

[Burton]

The 500 returns this in the logs:

[client IPADDRESSHERE] SSL Proxy requested for 127.0.1.1:443 but not enabled [Hint: SSLProxyEngine]
proxy: HTTPS: failed to enable ssl support for IPADDRESSHERE:8080 (IPADDRESSHERE)

This was for the [example.com...] address.

If I go to [example.com...] it will bring up the site in SSL, and it will return the json object if I go to the above address and append :8080 on to the example.com.

I will look into my settings to see if the engine is disabled or not specified. I know tomcat turns off the APR SSLEnging in favor of other methods and specifies TLS as its protocol. I know it supports APR so maybe I should try to get it to work on that as well.

my default and default-ssl both have SSLEngine on, and SSLOptions +StrictRequire flagged.


Just checked the tomcat logs and this is what I found:

IPADDRESSHERE - - [20/Jun/2012:10:45:05 -0400] "GET /proxy/findaid?aid=1 HTTP/1.1" 200 1312

[Burton]

Update: Still not working BUT I think I know why it isn't working.

The only way I was able to get the tomcat services working on 8080 with SSL by turning the APR in tomcats config off per the user guide I read. I noticed you could set up APR and use it which come to find out is what I should be doing.

The APR, when not bypassed in tomcat, uses APACHE as its SSL handler and doesn't rely on the slow tomcat SSL implementation.

After beating my head against a wall most of the morning I realized APR wasn't even installed, figuring out how to do this took some searching and luck but it is now installed as well as other dependencies needed by Tomcat to run APR SSL.

Sadly I have not been able to get the config files set up in tomcat to accept the cert / key from the apache install. There really are not any good entries in the log files for tomcat to indicate why the settings are not working but at least it is a start.

This is my current error now when trying the proxypass. I should note example.com:8080 does not bring up the base tomcat install unless I revert to blocking APR.

[Thu Jun 21 13:01:47 2012] [error] (111)Connection refused: proxy: HTTPS: attempt to connect to IPADDRESSHERE:8080 (*) failed

UPDATE: Found some good stuff buried in some tomcat logs

INFO: The APR based Apache Tomcat Native library which allows optimal performance in production environments was not found on the 
java.library.path: 
/usr/lib/jvm/jdk1.6.0_30/jre/lib/i386/server:
/usr/lib/jvm/jdk1.6.0_30/jre/lib/i386:
/usr/lib/jvm/jdk1.6.0_30/jre/../lib/i386:
/usr/lib/oracle/11.2/client/lib:
/usr/java/packages/lib/i386:
/lib:/usr/lib

So apparently java doesn't know I installed APR or the package it is trying to reference is a different version. Looking into it. Hopefully fixing this will 'fix' the https > https issue.

[Burton]

Solved:

Installed APR
Installed Native tomcat and told it where APR was
Copied lib files from APR into a path java.library.path had active, in my case the oracle /lib

Added to the default-ssl:
SSLProxyEngine On
<Proxy *>
Order deny,allow
Allow from all
</Proxy>
and updated SSLCertificateFile and SSLCertificateKeyFile locations to the ones I created and signed.

Added to the default
<Proxy *>
Order deny,allow
Allow from all
</Proxy>
SSLProxyEngine on
SSLEngine on
SSLOptions +StrictRequire
SSLCertificateFile /etc/ssl/certs/mycert.crt
SSLCertificateKeyFile /etc/ssl/private/server.key

added to the tomcat config file:
<Connector port="8443" maxHttpHeaderSize="8192"
maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
enableLookups="false" disableUploadTimeout="true"
acceptCount="100" scheme="https" secure="true"
clientAuth="false"
sslProtocol="TLS"
SSLEngine="on"
SSLEnabled="true"
SSLPassword="himitsu"
SSLCertificateFile="/etc/ssl/certs/mycert.crt"
SSLCertificateKeyFile="/etc/ssl/private/server.key" />


In my tomcat logs it can now find the APR and instantiate it as needed. And obviously now apache can control communication with tomcat since it is using APR so the proxy goes through via ssl on 8443.

Questions welcome.