Providing HTTP access via reverse proxy to an internal HTTPS site

Posted on

Providing HTTP access via reverse proxy to an internal HTTPS site – Problems with loading a website are often blamed on the Internet connection, but even the most perfectly set up network cannot help if there is no service to reply at your destination. One of the most popular HTTP servers used for this task is Apache2. Much of Apache’s popularity can be attributed to its easy installation and use, but never the less it is possible to run into problems with even the easiest of the software. If you’ve encountered an issue loading your web page, follow these simple troubleshooting methods outlined in this guide to attempt to get your web server back up and working again. Below are some tips in manage your apache2 server when you find problem about apache-2.2, https, reverse-proxy, , .

I am trying to set up an HTTP reverse proxy to an internal HTTPS server. As a sidenote, yes, I know I am throwing all security away. The original HTTPS server is not sensitive in nature for us, and the product that runs it does not allow turning off HTTPS or reconfiguring the embedded webserver in any way.

I have tried with Nginx, but most people out there seem to be using Apache, so that’s what I’m trying now.

This is my current virtual host configuration:

<VirtualHost 0.0.0.0:10443>
    ServerName server.domain.com

    SSLProxyEngine on
    #UnknownSSLDirectives
    #SSLProxyMachineCertificateFile /etc/apache2/selfsignedcert.pem
    SSLProxyCACertificateFile /etc/apache2/selfsignedcert.pem

    ProxyRequests Off
    ProxyPass / https://internalserver.internaldomain.com:2941/
    ProxyPassReverse / https://internalserver.internaldomain.com:2941/

    <Proxy>
        Order Deny,Allow
        Allow from all
    </Proxy>

    RequestHeader unset Authorization

    ErrorLog /var/log/apache2/internalserver-error.log
    CustomLog /var/log/apache2/internalserver-access.log common

</VirtualHost>

When I try to open http://server.domain.com:10443/ I get the error “401 Unauthorized”.

In other ServerFault questions I saw references to UnknownSSLDirectives, but Apache complains that the option doesn’t exist.
And to using SSLProxyMachineCertificateFile instead of SSLProxyCACertificateFile, but Apache complains that the SSL setup is incomplete in that case.

I am quite stuck. How can I debug this or make some progress? Thank you!

As of 2018, don’t recommend Apache or stunnel for this task. I’d recommend haproxy for its clarity and speed.

As for Apache 2.2, you made mistake with <Proxy>. In a reverse proxy scenario, the access to ProxyPass is controlled with <Location> block, not with <Proxy>.

The <Proxy> applies only to forward proxies and you make a reverse proxy. It’s in the manual.

I don’t have an answer, but here are some suggestion for debugging the problem.

I’d try to go with “reverse SSL termination” using stunnel in client mode (http://www.thegoldfish.org/2010/01/stunnel-in-client-mode/), and try whether I can connect to http directly via stunnel on a high port (via curl / lynx / tunneling the high port via ssh). At this moment, I deal only with ssl client, and not with Apache’s proxy settings.

When I got this working, I’d try to set up plain unencrypted http proxy in Apache to the stunnel port. I got decryption part working, and unencrypted http proxy in Apache is a known and well documented setup. Also, I can use a sniffer (such as tcpdump) to listen on communication between Apache and unencrypted stunnel socket.

Only after this is working, I’d try to figure out how to remove the stunnel middleman and make Apache itself talk https.

Side note: I’d expect some problems with authentication if the backend service sets the secure flag on cookies, and browser believes it’s on unencrypted http. Some other headers and redirects may also create problems. In any case, debug the service with curl -v before using browser, and use a Web inspector (such as Firebug) to inspect request/response headers and cookies.

Leave a Reply

Your email address will not be published.