NodeBalancer without SSL termination -ERR_SSL_PROTOCOL_ERROR

The only way that port 80 in http mode is working on the NodeBalancer is if the backend server it's talking to is talking HTTP, not HTTPS. As such, if it's talking to port 443 on your backend, your backend is not talking HTTPS. If that's the case, and you route port 443 on the NodeBalancer to 443 on the backend via TCP mode, you'd need to talk to that via HTTP as well, not HTTPS.

Double check whether your backend server is actually using SSL on port 443. If it's not, you're gonna want to turn it on (and make sure it's serving HTTP on port 80, so you can route the NodeBalancer's port 80 traffic there).

• Les

Indeed it is serving SSL on port 443, at least when I'm not using the nodebalancer.

Do I need to check that it's using SSL on port 443 when it's accessed from its network? I might need a pointer how to check that.

Oh and your first comment…I see it's because I wasn't clear in my parenthesized note: (192.168.1.1:443) I only gave that for the one I was having trouble with, but the HTTP one is 192.168.1.1:80. I'm sorry about my poor question asking skills.

What is your NodeBalancer's actual IP, what is the backend's private IP, and what datacenter are they in?

If by chance you're actually using "192.168.1.1:80" and "192.168.1.1:443": that IP definitely isn't your Linode's private IP, and you should use your real private IP that you find on the Remote Access tab.

• Les

NodeBalancer public: 23.92.23.30

Server private: 192.168.182.86

Newark

No I was using the real private IP. I should have denoted the numbers with 192.168.x.x but now what difference can it make.

While we're at giving out specific info, here's the hostname as well that I've been working with: strictlyt.com

I tested it at https://www.ssllabs.com/ssltest/analyze … com&latest">https://www.ssllabs.com/ssltest/analyze.html?d=strictlyt.com&latest and it pointed out incompatibility with some older browsers that aren't SNI compatible. I'm thinking this might have something to do with that. Perhaps giving this account its own IP would solve the issue because the nodebalancer doesn't support SNI?

The NodeBalancer is never doing an HTTPS handshake with your backend server, so SNI and ciphers play no role.

Your backend server is throwing the error, not the NodeBalancer:

❯ curl -I https://192.168.182.86
curl: (35) error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol

This is because your backend is responding with HTTP on port 443, not HTTPS:

❯ curl -I http://192.168.182.86:443
HTTP/1.1 302 Found
Date: Wed, 17 Dec 2014 05:25:24 GMT
Server: Apache/2.4.10 (Unix) OpenSSL/1.0.1e-fips mod_bwlimited/1.4
Location: http://192.168.182.86:443/cgi-sys/suspendedpage.cgi
Content-Type: text/html; charset=iso-8859-1

As I said, you're going to want to look into that.

• Les

Thanks for your help. As it turns out, my vhosts templates did not specify which port to use for the private IP (which I inserted manually into the template), so it was grabbing the first virtualhost specified that happened to be the one without the SSLCertificateFile directives. I specified the ports and bingo: it works.