Настройка виртуального хоста NGiNX для работы по HTTPs с SSL-сертификатом Let's Encrypt

После того, как SSL-сертификаты от Let's Encrypt получены их можно смело прикручивать к NGiNX для того, чтобы сайт наконец-то начал работать по защищённому протоколу HTTPs. Для этого потребуется внести правки в конфиги виртуальных хостов, к которым получены SSL-сертификаты, поменять порт, который будет использоваться для приёма и передачи данных от клиента и сразу настроить редирект с HTTP на HTTPs (чтобы весь трафик впредь шёл в зашифрованном виде).

Конфиг виртуального хоста NGiNX для работы по защищённому протоколу HTTPs с SSL-сертификатом Let's Encrypt

Итак, у нас есть конфиг виртуального хоста NGiNX для настройки работы домена в связке Apache + NGiNX. Всё работает как надо, но нам этого мало, нам надо, чтобы весь трафик шифровался. И не славы ради, а SEO для. Всё для лучшего ранжирования и занятия призовых мест в выдаче поисковых машин, которые последнее время писают кипятком от сайтов, работающих по протоколу HTTPs. А нужно ли это вообще или нет, — никого не интересует. Мощности современных телефонов давно уже позволяют выводить космические корабли не только на околоземную орбиту, но и шифровать/дешифровать данные, которые им прилетают из окружающего эфира.

Сразу приведу рабочий конфиг виртуального хоста, отвечающего за замен mb4.ru. Для других доменов, работающих по описанным ранее схемах, нужно просто поменять доменное имя.

server {
  listen 443 ssl;
  server_name mb4.ru;
  
  ssl_certificate /etc/letsencrypt/live/mb4.ru/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/mb4.ru/privkey.pem;
  ssl_trusted_certificate /etc/letsencrypt/live/mb4.ru/chain.pem;
  
  ssl_stapling on;
  ssl_stapling_verify on;
  resolver 127.0.0.1 8.8.8.8;
  
  add_header Strict-Transport-Security "max-age=31536000";
  
  add_header Content-Security-Policy "img-src https: data:; upgrade-insecure-requests";

  root /var/www/mb4/data/www/mb4.ru;
  charset utf-8;

  access_log /var/www/mb4/data/www/logs/mb4.ru.access-nginx.log main;
  error_log  /var/www/mb4/data/www/logs/mb4.ru-nginx.error.log error;

  index index.html index.htm index.php;
  
  include /etc/nginx/letsencrypt;

  include /etc/nginx/templates/apache24.conf;
  include /etc/nginx/templates/phpmyadmin.conf;
}

server {
  listen 443 ssl; 
  server_name www.mb4.ru;
  
  ssl_certificate /etc/letsencrypt/live/mb4.ru/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/mb4.ru/privkey.pem;
  ssl_trusted_certificate /etc/letsencrypt/live/mb4.ru/chain.pem;
  
  ssl_stapling on;
  ssl_stapling_verify on;
  resolver 127.0.0.1 8.8.8.8;
  
  add_header Strict-Transport-Security "max-age=31536000";
  
  add_header Content-Security-Policy "img-src https: data:; upgrade-insecure-requests";
  
  return 301 https://mb4.ru$request_uri;
  
  include /etc/nginx/letsencrypt;
}

server {
  listen 80;
  server_name mb4.ru;

  return 301 https://mb4.ru$request_uri;
}

server {
  listen 80; 
 
  server_name www.mb4.ru;
  return 301 http://mb4.ru$request_uri;
}

Разъяснения конфига виртуального хоста NGiNX для работы по защищённому протоколу HTTPs с SSL-сертификатом Let's Encrypt

Итак, рассмотрим, что есть что в этом новом конфиге. Поменялось мало что, но кое-что новое добавилось.

• listen 443 ssl; вместо listen 80; — это понятно, что теперь нужно слушать 443-й порт и ждать шифрованных данных, защишённых ключами SSL-сертификатов Let's Encrypt вместо простой и понятной передачи текстовых данных на 80-м порту.
• Блок с указанием сертификатов и ключей:
  • ssl_certificate /etc/letsencrypt/live/mb4.ru/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/mb4.ru/privkey.pem;
ssl_trusted_certificate /etc/letsencrypt/live/mb4.ru/chain.pem;
    • указывает на то, где на сервере хранятся файлы с сертификатами и ключами для того, чтобы можно было шифровать/дешифровать  передаваемые/получаемые данные.
• Блок технической части по использованию SSL-сертификатов
  • ssl_stapling on;
ssl_stapling_verify on;
resolver 127.0.0.1 8.8.8.8;
• Перманентный переезд на HTTPs протокол для тех, кто захочет это выяснить (в первую очередь конечно поисковики):
  • add_header Strict-Transport-Security "max-age=31536000";
• Отдавать все файлы с изображениями только по HTTPs протоколу:
  • add_header Content-Security-Policy "img-src https: data:; upgrade-insecure-requests";
• Ну и для всех поддоменов (у меня с www), отдавать главное зеркало сайта по HTTPs протоколу (301-й редирект):
  • return 301 https://mb4.ru$request_uri;
• Финальные блоки listen 80 и return 301 нужны для правильного склеивания зеркал http и https поисковыми машинами. Если не сделать 301-й редирект с 80-го порта, по правилам склейки зеркал в Яндексе, склейка не произойдёт и сайты на 80-м порту и 443-м порту будут восприниматься как отдельные независимые сайты, что плохо скажется на ранжировании в поисковой выдаче.
  • И ещё следует учесть то, что с 80-го порта может начать отдаваться контекст папки по умолчанию, настроенной в основных настройках NGiNX, т.е. папки /var/www/html, а в ней, как правило, лежит единственный HTML-файл с приветствием NGiNX. По всем остальным запросам будет отдаваться 404-я ошибка (страница не найдена). И сайт может потерять все страницы, которые были проиндексированы поисковыми роботами.

После внесённых правок перезагружаем NGiNX service nginx reload и наслаждаемся работой виртуального хоста, отвечающего за данное доменное имя по HTTPs протоколу и видом зелёного замочка в браузере. =D

Резюме

Также нужно поправить директиву Host: в robots.txt и настроить новое основное зеркало в Яндекс.Вебмастер. (Хотя оно само рано или поздно подхватится, но так будет быстрее.)

Осталось только настроить автоматическое продление SSL-сертификатов Let's Encrypt и на этом тему перехода на HTTPs протокол можно будет считать полностью раскрытой. =)

Заберите ссылку на статью к себе, чтобы потом легко её найти!
Раз уж досюда дочитали, то может может есть желание рассказать об этом месте своим друзьям, знакомым и просто мимо проходящим?
Не надо себя сдерживать! ;)