Как найти настройки ssl

В статье мы рассмотрим, как установить SSL-сертификат на веб-сервер Nginx.

Перед установкой SSL убедитесь, что вы его заказали. Затем перейдите в Личный кабинет, кликните по строке нужного SSL-сертификата и убедитесь, что у услуги статус «Активна»:

Если услуга неактивна, используйте инструкцию в зависимости от типа сертификата: Как активировать сертификаты: AlphaSSL и DomainSSL или Как активировать сертификаты: OrganizationSSL и ExtendedSSL.

Как установить SSL-сертификат на Nginx

После активации сертификата вам будут доступны необходимые данные для его установки, подробнее в статье Где взять данные для установки SSL-сертификата.

Также вы можете использовать для установки сертификат, купленный в сторонней компании.

Рассмотрим, как выполняется установка и настройка Nginx SSL:

Готово, вы установили SSL-сертификат на Nginx.

• Установка SSL на Nginx
• Настройка Nginx SSL

В статье мы расскажем, как установить SSL-сертификат на веб-сервер Nginx и опишем дополнительные настройки Nginx HTTPS.

Если вы заказывали SSL-сертификат на 2domains.ru, перед установкой проверьте статус сертификата в личном кабинете:

1. В списке услуг нажмите на сертификат.

2. Найдите статус рядом с названием сертификата: 

Если статус услуги “Активная”, переходите к установке. Если услуга неактивна, активируйте сертификат.

Установка SSL на Nginx

Инструкция по установке SSL на Nginx подойдёт не только для сертификатов, купленных в 2DOMAINS, но и для сертификатов других провайдеров. 

Чтобы установить и настроить SSL на Nginx: 

1. В директории /etc/ssl/ создайте файл с названием domain.crt (вместо domain введите доменное имя) и откройте его в текстовом редакторе. Вставьте в файл содержимое сертификатов в следующем порядке: сертификат, промежуточный сертификат и корневой сертификат. Структура файла должна выглядеть так: 

——BEGIN CERTIFICATE——
#Файл сертификата#
——END CERTIFICATE——
——BEGIN CERTIFICATE——
#Промежуточный сертификат#
——END CERTIFICATE——
——BEGIN CERTIFICATE——
#Корневой сертификат#
——END CERTIFICATE——

В файле не должно быть пустых строк. 

Обратите внимание: если директория /etc/ssl/ отсутствует, создайте её при помощи команды:

sudo mkdir /etc/ssl/

2. В директории /etc/ssl/ создайте файл domain.key (domain — ваш домен). Откройте его в текстовом редакторе и вставьте в него приватный ключ. В файле приватного ключа не должно быть пустых строк.

3. Откройте файл конфигурации Nginx nginx.conf и измените виртуальный хост вашего сайта. Для этого добавьте в файл строки: 

server {
    listen 443 ssl;
    server_name domain;
    ssl_certificate /etc/ssl/domain.crt;
    ssl_certificate_key /etc/ssl/domain.key;
}

Вместо domain укажите доменное имя вашего сайта и сохраните изменения в файле.

4. Примените изменения в конфигурационном файле: 

sudo nginx -s reload

Или: 

systemctl reload nginx

Готово, сертификат установлен.

Настройка Nginx SSL

Рассмотрим дополнительные настройки защищенного соединения: 

• Чтобы сайт работал не только по защищённому протоколу HTTPS, но и по обычному HTTP, откройте конфигурационный файл и под строку “listen 443 ssl” добавьте ещё одну строку:

listen 80;

• С SSL-сертификатом сервер тратит больше ресурсов, чем без него. Вы можете оптимизировать работу веб-сервера Nginx при помощи кеша SSL-сессий. Для этого добавьте в конфигурационный файл строки: 

ssl_session_cache   shared:SSL:10m; # 10 МБ кеша, разделяемого между рабочими процессами
ssl_session_timeout 10m; # таймаут кеша, в течение которого параметры сессии используются повторно
keepalive_timeout 70; # время работы одного соединения

• Укажите протоколы TLS, с которыми будет работать сервер:

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

• Повысьте приоритет серверных шифров над клиентскими:

ssl_prefer_server_ciphers on;

• Чтобы сократить время загрузки страниц, разрешите серверу прикреплять OCSP-ответы для проверки сертификата. Для этого создайте файл /etc/ssl/ca.crt и добавьте в него содержимое корневого сертификата. После этого откройте конфигурационный файл и добавьте строки:

ssl_stapling on; #разрешает отправку OCSP-ответы
ssl_trusted_certificate /etc/ssl/ca.crt; # путь до корневого сертификата
resolver 8.8.8.8; # DNS-сервер

После изменений, которые вы внесли, сохраните файл конфигурации. Затем примените новую конфигурации при помощи команд:

sudo nginx -s reload

Или: 

systemctl reload nginx

Готово, вы установили SSL-сертификат и настроили Nginx для работы с ним.

Основная установка и настройка будет проходить под Debian 8 Jessie, вебсервер NGINX, в бекенде Apache или PHP-FPM.
Инструментарий: Far Manager и Putty.
Команды вводятся в консоль SSH.
Если вы авторизованы не под root, добавляйте перед консольными командами sudo

SSL (англ. secure sockets layer — уровень защищённых cокетов) — криптографический протокол, который обеспечивает безопасную связь между сервером и клиентом. Этим протоколом шифруется интернет-трафик, который невозможно прослушать. В 2014 году был скомпрометирован (была обнаружена уязвимость), из-за чего на основании протокола SSL 3.0 был создан стандарт TLS, учитывающий ошибки предшественника, а SSL фактически прекратил своё развитие.

TLS (англ. Transport Layer Security — безопасность транспортного уровня) — криптографический протокол, обеспечивающий защищённую передачу данных от сервера к клиенту. TLS является потомком SSL 3.0. В основе работы лежат симметричное шифрование для конфиденциальности, асимметричная криптография для аутентификации и коды аутентичности сообщений для сохранения их целостности.

Данный протокол широко используется в приложениях, работающих с сетью Интернет, таких как веб-браузеры, работа с электронной почтой, обмен мгновенными сообщениями и IP-телефония (VoIP).

Сегодня, когда говорят об SSL, то, как правило, подразумевают его потомка TLS. Поэтому, когда говорят, что нужно установить SSL сертификат на сайт, то, как правило, подразумевают установку TLS сертификата.

Почему нужно использовать SSL/TLS

Есть как минимум одна веская причина: вы не сможете воспользоваться преимуществами нового протокола HTTP2 (HTTP/2 приходит на смену текущему стандарту HTTP/1.1), если для вашего сайта не установлен и настроен сертификат безопасности SSL/TLS.

Также безопасность данных в интернете является всё более востребованной и актуальной темой. И чем дальше, тем больше: Google заявил, что наличие SSL-шифрования на сайте является положительным фактором в ранжировании сайта в поисковой выдаче. Также, наличие HTTPS является обязательным атрибутом для каждого e-commerce сайта: интернет-магазинов, сервисов по приёму платежей, обменников, а также платных сервисов, данные пользователей которых являются желанной добычей хакеров. Чтобы предотвратить фишинг-атаку на пользователя и не дать обмануть его, и нужно настроить SSL-сертификат безопасности и шифрования данных, чтобы он видел подтверждение того, что находится на правильном сайте.

Бесплатные сертификаты SSL/TLS от Let’s Encrypt

Рекомендую воспользоваться сертификатами SSL/TLS от Let’s Encrypt, так как:

1. Они бесплатные;
2. Подойдут большинству проектов;
3. Установка и настройка относительно несложные, и не займут много сил и времени.

Из минусов — сертификат актуален 90 дней, поэтому настроим его обновление на автомате.

Если у Вас виртуальный хостинг, можете написать в службу поддержки, вам помогут получить сертификат и всё настроят. Если же у вас свой сервер, описание получения сертификата SSL, TLS и его настройки на сервере будет дальше.

Установка Certbot

Сам гайд по установке Let’s Encrypt советует делать всё через Certbot. Сработает, если есть доступ по SSH.

Certbot — это утилита от Let’s Encrypt, помогающая в настройке SSL/TLS сертификата на сервер и его дальнейшем обновлении.

Установка Certbot в Debian 8 Jessie

Сначала убедимся, что certbot ещё не установлен:
certbot --help
Если увидите ошибку, значит, надо его установить.

Выбираем установку https://certbot.eff.org/#debianjessie-nginx

apt-get install certbot -t jessie-backports

Если вылезла ошибка The value 'jessie-backports' is invalid for APT::Default-Release as such a release is not available in the sources
, нужно настроить поддержку Backports

Как настроить поддержку Backports

Пишете в консоль (добавляет дополнительный источник для пакетов):

echo "deb http://ftp.debian.org/debian jessie-backports main contrib non-free" >> /etc/apt/sources.list

Потом обновляете список пакетов:

apt-get update

и снова пробуете установить Certbot:

apt-get install certbot -t jessie-backports

Затем проверяете, как вышло

certbot --help

Установка Certbot в CentOS 7

Установка происходит так:

1. yum -y install yum-utils

2. yum-config-manager --enable rhui-REGION-rhel-server-extras rhui-REGION-rhel-server-optional

3. yum install certbot

Если у Вас CentOS 6, воспользуйтесь универсальной инструкцией ниже.

Универсальная инструкция по установке Certbot

1. Скачиваем Certbot:

   wget https://dl.eff.org/certbot-auto

2. Даём права на исполнение с помощью chmod

   chmod a+x certbot-auto

3. Перемещаем certbot-auto к остальным бинарным файлам, чтобы появилась возможность начинать команды с certbot

   mv certbot-auto /usr/local/bin/certbot

4. Проверяем, что получилось:

   certbot --help

   Должы увидеть что-то подобное:
   

Настройка Certbot

Теперь, когда certbot установлен (а вы можете убедиться в этом, задав команду
certbot --help), советую заглянуть в cron-задачи

cd /etc/cron.d

В директории должен появиться файл certbot с примерно следующим содержанием

Самая последняя строчка — это правило cron, которое будет проверять сертификаты SSL, TLS дважды в день и обновлять устаревшие. К сожалению, он не перезагружает вебсервер, поэтому Вам нужно добавить правило && /etc/init.d/nginx reload вручную в конец строки.

В итоге, строка будет выглядеть примерно так:

0 */12 * * * root test -x /usr/bin/certbot && perl -e 'sleep int(rand(3600))' && certbot -q renew && /etc/init.d/nginx reload

Добавили, сохраняем.

Если строка в cron.d отстутствует, можно установить правило обновления сертификатов вручную:

1. Открываем расписание планировщика (сначала приведу пример для nano, затем для vim):

   crontab -e

2. Добавляем новое правило в конце планировщика:

   0 */12 * * * test -x /usr/bin/certbot && perl -e 'sleep int(rand(3600))' && certbot -q renew && /etc/init.d/nginx reload

3. Затем сохраняем (Ctrl+X , сохранить кнопкой Y)

Для vim то же самое, только при открытии планировщика нужно запустить режим редактора кнопкой Insert, внести правило для планировщика (см. выше), затем выйти из режима редактора кнопкой Esc, затем нажать комбинацию Shift + :(двоеточие), ввести буквы wq и нажать Enter, и новые правила для планировщика cron вступят в силу.

Далее, подготовка, тестирование и установка сертификата для сайта.

Подготовка и тестирование конфигурации SSL, TLS

Перед тем, как получить сертификат SSL/TLS, хорошей практикой будет протестировать правильность настройки сервера. Дело в том, что если есть проблема, которая не даст получить или обновить сертификат: центр сертификации имеет жёсткие лимиты обращений к нему (10 в час). И если есть ошибка, которую никак не удаётся выявить, то можно очень быстро упереться в лимит. Чтобы избежать этой проблемы, можно воспользоваться Staging Environment от Let’s Encrypt.
Staging Environment — это тестовая среда, полностью имитирующая общение с центром сертификации, и выдающая недоверенные сертификаты-пустышки. Однако, она имеет повышенные лимиты обращения к ней и служит исключительно для тестирования и настройки конфигурации сервера:

• Выдача и обновление сертификата на 1 домен имеет лимит 30 000 в неделю.
• Ошибка валидации имеет лимит 60 раз в час.

Чтобы воспользоваться тестовой окружающей средой, достаточно для certbot использовать ключ --staging.
Например, так можно протестировать выдачу сертификата:

certbot certonly --webroot -w /var/www/example.com -d example.com -d www.example.com --email [email protected] --agree-tos --staging

Кстати, посмотреть, как происходит обновление сертификатов, но без реального обновления, просто проверить правильность конфигурации, можно командой:

certbot renew --dry-run

А обновить все сертификаты на сервере вручную можно командой

certbot renew

После перезагрузите NGINX

nginx -s reload

Установка сертификата SSL, TLS от Let’s Encrypt

Вводим команду в консоль Putty:

certbot certonly --webroot -w /var/www/example.com -d example.com -d www.example.com --email [email protected] --agree-tos

• -w /var/www/example.com — путь до директории с файлами сайта
• -d example.com -d www.example.com — прописываем имена доменов
• --email [email protected] — ваш email, куда можно будет восстановить доступ
• --agree-tos — согласие с лицензионными требованиями

Если домен в кириллице, надо получить его Punnycode (например, яндекс.рф имеет код xn--d1acpjx3f.xn--p1ai) и пользоваться этим кодом. Сделать это можно с помощью Punycode-конвертера.

