Lets encrypt ssl сертификат инструкция nginx

Nginx — один из самых популярных веб-серверов, благодаря его высокой производительности при больших нагрузках. В наше время всё больше и больше сайтов поддерживают HTTPS и производители браузеров, такие как Google и Mozilla всеми силами пытаются мотивировать владельцев сайтов переходить на этот защищённый протокол.

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

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

Обратите внимание, что для получения сертификата необходимо чтобы к серверу был привязан домен, потому что сертификат будет выдан именно для этого домена и только так центр сертификации сможет убедится, что этот домен и сервер ваши. В этом примере я буду получать сертификат для домена vps.losst.pro и www.vps.losst.pro. Соответственно А запись обоих доменов должна указывать на сервер.

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

Если у вас ещё не настроен HTTP виртуальный хост для сайта, то это надо сделать потому что иначе установить SSL сертификат Nginx не получится. Например, для vps.losst.pro самая простая конфигурация будет выглядеть вот так:

sudo vi /etc/nginx/conf.d/vps-losst-ru.conf

server {
listen 80;
server_name vps.losst.pro www.vps.losst.pro;
access_log /var/log/nginx/vps-losst-ru.access.log main;
root /var/www/vps.losst.pro/public_html/;
index index.html index.htm;
location / {
try_files $uri $uri/ =404;
}
}

Затем проверьте конфигурацию Nginx:

nginx -t

И если всё верно, перезапустите веб-сервер:

sudo systemctl restart nginx

Директория /var/www/vps.losst.pro/public_html/ должна существовать, и в ней надо расположить индексный файл с каким нибудь содержимым:

sudo mkdir -p /var/www/vps.losst.pro/public_html/

sudo vi /var/www/vps.losst.pro/public_html/index.html

Its works!

Убедиться что всё работает можно с помощью браузера или утилиты curl:

curl vps.losst.pro

2. Установка Certbot

Для получения сертификатов LetsEncrypt официально рекомендовано использовать клиент Certbot. Установить программу можно из официальных репозиториев:

sudo apt install certbot certbot-python-nginx

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

3. Получение сертификата

Мы не будем устанавливать сертификат автоматически, а только сгенерируем его с помощью этой утилиты, а потом добавим вручную в Nginx. Для генерации и подписи сертификата используйте такую команду:

sudo certbot certonly --nginx -d vps.losst.pro -d www.vps.losst.pro

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

Далее сертификат SSL создастся и вы получите такое сообщение:

Здесь программа сообщает о том, что файлы сертификата SSL Nginx сохранены в каталоге /etc/letsencrypt/live/vps.losst.pro/. Теперь настройка SSL Nginx.

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

В папке /etc/letsencrypt/live/vps.losst.pro/ находятся такие файлы сертификатов:

• cert.pem — файл сертификата, использовать его мы не будем;
• chain.pem — файл цепочки сертификата, тоже не будем использовать;
• privkey.pem — приватный ключ сертификата, надо прописать в параметре ssl_certificate_key;
• fullchain.pem — в нём объединено содержимое cert.pem и chain.pem, надо прописать в параметре ssl_certificate.

Для SSL надо создать отдельный файл виртуального хоста, в котором порт прослушивания будет 443, и будут присутствовать несколько директив настройки SSL:

sudo vi /etc/nginx/conf.d/vps-losst-ru-ssl.conf

server {
listen 443 ssl;
server_name vps.losst.pro www.vps.losst.pro;
access_log /var/log/nginx/vps-losst-ru.access.log main;
root /var/www/vps.losst.pro/public_html/;
index index.html index.htm;
ssl on;
ssl_certificate /etc/letsencrypt/live/vps.losst.pro/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/vps.losst.pro/privkey.pem;
location / {
try_files $uri $uri/ =404;
}
}

После создания файла останется перезапустить Nginx:

sudo systemctl restart nginx

Уже на этом этапе всё должно работать.

5. Дополнительная безопасность

Чтобы сделать соединение SSL более безопасным надо отключить небезопасные протоколы и включить только надежные шифры. Для настройки протоколов используйте директиву ssl_protocols. На сегодняшний день самым безопасным считается TLS:

sudo vi /etc/nginx/conf.d/vps-losst-ru-ssl.conf

ssl_protocols TLSv1.2 TLSv1.3;

В примере я разрешаю только TLSv1.2 и TLSv1.3 для хорошей оценки от ssllabs, но в производственной системе возможно стоит разрешить всю линейку протоколов 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: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_prefer_server_ciphers on;

После завершения настроек не забудьте перезапустить Nginx.

6. Проверка

Проверить параметры работы SSL можно с помощью сайта SSLlabs. Просто откройте такую ссылку в браузере, заменив домен сайта на свой:

https://www.ssllabs.com/ssltest/analyze.html?d=vps.losst.pro&latest

Как видите, всё хорошо, и сайт получил оценку A. Сертификат SSL Nginx установлен и работает.

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

Минус сертификатов от Lets Encrypt в том, что они актуальны только 90 дней. За 30 дней до истечения этого срока их рекомендуется перевыпускать. Для этого существует специальная команда:

certbot renew

Она проверяет все сертификаты, установленные в системе и перевыпускает те, что скоро будут просрочены. Чтобы настроить автоматический перевыпуск сертификатов просто добавьте эту команду в crontab:

crontab -e

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

Эта команда будет выполнятся каждый понедельник в 2:30 и записывать свой вывод в файл /var/log/le-renew.log.

Выводы

В этой небольшой статье мы рассмотрели как выполняется настройка SSL Nginx с Lets Encrypt. Как видите, всё вполне выполнимо, несмотря на определённую сложность. А вы уже используете SSL? Планируете использовать? Напишите в комментариях!

Обнаружили ошибку в тексте? Сообщите мне об этом. Выделите текст с ошибкой и нажмите Ctrl+Enter.

Время на прочтение
13 мин

Количество просмотров 274K

Если вдруг вся эта история прошла мимо вас, Let’s Encrypt — центр сертификации от некоммерческой организации ISRG, существующий при поддержке EFF и многих компаний, взявшей на себя миссию дать людям бесплатные SSL/TLS сертификаты для сайтов и серверов. Сертификаты от Let’s Encrypt уже используются на более чем 10 миллионах доменов.

Кроме очевидной бесплатности у сертификатов от Let’s Encrypt есть особое, отсутствующее у любых других коммерческих сертификационных центров, достоинство: если вы однажды получили сертификат от Let’s Encrypt, то, при прочих равных, это навсегда. Не нужно раз в год-два вручную обновлять сертификаты. Не нужно вообще вспоминать что сертификаты где-то есть. Получил, настроил и забыл!

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

Организации автоматического обновления сертификатов в статье уделено пристальное внимание, с тем чтобы вы могли в полной мере оценить это принципиальное преимущество Let’s Encrypt.

Почему эта статья

На сайте EFF есть краткие инструкции по использованию Certbot, рекомендуемой программы для получения сертификатов, но они скорей рассчитаны на тех, кто заходит на свой сервер по SSH лишь по острой необходимости. Более подробная документация тоже есть, но пока всю ее прочитаешь и найдешь всё то, что действительно нужно знать… К тому же, в ней не рассмотрены некоторые важные стратегические вопросы использования сертификатов.

Очевидно, нужна короткая и понятная инструкция для тех, кто привычен к серверной консоли, но хочет во всём разобраться без излишних трат времени.

Содержание

Из этой статьи вы узнаете…

1. Как установить и настроить Certbot для регулярного использования.
2. Что требуется от nginx и как настроить nginx для получения сертификатов.
3. Как получать сертификаты и как проверить полученный сертификат.
4. Как установить сертификат от Let’s Encrypt в nginx.
5. Как автоматически обновлять сертификаты.

Caveat emptor

Всё знаете про SNI? Читайте сразу про установку.

В инструкциях ниже я исхожу из того что ваши сайты будут использовать SNI. Это расширение протокола TLS позволяет браузерам сообщить желаемое имя сайта до получения и проверки SSL сертификата от сервера. Благодаря SNI вы можете разместить сколько угодно сайтов за HTTPS на одном IP. Но не всё так просто — иначе бы зачем я об этом писал?

Есть ряд старых браузеров в принципе не поддерживающих SNI. В их число входят любые версии IE в уже заброшенном Windows XP, встроенный браузер в Android 2.3 и 2.2 из 2010 года, а также некоторые другие более экзотические браузеры и библиотеки типа Java версии 1.6 и Python до версии 2.7.9.

Если вы всё-таки хотите чтобы ваш сайт открывался в IE в Windows XP, то одним отказом от SNI эта проблема не решается. Нужно специальным образом подбирать шифры, уже отказываясь от forward secrecy и рискуя получить низкую оценку от SSL Labs. Как можно догадаться, этот вопрос заслуживает отдельного обсуждения хотя бы потому что пользователям IE под XP можно посочувствовать — у них уже не открывается половина интернета!

Еще год назад от перехода на SNI вас могла бы удержать ограниченная поддержка этой технологии некоторыми поисковыми ботами типа Bing, но сейчас, с появлением десятков сайтов с бесплатными сертификатами от Cloudflare, что без SNI не открываются, бот Bing (что легко проверить), и боты других основных поисковиков, пришли в согласие с реальностью. Сейчас за это можно не волноваться. Отмечу, что у Googlebot таких проблем не было никогда.

Другим поводом для волнений могут быть различные средства доступа к API вашего сайта. Если у вас давно есть API, то есть небольшой шанс что среди ваших клиентов есть какие-то, использующие устаревшие версии Java или Python. Если у вас таких нет, то не о чем переживать. Если же есть — мои соболезнования.

Почему лучше рассчитывать на SNI?

1. Это просто. Вам не нужно постоянно держать в голове факты о выданных сертификатах. Для какого домена сертификат был выдан первым. К какому сертификату нужно добавлять еще домены. И так далее… Ни о чем таком со SNI не нужно думать.

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

Например, так можно посмотреть домены в сертификате Тематических Медиа:

true | openssl s_client -showcerts -connect habrahabr.ru:443 2>&1 |
    openssl x509 -text | grep -o 'DNS:[^,]*' | cut -f2 -d:

На момент написания статьи эта команда выведет подробный список всевозможных доменов ТМ:

habrastorage.org
api.geektimes.ru
api.habrahabr.ru
geektimes.ru
habrahabr.ru
id.tmtm.ru
lab.geektimes.ru
m.geektimes.ru
m.habrahabr.ru
special.geektimes.ru
special.habrahabr.ru
www.geektimes.ru
www.habrahabr.ru

Никакой секретности и никаких тайн. Вы этого хотите?

Установка Certbot

Если вы читаете этот текст из будущего, когда Certbot уже есть в Debian stable и Ubuntu без обиняков и оговорок, то всё просто:

apt-get install certbot

Либо используйте aptitude или другой пакетный менеджер вашего дистрибутива.

Установка в Jessie

Если у вас еще в ходу актуальный на конец 2016 года Debian stable «jessie», то всё лишь немного сложнее.

1. Нужно подключить Debian Backports, добавив строчку в /etc/apt/sources.list:

   deb http://ftp.debian.org/debian/ jessie-backports main contrib non-free

2. Теперь можно устанавливать с указанием источника:

   apt-get update
   apt-get install certbot -t jessie-backports

   (Раздел актуален пока только stretch не стал stable.)

Ubuntu версий ниже 16.10 (yakkety)

sudo add-apt-repository ppa:certbot/certbot
sudo apt-get update
sudo apt-get install --upgrade letsencrypt

Дальше везде вместо certbot используйте letsencrypt.

Другой дистрибутив

Если у вас какой-то другой дистрибутив, то дополнительные инструкции по установке есть на официальном сайте Certbot. Если обходиться без пакетного менеджера, то обычно установка сводится к…

wget -O /usr/local/bin/certbot-auto https://dl.eff.org/certbot-auto
chmod +x /usr/local/bin/certbot-auto
ln -s /usr/local/bin/certbot-auto /usr/local/bin/certbot

Везде ниже вместо команды certbot можно использовать команду certbot-auto.

Certbot и webroot

Мы будем получать сертификаты по методу webroot без перенастройки или остановки веб-сервера, под которым подразумевается nginx. Нам нужен какой-то каталог, в который certbot будет писать свои файлы, и какой должен быть доступен из сети удостоверяющему серверу согласно протокола ACME.

Чтобы не писать каждый раз длинную строку из опций, а еще лучше — не вспоминать о них, запишем основные настройки в файл конфигурации, который certbot ожидает найти в /etc/letsencrypt/cli.ini:

authenticator = webroot
webroot-path = /var/www/html
post-hook = service nginx reload
text = True

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

Также нам нужно мягко перезагрузить nginx (без перерыва в обслуживании) при успешном обновлении сертификатов. Ничего не мешает в этот же момент перезапускать и другие сервисы вроде Postfix, использующие полученные сертификаты. Команды указываются через точку с запятой.

letsencrypt: error: Unexpected line 14 in /etc/letsencrypt/cli.ini: post-hook = service nginx reload; service postfix reload

Что будет делать Certbot

Ожидается что certbot будет создавать необходимые для проверки прав на домен файлы в подкаталогах ниже по иерархии к указанному. Вроде таких:

/var/www/html/.well-known/acme-challenge/example.html

Эти файлы должны будут быть доступны из сети на целевом домене по крайней мере по HTTP:

http://www.example.com/.well-known/acme-challenge/example.html

Для следующих проверок создадим какой-то такой файл:

mkdir -p /var/www/html/.well-known/acme-challenge
echo Success > /var/www/html/.well-known/acme-challenge/example.html

Регистрация в Let’s Encrypt

Регистрацию нужно сделать только один раз:

certbot register --email me@example.com

Здесь ничего сложного.

Подготовим nginx к получению сертификатов

В общем случае для получения сертификата необходимо во всех блоках server добавить следующий блок до других блоков location:

location /.well-known {
    root /var/www/html;
}

Понятно, что вписывать для каждого сайта такой блок явно — это моветон, потому создадим файл /etc/nginx/acme с содержанием блока выше.

# cat /etc/nginx/acme 
location /.well-known {
    root /var/www/html;
}

Затем для каждого домена и поддомена, для которых нужно получить сертификаты, в блоке server перед всеми блоками location укажем:

include acme;

Хосты-редиректоры (например, с голого домена на www) можно пропустить. ACME сервер обязан учитывать стандартную переадресацию. Подробней об этом ниже.

Перезагрузим nginx и проверим что наш тестовый файл виден:

# service nginx reload
# curl -L http://www.example.com/.well-known/acme-challenge/example.html
Success

После проверки лучше удалить тестовый файл — certbot любит удалять за собой всё лишнее, а такой файл будет мешать и вызывать сообщение об ошибке (Unable to clean up challenge directory).

rm /var/www/html/.well-known/acme-challenge/example.html

Теперь у нас всё готово чтобы получить наш первый сертификат.

О переадресации с кодами 301 и 302

Как было уже сказано, ACME сервер Boulder учитывает переадресацию с кодами 301 и 302. В этом смысле не имеет значения где, в конечном счете, находятся файлы, требуемые для прохождения проверок. Переадресация возможна даже на нестандартные порты, без ограничений по конечному протоколу HTTP или HTTPS. Сами Let’s Encrypt рекомендуют использовать переадресацию для создания единой точки проверки прав на домены.

Если вы можете получить эти файлы с помощью curl с ограничением в десять переадресаций, то и Boulder эти файлы увидит. Не должно быть никаких ограничений по IP адресам.

curl --location --max-redirs 10 http://example.com/.well-known/acme-challenge/example.html

Это удобно если у вас сложная структура переадресаций между разными версиями сайтов. Должно быть достаточно подключить тот блок с location только на основном сайте для получения сертификатов для всех остальных.

$ curl --head --silent --location --max-redirs 10 http://somewhere.example.net/... | grep ^HTTP
HTTP/1.1 301 Moved Permanently
HTTP/1.1 301 Moved Permanently
HTTP/1.1 200 OK

Проверка всегда начинается с запроса по протоколу HTTP на 80 порту.

Если у вас уже всё зашифровано…

Если у вас уже все сайты работают по HTTPS, то вся схема будет работать если у вас настроен переадресующий сервер на 80 порту, сохраняющий $request_uri в ответе.

Другое дело что можно сократить путь и подключить наш блок с location в умолчальном сервере для 80 порта, который делает переадресацию на HTTPS. Тогда не нужно будет ничего дописывать в конфиги отдельных сайтов.

Пример конфигурации такого переадресующего всё-подряд-на-HTTPS сервера:

server {
    listen server.example.com:80 default_server;

    include acme;

    location / {
        return 301 https://$host$request_uri;
    }
}

Такой конфиг стоит определить в /etc/nginx/conf.d/default.conf, в стороне от конфигов конкретных сайтов.

Сервер запускаем явно на внешнем IP чтобы не перенастраивать Apache на другой порт. Если для вас это не проблема, то указание имени сервера в директиве listen можно пропустить.

Если нужно получить сертификат для домена без сайта…

Типичный пример — сертификат для выделенных под SMTP или IMAP серверов, на которых вообще нет каких-то сайтов. Либо используйте универсальный переадресатор что выше, либо…

server {
    server_name smtp.example.com imap.example.com;
    listen server.example.com:80;

    include acme;

    location / {
        return 404;
    }
}

К сожалению, протокол ACME требует чтобы такой сервер был доступен во время каждой проверки. Это практически эквивалентно постоянной доступности, ввиду требования получения и обновления сертификатов без перезагрузки сервера. Не удаляйте такой конфиг после получения сертификата.

Если у вас только Apache2…

Если у вас Apache2, а перейти на всеми любимый nginx возможности нет, то… Добавьте следующие строчки в /etc/apache2/conf-available/certbot.conf:

Alias /.well-known/ /var/www/html/.well-known/
<Directory /var/www/html/.well-known/>
    Satisfy any
</Directory>

Затем

a2enconf certbot
mkdir -p /var/www/html/.well-known
service apache2 reload

И обязательно проверьте, так:

mkdir -p /var/www/html/.well-known/acme-challenge
echo Success > /var/www/html/.well-known/acme-challenge/example.html
curl -L http://localhost/.well-known/acme-challenge/example.html && 
rm /var/www/html/.well-known/acme-challenge/example.html

Существует много причин почему такая схема может у вас в Apache2 не заработать. Пары экранов текста не хватит чтобы описать их все. Не серчайте — статья про nginx.

Получаем сертификаты

У Let’s Encrypt есть лимиты на количество обращений за сертификатами, потому сначала попробуем получить необходимый сертификат в режиме для тестов:

certbot certonly --dry-run -d example.com -d www.example.com

В конце программа должна отчитаться об успешной работе:

The dry run was successful.

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

# certbot certonly -d example.com -d www.example.com
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for example.com
http-01 challenge for www.example.com
Using the webroot path /var/www/html for all unmatched domains.
Waiting for verification...
Cleaning up challenges
Generating key (2048 bits): /etc/letsencrypt/keys/0001_key-certbot.pem
Creating CSR: /etc/letsencrypt/csr/0001_csr-certbot.pem

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at
   /etc/letsencrypt/live/example.com/fullchain.pem. Your cert will
   expire on 2017-04-01. To obtain a new or tweaked version of this
   certificate in the future, simply run certbot again. To
   non-interactively renew *all* of your certificates, run "certbot
   renew"

Ура! С получением сертификата закончено!

Если нужно добавить поддомен или домен в сертификат

Если вы вдруг забыли указать поддомен www, или вам нужно добавить другой домен или поддомен в сертификат (которых может быть до 100 в одном сертификате), то это легко сделать после получения сертификата. Просто запустите команду еще раз, добавив требуемое имя:

certbot certonly -d example.com -d www.example.com -d shop.example.com

Вам будет безальтернативно предложено добавить этот домен в сертификат. Если хочется избежать вопросов, то можно сразу указать одобряющий такое поведение ключ:

certbot certonly --expand -d example.com -d www.example.com -d shop.example.com

Операцию можно повторять.

Проверим полученный сертификат

Убедимся что полученный сертификат — именно тот, что нам нужен:

# openssl x509 -text -in /etc/letsencrypt/live/example.com/cert.pem
Certificate:
    Signature Algorithm: ...
      Validity
        Not Before: Jan  3 06:00:00 2017 GMT
        Not After : Apr  3 06:00:00 2017 GMT
        X509v3 extensions:
            ...
            X509v3 Subject Alternative Name: 
                DNS:example.com, DNS:www.example.com

Или, если подробности вам не нужны:

cat /etc/letsencrypt/live/*/cert.pem | openssl x509 -text | 
        grep -o 'DNS:[^,]*' | cut -f2 -d:

Команда должна вывести список доменов в сертификате.

Установка и использование сертификатов

Certbot не перезаписывает сертификаты, а заменяет их ссылками на самые актуальные варианты сертификатов в определенном каталоге, одноименном с первым доменом сертификата (т.е. CN).

Давайте посмотрим что за файлы у нас есть:

 # find /etc/letsencrypt/live/ -type l
/etc/letsencrypt/live/example.com/fullchain.pem
/etc/letsencrypt/live/example.com/chain.pem
/etc/letsencrypt/live/example.com/privkey.pem
/etc/letsencrypt/live/example.com/cert.pem

С этим знанием мы можем задать настройки SSL для nginx:

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

Как видите, cert.pem нигде в конфиге не используется, и это не ошибка. Для nginx он не нужен.

Полный рабочий пример конфига:

server {
    server_name www.example.com;
    listen www.example.com:443 ssl; # default_server;
    # выше можно добавить default_server для клиентов без SNI

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

    ssl_stapling on;
    ssl_stapling_verify on;
    resolver 127.0.0.1 8.8.8.8;

    # исключим возврат на http-версию сайта
    add_header Strict-Transport-Security "max-age=31536000";

    # явно "сломаем" все картинки с http://
    add_header Content-Security-Policy "img-src https: data:; upgrade-insecure-requests";

    # далее всё что вы обычно указываете
    #location / {
    #    proxy_pass ...;
    #}
}

Конфиг для переадресации с голого домена без www:

server {
    server_name example.com;
    listen example.com:443 ssl;
    access_log off;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    ssl_trusted_certificate /etc/letsencrypt/live/example.com/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";

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

Подразумевается что вы используете какой-то локальный сервер для кеширования DNS запросов. Если это не так, то 127.0.0.1 в директиве resolver нужно заменить на IP используемого DNS сервера.

Настройки шифров и прочее подобное (ssl_dhparam, ssl_session_cache) лучше держать вне конфигов отдельных серверов.

Perfect Forward Secrecy

Если вы переживаете что Certbot может утащить ключи от вашего сертификата не смотря на открытые исходные коды, а значит, в теории, какие-то злодеи смогут расшифровать весь трафик, то спешу вас успокоить. Если для соединения с вашим сайтом используются шифры из семейств DHE и ECDHE, то утечка ключа не позволит расшифровать трафик. В этих шифрах ключ сертификата используется только для подтверждения подлинности, и не используется в качестве ключа для шифрования. Все современные браузеры поддерживают эти шифры.

Если для ECDHE на эллиптических кривых ничего не нужно делать, то для DHE можно было бы использовать усиленные параметры. Лучше всего будет отключить DHE вообще.

openssl dhparam -out /etc/ssl/private/dhparam.pem 2048

ssl_dhparam /etc/ssl/private/dhparam.pem;

Продление сертификатов

Сертификаты выдаются на три месяца. Не на полгода, не на год, а лишь на три месяца. Естественно это вызывает вопросы. Нужно ли проходить всю эту процедуру через три месяца? Нужно ли это делать всегда до искончания веков? Может стоит всё-таки вложиться в платный сертификат чтобы забыть об этом всем и не воспоминать пару лет?

Но нет, не спешите искать платежные средства! Как и было обещано в начале статьи, с обновлением сертификатов проблем нет.

Если у вас Debian, то нужно лишь дописать к вызову certbot в /etc/cron.d/certbot ключ --allow-subset-of-names:

# последняя строка в /etc/cron.d/certbot
# было certbot -q renew, а надо
certbot -q renew --allow-subset-of-names

Если у вас Debian и systemd, то посмотрите эти инструкции.

Если у вас не Debian или нет файла, то добавим в crontab от root одну лишь строчку (sudo crontab -e):

42 */12 * * * certbot renew --quiet --allow-subset-of-names

Согласно рекомендаций Let’s Encrypt следует пытаться обновить сертификаты два раза в день. Делать это нужно в случайным образом выбранную минуту того часа, а значит вам нужно заменить 42 в этой строке на другое число в диапазоне между 0 и 59. Либо вы можете поступить так как это делается в /etc/cron.d/certbot.

Как это работает

В этой команде ключ --allow-subset-of-names нужен чтобы Certbot пытался получить сертификаты для частичного набора доменов.

Например, были у вас на сервере были сайты www.example.com и shop.example.com, проходящие под одним сертификатом, но потом вы перенесли shop.example.com на другой сервер. Если такой ключ не указать, то Certbot упадет с ошибкой при попытке подтвердить владение shop.example.com, не получив для вас вообще никакого сертификата. Сертификат истечет и ваш сайт уйдет в оффлайн. С этим ключом вы всё же получите сертификаты хотя бы для частичного набора доменов, оставив ваши сайты в сети.

Вот и всё

Если вам близки по духу tee и sed, то есть гораздо более короткая инструкция по настройке связки Let’s Encrypt и nginx, при условии корректно настроенного hostname. Только копируй команды и вставляй.

Нашли ошибку? Напишите в личку, пожалуйста.

Репутация веб-ресурсов во многом зависит от уровня безопасности и уровня защиты персональных данных на сервере. В случае с сайтами речь идет о включении протокола 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 и записывать результат в файл с указанным названием.

• Главная

• Инструкции

• Ubuntu

• Как обезопасить Nginx с Let’s Encrypt на Ubuntu

В современном мире мы проводим в интернете немало времени — общаемся, совершаем банковские операции, пользуемся сервисами оплаты ЖКХ. Если не шифровать трафик, злоумышленники могут перехватить данные пользователя или системы — от информации, которую оставляет пользователь на сайте, до паролей и доступов к личным кабинетам.

Чтобы этого избежать, был создан протокол HTTPS, который работает благодаря SSL/TLS-сертификатам. 

HTTPS (HyperText Transfer Protocol Secure) — протокол передачи данных, который поддерживает шифрование при помощи криптографических протоколов SSL/TLS. По своей сути это расширенная версия обычного HTTP, на основе которого работает интернет.

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

По умолчанию все запросы HTTPS используют для подключения 443 порт. 

SSL и TLS — в чём разница?

В 90-х годах прошлого века компания Netscape разработала SSL-сертификат, чтобы обезопасить интернет-соединение. Но уже в 1999 году были произведены существенные доработки сертификата, потому что в его начальных версиях было немало недостатков. Такая новая версия получила название TLS — transport layer security — защита транспортного уровня. Но для того, чтобы не путать пользователей, разработчики допустили использование и старого, и нового названий. В официальной документации вы вероятнее всего встретите аббревиатуру TLS, но в этой статье мы используем более привычное SSL.

Ключ шифрования

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

Асиметричное шифрование

Каждая сторона имеет два ключа — частный и публичный. Они известны только владельцу и любому клиенту соответственно. Когда клиент отправляет сообщение, он находит публичный ключ сервера и шифрует сообщение. Сервер же расшифровывает сообщение при помощи своего частного ключа, то же самое работает и в обратную сторону. 

Симметричное шифрование

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

Let’s Encrypt — центр сертификации, который выдаёт бесплатные SSL-сертификаты. С его помощью можно легко и быстро обезопасить сайт с помощью HTTPS-протокола. Его простота заключается в том, что практически за все шаги отвечает специальный клиент — certbot, который автоматизирует все действия с сертификатом. 

Однако несмотря на всю простоту установки и работы с сертификатами Let’s Encrypt, у них есть существенные минусы. Во-первых, его можно получить только на 90 дней, дальше придётся обновлять, тогда как платные сертификаты можно выпустить на срок до трёх лет. Во-вторых, они рассчитаны только на один домен и не проверяют компанию, которой принадлежит домен. В-третьих, — это самое важное для коммерческого проекта — Let’s Encrypt не несёт ответственность за ваши данные, вы не получаете никаких финансовых гарантий; если случится взлом бесплатных сертификатов, ущерб никто не возместит.

Но сертификаты Let’s Encrypt — отличный вариант для небольших проектов, для сайтов, которые находятся на стадии разработки или для внутренней инфраструктуры.

В этой статье мы рассмотрим, как установить бесплатный сертификат Let’s Encrypt для Nginx в Ubuntu 20.04, а также настроим его автоматическое продление. 

Требования

В этой статье нам понадобится сервер Ubuntu 20.04, который вы можете заказать на cloud.timeweb.com с настроенным пользователем, которому доступны привилегии sudo. На этом сервере должен быть установлен и сконфигурирован Nginx и виртуальный хост для него.

Кроме этого вы должны обладать зарегистрированным доменным именем. Вы можете купить его с помощью любого регистратора доменных имён. В нашем примере мы используем домен example.com. 

Для домена должны быть корректно настроены А-записи. В нашем случае мы установим сертификат на example.com, а также защитим www.example.com. Поэтому нужно убедиться в том, что существует две А-записи, где оба этих домена указывают на публичный адрес вашего сервера.

Установка Certbot

На официальном сайте certbot рекомендуют устанавливать через snap. Основное отличие от установки deb-пакета через менеджер apt в том, что snap устанавливает приложение сразу со всеми зависимостями, которые будут использоваться только им. Такой способ помогает избежать проблем с версиями дистрибутивов, но приложение займёт больше места на диске и будет дольше запускаться.

В нашем руководстве мы установим пакет классическим методом,так как никаких проблем с версиями зависимостей cerbot на нашем новом, «чистом» сервере нет. Если вы хотите использовать snap, воспользуйтесь официальным руководством.

В первую очередь нужно обновить индекс пакетов:

sudo apt update && sudo apt upgrade -y

Далее можно устанавливать Cerbot:

sudo apt install certbot python3-certbot-nginx

После этих двух шагов Certbot установлен и готов к использованию. Следующий шаг — убедиться в том, что конфигурация Nginx правильная, чтобы certbot смог автоматически установить SSL-сертификат.

Конфигурация Nginx

Для автоматизации всех действий с помощью certbot вы должны соблюдать некоторые правила при написании конфигурации виртуальных хостов nginx. Во-первых, серверный блок для домена, на который вы устанавливаете SSL-сертификат, должен располагаться по адресу /etc/nginx/sites-available/example.com. Во-вторых, в этом файле должна быть настроена директива server_name, которая будет соответствовать доменам, для которых мы настраиваем безопасное соединение. 

Чтобы проверить, соблюдены ли все эти требования, откройте файл с конфигурацией:

sudo nano /etc/nginx/sites-available/example.com

Теперь найдите в нём строчку:

server_name example.com www.example.com;

Если её нет, вы можете добавить директиву самостоятельно.

После того, как вы завершили проверку или обновление конфигурации, проверьте синтаксис nginx и перезагрузите веб-сервер:

sudo nginx -t
sudo systemctl reload nginx

Теперь certbot точно сможет найти нужную конфигурацию и автоматически её обновить.

Брандмауэр

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

sudo ufw allow 'Nginx Full'
sudo ufw delete allow 'Nginx HTTP'

В итоге при выполнении команды sudo ufw status вы увидите приблизительно следующую картину:

Status: active
To                       Action           From
--                         ------             ----
OpenSSH              ALLOW       Anywhere
Nginx Full           ALLOW       Anywhere
OpenSSH (v6)         ALLOW       Anywhere (v6)
Nginx Full (v6)      ALLOW       Anywhere (v6)

Получение сертификата SSL

С помощью плагина nginx certbot автоматически изменит конфигурацию нашего веб-сервера и перезагрузит её, когда это потребуется. Для установки сертификата с помощью плагина введите следующую команду:

sudo certbot --nginx -d example.com -d www.example.com

Здесь флаг --nginx отвечает за использование плагина nginx, а домены, для которых устанавливается SSL указываются при помощи опции -d.

При первом запуске certbot предложит вам принять условия обслуживания и запросит адрес электронной почты. Затем он свяжется с сервером Let’s Encrypt для получения сертификата и отправит запрос, чтобы подтвердить, что вы контролируете домен. 

Когда все проверки будут пройдены, certbot спросит у вас, как настроить HTTPS:

Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: No redirect - Make no further changes to the webserver configuration.
2: Redirect - Make all requests redirect to secure HTTPS access. Choose this for
new sites, or if you're confident your site works on HTTPS. You can undo this
change by editing your web server's configuration.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate number [1-2] then [enter] (press 'c' to cancel):

Первый вариант означает, что certbot не станет настраивать автоматическое перенаправление с адреса http:// на https://. Второй — что все запросы будут перенаправлены на безопасный протокол https. В большинстве случаев следует выбирать последний вариант, однако перед этим вы должны убедиться в том, что ваш сайт корректно работает с такими запросами. Если кодовая база ещё не подготовлена, выбирайте первый вариант, перенаправление можно настроить позже.

После выбора варианта, конфигурация обновится, а nginx перезагрузится для применения новых настроек. Certbot выведет сообщение, в котором укажет места хранения сертификатов и дату их окончания.

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/example.com/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/example.com/privkey.pem
   Your cert will expire on 2022-08-18. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot again
   with the "certonly" option. To non-interactively renew *all* of
   your certificates, run "certbot renew"
 - If you like Certbot, please consider supporting our work by:
   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

Корректность настройки вы можете проверить, запросив сайт в браузере. Вы увидите значок замка, который означает безопасное соединение, и можете изучить информацию о сертификате. Кроме того, можно дополнительно протестировать сервер с помощью ssllabs.com.

Автоматическое обновление сертификата

Certbot устанавливает сертификаты, которые действительны только в течение 90 дней. Это сделано для безопасности — разработчики из Let’s Encrypt стимулируют администраторов периодически обновлять ключи. 

Однако certbot сам продлевает сертификаты, которые истекают менее, чем через 30 дней. Это происходит при помощи таймера systemd. Статус таймера вы можете узнать с помощью systemctl:

sudo systemctl status certbot.timer

Чтобы протестировать, будут ли корректно обновляться сертификаты, вы можете имитировать запуск продления:

sudo certbot renew --dry-run

Если ошибок нет, значит всё настроено корректно и работает правильно. При необходимости certbot сам установит новый сертификат и перезагрузит конфигурацию nginx. Но если по каким-то причинам процесс не выполняется, nginx отправит письмо на почту, которую вы указали при первом запуске. 

Заключение

В этой статье мы рассмотрели основные принципы работы https и разобрались, зачем он нужен. На тестовый домен example.com и его поддомен поставили SSL-сертификат с помощью утилиты certbot — так наглядно проверили, как происходит установка Let’s Encrypt в Ubuntu.

Кроме этого, мы настроили автоматическое обновление сертификатов, чтобы веб-ресурс всегда использовал шифрование трафика.

Let’s Encrypt — центр сертификации, который позволяет бесплатно получить TSL/SSL-сертификат. Благодаря клиенту Certbot, который автоматически выполняет большую часть настроек, выпустить сертификат и настроить HTTPS-протокол можно за несколько простых шагов.

Предварительная подготовка

Вам необходимы:

• сервер с операционной системой Ubuntu 18.04/20.04;
• Nginx, установленный на сервер (Как установить Linux, Nginx, MySQL, PHP (LEMP) в Ubuntu 18.04/20.04);
• домен, который привязан к облачному серверу (Как привязать домен к облачному серверу?).

Этап 1. Установка Certbot

Certbot — клиент для автоматического создания и установки SSL-сертификата. Разработчики постоянно работают над его улучшением. Поэтому Certbot, который имеется в стандартном репозитории Ubuntu, обычно устаревший.

Готово, Certbot установлен.

Этап 2. Настройка Nginx Ubuntu

Certbot автоматический ищет в конфигурационных файлах Nginx блок server, отвечающий за домен, для которого будет установлен SSL-сертификат.

Если вы устанавливали Nginx по инструкции Как установить Linux, Nginx, MySQL, PHP (LEMP) в Ubuntu 18.04/20.04, то вы используете конфигурационный файл по умолчанию для одного домена. Файлы вашего сайта расположены в каталоге /var/www/html, а в конфиге в директиве server_name указан домен, который привязан к серверу.

Проверим настройки конфига:

Готово, вы настроили Nginx.

Этап 3. Разрешение HTTPS-подключения

В инструкции Как установить Linux, Nginx, MySQL, PHP (LEMP) в Ubuntu 18.04/20.04 на втором этапе «Установка Nginx» были произведены настройки firewall. Проверьте, что HTTPS-подключение для сервера доступно, с помощью команды

Вы должны получить примерно следующее содержимое:

Этап 4. Получение SSL-сертификата

Certbot позволяет получить SSL-сертификат, а плагин для Nginx — выполнить автоматическую настройку и перезагрузку конфига, если это необходимо.

Для получения SSL-сертификата выполните команду:

sudo certbot --nginx -d faq-reg.ru -d www.faq-reg.ru

Ключ -d определяет имя домена, для которого выпускается сертификат. Укажите вместо домена faq-reg.ru свой домен, который привязан к серверу.

При первом запуске Certbot система запросит ваш e-mail и соглашение на использование сервиса. Затем будет произведена проверка домена: DNS-серверы домена должны указывать на ваш сервер.

Если проверка прошла успешно, Certbot спросит, как вы хотите настроить конфигурацию HTTPS:

1. Без редиректа — не вносит никаких изменений в конфигурационный файл.
2. Редирект — настраивает все редиректы для безопасного доступа по HTTPS. Рекомендуется для новых сайтов.

Выберите подходящий вариант (введите 1 или 2) и нажмите Enter:

После окончания установки SSL-сертификата система выдаст сообщение, что процесс установки прошёл успешно. В сообщении будет указано, где расположены файлы вашего сертификата. Сертификат Let’s Encrypt действителен только 90 дней. Certbot автоматически будет обновлять сертификат. При возникновении ошибки вы получите сообщение на e-mail, который был указан при первом запуске Certbot.

При переходе по вашему домену будет указано, что соединение с сайтом защищено:

Готово, теперь ваш сайт защищён SSL-сертификатом Let’s Encrypt. Настройка была произведена автоматически благодаря Certbot.

Let’s Encrypt — это бесплатный, автоматизированный и открытый центр сертификации, разработанный исследовательской группой Internet Security Research Group (ISRG), который предоставляет бесплатные SSL-сертификаты.

Сертификаты, выпущенные Let’s Encrypt, являются доверенными для всех основных браузеров и действительны в течение 90 дней с даты выпуска.

В этом руководстве объясняется, как установить бесплатный SSL-сертификат Let’s Encrypt на Ubuntu 20.04, запустив Nginx в качестве веб-сервера.

Certbot — это полнофункциональный и простой в использовании инструмент, который автоматизирует задачи по получению и обновлению SSL-сертификатов Let’s Encrypt и настройке веб-серверов для использования сертификатов.

Пакет certbot включен в репозитории Ubuntu по умолчанию. Для его установки выполните следующие команды:

sudo apt update

sudo apt install certbot

Обмен ключами Диффи-Хеллмана (DH) — это метод безопасного обмена криптографическими ключами по незащищенному каналу связи.

Создайте новый набор 2048-битных параметров DH, введя следующую команду:

sudo openssl dhparam -out /etc/ssl/certs/dhparam.pem 2048

Также можно использовать ключ длиной до 4096 бит, но генерация может занять более 30 минут, в зависимости от энтропии системы.

Чтобы получить SSL-сертификат для домена, мы собираемся использовать плагин Webroot, который работает, создавая временный файл для проверки запрошенного домена в ${webroot-path}/.well-known/acme-challengeкаталоге. Сервер Let’s Encrypt отправляет HTTP-запросы к временному файлу, чтобы убедиться, что запрошенный домен разрешается на сервер, на котором работает certbot.

Чтобы упростить задачу, мы собираемся сопоставить все HTTP-запросы .well-known/acme-challengeс одним каталогом /var/lib/letsencrypt.

Следующие команды создадут каталог и сделают его доступным для записи для сервера Nginx:

sudo mkdir -p /var/lib/letsencrypt/.well-known

sudo chgrp www-data /var/lib/letsencrypt

sudo chmod g+s /var/lib/letsencrypt

Чтобы избежать дублирования кода, мы создадим два фрагмента и включим их во все файлы блоков сервера Nginx.

Откройте текстовый редактор и создайте первый фрагмент letsencrypt.conf:

sudo nano /etc/nginx/snippets/letsencrypt.conf

location ^~ /.well-known/acme-challenge/ {
  allow all;
  root /var/lib/letsencrypt/;
  default_type "text/plain";
  try_files $uri =404;
}

Затем создайте второй фрагмент кода ssl.conf, который включает в себя чипперы, рекомендованные Mozilla , включает OCSP Stapling, HTTP Strict Transport Security (HSTS) и применяет несколько HTTP-заголовков, ориентированных на безопасность.

sudo nano /etc/nginx/snippets/ssl.conf

ssl_dhparam /etc/ssl/certs/dhparam.pem;

ssl_session_timeout 1d;
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off;

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
ssl_prefer_server_ciphers on;

ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 30s;

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Frame-Options SAMEORIGIN;
add_header X-Content-Type-Options nosniff;

После создания фрагментов откройте файл блока сервера домена и letsencrypt.confвключите фрагмент, как показано ниже:

sudo nano /etc/nginx/sites-available/example.com.conf

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

  include snippets/letsencrypt.conf;
}

Чтобы включить новый блок сервера, создайте символическую ссылку из файла в sites-enabledкаталог:

sudo ln -s /etc/nginx/sites-available/example.com.conf /etc/nginx/sites-enabled/

Перезапустите службу Nginx, чтобы изменения вступили в силу:

sudo systemctl restart nginx

Теперь вы можете запустить Certbot с подключаемым модулем webroot и получить файлы сертификатов SSL, выполнив:

sudo certbot certonly --agree-tos --email admin@example.com --webroot -w /var/lib/letsencrypt/ -d example.com -d www.example.com

Если SSL-сертификат успешно получен, certbot напечатает сообщение. Теперь, когда у вас есть файлы сертификатов, вы можете отредактировать блок сервера домена следующим образом:

sudo nano /etc/nginx/sites-available/example.com.conf

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

    include snippets/letsencrypt.conf;
    return 301 https://$host$request_uri;
}

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

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem;
    include snippets/ssl.conf;
    include snippets/letsencrypt.conf;

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

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

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem;
    include snippets/ssl.conf;
    include snippets/letsencrypt.conf;

    # . . . other code
}

Перезагрузите службу Nginx, чтобы изменения вступили в силу:

sudo systemctl reload nginx

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

Автообновление SSL-сертификата Let’s Encrypt

Сертификаты Let’s Encrypt действительны в течение 90 дней. Для автоматического обновления сертификатов до истечения срока их действия пакет certbot создает задание cronjob и системный таймер. Таймер автоматически продлит сертификаты за 30 дней до истечения срока их действия.

При обновлении сертификата необходимо перезагрузить службу nginx. Откройте /etc/letsencrypt/cli.iniи добавьте следующую строку:

sudo nano /etc/letsencrypt/cli.ini

deploy-hook = systemctl reload nginx

Чтобы протестировать процесс обновления, запустите команду certbot --dry-run:

sudo certbot renew --dry-run

Если ошибок нет, значит, процесс обновления прошел успешно.

Продолжая тему настройки защищенного соединения для веб-сервера, мы сегодня рассмотрим работу с Nginx. Данный сервер может применяться как самостоятельно, а также в виде фронтенда для Apache, либо вообще, как обратный-прокси. Это позволяет эффективно использовать его для защиты посредством SSL даже тех узлов и сервисов, настроить работу которых по защищенному протоколу может быть проблематично. В данном материале мы будем рассматривать настройку SSL в связке с Let’s Encrypt — бесплатным центром сертификации, сделавшем шифрование доступным действительно каждому.

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Мы не будем касаться первоначальной настройки, будем считать, что веб-сервер уже настроен вами и работает. Наш экземпляр был настроен по следующей инструкции и мы в дальнейшем будем придерживаться его конфигурации:

Настраиваем веб-сервер на базе Nginx + PHP-FPM в Debian / Ubuntu Server

В данном примере используются Nginx 1.19.5, PHP 7.3 и MariaDB 10.3 в среде Debian 10, но с небольшими поправками данная статья может использоваться для любого основанного на Debian дистрибутива.

Будем считать, что все конфигурационные файлы сайтов располагаются в /etc/nginx/sites-available, символические ссылки на активные сайты в /etc/nginx/sites-enabled, а шаблоны настроек в /etc/nginx/templates. Если вы используете иное расположение конфигурационных файлов, то это следует учитывать при выполнении описанных ниже действий.

В качестве примера будем рассматривать некий сайт example.org для которого будет настроена минимальная конфигурация следующего вида и установлена популярная CMS WordPress:

server {
   listen 80;
   server_name example.org;
   charset utf-8;
   root /var/www/example.org;
    index index.php;   access_log /var/log/nginx/example.org_access.log;
   error_log /var/log/nginx/example.org_error.log;   include /etc/nginx/templates/php-fpm.conf;
}server {
    listen 80; 
    server_name www.example.org;
   return 301 http://example.org$request_uri;
}

Прежде всего создадим новый шаблон для работы с Let’s Encrypt:

touch /etc/nginx/templates/le.conf

Откроем его и внесем следующий текст:

location ^~ /.well-known/acme-challenge/ {
   default_type "text/plain";
   root /var/www/letsencrypt;
}location = /.well-known/acme-challenge/ {
   return 404;
}

И подключим его в конфигурационный файл нашего сайта, добавив в самый конец основной секции server строку:

 include /etc/nginx/templates/le.conf;

Также не забудем создать указанную нами в шаблоне директорию и сделать ее владельцем веб-сервер:

mkdir /var/www/letsencrypt
chown -R www-data:www-data /var/www/letsencrypt

Проверим правильность конфигурации nginx:

nginx -t 

и перезапустим веб-сервер:

nginx -s reload

Затем установим certbot, в современных дистрибутивах достаточно выполнить:

apt install certbot

Более подробную информацию по установке и работе с certbot вы можете получить в нашей статье: Получаем сертификаты Let’s Encrypt при помощи Certbot

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

certbot certonly --dry-run --webroot -w /var/www/letsencrypt -d example.com -d www.example.com

Ключ —dry-run указывает на тестовый режим, —webroot задает используемый плагин, в данном случае работающий с уже имеющимся веб-сервером. Опция -w указывает рабочую директорию, которую мы настроили ранее, а через опцию -d задаются домены и поддомены, для которых мы хотим получить сертификат. Если все прошло успешно, то вы получите лаконичное сообщение:

Убедившись, что все работает нормально, можно получить рабочие сертификаты, для этого еще раз запустим приведенную выше команду, но уже без ключа —dry-run:

certbot certonly --webroot -w /var/www/letsencrypt -d example.com -d www.example.com

Символические ссылки на полученные сертификаты хранятся в /etc/letsencrypt/live, это позволяет использовать один и тот же путь несмотря на постоянное обновление сертификатов раз в 90 дней. Настройки продления для каждого сайта расположены в /etc/letsencrypt/renewal, откроем файл с настройками нашего домена /etc/letsencrypt/renewal/example.com.conf и внесем в секцию [renewalparams] следующую опцию:

[renewalparams]
...
renew_hook = nginx -s reload

Порядок расположения опций значения не имеет, данная настройка задает действие при успешном обновление сертификата, в данном случае это перезапуск веб-сервера nginx.

После получения сертификата настроим наш виртуальный хост на работу с ним. Для этого вернемся к конфигурационному файлу /etc/nginx/sites-available/example.org.conf и создадим в нем новую секцию server, внеся в нее следующие строки:

server {
   listen 443 ssl http2;
   server_name example.org;

Здесь мы задаем обязательно использовать ssl и протокол HTTP/2 (если такая возможность поддерживается клиентом).

Ниже добавим пути к сертификатам и настройки SSL-сессии:

ssl_certificate /etc/letsencrypt/live/example.org/fullchain.pem;
 ssl_certificate_key /etc/letsencrypt/live/example.org/privkey.pem;
 ssl_session_timeout 1d;
 ssl_session_cache shared:SSL:50m;
 ssl_session_tickets off;

Для обеспечения режима прямой секретности нам понадобится файл параметров Диффи-Хелмана, создадим его:

openssl dhparam -out /etc/ssl/private/dhparam.pem 2048

В данном случае мы используем криптостойкость ключа в 2048 бит, это минимальный размер для современных условий, для повышения криптостойкости можно использовать ключ длинной 4096 бит. Генерация ключа может занять длительное время в зависимости от вычислительной мощности вашего сервера.

Добавим путь к нему в наш конфигурационный файл:

ssl_dhparam /etc/ssl/private/dhparam.pem;

Теперь один из наиболее важных шагов — указание используемых шифров, это достаточно сложная тема, поэтому воспользуемся для генерации актуального и современного набора алгоритмов шифрования сервисом moz://a SSL Configuration Generator, из предлагаемых им вариантов наиболее оптимальным является вариант Intermediate.

ssl_protocols TLSv1.2 TLSv1.3;
 ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
 ssl_prefer_server_ciphers off;

Первая строка указывает допустимые протоколы, вторая — шифры и, наконец, третья, включает приоритет клиента в выборе протокола и алгоритма шифрования.

Следующую опцию пока следует закомментировать:

#add_header Strict-Transport-Security "max-age=63072000" always;

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

Следующие строки отвечают за поддержку OCSP Stapling, что позволяет ускорить проверку сертификата клиентом и ускорить загрузку сайта.

ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/letsencrypt/live/example.org/chain.pem;
resolver 8.8.8.8;

Ниже скопируем из основной секции сервер оставшиеся параметры и немного отредактируем их:

charset utf-8;
root /var/www/example.org;
index index.php;

access_log /var/log/nginx/example.org_ssl_access.log;
error_log /var/log/nginx/example.org_ssl_error.log;include /etc/nginx/templates/php-fpm.conf; 
include /etc/nginx/templates/le.conf;
}

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

nginx -t 
nginx -s reload

После чего убедимся, что сайт работает по защищенному протоколу HTTPS:

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

После того, как вы убедились, что ваш сайт отлично работает в защищенном режиме, внесем последние штрихи. Прежде всего включим режим HSTS, раскомментировав опцию:

add_header Strict-Transport-Security "max-age=63072000" always;

Затем приведем к следующему виду секции бывшие ранее основной на 80 порту и отвечавшую за перенаправление запросов с www:

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

server {
 listen 80;
 listen 443 ssl;
 server_name www.example.org;
 ssl_certificate /etc/letsencrypt/live/example.org/fullchain.pem;
 ssl_certificate_key /etc/letsencrypt/live/example.org/privkey.pem;
 return 301 https://example.org$request_uri;
}

Которые обеспечат перенаправление всех запросов на HTTPS версию сайта без www.

В исходной инструкции мы настраивали дополнительный серверный блок по умолчанию, который обрабатывал запросы по IP и к несуществующим узлам, блокируя такие соединения. Для этого мы использовали штатную конфигурацию по умолчанию в /etc/nginx/conf.d/default.conf или /etc/nginx/sites-available/default, если вы ставили nginx из стандартного репозитория. Изменим содержимое файла на:

server {
 listen 80 default_server;
 listen 443 default_server ssl;
 server_name _;
 ssl_certificate /etc/nginx/nginx.crt;
 ssl_certificate_key /etc/nginx/nginx.key;
 ssl_reject_handshake on;
 return 444;
}

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

openssl req -x509 -nodes -days 3650 -newkey rsa:2048 -keyout /etc/nginx/nginx.key -out /etc/nginx/nginx.crt

В данном случае мы выпустили самоподписанный сертификат на 10 лет и разместили его по путям указанным в конфиге выше.

Теперь еще раз проверим конфигурацию и перезапустим веб-сервер:

nginx -t 
nginx -s reload

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

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.