Error during SSL Handshake with remote server

Question

I have Apache2 (listening on 443) and a web app running on Tomcat7 (listening on 8443) on Ubuntu.

I set apache2 as reverse proxy so that I access the web app through port 443 instead of 8443. Besides, I need to have SSL communication not only between browser and apache2 but also between apache2 and tomcat7, thus I set SSL on both apache2 and tomcat7. If I try to access the web app by directly contacting tomcat7, everything is fine. The problem is that when I try to access the tomcat's web app through apache2 (reverse proxy), on the browser appears the error:

Proxy Error
The proxy server could not handle the request GET /web_app.
Reason: Error during SSL Handshake with remote server

Answer 1

The comment by MK pointed me in the right direction.

In the case of Apache 2.4 and up, there are different defaults and a new directive.

I am running Apache 2.4.6, and I had to add the following directives to get it working:

SSLProxyEngine on
SSLProxyVerify none 
SSLProxyCheckPeerCN off
SSLProxyCheckPeerName off
SSLProxyCheckPeerExpire off

Answer 2

I have 2 servers setup on docker, reverse proxy & web server. This error started happening for all my websites all of a sudden after 1 year. When setting up earlier, I generated a self signed certificate on the web server.

So, I had to generate the SSL certificate again and it started working...

openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout ssl.key -out ssl.crt

Answer 3

On a remote OEL (Oracle Enterprise Linux) 7.8 server, i have a backend web application running with HTTPS/8009. As its a third party app, I did not have choice to disable SSL or change port.

As i needed to access the web app from my local machine's browser, i thought of setting up a reverse proxy (HTTP to HTTPS mapping) using Apache httpd. Now i can access the web app from my local browser through below URL:

http://10.157.146.97:1234/

FYI, CURL commands working inside the Linux Machine were below ones:

curl http://10.157.146.97:1234/
curl -k https://localhost:8009/

Here is my reverse proxy setup :

/etc/httpd/conf/httpd.conf

Listen 1234

<VirtualHost *:1234>
SSLProxyEngine On
SSLProxyVerify none
SSLProxyCheckPeerCN off
SSLProxyCheckPeerName off
SSLProxyCheckPeerExpire off
ProxyPreserveHost On
ProxyPass / https://localhost:8009/
ProxyPassReverse / https://localhost:8009/
</VirtualHost>

One aspect i struggled a lot, earlier i was trying with url pattern (/sample) in ProxyPass/ProxyPassReverse but that was causing HTTP 404 (not found) for css/js files as web-app's welcome page contains indirect css/js paths (sample code below). So replacing url pattern (/sample) with (/) solved that problem too.

previous Not working config:
ProxyPass /sample https://localhost:8009/
ProxyPassReverse /sample https://localhost:8009/

<script defer src="abc.js"></script><link href="xyz.css" rel="stylesheet"></head>  

Answer 4

Faced the same problem as OP:

• Tomcat returned response when accessing directly via SOAP UI
• Didn't load html files
• When used Apache properties mentioned by the previous answer, web-page appeared but AngularJS couldn't get HTTP response

Tomcat SSL certificate was expired while a browser showed it as secure - Apache certificate was far from expiration. Updating Tomcat KeyStore file solved the problem.

Answer 5

Here is my variation on this theme, inspired by this Git gist. The server is a Docker container with an internal self-signed SSL certificate, reachable at https://localhost:8443. Proxied to server.example.org:443. Relevant config details:

<VirtualHost AAA.BBB.CCC.DDD:443>
    ServerName server.example.org

    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined

    # These settings are definitely needed
    SSLEngine On
    SSLProxyEngine On
    ProxyRequests Off
    SSLProxyVerify none 
    SSLProxyCheckPeerCN off
    SSLProxyCheckPeerName off
    SSLProxyCheckPeerExpire off

    # These may not be needed, depending on proxied application
    ProxyPreserveHost on
    RequestHeader set X-Forwarded-Proto https

    ProxyPass "/" "https://localhost:8443/"
    RewriteEngine on
    RewriteCond %{HTTP:Upgrade} websocket [NC]
    RewriteCond %{HTTP:Connection} upgrade [NC]
    RewriteRule ^/?(.*) "wss://localhost:8443/$1" [P,L]
    ProxyPassReverse "/" "https://localhost:8443/"
</VirtualHost>

The section between SSLEngine On and RequestHeader... I put together via Googling and trial and error. Maybe some of these settings are not needed, YMMV.

Note: the RewriteRule with "wss" was needed because the server uses secure websockets.

Platform: Ubuntu 20.04.3 LTS, Apache 2.4.41.

Answer 6

My problem was having one Apache server behind another and having mismatched certificates on each server.

It took me a while to realise that

SSLCertificateFile

and

SSLCertificateKeyFile

were pointing to files with the same names on each server, but that the first first server had an updated certificate and private key compared with the second one, so the content of the files was different.

Answer 7

If the host of your apache proxy is different from the host of the proxy target (or its sni name), set -

ProxyPreserveHost Off

Answer 8

Note that the error might also occur when your system have TLSv1 disabled. Like e.g Ubuntu 20.x have TLSv1.0 disabled by default. For example if you have something like this:

Apache 2.4.41 on Ubutntu20 (proxy) --[https]--> old Apache serving TLS v1.0

SSLProxyVerify etc will not help you.

What you need to do is to enable TLS 1.0 in openssl.conf. At least until you can update the old server ...

Enabling old TLS on Ubuntu

So in Ubuntu 20.04.3 TLS to effectively enable TLSv1 change /etc/ssl/openssl.cnf. At the top of the file (before any sections) add:

# Added to enable TLS1.0
openssl_conf = default_conf

And on the very end of the file

##
# Added to enable TLS1.0
[default_conf]
ssl_conf = ssl_sect

[ssl_sect]
system_default = system_default_sect

[system_default_sect]
CipherString = DEFAULT@SECLEVEL=1
##

Comments are obviously not required , but will help when you want to disable TLS1 again.

Once you restart / reboot everything should work fine.

Note that this is a global (system-wide) change. So it is not ideal, but it just works. See also: more notes about Ubuntu and default TLS versions.