1

I'm trying to get a site secured with SSL, using nginx on Ubuntu 14.04.

Here's what my server block file looks like:

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

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name example.com;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    return 301 https://www.example.com$request_uri;
}

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name www.example.com;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;


    root /var/www/html;

    index index.php;

    location = /favicon.ico { log_not_found off; access_log off; }

    location = /robots.txt { log_not_found off; access_log off; allow all; }

    location ~* \.(css|gif|ico|jpeg|jpg|js|png)$ {
        expires max;
        log_not_found off;
    }

    location / {
        #try_files $uri $uri/ =404;
        #index index.php index.html index.htm index.nginx-debian.html;
        try_files $uri $uri/ /index.php$is_args$args;
    }

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php7.0-fpm.sock;
    }

    location ~ /\.ht {
        deny all;
    }

    location ~ /.well-known {
        allow all;
    }
}

The 3rd block is the "main" block which serves the www url with https (works fine). The 1st block redirects any http and non-www requests to the 3rd block (works fine).

The second block does not work. What I'm trying to achieve here is direct any https and non-www requests to the 3rd block, but attempting to access the site this way yields "example.com refused to connect" (different from what Chrome calls ERR_CONNECTION_REFUSED in that no error is shown in the Network tab for the request and it's simply an empty request).

I've tried many things and I'm at a loss as to why this is the case.

Additional info: the nginx access logs show a 200/OK response when accessing the block 2 url (https without www), but the response is simply empty.

smerg
  • 131
  • 1
    Check if you can access the site from the local machine where the server is running on (using curl, wget or similar). Alternatively check the output of netstat -nlpt and verify that it is actually listening on the IP and port. If all this succeeds then there is probably a firewall setting blocking access from outside on this port. – Steffen Ullrich Mar 14 '17 at 17:40
  • Local access is successful via wget and curl, and netstat -nlpt shows it's indeed listening on 443. Small update on the error: it's not the same "connection refused" I had before (had that in cache), rather it's "This site can't be reached - example.com refused to connect." with no error in the network tab - the response to the GET is just empty.

    I've entirely disabled the VPS firewall and it still happens. There is no provider-level firewall (it's DigitalOcean) that I know of.

     – smerg Mar 14 '17 at 17:50
  • Couple of basics: DNS CNAME set up correctly for www, and the certificate includes the www subdomain? – Tim Mar 14 '17 at 17:53
  • Possible duplicate of What causes the 'Connection Refused' message? – user9517 Mar 14 '17 at 17:57
  • I'm using an A record for www rather than CNAME, and the certificate was issued via Let's Encrypt certbot with -d example.com -d www.example.com so both are included. – smerg Mar 14 '17 at 17:57
  • It would be helpful to you if you posted the real domain name. – Michael Hampton Mar 14 '17 at 19:08
  • @MichaelHampton I'm not allowed to disclose the site unfortunately, as I'm not the owner. – smerg Mar 14 '17 at 22:08

1 Answers1

2

Solved -- This was a case of failure due to magic.

The domain name registrar control panel has a www/no-www convenience setting which causes a redirect that overrides the DNS settings.

Disabling the convenience setting (i.e. choosing "no preference") made the actual DNS settings work.

smerg
  • 131