Need help trouble shooting Https webserver error - SSL Handshake failed

Question

I followed this guide: http://hints.macworld.com/article.php?story=20041129143420344

Here is my virtual host definition

<VirtualHost *:443>
    SSLEngine on
    SSLProxyEngine On
    RequestHeader set Front-End-Https "On"
    CacheDisable *
    SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
    DocumentRoot "/Users/me/projects/myproject/public"
    ServerName ssl.mydomain.com
    ServerAlias *.ssl.mydomain.com
    SSLCertificateKeyFile "/private/etc/apache2/certs/webserver.nopass.key"
    SSLCertificateFile "/private/etc/apache2/certs/newcert.pem"
    SSLCACertificateFile "/private/etc/apache2/certs/demoCA/cacert.pem"
    SSLCARevocationPath "/private/etc/apache2/certs/demoCA/crl"
    ErrorLog "/Users/me/Desktop/ssl.log"

    ProxyPass / https://localhost:3002/
    ProxyPassReverse / https://localhost:3002
    ProxyPreserveHost on    
</VirtualHost>

And when I try connecting to the sevre viov the web browser, I get this error:

[Thu Feb 02 16:50:40 2012] [error] (502)Unknown error: 502: proxy: pass request body failed to 127.0.0.1:3002 (localhost)
[Thu Feb 02 16:50:40 2012] [error] [client 96.11.81.39] proxy: Error during SSL Handshake with remote server returned by /session/new
[Thu Feb 02 16:50:40 2012] [error] proxy: pass request body failed to 127.0.0.1:3002 (localhost) from 96.11.81.39 ()

how do I debug / fix this?

score 13 · Answer 1 · answered Feb 27 '14 at 13:15

13

To add to vbartoni's answer, it seems that from 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

answered Feb 27 '14 at 13:15

mydoghasworms

231
3
7

2

That does the job - only with all those directives its not gonna complain. – Michael Böckling Aug 25 '14 at 17:30
@MichaelBöckling Thank you that held me up. I want to point out specifically that the documentation states that `SSLProxyCheckPeerName` supersedes `SSLProxyCheckPeerCN` but it won't work unless you specify **all** of the directives. – dualed Apr 24 '15 at 16:37

score 3 · Answer 2 · answered May 25 '12 at 08:39

I had a similar problem (the same error logs), except that the proxy was forwarding https traffic to another host.
Since I was lazy and the hosts are in my own isolated network, these directives solved the problem:

SSLProxyVerify none
SSLProxyCheckPeerCN off

score 2 · Answer 3 · answered Feb 03 '12 at 20:04

2

Don't bother with HTTPS between your front-end and your back-end server, there's little point in enabling SSL for a localhost connection.

To clarify, use ProxyPass / http://localhost:3002/ instead of ProxyPass / https://localhost:3002/

Alternatively, if you really want to connect your reverse proxy to the back-end server using SSL as well (mostly useful when that server isn't where the Apache Httpd reverse proxy is), in addition to https://backend-server-address, use the SSLProxy* directives to set up the CA certs, as documented in the introduction to the mod_proxy documentation. In particular, you would need to configure SSLProxyCACertificateFile and make sure the certificate of the backend server is issued to the right host name as seen by Apache Httpd (i.e. localhost in your case).

If you're not connecting to your back-end server using SSL, it may fail to detect you're actually using SSL and be configured to force you to go to SSL (hence the infinite redirects). You may want to look at similar mechanisms as what Jetty does with its forwarded option (to be able to tell the back-end it's behind a proxy). Rails might be able to interpret the X-Forwarded-Proto by default. In this case, add this to your Apache config (in the SSL virtual host):

RequestHeader set X-Forwarded-Proto 'https'

There seems to be a similar issue discussed here, for example.

answered Feb 03 '12 at 20:04

Bruno

4,099
1
21
37

SSLProxy is only mentioned once on that link. No examples of how to use it. I changed the request header to be set X-Forwarded-Proto 'https'... but it still doesn't work / I get the same error. Going to https://localhost:3002 also gives the same error – NullVoxPopuli Feb 06 '12 at 13:26
1

There are valid reasons for connecting to https with localhost: example socket.io in an HTTPS back-end. It will through errors with mixed content. – Florestan06 Jun 17 '15 at 09:45
If your backend need SSL connections with some servers, you need to put that backend with HTTPS. – Leandro Bardelli Dec 29 '20 at 04:15
@MacGyver What do you mean by "need": you have to technically, or you should from a security point of view? In the first case, that's clearly not true. In the second case, that's certainly not useful or required for connections to `localhost`, and could be unnecessary (depending on a more complex analysis of the network) if the LAN of the load-balancer is closely controlled. – Bruno Dec 29 '20 at 23:57
Bruno for e.g. if you are working with a reverse proxy – Leandro Bardelli Dec 30 '20 at 01:03
@MacGyver If the machine behind your reverse proxy is on localhost (or even on a separate LAN that's isolated from other connections, where it couldn't be intercepted), you don't need HTTPS there. Not sure what you had in mind. Also still unsure whether you mean "cannot" (impossible) or "should not" (because it could be insecure) use HTTP between the reverse proxy server (front-end) and the backend server, when the front-end uses HTTPS? – Bruno Dec 30 '20 at 22:46
can't explain my scenario because is very complex, but in any case "do not do that" is not an answer for "how do i do this?" – Leandro Bardelli Dec 31 '20 at 00:03
and by the way, I can tell you, you don't understand (at this time) the security hole you are making. – Leandro Bardelli Dec 31 '20 at 00:04
@MacGyver I'd really like you to elaborate on what you're reproaching this answer with. What exactly would be the point in enabling the HTTPS to localhost: it's a connection from the reverse proxy (front-end) to a service on the very same machine (localhost), which by definition will no go through the network. How exactly is that a security hole? I'm guessing you know you can only connect to `localhost` from the same host? There's no network traffic to be intercepted in this case. – Bruno Dec 31 '20 at 01:12
@MacGyver In short, my answer says that you don't need HTTPS when using a `localhost` backend (since it's on the same machine), and it also says you should use the options for proper certificate verification when using HTTPS connections to a (generally remote) backend, using the various `SSLProxy*` directives. Those verifications are off by default in Apache Httpd 2.4, which is bad), and I'm saying they should be enabled. Surely, you'd agree that's a good thing from a security point of view? So what do I not understand? – Bruno Dec 31 '20 at 01:20
Note that the other answers recommend to turn off certificate verification, which **is** insecure (although not an issue on `localhost`). – Bruno Dec 31 '20 at 01:24
lol, how can be use http less insecure that turn off certificate verification. Your answer is not an answer, sorry. Is just a comment. Please read guidlines – Leandro Bardelli Dec 31 '20 at 03:12
@MacGyver Just to be clear, are you talking about connections to `localhost` or to a remote machine? (Note that I'm only saying you don't need SSL for `localhost`) – Bruno Dec 31 '20 at 09:20

score 1 · Answer 4 · answered Feb 02 '15 at 18:19

1

If the backend server uses out-of-date self signed certificate, one more option is needed (if there is no access to the backend server):

SSLProxyCheckPeerExpire off

answered Feb 02 '15 at 18:19

Milan Kerslager

371
3
9

Need help trouble shooting Https webserver error - SSL Handshake failed

4 Answers4