Как установить certbot ubuntu
Обновлено: 04.07.2024
Сервис настройки NGINX
Не тратьте время на ручную подготовку конфигурационных файлов для NGINX. Выберите нужные параметры и скачайте уже сформированный конфигурационный файл.
Предварительная подготовка
- сервер с операционной системой Ubuntu 18.04/20.04;
- Nginx, установленный на сервер (Как установить Linux, Nginx, MySQL, PHP (LEMP) в Ubuntu 18.04/20.04);
- домен, который привязан к облачному серверу (Как привязать домен к облачному серверу?).
Этап 1. Установка Certbot
Certbot — клиент для автоматического создания и установки SSL-сертификата. Разработчики постоянно работают над его улучшением. Поэтому Certbot, который имеется в стандартном репозитории Ubuntu, обычно устаревший.
Для возможности добавления PPA репозиториев выполните команду:
Добавьте репозиторий Certbot командами:
Затем обновите информацию в операционной системе:
Установите Certbot для Nginx командой:
Готово, 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 командой:
Готово, вы настроили Nginx.
Вы должны получить примерно следующее содержимое:
Этап 4. Получение SSL-сертификата
Certbot позволяет получить SSL-сертификат, а плагин для Nginx — выполнить автоматическую настройку и перезагрузку конфига, если это необходимо.
Для получения SSL-сертификата выполните команду:
При первом запуске Certbot система запросит ваш e-mail и соглашение на использование сервиса. Затем будет произведена проверка домена: DNS-серверы домена должны указывать на ваш сервер.
Выберите подходящий вариант (введите 1 или 2) и нажмите Enter:
При переходе по вашему домену будет указано, что соединение с сайтом защищено:
Готово, теперь ваш сайт защищён SSL-сертификатом Let’s Encrypt. Настройка была произведена автоматически благодаря Certbot.
Если вдруг вся эта история прошла мимо вас, 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 при помощи Certbot
Начиная цикл статей о шифровании при помощи сертификатов Let's Encrypt мы упоминали Certbot как официальный клиент. Несмотря на простоту, его установка и использование может таить некоторые подводные камни, особенно для начинающих, и поэтому мы решили посвятить ему отдельную статью, чтобы более не возвращаться к данному вопросу. Также мы рекомендуем ознакомиться с данной статьей и более опытным пользователям, особенно если вы планируете в дальнейшем использовать наши материалы по SSL.
Что такое Certbot? Это клиент протокола ACME предназначенный для автоматического управления SSL-сертификатами от Let's Encrypt, он позволяет полностью автоматизировать процесс получения и продления сертификата, а при использовании соответствующих плагинов даже может автоматически конфигурировать веб-сервер или иное, использующее сертификат приложение.
Все дальнейшие инструкции будут предназначены для пользователей актуальных версий Debian и Ubuntu, но многое будет справедливо и для иных дистрибутивов Linux.
Установка в Debian 8 Jessie
Debian 8 является на сегодня основной "рабочей лошадкой" в своем семействе. Однако в официальных репозиториях Certbot отсутствует и для его установки вам потребуется подключить специальный backports-репозиторий. Он содержит скомпилированные для использования в среде текущего дистрибутива пакеты из более новых версий, которые могут быть недостаточно стабильными или иметь некоторые иные проблемы, поэтому использовать его следует с осторожностью.
Откроем файл /etc/apt/sources.list и добавим в него следующую строку:
Затем обновим список пакетов:
Теперь установим пакет с явным указанием репозитория:
Так как Certbot написан на Python при его установке будет автоматически подтянуто довольно большое количество python-пакетов по зависимостям, однако это не должно вызвать каких-либо проблем.
Установка в Debian 9 Stretch
В новом выпуске Debian все просто, отныне Certbot представлен в официальном списке пакетов и для его установки достаточно выполнить одну простую команду:
В остальном процесс ничем не отличается от Jessie, также будет подтянуты необходимые python-зависимости.
![certbot-001.jpg]()
Установка в Ubuntu 14.04/16.04
В отличие от разработчиков Debian в Ubuntu пошли другим путем, оформив Certbot в виде отдельного PPA. Данная технология позволяет любому желающему создать собственный репозиторий и хорошо известна любому пользователю Ubuntu, однако вся ответственность за содержимое PPA лежит только на их авторах, поэтому использовать их следует с определенной долей осмотрительности и осторожности.
Прежде всего установим необходимое для работы с PPA программное обеспечение:
Затем добавим нужный PPA:
Обновим список пакетов:
и установим Certbot:
Последовательность действий для всех дистрибутивов Ubuntu одинаковая, при подключении PPA автоматически определяется выпуск Ubuntu и добавляются нужные репозитории. Точно также можно установить Certbot на промежуточные релизы (16.10 или 17.04) но мы не рекомендуем их использование в производственных средах.
Подготовка к получению сертификатов
В предыдущей статье цикла мы довольно подробно разбирали работу плагина webroot, который позволяет автоматически получать сертификаты используя уже установленный в системе веб-сервер. Если коротко, то вы указываете путь к корневой директории сайта, для которого получаете сертификат в файловой системе, Certbot создает там необходимую структуру папок и размещает необходимый для проверки файл.
В случае с одним доменом это не вызывает проблем, но если их много или вам требуется сертификат сразу на несколько доменов (основной домен и поддомены), корневые директории у которых отличаются, то у вас возникнут затруднения. Поэтому сам Let's Encrypt рекомендует перейти в таком случае на единую точку подтверждения сертификатов. Сделать это несложно, и мы сейчас расскажем, как.
В доступной для веб-сервера директории создадим отдельную папку, скажем, letsencrypt, которую затем мы будем использовать для всех обслуживаемых доменов и установим ее владельцем веб-сервер:
Теперь нам нужно сделать так, чтобы любой запрос вида:
приводил к физическому размещению:
Это несложно, но для каждого из веб-серверов делается по-разному, ниже мы рассмотрим самые популярные из них.
Apache 2.x
Apache является самым распространенным и популярным веб-сервером, актуальной версией является 2.4.x, для его подготовки к работе с Certbot добавьте в основной конфигурационный файл /etc/apache2/apache2.conf следующую секцию:
Для устаревшей версии Apache 2.2 данный блок должен выглядеть следующим образом:
Данная секция создает для любого запроса к /.well-known/acme-challenge алиас (псевдоним), указывающий на физическую директорию /var/www/letsencrypt/.well-known/acme-challenge, а ее расположение в основном конфигурационном файле позволит распространить действие директив для любого обслуживаемого домена. Остальные параметры задают необходимые параметры безопасности.
Nginx
Nginx - второй по популярности веб-сервер (и первый среди продвинутых пользователей) предполагает несколько иной подход к настройке. Для каждого виртуального хоста в секцию server следует добавить блок:
Если вы настраивали сервер по нашей инструкции, то мы рекомендуем вынести указанный блок в отдельный шаблон, например, /etc/nginx/templates/letsencrypt.conf и впоследствии подключать в конфигурацию виртуального хоста именно его и в общих чертах это должно выглядеть так:
Данный подход является хорошей практикой, так как в случае внесения каких-либо изменений их придется делать только в одном месте, вне зависимости от числа обслуживаемых виртуальных хостов.
После чего дополните конфигурацию следующей секцией:
Не забывайте, что после внесения изменений в конфигурационные файлы любой веб-сервер необходимо перезапустить.
Да, вы не ошиблись, именно регистрация. Обычно этот пункт пропускают, так как регистрация автоматически выполняется при первом получении сертификата. Но так как мы подробно разбираем работу Certbot, то решили коротко коснуться и этого момента.
Адрес электронной почты указываемый при регистрации используется для рассылки уведомлений, например, при неудачной попытке продления сертификата, поэтому следует указывать рабочий ящик, лучше всего собственный. Один и тот-же адрес можно использовать для регистрации на разных хостах, ограничений по этому параметру нет.
Для регистрации выполните команду:
Для успешного прохождения процедуры вам потребуется всего-лишь согласиться с условиями использования. Учетная информация будет сохранена в каталог /etc/letsencrypt/accounts, если содержимое данной директории будет утрачено, то вы не сможете продлить сертификаты и вам придется получать их заново, создав новый аккаунт. Это следует учитывать, например, при переносе системы на новый сервер.
Если вам необходимо изменить адрес электронной почты аккаунта, скажем при смене администратора, то это можно сделать командой:
Следует помнить, что технической возможности восстановления аккаунта нет и в случае его утраты вам придется заново выпускать все сертификаты.
Получение сертификата
Наконец-то мы подошли к самому главному - получению сертификата, но не стоит спешить, количество запросов на сертификат в единицу времени ограничено (20 запросов на регистрацию в неделю и 5 неудачных запросов в час), поэтому следует убедиться, что все сделано правильно. Для этого следует использовать возможность тестового запуска Certbot, наберем в консоли:
Ключ --dry-run включает тестовый режим, при котором производится симуляция получения сертификата, --webroot - указывает используемый плагин, после ключа -w указываем путь к директории для letsencrypt, а затем через ключ -d указываем домены для которых мы получаем сертификат. Как минимум это должно быть основное имя сайта и имя c www, хотя никто не мешает включить вам в сертификат все нужные поддомены или вообще разные домены. Лимит на количество доменов в сертификате равен 100.
При удачном прохождении теста вы получите краткий ответ:
После того как тестовый запуск увенчался успехом можно переходить к получению сертификата:
- cert.pem - собственно сертификат
- chain.pem - цепочка доверия, включает корневой и промежуточный сертификаты Let's Encrypt
- fullchain.pem - полная цепочка, включающая кроме содержимого chain.pem сам сертификат
- privkey.pem - закрытый ключ сертификата, данный файл является секретным.
Именно эти файлы следует использовать в конфигурационных файлах служб при настройке SSL, конкретные реализации выходят за рамки данной статьи и это будет сделано в отдельных материалах, мы же заглянем еще глубже под капот.
При внимательном рассмотрении выяснится, что файлы в директории live являются символьными ссылками на аналогичные файлы в /etc/letsencrypt/archive:
Настоящие файлы хранятся в аналогичной по структуре директории archive и имеют в наименовании порядковый номер, который увеличивается при каждом продлении сертификата. Например, при первом получении сертификата ссылка cert.pem из live будет указывать на cert1.pem из archive, после продления туда добавится cert2.pem, и ссылка начнет указывать на него. Как видим процесс обновления сертификатов реализован прозрачно для использующих их служб и достаточно все настроить один единственный раз, остальное Certbot берет на себя.
Полученный сертификат можно в любой момент расширить, добавив в него новые домены, для этого следует использовать ключ --expand:
Таким образом вы всегда можете добавить в сертификат нужные домены не затрагивая остальной инфраструктуры, напомним, что лимит составляет 100 доменов на один сертификат.
Продление сертификатов
После того, как все сертификаты получены и настроены сайты и службы их использующие встает вопрос об их продлении. Мы помним, что срок действия сертификата - 90 дней, поэтому если их много и получены они в разное время, то вручную следить за всем этим хозяйством будет весьма и весьма проблематично.
Поэтому основное назначение Certbot - это именно автоматическое продление сертификатов. Производится оно одной простой командой renew. Если мы заглянем в /etc/cron.d то найдем там файл certbot в котором дважды в день запланирован запуск команды:
Секция renewalparams указывает основные параметры получения сертификата: плагин - webroot, инсталлятор сертификата - в нашем случае отсутствует и аккаунт, к которому привязаны данные сертификаты. В секции webroot_map перечислены требующие продления домены и указан путь к корневой папке для Let's Encrypt.
Здесь скрыт один из подводных камней, допустим сначала у вас был один домен, и вы просто получали сертификат для него указывая:
Поэтому мы рекомендуем всегда проверять возможность продления командой:
Как и в случае с получением сертификата ключ --dry-run предписывает провести тестовый запуск с симуляцией продления, что позволит своевременно выявить возможные ошибки и устранить их.
Сама же команда renew, как многие успели догадаться, последовательно получает конфигурационные файлы из директории renewal и выполняет продление согласно указанным там параметрам.
В принципе, убедившись в успешности тестового продления можно оставить все как есть, но лучше произвести тонкую настройку. Прежде всего добавим к команде продления ключ --allow-subset-of-names:
Данный ключ предписывает получать сертификат для неполного набора доменов, это нужно для того, чтобы если один из доменов, перечисленных в сертификате вдруг окажется недоступным, сертификат был получен для остальных.
Простой пример из жизни. Вы собираетесь провести серьезную переработку сайта, для этого вы создаете новый домен new.example.com и производите разработку и тестирование на нем, его же вы добавляете в сертификат. Затем вы переносите новый сайт на основной домен, а старый перемещается на old.example.com, который также добавляется в сертификат. Через какое-то время кто-то отключает new.example.com за ненадобностью и потом в одно не очень прекрасное утро сайт "порадует" вас просроченным сертификатом.
Но это еще не все, после того как сертификат будет продлен нужно перезапустить все службы его использующие, например, веб-сервер. Можно прописать еще одно задание в cron, но правильно будет сделать по-другому. Certbot поддерживает специальные ключи, которые позволяют выполнять некие действия перед и после запуска утилиты:
- --pre-hook PRE_HOOK - позволяет выполнять некие действия перед запуском certboot
- --post-hook POST_HOOK - выполняет указанные действия после запуска certboot
- --renew-hook RENEW_HOOK - выполняет действия только после успешного продления сертификата.
Наиболее удобным в использовании является ключ --renew-hook, который будет перезапускать службы только тогда, когда получит новый сертификат, а не два раза в день, как это будет делать --post-hook.
Как использовать данные ключи? В простейшем случае можно просто добавить их к команде продления в cron:
В указанном нами примере будут перезапущены веб-сервер Apache и ftp-сервер vsftpd. Однако разные сертификаты могут быть привязаны к разным службам, поэтому более правильно будет указать эти параметры в конфигурационных файлах в директории renewal. Для этого в секцию [renewalparams] добавьте:
Обратите внимание на синтаксис, который несколько отличается от синтаксиса, используемого при указании в составе команды.
Надеемся, что данный материал поможет вам лучше понять работу Certboot, что в дальнейшем позволит нам не обращаться этой теме, а уделить больше внимания конкретным реализациям защиты c помощью SSL для различных приложений.
- Бесплатный SSL-сертификат не вечен.
- Не все домены можно защитить бесплатным SSL-сертификатом.
Установка certbot для получения сертификата от letsencrypt в Unix/Linux
Вот пример того, как же работает letsencrypt с веб-сервером:
На этом примере, я показал как работает certbot с letsencrypt для nginx. Но можно использовать apache или любой другой веб-сервер.
Установка Certbot в Unix/Linux
Приведу пример установки на различные ОС.
Установка Certbot в Ubuntu:
Установим вспомогательный пакет:
Установка Certbot в Debian:
Не приходилось еще ставить и возможно данная инструкция не будет работать на новых версиях debian. Но внизу будут представлено решение ( универсальное) для Unix/Linux ОС.
Установка Certbot в Mac OS X:
Устанавливаем homebrew, если не знаете как, то вот статья:
Выполним поиск пакета:
Установка Certbot в RedHat/CentOS/Fedora:
Подключаем репозиторий EPEL:
И потом, выполняем установку:
Установка Certbot в Gentoo:
Установка Certbot в Arch Linux:
Установка Certbot в FreeBSD:
Установка Certbot на другие Unix/Linux ОС:
Ставим гит и выполняем:
Вот, можно ознакомится:
Установку выполнили, переходим к установке и настройке сертификатов.
Настройка сертификат от letsencrypt
Чтобы получить помощь, можно использовать:
Если нужно добавить поддомен или домен в сертификат
Отвечая на вопросы, вы сгенерируете себе сертификат для поддоменов и он будет единый для всех.
Если добавить нужный ключ, то можем избавиться от вопросов, например:
ЗАМЕЧАНИЕ: Один такой сертификат может включать в себя до 100 поддоменов в одном сертификате!
Если используется APACHE
Если у вас Apache2, открываем:
Затем, подключаем модуль в апач:
Создаем папку для работы:
и перезапускаем сервер:
И выполним проверку:
Но я не проверял работу на апаче!
Если используется NGINX
Т.к у меня установлен и используется nginx в качестве веб сервера, то я приведу настройку сертификата именно для него.
И прописываем к уже имеющемуся конфигу следующие строки:
PS: Если вы получаете все файлы с папки ( можно проверить curl-ом)с ограничением в 10 переадресаций:
Если это так, то Boulder сможет получить все эти файлы. Так же, вы не должны создавать никаких ограничений по IP.
Вот полезное чтиво по CURL:
Сохраняем, закрываем файл и перезапускаем веб-сервер:
Уже имеется в системе certbot, и сейчас можно прогнать тестовый запуск:
Устанавливаем сертификат вручную (первый раз):
После этого действия, certbot будет запущен в 5.00 ( каждый день) и будет проверять состояние сертификата. При истечении срока, он будет продлен автоматически.
Генерация dhparam (группы Диффи-Хеллмана), для этого выполняем:
И так, все уже имеется. Открываем конфиг веб сервера:
И приводим к виду:
Так же, я внес в настройку certbot-а. Открываем:
Проверяем, всели в порядке:
И выполняем релоад:
После всех этих действий, можно проверить когда же истекает созданный сертификат:
PS: Больше полезных команд по OpenSSL можно найти тут:
Это все хорошо, но если имеется несколько доменов. Как быть? Я нашел решение, приведу его ниже.
PS: Замените параметры на свои!
Если это новый сайт и нет сертификатов, нужно запустить:
НЕ ЗАБЫВАЕМ ПРОПИСАТЬ ВСЕ НЕОБХОДИМОЕ В КОНФИГ-ФАЙЛЕ САМОГО NGINX!
и так для каждого сайта.
Если вы хотите удалить сертификат с вашего сервера, его можно аннулировать с помощью подкоманды. Команда ниже может использоваться, чтобы отменить определенный сертификат. Замените имя_домена доменом, сертификат которого вы хотите отозвать:
Добавить комментарий Отменить ответ
Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.
Читайте также: