SSL-перенаправление и аутентификация в блоге Ghost с помощью Nginx

Я исследовал большую часть выходных, чтобы решить эту проблему, и мне удалось найти решение. Ни в Let’s Encrypt, ни в Nginx нет ошибок, все ссылаются на плохую конфигурацию с моей стороны; Однако я не могу перестать думать, что это странная вещь, и что мое решение можно улучшить, даже не говоря больше, это мой файл конфигурации Nginx:

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;
    }
}

Чтобы избежать ошибок перетаскивания, полностью удалите мою виртуальную машину и создайте ее с нуля, также установите последнюю версию Nginx для Debian, то есть 1.10.3, которая позволяет мне использовать http2, что также является улучшением.

Одним из решений является запрос и установка второго SSL-сертификата для поддомена www.

Шаги:

1. Откройте файл конфигурации HTTP nginx: sudo nano /etc/nginx/sites-available/example.com.conf. Дублируйте существующий блок сервера. Оставьте первый блок без изменений, чтобы он продолжал работать для примера.com. Во втором блоке укажите www в строке server_name: server_name www.example.com;. Сохраните и закройте файл.

2. Откройте файл конфигурации nginx SSL: sudo nano /etc/nginx/sites-available/example.com-ssl.conf. Оставьте первый блок без изменений, чтобы он продолжал работать для примера.com. Во втором блоке включите www в строку server_name, что даст вам server_name www.example.com;. Затем удалите строки, начинающиеся с ssl_certificate и ssl_certificate_key, потому что они нам не нужны, потому что мы будем запрашивать новый SSL-сертификат для поддомена www. Сохраните и закройте файл.

3. Запросите SSL-сертификат Let's Encrypt для поддомена www: 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 [email protected]

4. Снова откройте файл конфигурации nginx SSL: sudo nano /etc/nginx/sites-available/example.com-ssl.conf. Вернитесь к серверному блоку www.example.com, который вы настроили на шаге 2, и повторно добавьте строки ssl_certificate: ssl_certificate /etc/letsencrypt/www.example.com/fullchain.cer; и ssl_certificate_key /etc/letsencrypt/www.example.com/www.example.com.key;. Сохраните и закройте файл.

5. Перезагрузите nginx с помощью sudo nginx -s reload, и ошибка должна исчезнуть.

В вашем первом блоке сервера нет определения сертификата. Поэтому вы можете дублировать операторы ssl_certificate и ssl_certificate_key в этом блоке server.

Если это единственные блоки SSL server и поскольку у вас есть общий файл сертификата для обоих доменов, вы можете переместить операторы ssl_certificate и ssl_certificate_key на уровень http и разрешить их наследование обоими блоками server.

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;
    ...
}

Дополнительные сведения см. в этом документе.

(OP действительно просил увидеть мой прокси-код nodejs в комментарии из другого ответа.)

Прежде чем мы перейдем к прокси-серверу nodejs, мы должны проверить несколько вещей:

Сертификат

Ваш сертификат действителен как с www, так и без него?

Если ваш сертификат действителен только для без www (или наоборот), то никакая настройка прокси (nginx или мой или любой другой) не поможет. Поскольку рукопожатие SSL/TLS происходит ДО перенаправления. Браузер будет жаловаться сразу, до того, как произойдет какое-либо перенаправление. Конечный пользователь видит ошибку сертификата в браузере.

Мой действителен для обоих, и вы можете проверить мой блог https://johnsiu.com и https://www.johnsiu.com . Перенаправление происходит без каких-либо жалоб на сертификат.

DNS

Правильно ли настроен ваш DNS как с www, так и без него? Они должны указывать на один и тот же IP-адрес.

Мне интересно, связано ли это с ошибкой ERR_SOCKET_NOT_CONNECTED.

Nodejs прокси

Он размещен на ghithub: https://github.com/J-Siu/ghost-https-nodejs-proxy

Я только что закончил тонкую настройку моего прокси-сервера nodejs, вот последняя версия:

// 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');

Он может:

1. перенаправить любой http-трафик на https (здесь я не проверяю URL-адрес)
2. перенаправить любой трафик https на правильное полное доменное имя (любой запрос, не соответствующий моему полному доменному имени, перенаправляется)
3. ab тест показывает ~16запросов/сек

Я создаю это для своей единой настройки одного сайта и специально для того, чтобы избежать использования пакетов apache/nginx при поддержке HTTPS/HTTP2. Это может не полностью удовлетворить ваши потребности, поскольку вы делаете несколько сайтов.

Это мой файл конфигурации Nginx, в котором я веду блог с помощью Ghost. Сертификат генерируется с помощью Let's Encrypt и корректно работает для обоих доменов. Недостаток дается при выполнении перенаправления 301, так как оно работает некорректно, потому что домен с www говорит мне, что сертификат недействителен, однако, если я пытаюсь сделать перенаправление в обратном направлении, с не www на www, он показывает мне такое же сообщение, но для домена без 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;
    }
}

В настоящее время я использую дроплет Digital Ocean, где я настроил 3 поля A, поле A со значением *, которое указывает на IP-адрес виртуальной машины, поле @, которое также указывает на IP-адрес сервера, и Наконец, поле A со значением www, которое соответствует IP-адресу моего сервера.