Нет правила для сборки цели debian canonical certs pem
Обновлено: 06.07.2024
Подготовка
Прежде чем продолжить работу с руководством, убедитесь, что выполнены следующие предварительные условия:
Установка Certbot
Мы будем использовать инструмент certbot для получения и обновления сертификатов.
Пакет certbot включен в репозитории Debian по умолчанию. Выполните следующие команды, чтобы установить certbot:
Создание группы Dh (Диффи-Хеллмана)
Вы также можете изменить размер до 4096 бит, но генерация может занять более 30 минут в зависимости от энтропии системы.
Выполните следующие команды, чтобы создать каталог и сделать его доступным для записи для сервера Nginx:
Чтобы избежать дублирования кода, мы создадим два сниппета, которые будут включены во все файлы блоков сервера Nginx.
Откройте свой текстовый редактор и создайте первый фрагмент, letsencrypt.conf :
После этого откройте файл блока сервера домена и letsencrypt.conf фрагмент letsencrypt.conf как показано ниже:
Создайте символическую ссылку на каталог с sites-enabled чтобы включить блокировку сервера домена:
Перезапустите сервис Nginx, чтобы изменения вступили в силу:
Теперь вы готовы получить файлы сертификатов SSL, выполнив следующую команду:
Отредактируйте блок сервера домена и включите файлы сертификата SSL следующим образом:
Перезапустите или перезагрузите службу Nginx, чтобы изменения вступили в силу:
Если вы протестируете свой домен с помощью SSL Labs Server Test , вы получите оценку A+ , как показано на изображении ниже:
При обновлении сертификата нам также необходимо перезагрузить службу nginx. Откройте /etc/letsencrypt/cli.ini и добавьте следующую строку:
Протестируйте процесс автоматического продления, выполнив эту команду:
Если ошибок нет, значит процесс продления прошел успешно.
Выводы
В этом руководстве мы показали вам, как создавать и обновлять сертификаты SSL с помощью скрипта certbot. Мы также показали вам, как настроить Nginx для использования сертификатов.
Чтобы узнать больше о Certbot, посетите документацию Certbot .
Если у вас есть какие-либо вопросы или отзывы, не стесняйтесь оставлять комментарии.
Я знаю, вам интересны пушки, пистолеты, пардон, усилители, цапы, акустика и все такое, но придется потерпеть и вникнуть в одну из тем актуального настоящего.
У многих аудиофилов уже не составляет труда застать сетап трудящийся на базе ОС Linux с использованием одного из лучших в мире программных аудипроигрывателей mpd и замечательной звуковой системы Alsa (которой не нужны никакие ASIO). Кто-то настраивает свой Linux для воспроизведения музыки самостоятельно, кто-то использует аудиофильные, уже преднастроенные, дистрибутивы, подобные Daphile.
Одной из особенностей таких дистрибутивов является специально скомпилированное под аудио ядро реального времени. Я сразу скажу, очень маловероятно, что вы способны будете прослушивая музыка заметить разницу между стандартным ядром Linux и оптимизированным realtime. Сам я изначально заморачивался с релтаймом, но сейчас вполне доволен штатным ядром из Kubuntu Linux.
ГДЕ НАЙТИ НОВОЕ ЯДРО И RT-ПАТЧ
patch-4.6.4-rt8.patch.gz 15-Jul-2016 11:39 202K
patch-4.6.4-rt8.patch.sign 15-Jul-2016 11:39 543
patch-4.6.4-rt8.patch.xz 15-Jul-2016 11:39 166K
patches-4.6.4-rt8.tar.gz 15-Jul-2016 11:39 329K
patches-4.6.4-rt8.tar.sign 15-Jul-2016 11:39 543
patches-4.6.4-rt8.tar.xz 15-Jul-2016 11:39 247K
sha256sums.asc 15-Jul-2016 11:57 1.2K
МЕХАНИК, КЛЮЧ НА 6092693 ПОЖАЛУЙСТА
Makefile:954: ошибка выполнения рецепта для цели «certs»
make[1]: *** [certs] Ошибка 2
Ключи получены, поэтому окончательно распаковываем ядро:
tar xvf linux-4.6.4.tar
В папке src появится директория с исходными кодами ядра Linux-4.6.4.
Распакует релтайм патч patch-4.6.4-rt8.patch.xz командой
unxz patch-4.6.4-rt8.patch.xz и скопируем его в папку с исходниками ядра:
cp patch-4.6.4-rt8.patch linux-4.6.4/
Дальнейшие действия в терминале будем производить находясь в папке с исходными кодами ядра, для это войдем в нее:
сd linux-4.6.4
RT-KERNEL НА СТАРТ И ДРУГИЕ МЕЛОЧИ
Не забудьте установить и сам gcc-g++.
Кроме того, если сейчас дать команду make xconfig, то вам придется настраивать много параметров вручную, логичнее получить их значения из настроек текущего ядра. Для этого скопируем файл конфигурации текущего ядра в папку с исходными кодами нового ядра 4.6.4:
cp /boot/config-$(uname -r) .config
И вот только теперь даем команду make xconfig и наблюдаем красивое графическое окно, в котором и будем изменять лишь некоторые параметры ядра.
Во первых в ядре нужно включить само свойство реалтаймовости (т.е. работы в реальном времени, что требуется программам работающим с прецизионной точностью).
Для этого в левом окне программы щелкните на раздел “Processor type and features”, а в правом найдите пункт Preemption Model и отметьте пункт
Fully Preemptible Kernel (RT)
Включение режима реального времени.
Далее нужно задать частоту обновления в 1000 Hz (этот параметр скорее всего уже будет установлен на таком значении).
Этот пункт находится чуть ниже в разделе Timer frequency.
Бескомпромисcные 1000 Hz.
Планировщик Deadline.
Выбор процессора.
Cохраняем .xconfig.
В моем случае сборка велась в пределах 40 минут, после чего в каталоге src появились два пакета с расширением deb, готовых к установке linux-image-4.6.4-rt8_4.6.4.RT_amd64.deb и linux-headers-4.6.4-rt8_4.6.4.RT_amd64.deb.
Свежее rt-ядро 4.6.4 готово к установке.
ФИНАЛЬНЫЙ АККОРД ИЛИ БЕЗ ЗАПРЕТОВ
Установка ядра.
Но раз уж мы получили ядро реального времени, то нужно внести небольшие изменения, чтобы реалтаймовость была задействована на полную катушку.
Главным образом нужно снять некоторые ограничения, за это отвечает файл limits.conf. Об этом трюке можно прочитать по ссылке на сайте разработчиков alsa.
Откроем файл для редактирования:
sudo nano /etc/security/limits.conf
Вы видите некоторое количество записей, но они все закоментированы. Просто внесите несколько новых:
Этими значениями мы задали аудиозадачам запущенным от обычного пользователя приоритет реального времени, а так же выделили участок памяти размером в 1 Гб, который будет использоваться единолично для аудио. Размер этой памяти вы можете выбрать самостоятельно, в старых руководствах рекомендуется ставить половину объема от имеющегося, но сегодня в персоналках такие объемы памяти, что и не снились пользователям прошлых лет, так что 1 Гб я думаю будет достаточно для большинства случаев.
Сохраняем файл (Ctrl+O), выходим (Ctrl+X) и перегружаемся.
Магия RT.
О ДИВНЫЙ НОВЫЙ МИР
У вас получилась фантастически быстрая система Linux с ядром работающим в режиме реального времени. Фантастически малые задержки (latency), сверхвысокоточный таймер отмеряющий время с безумной точностью, звуковая система alsa передающая аудиопоток в режиме bitperfect, и это не сон. О чем еще можно мечтать (кроме, разумеется, мира во всем мире)?
Улыбнитесь, добро пожаловать в Linux!
Если компиляция прекращается с ошибкой, возможно вы не установили все требуемые для этого компоненты, например kernel-package или fakeroot.
Требования
1: Установка клиента certbot
Пакета certbot нет в официальном репозитории Debian 8. Загрузить пакет certbot можно из backports-репозитория Jessie.
Добавьте этот репозиторий:
Обновите индекс пакетов:
sudo apt-get update
Теперь можно установить пакет certbot.
Примечание: Backports-репозитории не рекомендуется использовать для общесистемных обновлений. Устанавливайте только необходимые вам пакеты. Backports-пакеты менее совместимы, чем пакеты из основных репозиториев.
Чтобы избежать случайной установки или обновления пакетов из backports-репозитория, используйте флаг –t перед именем репозитория.
sudo apt-get install certbot -t jessie-backports
Клиент certbot готов к работе.
2: Получение сертификата
В данном руководстве для создания SSL-сертификата используется плагин Webroot.
Использование плагина Webroot
Если Nginx ещё не установлен, установите его с помощью этого руководства.
sudo nano /etc/nginx/sites-available/default
Добавьте в блок server новый блок location.
Также нужно проверить настройку каталога document root, за который отвечает директива root. По умолчанию каталогом document root является /var/www/html.
Сохраните и закройте файл.
Убедитесь, что в файле нет ошибок:
sudo nginx -t
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
После запуска certbot запросит некоторые данные.
Примечание: Вопросы, задаваемые при первом запуске программы, отличаются от вопросов, задаваемых при дальнейшем её использовании. В руководстве предполагается, что программа запущена впервые.
Укажите адрес электронной почты, который будет использоваться для отправки извещений и восстановления утерянных ключей.
Если всё выполнено правильно, программа вернёт:
Выпишите или запомните путь и срок действия сертификата (в примере они выделены красным).
Важно! Если вы получили ошибку Failed to connect to host for DVSNI challenge, разблокируйте трафик на портах 80 и 443.
Примечание: В некоторых случаях домен нужно отключить на время получения сертификата.
Файлы сертификата
После получения сертификата на сервере появятся следующие PEM-файлы:
Чтобы убедиться, что все файлы существуют, нужно выполнить такую команду:
sudo ls -l /etc/letsencrypt/live/your_domain_name
Команда покажет список существующих файлов.
Ключи Диффи-Хеллмана
sudo openssl dhparam -out /etc/ssl/certs/dhparam.pem 2048
Выполнение команды займёт несколько минут. Ключи DH будут храниться в /etc/ssl/certs/dhparam.pem.
3: Настройка TLS/SSL на веб-сервере Nginx
Теперь нужно настроить веб-сервер Nginx для обслуживания сертификата. Для этого нужно внести в настройки такие изменения:
- Добавить сниппет для сертификата и ключа SSL.
- Добавить сниппет общих настроек SSL, который будет доступен всем сертификатам.
- Настроить поддержку SSL и обработку новых сниппетов в виртуальном хосте (блоке server) Nginx.
Сниппет для SSL-сертификата и ключа
Создайте новый сниппет Nginx в каталоге /etc/nginx/snippets. Выберите для него описательное имя (например, можно добавить префикс ssl-):
В этом файле нужно определить директивы ssl_certificate и ssl_certificate_key, которые указывают путь к сертификату и ключу соответственно.
Сохраните и закройте файл.
Сниппет общих настроек SSL
Теперь нужно создать сниппет общих настроек SSL. Здесь нужно определить шифрование и включить дополнительные функции безопасности.
Эти параметры Nginx сможет использовать и в будущих настройках.
sudo nano /etc/nginx/snippets/ssl-params.conf
Для настройки SSL на Nginx используйте рекомендации Remy van Elst с сайта Cipherli.st. Больше рекомендаций для Nginx можно найти здесь.
Примечание: Предлагаемые на сайте Cipherli.st настройки очень надёжны. Однако в некоторых случаях это негативно влияет на совместимость клиента. Если вам нужна поддержка старых клиентов, откройте альтернативный список настроек, перейдя по ссылке «Yes, give me a ciphersuite that works with legacy / old software».
Эти альтернативные настройки можно использовать далее вместо рекомендуемых настроек по умолчанию. Выбор настроек во многом зависит от потребностей сайта или приложения.
Скопируйте все предложенные настройки и внесите в них небольшие коррективы.
Сначала укажите DNS-преобразователь. В данном руководстве используется преобразователь Google. Также нужно добавить параметр ssl_dhparam, чтобы указать сгенерированный ключ Диффи-Хеллмана.
Предзагрузка HSTS обеспечивает повышенную безопасность, но неправильное или случайное подключение может иметь далеко идущие последствия. В этом руководстве мы не будем предварительно загружать настройки, но вы можете сделать это, если вы уверены, что понимаете последствия:
Сохраните и закройте файл.
Настройка Nginx для поддержки SSL
Теперь сниппеты готовы, и вы можете отредактировать конфигурации Nginx, чтобы настроить поддержку SSL.
Примечание: Далее предполагается, что вы используете виртуальный хост default из каталога /etc/nginx/sites-available. Если вы используете другой файл, укажите его имя.
Сначала нужно создать резервную копию виртуального хоста:
sudo cp /etc/nginx/sites-available/default /etc/nginx/sites-available/default.bak
Откройте файл в редакторе:
sudo nano /etc/nginx/sites-available/default
На данный момент файл, скорее всего, содержит такие строки:
Настройки нужно разделить на два блока. После директив listen нужно добавить server_name и указать доменное имя сервера. Затем нужно настроить редирект.
После этого нужно добавить второй блок настроек и поместить в него оставшиеся параметры. Раскомментируйте директивы listen, которые указывают порт 443, и укажите файлы сниппетов.
Примечание: Вы можете использовать только одну директиву listen с модификатором default_server для каждой комбинации IP-адреса и порта. Если эти порты и default_server используются в другом виртуальном хосте, оставьте модификатор только водном из них.
Сохраните и закройте файл.
Чтобы настроить поддержку шифрованного и нешифрованного трафика, используйте следующие настройки Nginx.
Примечание: Использовать незашифрованный трафик не рекомендуется.
В целом, нужно просто сжать два отдельных блока в один блок и удалить редирект:
Сохраните и закройте файл.
4: Настройка брандмауэра
Если вы включили брандмауэр, нужно разблокировать трафик SSL.
Примечание: Если брандмауэр отключен, можете пропустить этот раздел.
Брандмауэр UFW
Чтобы просмотреть текущие правила UFW, введите:
sudo ufw status
Status: active
To Action From
-- ------ ----
SSH ALLOW Anywhere
WWW ALLOW Anywhere
SSH (v6) ALLOW Anywhere (v6)
WWW (v6) ALLOW Anywhere (v6)
sudo ufw allow 'WWW Full'
sudo ufw delete allow 'WWW'
Теперь настройки выглядят так:
sudo ufw status
Status: active
To Action From
-- ------ ----
SSH ALLOW Anywhere
WWW Full ALLOW Anywhere
SSH (v6) ALLOW Anywhere (v6)
WWW Full (v6) ALLOW Anywhere (v6)
Брандмауэр iptables
Чтобы просмотреть текущий набор правил iptables, введите:
sudo iptables -S
На экране появится список правил. Например:
-P INPUT DROP
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
Какие правила нужно добавить, чтобы настроить поддержку SSL, зависит от текущих правил брандмауэра. Если вы используете базовый набор правил, используйте такое правило:
sudo iptables -I INPUT -p tcp -m tcp --dport 443 -j ACCEPT
Просмотрите правила. Теперь они выглядят так:
sudo iptables -S
-P INPUT DROP
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
Если правила iptables загружаются автоматически вместе с сервером, добавьте в эту настройку и новое правило.
5: Обновление настроек Nginx
Теперь нужно перезапустить Nginx, чтобы изменения вступили в силу. Сначала проверьте синтаксис:
Если в настройках не обнаружено ошибок, вы увидите такой вывод:
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
Чтобы убедиться, что сертификат работает, откройте свой домен в браузере.
Чтобы проверить настройку сертификата, можно использовать сервис Qualys SSL Labs.
Проверка может занять несколько минут.
6: Автоматическое обновление сертификата
Сертификаты Let’s Encrypt действительны в течение 90 дней, но во избежание ошибок их рекомендуется обновлять каждые 60 дней. На момент написания статьи клиент не оборудован функцией автоматического обновления сертификатов. Этот процесс можно выполнить вручную при помощи опции Let’s Encrypt renew.
Чтобы запустить обновление для всех доменов, запустите:
sudo certbot renew
Поскольку текущий сертификат был создан только что, у команды нет необходимости обновлять его, она просто сообщит, сколько дней осталось до истечения срока действия сертификата:
Примечание: Если вы создали сертификат для нескольких доменов, в выводе команды будет указан только базовый домен, но обновление будет выполнено для всех доменов.
Надёжный способ обеспечить своевременное обновление сертификата – это демон cron.
Команда renewal будет отслеживать срок действия сертификата и обновлять его за 30 дней до истечения этого срока. Настройте cron запускать команду раз в неделю. Таким образом, в случае сбоя cron у вас будет в запасе 30 дней, чтобы снова попытаться обновить сертификат.
Программа может предложить выбрать текстовый редактор по умолчанию. Добавьте в crontab root-пользователя следующие строки:
Если вдруг вся эта история прошла мимо вас, 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 . Только копируй команды и вставляй.
Читайте также: