1

I have a page example.com, which has ssl certificates setup and everything is working fine. Here is the ssl part of the config:

server {
  listen 80 default_server;
  server_name www.example.com example.com;
  return 301 https://$server_name$request_uri;
 }

server {
    listen  443 default_server;
    server_name example.com www.example.com;

  # strenghen ssl security
  ssl_certificate /some/ssl/files.crt;
  ssl_certificate_key /some/ssl/files.key;
  ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
  ssl_prefer_server_ciphers on;
  ssl_session_cache shared:SSL:10m;  
  ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:ECDHE-RSA-AES128-GCM-SHA256:AES256+EECDH:DHE-RSA-AES128-GCM-SHA256:AES256+EDH:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4";
  ssl_dhparam /etc/ssl/certs/dhparam.pem;

  # Add headers to serve security related headers
  add_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload;";
  add_header X-Content-Type-Options nosniff;
  add_header X-Frame-Options "SAMEORIGIN";
  add_header X-XSS-Protection "1; mode=block";
  add_header X-Robots-Tag none;

When I browse example.com everything I get the page with ssl, so everything is working as expected.

Then when I browse 'http://dl.example.com' which has the following server config, nginx always rewrites it to https://dl.example.com which brings me back to https://example.com (beacuse dl.example.com is not set to use ssl and https://example.com is the default server). But why? This page is not even setup to use any kind of ssl but it does? My guess is that the ssl rewrites from 'example.com' are somehow cached and are also valid for 'dl.example.com'. Is it somehow possible to tell nginx to avoid any cache and don't even consider using any kind of ssl for one particular vhost?

server {
    listen 80;
    server_name dl.example.com;

    root /var/www/dl.example.com/files/;

    location / {
        autoindex on;
    }
}
Flatron
  • 318
  • 2
  • 5
  • 19
  • Are you sure that the `server` block for `dl.example.com` is being seen by `nginx`? The behaviour is consistent with the URL being interpreted as the non-SSL `default_server`. – Richard Smith Nov 13 '15 at 17:25
  • Both vhosts are in seperate files and symlinked to 'sites-enabled'. e.g. there is one file called example.com containing the upper vhost and one called dl.example.com which contains the lower vhost. – Flatron Nov 13 '15 at 17:53

1 Answers1

2

Sometimes things are starring in your face but you don't see them... The solution is to remove the highlighted http header flag from my root websites vhost below:

[...]** add_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload;";**[...]

What this basically does is pretty obvious, once you visit the main website 'example.com' your browser will cache the http headers for this domain and as we strictly forced to use strict transport security including subdomains we got into this issue (That once you visited the main side all subdomains regardless of their configuration were forced to use ssl). After removing this header flag and restarting nginx all is working fine again!

I hope this answer helps someday somebody out there.

server {
  listen 80 default_server;
  server_name www.example.com example.com;
  return 301 https://$server_name$request_uri;
 }

server {
    listen  443 default_server;
    server_name example.com www.example.com;

  # strenghen ssl security
  ssl_certificate /some/ssl/files.crt;
  ssl_certificate_key /some/ssl/files.key;
  ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
  ssl_prefer_server_ciphers on;
  ssl_session_cache shared:SSL:10m;  
  ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:ECDHE-RSA-AES128-GCM-SHA256:AES256+EECDH:DHE-RSA-AES128-GCM-SHA256:AES256+EDH:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4";
  ssl_dhparam /etc/ssl/certs/dhparam.pem;

  # Add headers to serve security related headers
  add_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload;";
  add_header X-Content-Type-Options nosniff;
  add_header X-Frame-Options "SAMEORIGIN";
  add_header X-XSS-Protection "1; mode=block";
  add_header X-Robots-Tag none;
Flatron
  • 318
  • 2
  • 5
  • 19