Если всё нормально, вам выдаст сообщение об успешном завершении создания сертификата

Итак, сертификат установлен в директорию /etc/letsencrypt/live/{тут_ваш_домен}/

Идём настраивать NGINX.

Настройка SSL, TLS в NGINX

Открываем конфигурационный файл вашего сайта.
Если NGINX настроен как тут, то конфигурационный файл может быть расположен тут:
/etc/nginx/vhosts/example.com.conf

Для уменьшения загрузки процессора официальная документация рекомендует

• установить число рабочих процессов равным числу процессоров,
• разрешить keep-alive соединения,
• включить разделяемый кэш сессий,
• выключить встроенный кэш сессий
• и, возможно, увеличить время жизни сессии (по умолчанию 5 минут):

Изменения я буду комментировать

# Создаём отдельный server для перенаправления с http на https
server {
 server_name example.com www.example.com;  # Можно указать любые домены и поддомены, смотря как вы настроили сертификат
 listen 1.2.3.4:80; #где 1.2.3.4 - айпи вашего сервера
 rewrite ^(.*) https://$host$1 permanent; # Редирект HTTP/1.1 301 Moved Permanently с http на https
}

# А это основной сервер с https
server {
  server_name example.com www.example.com;  # Копируем из верхнего сервера
  listen 1.2.3.4:443 ssl http2; #вместо 1.2.3.4 вставляете IP своего сервера. http2 включчает поддержку протокола http/2

  ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; # Сертификат
  ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem; # Ключ

  # Рекомендации по кешированию запросов
  keepalive_timeout   70; # 70 секунд держим соединение открытым
  keepalive_requests 150; # 150 запросов максимум на 1 соединение, после закрываем
  ssl_session_cache   shared:SSL:10m; # Разделяемый между всеми процесами кеш сессий на 10 байт с названием SSL. 1 Мб вмещает около 4000 сессий
  ssl_session_timeout 10m; # 10 минут - максимальное время жизни сессии

  # А строки ниже - для усиления безопасности соединения
  ssl_prefer_server_ciphers on; # Указывает, чтобы при использовании протоколов SSLv3 и TLS серверные шифры были более приоритетны, чем клиентские
  ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA; # Типы шифров
  ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # Разрешённые типы протоколов

... # Тут остальные правила NGINX

Сохранили, проверили, перезагрузили

nginx -t && service nginx reload

Настройка SSL, TLS на WordPress

Для примера, возьмём сайт на WordPress и настроим на нём SSL/TLS, сделаем его доступным по HTTPS.
Нужно будет обязательно пройтись по списку и внести соответствующие изменения:

1. Переписать в базе данных все ссылки, заменив http://example.com на https://example.com
   Для этого, вы можете воспользоваться WP-Cli или специальной утилитой Seach Replace DB
2. Переписать в файлах темы все ссылки, заменив http:// на https:// или //
3. Отредактировать wp-config.php, а именно, перед define('WP_DEBUG', false); добавить:

   // example.com меняем на своё имя домена
   define('WP_HOME', 'https://example.com'); 
   define('WP_SITEURL', 'https://example.com');
   
   // Принудительная авторизация в админке по защищённому протоколу
   define('FORCE_SSL_ADMIN', true);
   
   // Чтобы предотвратить бесконечный редирект с http на https
   if (strpos($_SERVER['HTTP_X_FORWARDED_PROTO'], 'https') !== false)
          $_SERVER['HTTPS']='on';
   
   

   2 и 3 строки не обязательны, если выполнили первый пункт списка.

   Про последнее можно добавить, что если WordPress находится за проксирующим сервером с SSL, но хостится на сервере без SSL (то есть, как в нашем случае, SSL на NGINX, Apache без), запросы к страницам сайта будут создавать бесконечный цикл. Чтобы его предотвратить, и используется определение в заголовках HTTP_X_FORWARDED_PROTO, наличие https в котором и будет говорить о том, что в заголовки надо будет записать метку о том, что HTTPS включен, и она будет сигнализировать Вордпрессу о том, что мы работаем на https.
   Подробности можете посмотреть тут https://codex.wordpress.org/Administration_Over_SSL

Как перенести сайт с HTTP на HTTPS правильно

Я считаю, что можно не ждать склейки http и https, и сразу настроить редирект на https, они всё равно склеятся, но далее приведу рекомендации, которые дают специалисты по поисковому продвижению

Если вы переводите существующий проиндексированный сайт на SSL, то сначала рекомендуется, чтобы Yandex склеил http и https версии сайта. Для этого, вы должны сначала настроить сайт так, чтобы он был доступен и по http, и по https верно, а затем прописать в robots.txt нужный адрес в директиве Hosts.

Не забудьте добавить новую версию сайта на HTTPS в Яндекс Вебмастер и Google Webmasters.

Вот, скажем, пример файла robots.txt для сайта sheensay.ru

User-agent: Yandex
Disallow:
Host: https://sheensay.ru

User-agent: *
Disallow:

Sitemap: https://sheensay.ru/sitemap.xml

Далее, рекомендуется, чтобы все внутренние ссылки были относительными либо начинались строго с протокола https://. У всех внешних javascript скриптов, ссылок, вставленных картинок, аудио- и видеоплееров, и других внешних объектов протоколы http:// заменяются на абсолютные https:// или относительные //.
Приведу пример:

• НЕПРАВИЛЬНО: <img src="http://placehold.it/250x250">
• ПРАВИЛЬНО: <img src=»//placehold.it/250×250″>
• ПРАВИЛЬНО: <img src=»https://placehold.it/250×250″>

Далее, проверяем секцию head, ищем теги <rel rel canonical=""> и <rel rel alternate="">, и следим, чтобы адреса в них начинались с https://
Таким образом, вы добьётесь более быстрой склейки разных версий сайта в одну.

Далее, дождавшись, когда Яндекс всё склеит правильно, можно настроить 301 редирект с http на https

Как настроить 301 редирект с HTTP на HTTPS

Для NGINX мы настраивали редирект выше, поэтому если редирект настроили в нём, в Apache ничего не меняем. Но, для примера, покажу блок, ответственный за него

301 редирект с HTTP на HTTPS в NGINX

Тут нужно указать 2 блока server, для http (там мы настраиваем редирект) и для https

server {
 server_name example.com www.example.com;  # Можно указать любые домены и поддомены, смотря как вы настроили сертификат
 listen 1.2.3.4:80; #где 1.2.3.4 - айпи вашего сервера
 rewrite ^(.*) https://$host$1 permanent; # Редирект HTTP/1.1 301 Moved Permanently с http на https
}

server {
 server_name example.com www.example.com;  # Можно указать любые домены и поддомены, смотря как вы настроили сертификат
 listen 1.2.3.4:443 ssl; #где 1.2.3.4 - айпи вашего сервера
 ### Остальные правила
}

301 редирект с HTTP на HTTPS в .htaccess (Apache)

Если у Вас основной сервер Apache, в его конфигурационном файле (apache.conf) или в .htaccess в корне сайта прописываем

RewriteEngine On
RewriteBase /
RewriteCond %{HTTP:SSL} !=1 [NC]
RewriteRule ^(.*) https://%{SERVER_NAME}/$1 [L,R=301]

Или

RewriteEngine On
RewriteCond %{SERVER_PORT} !^443$
RewriteRule .* https://%{SERVER_NAME}%{REQUEST_URI} [R=301,L]

Эта конструкция отлавливает все запросы к портам, отличным от 443 (а именно на 443 порту сидит SSL), и редиректит на нужную версию сайта с HTTPS.

Если у вас во фронтенде NGINX, то редирект в .htaccess может и не сработать. В таком случае, рекомендую воспользоваться редиректом в WordPress.

301 редирект с HTTP на HTTPS в WordPress

Чтобы сделать 301 редирект на https в wordpress, достаточно найти в корне сайта wp-config.php и прописать там в любом месте (если ещё не прописано, example.com меняете на свой домен):

define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com' );

В большинстве ситуаций этого достаточно.

Если доступа к wp-config.php нет, то есть ещё один вариант.
Код ниже используете в MU Plugin, также можно создать обычный плагин (требует активации) или вставить в functions.php рабочей темы:

<?php // Эту строку удалить, если код вставляется в существующий файл php

/**
  Plugin Name: Sheensay HTTP HTTPS Redirect
  Plugin URI: http://sheensay.ru/?p=2013
  Description: Плагин, который редиректит с HTTP на HTTPS
  Version: 1.0.0
  Author: Sheens
  Author URI: http://sheensay.ru/
  License: GPLv2
 */

defined( 'ABSPATH' ) or exit;

// Редирект с HTTP на HTTPS
add_action( 'template_redirect', function () {

	if ( 'on' != $_SERVER['HTTPS'] ) {

		$url = get_option( 'siteurl' ) . $_SERVER['REQUEST_URI'];

		wp_redirect( $url, 301 );

		exit;
	}
} );

Перед включением кода убедитесь, что сайту уже присвоен HTTPS: (Настройки — Общие)

Как проверить правильность работы SSL, TLS

В интернете можно найти множество сервисов, которые помогут определить, как правильно вы установили SSL и настроили сайт под него.
Один из таких сервисов: ssllabs.com

Рекомендую проверять правильность установки и настройки сертификата SSL/TLS с помощью ssllabs.com

Вы просто вводите адрес сайта и через несколько минут получаете результаты теста. Например, вот высший результат тестирования (A+) по домену https://sheensay.ru

Как усилить безопасность SSL, TLS

Бывает так, что сертификат установлен, а тестирование ssllabs показывает не лучший грейд безопасности.
Чтобы добиться заветного A+, нужно правильно настроить NGINX.
Для этого, сначала запускаем следующую команду, которая сгенерирует нужные ключи для Forward Secrecy (прямая секретность означает, что если третья сторона узнает какой-либо сеансовый ключ, то она сможет получить доступ только к тем к данным, что защищены этим ключом, не более):

openssl dhparam -out /etc/letsencrypt/dhparam.pem 2048

Затем, необходимо присутствие следующих записей в конфигурации сервера:

server {
  server_name sheensay.ru www.sheensay.ru;

  ssl_session_cache   shared:SSL:10m; # Разделяемый между всеми процесами кеш сессий на 10 байт с названием SSL. 1 Мб вмещает около 4000 сессий
  ssl_session_timeout 10m; # 10 минут - максимальное время жизни сессии

  add_header Strict-Transport-Security "max-age=31536000;"; # Заголовок, принудительно включающий защищённое соединение, минуя небезопасный HTTP

  # Заголовок Content Security Policy - отвечает за то, что считать безопасным подгружаемым контентом на странице
  add_header Content-Security-Policy-Report-Only "default-src https:; script-src https: 'unsafe-eval' 'unsafe-inline' *.yandex.ru; style-src https: 'unsafe-inline' fonts.googleapis.com; img-src https: data:; font-src https: data: fonts.googleapis.com; child-src https: www.youtube.com; report-uri /csp-report";

  ssl_stapling on;
  ssl_stapling_verify on;
  ssl_trusted_certificate /etc/letsencrypt/live/sheensay.ru/chain.pem; # домен меняете на свой
  resolver 8.8.4.4 8.8.8.8 valid=300s;
  resolver_timeout 10s;

  ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
  ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:DES-CBC3-SHA:!RC4:!aNULL:!eNULL:!MD5:!EXPORT:!EXP:!LOW:!SEED:!CAMELLIA:!IDEA:!PSK:!SRP:!SSLv:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';
  ssl_prefer_server_ciphers on;

  ### Чтобы у нас заработал Forward Secrecy, сгенерируем ключ командой ниже:
  ## openssl dhparam -out /etc/letsencrypt/dhparam.pem 2048
  ### После генерации расскомментируем строку ниже
  ssl_dhparam /etc/letsencrypt/dhparam.pem;
  
  ### Дальше другие настройки сервера
  ### ...

После всех манипуляций, не забудьте перезагрузить NGINX

service nginx reload

Видео установки и настройки SSL сертификата в хостинге Beget

Если Вы хотите установить SSL, TLS сертификат на сайт, который расположен в Beget, Вам пригодится следующая видеоинструкция:

Как установить SSL/TLS, если на сервере несколько сайтов

Обычно, проблемы возникают, когда на сервере уже есть 1 сайт на HTTPS, и на этот сервер нужно перенести другой сайт.
Либо, ещё более патовая ситуация: нужно перенести сайт на HTTP и сделать его доступным по HTTPS. Проблема будет возникать из-за того, что на сервере на порту 443 уже есть сайт с сертификатом SSL/TLS, и обращения будут идти на него, и certbot не сможет прописать сертификат сайту, а сайты по HTTP будут недоступны.
Для решения этой проблемы можно сгенерировать временный самоподписанный сертификат:

openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365 -nodes

Эта команда создаст 2 файла в директории, из которой вызывается команда (обычно это /root):

• cert.pem — это сертификат SSL/TLS;
• key.pem — это ключ к сертификату.

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

Ещё пример, когда такое решение пригодится — на CloudFlare, настроенном на Flexible SSL, плагин Broken Link Checker при сканировании выдаёт ошибки доступа к изображениям Connection Failed. И тут тоже помогут самоподписанные сертификаты на 443 порту сайта.

Ключи прописываете в конфигурации сервера (пример есть ниже). Далее:

• Если сайт нужен по HTTP, просто делаете редирект с HTTPS на HTTP, по аналогии с редиректом на HTTPS, только наоборот (пример далее);
• Если сайт нужен по HTTPS, делаете сайт доступным по HTTP, затем получаете сертификат с помощью certbot, а дальше всё как по инструкции выше — редирект на HTTPS, прописывание сертификатов, настройка URL, и так далее.

Пример, как сделать редирект с HTTPS на HTTP в NGINX

Допустим, самоподписанные сертификаты сгенерированы командой выше и располагаются в каталоге /root/. Тогда, чтобы настроить редирект с HTTPS на HTTP для нового сайта example.com, мы можем использовать следующую конфигурацию (example.com заменяем на свой домен, 1.2.3.4 — на свой IP сервера):

server {
 server_name example.com   www.example.com;
 listen 1.2.3.4:443 ssl; ### Вместо 1.2.3.4 нужно подставить IP сервера

 ssl_certificate /root/cert.pem; # Путь к самоподписанному сгенерированному сертификату
 ssl_certificate_key /root/key.pem; # Путь к ключу самоподписанного сертификата

 rewrite ^(.*) http://$host$1 permanent; 
}

server {
    server_name example.com   www.example.com;
    listen 1.2.3.4:80 ; ### Вместо 1.2.3.4 нужно подставить IP сервера

    ### Остальные правила ###
}

SSL certificate problem: certificate has expired

Что делать, если при запросах curl вылезает ошибка:

curl: (60) SSL certificate problem: certificate has expired
More details here: https://curl.haxx.se/docs/sslcerts.html

Самым правильным вариантом будет обновление сертификатов на сервере. В Linux Debian, Ubuntu это делается так:

update-ca-certificates --fresh

Эта команда обновляет символические ссылки сертификатов в /etc/ssl/certs.

Если это не помогло, то нужно будет обновить пакеты системы.

Сначала убедитесь, что пакеты безопасности в /etc/apt/sources.list выглядят примерно так:

deb http://security.debian.org/debian-security stretch/updates main contrib non-free
deb-src http://security.debian.org/debian-security stretch/updates main contrib non-free

Если всё в порядке, обновляем пакеты

apt update && apt upgrade -y

После обновления изменения можно проверить с помощью команды:

apt-cache policy ca-certificates

Репутация веб-ресурсов во многом зависит от уровня безопасности и уровня защиты персональных данных на сервере. В случае с сайтами речь идет о включении протокола HTTPS, а для этого требуется подключение сертификата SSL.

Сегодня рассмотрим настройку SSL на примере наиболее популярного веб-сервера Nginx. Большинство хостинг-провайдеров поддерживают именно его.

Настройка SSL в Nginx с Let’s Encrypt

Мы будем устанавливать бесплатный сертификат от некоммерческого удостоверяющего центра Let’s Encrypt. Готовый к эксплуатации веб-сервер необходимо подготовить к дальнейшей установке SSL: перед началом процедуры требуется зарегистрировать домен и привязать его к конкретному аккаунту на хостинге. Сертификат выдается на определенное имя сайта.

Шаг 1: Настройка виртуального хоста

Если на веб-сервере еще не настраивался виртуальный хост, это нужно сделать вручную, иначе не получится установить SSL на Nginx. Например, для сайта test.ru конфигурация будет выглядеть так, как показано в нижеследующем примере. Команда просмотра:

$ sudo vi /etc/nginx/conf.d/test.conf

Простейшее содержимое выглядит так:

server {

listen 80;

server_name test.ru www.test.ru;

access_log /var/log/nginx/test.access.log main;

root /var/www/test.ru/public_html/;

index index.html index.htm;

location / {

try_files $uri $uri/ =404;

}

}

После создания файла рекомендуется проверить конфигурацию веб-сервера командой:

$ nginx -t

Если никаких ошибок не выдается, следующий шаг – перезагрузка Nginx:

$ sudo systemctl restart nginx

Теперь нужно убедиться, что каталог /var/www/test.ru/public_html/ действительно существует. Если его нет, он создается вручную до последующих действий. В нем следует расположить какой-либо файл для проверки его доступности, например index.html с содержимым «Hi user». Поможет это сделать команда:

$ sudo mkdir -p /var/www/test.ru/public_html/

$ sudo vi /var/www/test.ru/public_html/index.html

Проверяется правильность действий через браузер или утилитой CURL:

$ curl test.ru

Шаг 2: Установка Certbot

Получать сертификаты SSL рекомендуется через клиента Certbot. Он автоматизирует часть работы по настройке протокола HTTPS. Инсталлировать его следует только из официального репозитория, чтобы исключить риски получения на сервер вредоносных программ. Команда для загрузки:

$ sudo apt install certbot certbot-python-nginx

Первый пакет содержит непосредственно саму утилиту, а второй подключает расширение, которое позволяет работать с веб-сервером Nginx. После установки программа сразу готова к применению, поэтому можно продолжать настройку.

Шаг 3: Получение сертификата

Приложение Certbot способно устанавливать сертификат автоматически. Но в нашей инструкции с помощью него будет только сгенерирован ключ, а установка в Nginx проведена вручную. Чтобы создать и подписать SSL нужно ввести команду:

$ sudo certbot certonly --nginx -d test.ru -d test.ru

После запуска в первый раз запрашивается email администратора. Туда будут отправляться письма об истечении срока действия сертификата (заодно и новости проекта). После ввода адреса следует согласиться с лицензионным соглашением и ответить на вопрос, допускается ли передача контакта партнерским организациям. После указания нужных реквизитов начнет создаваться SSL-сертификат.

Важно отметить, что сгенерированные файлы сертификата будут сохранены в каталоге /etc/letsencrypt/live/test.ru/. Там располагается следующий перечень модулей:

• cert.pem – непосредственно сам сертификат;
• chain.pem – файл цепочки;
• privkey.pem – приватный ключ, он прописывается в поле ssl_sertificate_key;
• fullchain.pem – совмещенное содержимое первых двух файлов.

Последнее вносится в поле ssl_sertificate. Остается инсталлировать ключ безопасности в систему веб-сервера и проверить подключение нового протокола.

Шаг 4: Настройка виртуального хоста для SSL

С этой целью создается конфигурационный файл виртуального хоста. Он активирует функционал прослушивания порта 443. Также в нем прописывается ряд директив для настройки SSL. Команда для создания:

$ sudo vi /etc/nginx/conf.d/test-ssl.conf

Примерное содержимое файла:

server {

listen 443 ssl;

server_name test.ru www.test.ru;

access_log /var/log/nginx/test.ru.access.log main;

root /var/www/test.ru/public_html/;

index index.html index.htm;

ssl on;

ssl_certificate /etc/letsencrypt/live/test.ru/fullchain.pem;

ssl_certificate_key /etc/letsencrypt/live/test.ru/privkey.pem;

location / {

try_files $uri $uri/ =404;

}

}

После сохранения изменений в только что созданном файле требуется перезагрузка веб-сервера командой:

$ sudo systemctl restart nginx

Все, сертификат подключен. Можно приступать к дальнейшим работам по созданию и публикации сайта. Он будет защищен по самым современным стандартам (шифрованием трафика).

Проверить подключение можно при помощи сайта SSLlabs. Нужно открыть браузер и ввести ссылку, в которой следует заменить имя домена на собственное: https://www.test.ru/ssltest/analyze.html?d=test.ru&latest.

Шаг 5: Дополнительная безопасность

По умолчанию в системе остаются включенными все доступные протоколы обмена информацией. Поэтому для увеличения уровня безопасности рекомендуется вручную отключить ряд из них, при этом принудительно активировать наиболее эффективный режим. Здесь понадобится директива ssl_protocols:

$ sudo vi /etc/nginx/conf.d/test-ssl.conf

ssl_protocols TLSv1.2 TLSv1.3;

В этом примере подключается поддержка протоколов семейства TSL версии 1.2 и 1.3. При высоких требованиях к безопасности рекомендуется активировать все существующие методы шифрования и вручную добавить шифры, которые хочется использовать.

На завершающем этапе остается сообщить серверу, что нужно использовать именно их, а не те, что предлагает клиент:

ssl_prefer_server_ciphers on;

Перед дальнейшим использованием стоит перезапустить веб-сервер и еще раз убедиться, что все внесенные изменения приняты и SSL-сертификат определяется без ошибок.

Обновление сертификата

Если планируется использовать сертификат SSL от Let’S Encrypt более 90 дней, его придется систематически обновлять. И делать это рекомендуется заранее, минимум за 30 дней до истечения срока действия. Иначе возникают риски временной неработоспособности протокола SSL, когда сайт перестает открываться по прежним ссылкам (браузеры предупреждают об ошибке).

Выполняется процедура обновления командой:

$ certbot renew

После ее ввода будут проверены все ранее выпущенные и установленные в системе сертификаты и заново созданы те, по которым сроки подходят к концу. Если хочется настроить автоматический перевыпуск SSL, нужно ввести команду cron:

$crontab -e

30 2 * * 1 /usr/bin/certbot renew >> /var/log/renew-ssl.log

В таком виде она каждый понедельник в 2:30 будет выполнять проверку актуальности всех SSL и записывать результат в файл с указанным названием.