Настройка nginx ssl debian

Обновлено: 07.07.2024

В какой-то момент у меня снова возникли ошибки в браузерах: NET::ERR_CERT_AUTHORITY_INVALID (Google Chrome), MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT (Firefox). И снова мне пришлось разбираться, как решить эту проблему. Я написал новую статью о том, как добавить доверенный SSL-сертификат для локальной среды в Nginx на Debian/Ubuntu. На этот раз мы будем использовать корневой центр сертификации (ЦС).

Эта инструкция была выполнена на операционных системах: Debian 10, Debian 9, Ubuntu 20.10, Ubuntu 20.04, Ubuntu 19.10.

Создание конфигурации OpenSSL

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

Скопируйте и вставьте следующую подготовленную конфигурацию в новый файл, где DNS.1 — это название вашего сервера (укажите DNS.2, если вам нужна поддержка поддоменов):

Сохраняем изменения и закрываем файл.

Создание доверенного самоподписанного SSL-сертификата

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

req — это команда, которая указывает на использование X.509 (управление запросом подписи сертификата);
-x509 — это команда управления данными сертификата, указывающая на создание самоподписанного сертификата;
-nodes — это команда, которая пропускает использование парольной фразы;
-days 3650 — это команда, которая устанавливает срок действия сертификата в днях (мы установили его на десять лет);
-newkey rsa: 2048 — это команда, которая генерирует новый приватный ключ с использованием алгоритма RSA с длиной ключа 2048 бит;
-keyout /etc/ssl/private/localhost.key — это путь для размещения файла приватного ключа;
-out /etc/ssl/certs/localhost.crt — это путь для размещения файла сертификата;
-config /tmp/openssl.cnf — это путь к файлу конфигурации.

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

Настройка Nginx для использования SSL

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

Теперь применим изменения конфигурации, выполнив команду в терминале:

Установка утилиты certutil

Теперь нам необходимо добавить сгенерированный SSL-сертификат в базу данных, которую использует браузер. Для управления этой базой данных используется утилита certutil, которая входит в состав пакета libnss3-tools. Если у вас нет этого пакета в системе, тогда установим его.

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

Установим пакет libnss3-tools, выполнив команду в терминале:

Добавление сертификата в базу данных

Давайте добавим сгенерированный SSL-сертификат в базу данных с помощью утилиты certutil, выполнив команду в терминале:

Эта инструкция была протестирована на браузерах: Google Chrome и Opera.

Браузер Mozilla Firefox не хочет доверять сертификату, он использует базу данных cert8.db, которую я редактировал следующим образом:
certutil -d sql:$HOME/.mozilla/firefox/xqck5xx8.default -A -t "P,," -n localhost.crt -i /etc/ssl/certs/localhost.crt

Тестирование шифрования

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

TLS (Transport Layer Security) и его предшественник SSL (Secure Socket Layers) – криптографические протоколы, которые используются для защиты передачи данных в Интернете.

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

Данный мануал поможет создать самоподписанный SSL-сертификат для веб-сервера Nginx в Debian 10.

Требования

Сервер Debian 10, настроенный по этому мануалу.
Предварительно установленный веб-сервер Nginx. Можно установить стек LEMP, одним из компонентов которого является Nginx (для этого следуйте мануалу Установка стека LEMP в Debian 10); чтобы установить только Nginx, выполните инструкции мануала Установка Nginx в Debian 10.

1: Создание SSL-сертификата

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

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

sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/ssl/private/nginx-selfsigned.key -out /etc/ssl/certs/nginx-selfsigned.crt

Команда задаст ряд вопросов. Рассмотрим компоненты команды подробнее:

openssl: базовый инструмент командной строки для создания и управления сертификатами, ключами и другими файлами OpenSSL.
req: эта подкоманда указывает, что на данном этапе нужно использовать запрос на подпись сертификата X.509 (CSR). X.509 – это стандарт инфраструктуры открытого ключа, которого придерживаются SSL и TLS при управлении ключами и сертификатами. То есть, данная команда позволяет создать новый сертификат X.509.
-x509: эта опция вносит поправку в предыдущую субкоманду, сообщая утилите о том, что вместо запроса на подписание сертификата необходимо создать самоподписанный сертификат.
-nodes: пропускает опцию защиты сертификата парольной фразой. Нужно, чтобы при запуске сервер Nginx имел возможность читать файл без вмешательства пользователя. Установив пароль, придется вводить его после каждой перезагрузки.
-days 365: эта опция устанавливает срок действия сертификата (как видите, в данном случае сертификат действителен в течение года).
-newkey rsa:2048: эта опция позволяет одновременно создать новый сертификат и новый ключ. Поскольку ключ, необходимый для подписания сертификата, не был создан ранее, нужно создать его вместе с сертификатом. Данная опция создаст ключ RSA на 2048 бит.
-keyout: эта опция сообщает OpenSSL, куда поместить сгенерированный файл ключа.
-out: сообщает OpenSSL, куда поместить созданный сертификат.

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

Самой важной строкой является Common Name (введите FQDN или свое имя). Как правило, в эту строку вносят доменное имя, с которым нужно связать сервер. В случае если доменного имени нет, внесите в эту строку IP-адрес сервера. В целом эти поля выглядят примерно так:

Файлы ключа и сертификата будут помещены в каталог /etc/ssl.

При использовании OpenSSL нужно также создать ключи Диффи-Хеллмана, которые нужны для поддержки PFS (совершенной прямой секретности).

Для этого введите:

sudo openssl dhparam -out /etc/nginx/dhparam.pem 4096

Этот процесс займёт несколько минут. Ключи DH будут помещены в /etc/nginx/dhparam.pem.

2: Настройка Nginx для поддержки SSL

На данном этапе ключ и сертификат созданы и хранятся в каталоге /etc/ssl. Теперь нужно отредактировать настройки Nginx:

Создать сниппет, указывающий расположение файлов SSL-сертификата и ключа.
Добавить настройки SSL.
Настроить блоки server для обслуживания запросов SSL и поддержки новых настроек.

Расположение ключа и сертификата

Создайте новый сниппет Nginx в каталоге /etc/nginx/snippets.

Рекомендуется указать в названии файла его назначение (к примеру, self-signed.conf):

sudo nano /etc/nginx/snippets/self-signed.conf

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

ssl_certificate /etc/ssl/certs/nginx-selfsigned.crt;
ssl_certificate_key /etc/ssl/private/nginx-selfsigned.key;

Сохраните и закройте файл.

Настройка SSL

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

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

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

Для безопасной настройки SSL обратимся к рекомендациям Remy van Elst на сайте Cipherli.st. Этот сайт предназначен для распространения простых и надёжных параметров шифрования для популярного программного обеспечения.

Примечание: Данный список настроек обеспечивает высокую защиту, но иногда это делается за счет совместимости с другими клиентами. Чтобы получить настройки для других клиентов, перейдите по ссылке Yes, give me a ciphersuite that works with legacy / old software. Скопируйте все предложенные параметры.

В этом мануале мы используем все предложенные параметры, только немного отредактируем их.

Сейчас нужно добавить DNS резолвер для upstream запросов. В руководстве для этого используется Google.

Также нужно отключить заголовок Strict-Transport-Security (HSTS), а также его функцию предварительной загрузки. Предварительная загрузка заголовка HSTS обеспечивает повышенную безопасность, но может иметь далеко идущие последствия, если заголовок был включен случайно или некорректно. В этом мануале мы не будем включать эту опцию, но вы можете изменить это позже, если уверены, что понимаете последствия.

Скопируйте этот сниппет и вставьте его в ssl-params.conf:

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

Сохраните и закройте файл.

Настройка Nginx для поддержки SSL

Для начала создайте резервную копию файла блока server.

sudo cp /etc/nginx/sites-available/your_domain /etc/nginx/sites-available/your_domain.bak

Затем откройте файл блока server в текстовом редакторе:

sudo nano /etc/nginx/sites-available/your_domain

Файл должен выглядеть примерно так:

Ваш файл может быть составлен в другом порядке, и вместо директив root и index у вас может быть location, proxy_pass или другие пользовательские конфигурации. Это нормально, вам нужно только обновить директивы listen и включить сниппеты SSL. Этот блок нужно настроить для поддержки трафика SSL по порту 443, а затем создать новый блок server для обработки трафика по порту 80 и автоматической переадресации трафика на порт 443.

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

В текущем файле обновите директивы listen для поддержки порта 443 и ssl, а затем включите два новых сниппета:

Затем добавьте второй блок server в этот файл (после закрывающей фигурной скобки (>) первого блока):

Сохраните и закройте файл.

3: Настройка брандмауэра

Если вы включили брандмауэр ufw (согласно мануалу по начальной настройке), на данном этапе нужно настроить поддержку трафика SSL. К счастью, веб-сервер Nginx регистрирует при установке несколько своих профилей в ufw.

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

Чтобы просмотреть текущие настройки брандмауэра, наберите:

sudo ufw status

После этого настройки брандмауэра должны выглядеть так:

sudo ufw status
Status: active

4: Обновление настроек Nginx

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

Сначала нужно проверить синтаксис на наличие ошибок.

Если ошибок нет, команда вернёт:

nginx: [warn] "ssl_stapling" ignored, issuer certificate not found for certificate "/etc/ssl/certs/nginx-selfsigned.crt"
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Обратите внимание на предупреждение в начале. Как говорилось ранее, веб-сервер будет возвращать предупреждение в случае использования самоподписанного сертификата. Но соединения всё рано шифруются правильно.

Если в синтаксисе обнаружены ошибки, исправьте их. Затем перезапустите веб-сервер:

sudo systemctl restart nginx

5: Тестирование шифрования

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

Поскольку сертификат был подписан самостоятельно, браузер сообщит о его ненадёжности:

Your connection is not private
Attackers might be trying to steal your information
(for example, passwords,messages, or credit cards). NET::ERR_CERT_AUTHORITY_INVALID

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

После этого вы получите доступ к своему сайту. В адресной строке браузера вы увидите «x». В этом случае это означает, что подлинность сертификата невозможно проверить. Но он все еж шифрует ваше соединение.

6: Постоянный редирект

Если шифрование работает должным образом, настройте постоянный редирект вместо временного.

Откройте файл блока server:

sudo nano /etc/nginx/sites-available/<^>your_domain^>

Найдите в нём return 302 и замените значение строки на return 301.

Сохраните и закройте файл.

Проверьте синтаксис на ошибки:

Если ошибок нет, перезапустите Nginx:

sudo systemctl restart nginx

Заключение

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

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

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

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

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

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

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

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

Содержание

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

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

Caveat emptor

Есть ряд старых браузеров в принципе не поддерживающих 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?

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

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

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

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

Установка Certbot

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

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

Установка в Jessie

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

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

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

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

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

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

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

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

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

Certbot и webroot

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

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

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

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

Если вы видите такую ошибку:

То вам нужно обновить python-configargparse . Ошибка была исправлена в 0.11.0.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Perfect Forward Secrecy

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

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

Если по какой-то причине без DHE вы не можете обойтись

Если по какой-то причине без DHE вы не можете обойтись, то сначала создадим параметры:

Потом пропишем в /etc/nginx/conf.d/ssl_dhparam.conf одной строкой:

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

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

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

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

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

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

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

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

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

Вот и всё

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

Let's Encrypt - это бесплатный и открытый центр сертификации, разработанный Исследовательской группой по безопасности в Интернете (ISRG). Сертификаты, выпущенные Let's Encrypt, сегодня доверяют почти всем браузерам.

Прежде чем продолжить

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

Установить Certbot

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

Обновите список пакетов и установите пакет certbot:

Генерация группы Dh (Diffie-Hellman)

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

Получение SSL-сертификата Let's Encrypt

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

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

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

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

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

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

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

Затем отредактируйте блок сервера домена следующим образом:

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

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

Поскольку мы используем плагин certbot webroot после обновления сертификата, нам также необходимо перезагрузить службу nginx. Добавьте --renew-hook "systemctl reload nginx" в /etc/cron.d/certbot файл, чтобы он выглядел так:

Протестируйте процесс автоматического обновления, выполнив эту команду:

Вывод

В этом руководстве вы использовали клиент Let's Encrypt, certbot, для генерации SSL-сертификатов для вашего домена. Вы также создали фрагменты Nginx, чтобы избежать дублирования кода, и настроили Nginx для использования сертификатов. В конце урока вы установили cronjob для автоматического продления сертификата.

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

Читайте также: