SSL redirection and authentication on Ghost blog with Nginx

Question

I have a blog about Ghost on DigitalOcean. The same is served by Nginx, with the following configuration file:

server {
    listen 443 ssl;
    server_name www.example.com;
    return 301 $scheme://example.com$request_uri;
}

server {
    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;

    include snippets/ssl-params.conf;

    location / {
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header Host $http_host;
            proxy_set_header X-Forwarded-Proto $scheme;
            proxy_pass http://127.0.0.1:2825;
    }
}

The certificates were generated with Let's Encrypt, both for the domain with and without www. In the Ghost config.js file, the URL is written with the rules to take the SSL: https://example.com/ The problem is that when I enter my blog, My domain without wwww, login correctly and with SSL, but when I try to login with https://www.example.com I get an SSL certificate authentication error. I really do not understand what the problem might be here. I need that when entering my domain with www I redirect to the domain, but without the www. This operation I have done before with other applications node without problem, with the same configuration code above.

Answer 1

I was researching a good part of the weekend a solution for this inconvenience, and managed to find the solution. There is no bug in Let's Encrypt, nor in Nginx, all referring to a bad configuration on my part; However, I can not stop thinking that it is a strange thing, and that my solution can be improved even without saying more, this is my Nginx configuration file:

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

server {
    listen 443 ssl http2;
    server_name example.com www.example.com;

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

    include snippets/ssl-params.conf;

    if ($http_host = www.example.com) {
            return 301 https://example.com$request_uri;
    }

    location / {
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-NginX-Proxy true;
            proxy_pass http://localhost:8080/;
            proxy_ssl_session_reuse off;
            proxy_set_header Host $http_host;
            proxy_cache_bypass $http_upgrade;
            proxy_redirect off;
    }
}

To avoid dragging errors, completely remove my virtual machine and create it from scratch, also install the latest version of Nginx for Debian, which is 1.10.3, which enables me to use http2, which is also an improvement.

Answer 2

One solution is to request and install a second SSL certificate for the www subdomain.

Steps:

1. Open your nginx HTTP configuration file: sudo nano /etc/nginx/sites-available/example.com.conf. Duplicate the existing server block. Leave the first block unchanged so it will continue to work for example.com. In the second block, include www in the server_name line: server_name www.example.com;. Save & close the file.

2. Open your nginx SSL configuration file: sudo nano /etc/nginx/sites-available/example.com-ssl.conf. Leave the first block unchanged so it will continue to work for example.com. In the second block, include www in the server_name line, which will give you server_name www.example.com;. Then delete the lines starting with ssl_certificate and ssl_certificate_key because we don't need these lines because we will be requesting a new SSL certificate for the www subdomain. Save & close the file.

3. Request a Let's Encrypt SSL certificate for the www subdomain: sudo /etc/letsencrypt/acme.sh --issue --home /etc/letsencrypt --domain www.example.com -- webroot /var/www/ghost/system/nginx-root --reloadcmd "nginx -s reload" --accountemail exampleEmailAddress@example.com

4. Re-open your nginx SSL configuration file: sudo nano /etc/nginx/sites-available/example.com-ssl.conf. Return to the www.example.com server block you set up in step 2 and re-add your ssl_certificate lines: ssl_certificate /etc/letsencrypt/www.example.com/fullchain.cer; and ssl_certificate_key /etc/letsencrypt/www.example.com/www.example.com.key;. Save & close the file.

5. Reload nginx with sudo nginx -s reload, and the error should be gone.

Answer 3

Your first server block does not have a certificate definition. So you might want to duplicate the ssl_certificate and ssl_certificate_key statements in that server block.

If these are the only SSL server blocks, and because you have a common certificate file for both domains, you could move the ssl_certificate and ssl_certificate_key statements to the http level and allow them to be inherited by both server blocks.

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

server {
    listen 443 ssl;
    server_name www.example.com;
    return 301 $scheme://example.com$request_uri;
}

server {
    listen 443 ssl;
    server_name example.com;
    ...
}

See this document for more.

Answer 4

(OP did request to see my nodejs proxy code in comment from another answer.)

Before we jump into nodejs proxy, we should check several things:

Certificate

Is your certificate valid for both with and without www?

If your certificate is only valid for without www (or the other way round), then no proxy (nginx or mine or any other) setting can help. Because the SSL/TLS handshake happen BEFORE redirect. The browser will complaint right away, before any redirect happen. End user see certificate error in browser.

Mine is valid for both and you can check out my blog https://johnsiu.com and https://www.johnsiu.com . The redirect happen without any certificate complain.

DNS

Is your DNS setup correctly for both with and without www? They should point to the same IP address.

I am wondering if this has anything to do with the ERR_SOCKET_NOT_CONNECTED error.

Nodejs Proxy

It is hosted in ghithub: https://github.com/J-Siu/ghost-https-nodejs-proxy

I just finish fine tuning my nodejs proxy, following is the latest version:

// HTTPS

const fs = require('fs');
const url = require('url');
const http = require('http');
const https = require('spdy'); // http2 support
const proxy = require('http-proxy').createProxyServer();
const compression = require('compression');
const ex = require('express')();
const fqdn = '<your domain name here>';

// Fill in your certificate files
const serverKey = '<KEY file>';
const serverCrt = '<CRT file>';
//const serverCa='<CA file>';

const httpsOptions = {
 key: fs.readFileSync(serverKey),
 cert: fs.readFileSync(serverCrt),
 // ca: fs.readFileSync(serverCa),
 ciphers: [
  "ECDHE-RSA-AES256-SHA384",
  "DHE-RSA-AES256-SHA384",
  "ECDHE-RSA-AES256-SHA256",
  "DHE-RSA-AES256-SHA256",
  "ECDHE-RSA-AES128-SHA256",
  "DHE-RSA-AES128-SHA256",
  "HIGH",
  "!aNULL",
  "!eNULL",
  "!EXPORT",
  "!DES",
  "!RC4",
  "!MD5",
  "!PSK",
  "!SRP",
  "!CAMELLIA"
 ].join(':'),
};

// Ghost Proxy configuration

proxy.on('proxyReq', function (proxyReq, req, res, options) {

 // Ngix: proxy_set_header Host $http_host;
 proxyReq.setHeader('Host', req.headers.host);

 // Ngix: proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 proxyReq.setHeader('X-Forwarded-For', req.connection.remoteAddress);

 // Ngix: proxy_set_header X-Forwarded-Proto $scheme;
 proxyReq.setHeader('X-Forwarded-Proto', 'https');

});

ex
 .use(compression())
 .use((req, res) => {
  if (req.header.host == fqdn) {
   proxy.web(req, res, { target: 'http://localhost:2368' });
  } else {
   res.writeHead(301, { 'location': 'https://' + fqdn + req.url });
   res.end();
  }
 })

// HTTPS Server

https.createServer(httpsOptions, ex).listen(443, '0.0.0.0');

// HTTP Redirect to HTTPS

http.createServer(function (req, res) {
 res.writeHead(301, { 'location': 'https://' + fqdn + req.url });
 res.end();
}).listen(80, '0.0.0.0');

It is able to:

1. redirect any http traffic to https (I am not checking url here)
2. redirect any https traffic to the correct fqdn (any request not matching my fqdn is redirected)
3. ab test show ~16request/sec

I create this for my single box single site setup and specifically to avoid any apache/nginx package while supporting HTTPS/HTTP2. This may not suite your need completely as you are doing multiple sites.

Answer 5

This is my Nginx configuration file, where I am serving a blog with Ghost. The certificate is generated with Let's Encrypt, and works correctly for both domains. The disadvantage is given when performing the 301 redirection, since it does not work correctly because the domain with www tells me that the certificate is not valid, however if I try to make the redirection to the reverse, from not www to www, it shows me the Same message, but for the domain without www:

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

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

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

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

    ssl on;
    ssl_certificate /etc/letsencrypt/live/domain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/domain.com/privkey.pem;

    include snippets/ssl-params.conf;

    location / {
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header Host $http_host;
            proxy_set_header X-NginX-Proxy true;
            proxy_pass http://localhost:9002/;
            proxy_redirect off;
    }
}

Currently, I am using a droplet of Digital Ocean, where I have configured 3 fields A, a field A with the value * that is directed to the IP of the virtual machine, a field @ that also addresses the IP of the server, and Finally a field A with value www that goes to the IP of my server.