0

I've already search the whole web for an answer, unfortunately there isn't. I hope there is a genius out here.

Context: My nginx acts as a reverse proxy serving multiple domains

Problem: the problem occurs when a non-ssl domain gets forced to use https, I am trying to force a redirect back to http but it gives an SSL error before the redirect can be processed

Behavior:

  • The web browser gives an error on Chrome in incognito mode: "This is probably not the site you are looking for! You attempted to reach xxxx.com [client website], but instead you actually reached a server identifying itself as proxydomain.com [proxy identity]."
  • Only once you click "Proceed anyways" the browser will do the rewrite redirection

Config file that is currently in production but does the error:

server {
       listen 443 ssl;
       server_name _;

       ssl_certificate      conf.d/proxydomain_com.pem;
       ssl_certificate_key  conf.d/proxydomain_com.key;

       rewrite ^(.*)$ http://$host$request_uri permanent;
 }

Attempted solutions: https://stackoverflow.com/questions/3893839/how-do-i-redirect-https-requests-to-http-in-nginx/3915822#3915822

  • It is whining of an invalid SSL certificat for this domain (obviously) but if I take off the ssl_certificate attribute (error ssl_error_bad_cert_domain)
  • If i try to take off the "ssl" in the listen attribute i get an ssl_error_rx_record_too_long

Spent 4 hours on this going on 5, any ideas?

Thank you very much :)

2 Answers 2

0

The redirect will be done in the HTTP protocol. HTTPS is HTTP wrapped inside a SSL connection, so if establishing the SSL connection fails because of a bad certificate there will never be the redirect to http://. So to make this working you have to use a certificate which the client accepts, e.g. matching the host name and issued by a trusted CA.

If you take off the ssl it will just start a normal non-ssl http server on port 443 but the browser will try to talk SSL and thus you get this error about record_too_long.

9
  • Thx for the answer. Everything you said is correct, but the goal of doing a redirection to HTTP is to actually avoid having trusted CA certificat for each domain, since most of them don't have. According to many blogs (including the StackOverflow page I sent), the rewrite redirect should work on a non-ssl session through port 443, but isn’t... The ssl_error_bad_cert_domainis flag still remains whatsoever I try to do. Thank you for your help.
    – Fredow
    Apr 28, 2014 at 17:51
  • It will work with a non-ssl (http://) session to port 443 but the problem you have is that you want to redirect a ssl session (https://). And https:// against non-ssl port 443 will just fail if you configured the server to speak http (e.g. non-ssl) and not https (ssl). If you want to redirect https:// there is no choice other than to first establish a ssl-session, and thus you need a certificate the client accepts. Apr 28, 2014 at 18:10
  • Make sense since the SSL handshake occurs before the client sends the request. I’ve checked how other hosting companies handles that issue and none of them actually does, so I guess we can't do anything about it. That said, the origin of my concerns regarding this post was that, in some cases, it seems that web crawlers actually associates the client domain running with the invalid SSL cert with the hosting provider domain's. An example will follow.
    – Fredow
    Apr 28, 2014 at 20:45
  • Example, if you type "proxydomain" in a search engine, the equivalent of clientdomain.com via https (invalid) will figure in the results, but with the same headers of proxydomain.com (only URL changes). I am thinking that this is related with the issue we talked about. Thoughts?
    – Fredow
    Apr 28, 2014 at 20:46
  • @Fredow: I'm not sure if I fully understand you, but most crawlers seem to ignore certificate errors - otherwise I could not understand why lots of links with bad certificates are in the search results. Also, they might not use SNI to specify the target host name already in the SSL handshake and thus they get different results than the borwsers do. Apr 28, 2014 at 21:03
0

Check the log file, if you see something like:

46.17.57.175 - - [15/Oct/2015:11:15:00 -0400] "\x80t\x01\x03\x01\x00K\x00\x00\x00 \x00\x009\x00\x008\x00\x005\x00\x00\x16\x00\x00\x13\x00\x00" 400 166 "-" "-"

this is a failed SSL connection because of an out of date TLS. The trick/handle is nginx detects it and returns a "400" error. You can always catch those errors, filter them and do what you want for the visitor. (the IP/request record is an openVAS security probe to test TLS connections)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .