2

I'm configuring new Nginx server which will be used as reverse proxy. We have older Debian server with Apache up and running. On this apache server is site with HTTPS only access I want to hide behind proxy.

Connection from proxy to upstream Apache must be over HTTPS (servers are in different locations and apache allow only HTTPS access).

My problem is that connection from Nginx to Apache fails. Normal connection from browser to upstream over HTTPS work without problems. Connection from same proxy to Nginx upstream works. By when Nginx try connect to upstream Apache connection fails with Re-negotiation handshake failed

Log from proxy Nginx (debug level) says only:

2016/04/07 15:51:08 [error] 5855#0: *1 upstream prematurely closed connection while reading response header from upstream, client: 94.113.97.9, server: procrastination.com, request: "GET / HTTP/1.1", upstream: "https://77.240.191.234:443/", host: "procrastination.com"

Log from upstream Apache:

[Thu Apr 07 15:36:48 2016] [info] Initial (No.1) HTTPS request received for child 35 (server procrastination.com:443)
[Thu Apr 07 15:36:48 2016] [debug] ssl_engine_kernel.c(421): [client 83.167.254.21] Reconfigured cipher suite will force renegotiation
[Thu Apr 07 15:36:48 2016] [info] [client 83.167.254.21] Requesting connection re-negotiation
[Thu Apr 07 15:36:48 2016] [debug] ssl_engine_kernel.c(764): [client 83.167.254.21] Performing full renegotiation: complete handshake protocol (client does support secure renegotiation)
[Thu Apr 07 15:36:48 2016] [info] [client 83.167.254.21] Awaiting re-negotiation handshake
[Thu Apr 07 15:36:58 2016] [error] [client 83.167.254.21] Re-negotiation handshake failed: Not accepted by client!?

My Nginx site configuration on proxy:

server {
  listen 80;
  listen 443 ssl;

  server_name procrastination.com *.procrastination.com;

  ###
  # SSL
  ###
  ssl  on;
  ssl_certificate         /etc/ssl/localcerts/procrastination.com/fullchain.pem;
  ssl_certificate_key     /etc/ssl/localcerts/procrastination.com/privkey.pem;

  ##
  # Logging Settings
  ##
  access_log /var/log/nginx/procrastination_proxy-access.log;
  error_log /var/log/nginx/procrastination_proxy-error.log debug;


  include /etc/nginx/snippets/common;
  include /etc/nginx/snippets/proxy_params;

  location / {
    proxy_pass https://brigita_https;
    proxy_ssl_name $host;
  }
}

SSL related part of nginx.conf on proxy:

ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # Dropping SSLv3, ref: POODLE
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_prefer_server_ciphers on;

Apache site configuration on upstream:

<VirtualHost 77.240.191.234:80>
  ServerName procrastination.com
  ServerAlias *.procrastination.com
  DocumentRoot /var/www/procrastination-production/build/current/www
  php_value newrelic.appname /var/www/procrastination-production/build/current/www

  RewriteEngine On
  RewriteCond %{HTTPS} !=on
  RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L]

</VirtualHost>


<VirtualHost 77.240.191.234:443>
  ServerName procrastination.com
  ServerAlias *.procrastination.com
  DocumentRoot /var/www/procrastination-production/build/current/www
  php_value newrelic.appname /var/www/procrastination-production/build/current/www

  SSLEngine On
  SSLCertificateFile /etc/apache2/ssl/ssl_procrastination_com.crt
  SSLCertificateKeyFile /etc/apache2/ssl/ssl_procrastination_com.key

  RewriteCond %{HTTP_HOST} !^www\..*$
  RewriteRule (.*) https://www.%{HTTP_HOST}%{REQUEST_URI} [L]

</VirtualHost>

Other Apache config values are on default.

Any idea what could be the cause or where to look for more diagnostic data?

6

Solved!

Problem was in SNI on Apache upstream. Nginx didn't pass correct parameters and Apache sent him wrong certificate.

You need to set proxy_ssl_server_name on in Nginx config.

Just change:

  location / {
    proxy_pass https://brigita_https;
    proxy_ssl_name $host;
  }

to:

  location / {
    proxy_pass https://brigita_https;
    proxy_ssl_name $host;
    proxy_ssl_server_name on;
  }
  • Thanks, big help with my client certificates, nginx as a rproxy and apache tu handle the request. – Cédric Girard Oct 25 '16 at 14:07

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.