Качаем сертбота
либо с гитхаба
git clone https://github.com/certbot/certbot.git
либо, следуя инструкциям https://certbot.eff.org/docs/install.html
Подготовка к получению сертификатов
В принципе использование сертбота для получения одного сертификата даже для нескольких доменов достаточно просто.
Но если вам требуются несколько сертификатов сразу на несколько доменов (основной домен и поддомены), корневые директории у которых отличаются, то у вас возникнут затруднения. Поэтому сам Let’s Encrypt рекомендует перейти в таком случае на единую точку подтверждения сертификатов. Сделать это несложно, и мы сейчас расскажем, как.
В доступной для веб-сервера директории создадим отдельную папку, скажем, letsencrypt, которую затем мы будем использовать для всех обслуживаемых доменов и установим ее владельцем веб-сервер:
mkdir /var/www/letsencrypt
chown www-data:www-data /var/www/letsencrypt
Теперь нам нужно сделать так, чтобы любой запрос вида:
http://example.com/.well-known/acme-challenge
приводил к физическому размещению:
/var/www/letsencrypt/.well-known/acme-challenge
Это несложно, но для каждого из веб-серверов делается по-разному, ниже мы рассмотрим самые популярные из них.
Apache является самым распространенным и популярным веб-сервером, актуальной версией является 2.4.x, для его подготовки к работе с Certbot добавьте в основной конфигурационный файл /etc/apache2/apache2.conf следующую секцию:
Alias /.well-known/acme-challenge/ /var/www/letsencrypt/.well-known/acme-challenge/
<Directory «/var/www/letsencrypt/.well-known/acme-challenge/»>
Options None
AllowOverride None
ForceType text/plain
Require all granted
RedirectMatch 404 «^(?!/\.well-known/acme-challenge/[\w-]{43}$)«
</Directory>
Для устаревшей версии Apache 2.2 данный блок должен выглядеть следующим образом:
Alias /.well-known/acme-challenge/ /var/www/letsencrypt/.well-known/acme-challenge/
<Directory "/var/www/letsencrypt/.well-known/acme-challenge/">
Options None
AllowOverride None
ForceType text/plain
Order allow,deny
Allow from all
RedirectMatch 404 "^(?!/\.well-known/acme-challenge/[\w-]{43}$)"
</Directory>
Данная секция создает для любого запроса к /.well-known/acme-challenge алиас (псевдоним), указывающий на физическую директорию /var/www/letsencrypt/.well-known/acme-challenge, а ее расположение в основном конфигурационном файле позволит распространить действие директив для любого обслуживаемого домена. Остальные параметры задают необходимые параметры безопасности.
Регистрация в Let’s Encrypt
Да, вы не ошиблись, именно регистрация. Обычно этот пункт пропускают, так как регистрация автоматически выполняется при первом получении сертификата. Но так как мы подробно разбираем работу Certbot, то решили коротко коснуться и этого момента.
Регистрация нужна для формирования ключевой пары, которой впоследствии подписываются все запросы, что позволяет удостовериться в подлинности отправителя. Это важно, так как все запросы передаются по открытым каналам и теоретически возможен их перехват и модификация.
Адрес электронной почты указываемый при регистрации используется для рассылки уведомлений, например, при неудачной попытке продления сертификата, поэтому следует указывать рабочий ящик, лучше всего собственный. Один и тот-же адрес можно использовать для регистрации на разных хостах, ограничений по этому параметру нет.
Для регистрации выполните команду:
certbot register -m admin@example.com
Для успешного прохождения процедуры вам потребуется всего-лишь согласиться с условиями использования. Учетная информация будет сохранена в каталог /etc/letsencrypt/accounts, если содержимое данной директории будет утрачено, то вы не сможете продлить сертификаты и вам придется получать их заново, создав новый аккаунт. Это следует учитывать, например, при переносе системы на новый сервер.
Если вам необходимо изменить адрес электронной почты аккаунта, скажем при смене администратора, то это можно сделать командой:
certbot register —update-registration -m new_admin@example.com
Следует помнить, что технической возможности восстановления аккаунта нет и в случае его утраты вам придется заново выпускать все сертификаты.
Получение сертификата
Наконец-то мы подошли к самому главному — получению сертификата, но не стоит спешить, количество запросов на сертификат в единицу времени ограничено (20 запросов на регистрацию в неделю и 5 неудачных запросов в час), поэтому следует убедиться, что все сделано правильно. Для этого следует использовать возможность тестового запуска Certbot, наберем в консоли:
certbot certonly —dry-run —webroot -w /var/www/letsencrypt -d example.com -d www.example.com
Ключ —dry-run включает тестовый режим, при котором производится симуляция получения сертификата,—webroot — указывает используемый плагин, после ключа -w указываем путь к директории для letsencrypt, а затем через ключ -d указываем домены для которых мы получаем сертификат. Как минимум это должно быть основное имя сайта и имя c www, хотя никто не мешает включить вам в сертификат все нужные поддомены или вообще разные домены. Лимит на количество доменов в сертификате равен 100.
Для параноиков можно добавить ещё ключик —rsa-key-size 4096. Либо прописать его в /etc/letsencrypt/cli.ini, добавив строчку
rsa-key-size = 4096
При удачном прохождении теста вы получите краткий ответ: «- The dry run was successful»
А в случае неудачи довольно развернутый лог, который обычно легко позволяет понять, что именно пошло не так и оперативно исправить ошибки.
После того как тестовый запуск увенчался успехом можно переходить к получению сертификата:
certbot certonly —webroot —w /var/www/letsencrypt —d example.com —d www.example.com
Сертификат получен, отлично! Но где нам его искать? Перейдем в /etc/letsencrypt/live где для каждого полученного сертификата будет создана папка с именем первого указанного в запросе домена, т.е. для нашего примера — example.com. Внутри будут находиться четыре файла:
- 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:
certbot certonly —webroot -w /var/www/letsencrypt —expand -d example.com -d www.example.com -d forum.example.com
Таким образом вы всегда можете добавить в сертификат нужные домены не затрагивая остальной инфраструктуры, напомним, что лимит составляет 100 доменов на один сертификат.
Продление сертификатов
После того, как все сертификаты получены и настроены сайты и службы их использующие встает вопрос об их продлении. Мы помним, что срок действия сертификата — 90 дней, поэтому если их много и получены они в разное время, то вручную следить за всем этим хозяйством будет весьма и весьма проблематично.
Поэтому основное назначение Certbot — это именно автоматическое продление сертификатов. Производится оно одной простой командой renew. Если мы заглянем в /etc/cron.d то найдем там файл certbot в котором дважды в день запланирован запуск команды:
certbot -q renew
Как видим, никаких дополнительных параметров не передается, и Cerbot сам определяет что нужно продлевать. Каким образом он это делает? Вернемся в /etc/letsencrypt и заглянем еще в одну директорию renewal, там мы обнаружим некие конфигурационные файлы с именами доменов, например, example.com.conf, откроем его. В начале будут перечислены файлы сертификата и пути к ним, эта информация нас мало интересует, гораздо интереснее вторая часть файла, которая выглядит примерно так:
# Options used in the renewal process
[renewalparams]
authenticator = webroot
installer = None
account = 4073d66415ef4c5a89e2cbca53e5f899
[[webroot_map]]
example.com = /var/www/letsencrypt
www.example.com = /var/www/letsencrypt
forum.example.com = /var/www/letsencrypt
Секция renewalparams указывает основные параметры получения сертификата: плагин — webroot, инсталлятор сертификата — в нашем случае отсутствует и аккаунт, к которому привязаны данные сертификаты. В секции webroot_map перечислены требующие продления домены и указан путь к корневой папке для Let’s Encrypt.
Здесь скрыт один из подводных камней, допустим сначала у вас был один домен, и вы просто получали сертификат для него указывая:
—webroot -w /var/www/example.com
Затем доменов стало больше, и вы перешли на единую точку подтверждения сертификатов /var/www/letsencrypt, но в конфигурационном файле по-прежнему останется /var/www/example.com и такой домен автоматически продлиться не сможет.
Поэтому мы рекомендуем всегда проверять возможность продления командой:
certbot renew —dry-run
Как и в случае с получением сертификата ключ —dry-run предписывает провести тестовый запуск с симуляцией продления, что позволит своевременно выявить возможные ошибки и устранить их.
Сама же команда renew, как многие успели догадаться, последовательно получает конфигурационные файлы из директории renewal и выполняет продление согласно указанным там параметрам.
В принципе, убедившись в успешности тестового продления можно оставить все как есть, но лучше произвести тонкую настройку. Прежде всего добавим к команде продления ключ —allow-subset-of-names:
certbot -q renew —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:
certbot -q renew —allow-subset-of-names —renew-hook «service apache2 reload; service vsftpd restart»
В указанном нами примере будут перезапущены веб-сервер Apache и ftp-сервер vsftpd. Однако разные сертификаты могут быть привязаны к разным службам, поэтому более правильно будет указать эти параметры в конфигурационных файлах в директории renewal. Для этого в секцию [renewalparams]добавьте:
renew-hook = service apache2 reload; service vsftpd restart
Обратите внимание на синтаксис, который несколько отличается от синтаксиса, используемого при указании в составе команды.
Надеемся, что данный материал поможет вам лучше понять работу Certboot, что в дальнейшем позволит нам не обращаться этой теме, а уделить больше внимания конкретным реализациям защиты c помощью SSL для различных приложений.