lets encrypt настройка certbot

Как настроить SSL используя Certbot и Let’s Encrypt

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

Let’s Encrypt и Certbot

Let’s Encrypt — это бесплатный и автоматизированный (с помощью ACME протокола) центр сертификации, а Certbot — один из многих доступных клиентов, который сильно упрощает жизнь.

Установка Certbot

Мы используем CentOS 7 и на сайте Certbot уже есть необходимые команды для установки:

1. sudo yum install epel — release
2. sudo yum install certbot

У них также есть инструкции и для других операционных систем.

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

Certbot имеет систему плагинов. Наиболее многообещающий из них — nginx , однако меня смущают некоторые моменты в документации:

Плагин Nginx является экспериментальным… Nginx Web Server — в настоящее время не работает

У нас есть ряд виртуальных серверов и мне не хотелось все испортить, поэтому я решил воспользоваться другим плагином, который также хорошо подходил — webroot .

Webroot плагин

Принцип работы данного плагина прост: указываем ему на главную/root папку веб сервера, он создает там папку .well-known и кладет туда необходимые для проверки файлы, после чего клиент со стороны Let’s Encrypt проверяет их и таким образом мы подверждаем права на указанный домен. Более детально процесс описан на сайте Let’s Encrypt.

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

1. certbot certonly — webroot — w / var / www / 4devs / example . com / current / web — d example . com — w / var / www / 4devs / example2 . com / current / web — d sub1 . example2 . com — d sub2 . example2 . com

Здесь мы имеем следующие части:

certonly — при использовании данной команды Certbot лишь получит сертификаты, но не будет ничего делать с вашим веб сервером и устанавливать их;

—webroot — указываем необходимый нам плагин;

-w — флаг для указания главной веб директории сервера. Просто указываем путь;

-d — флаг для указания домена. Вы можете использовать несколько таких флагов после флага -w при условии, что они все имеют одну и ту же главную веб папку.

Все сгенерированные ключи и сертификаты будут находиться в /etc/letsencrypt/live/$domain . Если вы получаете сертификат для множества доменов за раз, то тогда на выходе получите только одну папку по имени первого из указанных доменов. В нашем примере это будет /etc/letsencrypt/live/example.com .

Настройка Nginx

Далее обновим конфигурацию виртуального сервера:

1. server <
2. listen 443 ssl http2 ;
3. server_name ДОМЕНОВ ДЛЯ ИСПОЛЬЗУЕМОГО СЕРТИФИКАТА>;
4. ssl_certificate К fullchain . pem ФАЙЛУ>;
5. ssl_certificate_key К privkey . pem ФАЙЛУ>;
6. >

Не забудьте перезагрузить Nginx:

Ограничения

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

Автоматизация продления сертификатов

Решать проблему мы будем с помощью crontab, но сначала советую выполнить следующую команду

под пользователем, под которым будете настраивать crontab, и убедиться, что все отработало нормально. Это необходимо сделать т.к. одна из потенциальных проблем — права на папки, с которыми работает certbot. Если проблем нет, то выполняем crontab -e и настраиваем продление сертификатов:

1. # Certbot: продление сертификатов
2. X */ 12 * * * certbot renew — quiet

Внимание: замените X значением от 0 до 59.

Certbot рекомендует запускать обновление чаще чем раз в 3 месяца. Задача выше будет запускаться дважды в день. Чтобы лучше понять crontab, воспользуйтесь Crontab Guru, который посоветовал @bfredit. Если ваши сертификаты будут свежими на момент запуска certbot, то он просто ничего не будет делать.

Выводы

Полная настройка заняла порядка 5 минут и была весьма приятной (думаю все любят когда всё работает быстро и с первого раза), поэтому я рекомендую вам опробовать данный подход.

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

Отличная новость для системных администоров и всего интернета. Let’s Encrypt начал поддерживать выпуск wildcard-сертификатов. Что это значит? Сертификаты безопасности (SSL/TLS-сертификаты)…

Все больше и больше компаний начинают использовать HTTP/2 для повышения производительности своих сайтов. Настроить HTTP/2 довольно просто, но что делать,…

При работе с curl не только в php может возникнуть подобная проблема: cURL error 60: SSL certificate : self signed…

источник

Записки IT специалиста

Технический блог специалистов ООО»Интерфейс»

Получаем сертификаты 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-зависимости.

Установка в Ubuntu 14.04/16.04

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

Прежде всего установим необходимое для работы с PPA программное обеспечение:

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

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

Lighttpd

В русскоязычной среде данный веб-сервер недостаточно распространен, так как пользователи отдают предпочтение Nginx, но в мировом масштабе он входит в число наиболее популярных веб-серверов. Если вы используете именно его, то откройте основной конфигурационный файл /etc/lighttpd/lighttpd.conf и убедитесь, что в секции server.modules присутствует значение mod_alias, в противном случае его необходимо добавить.

После чего дополните конфигурацию следующей секцией:

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

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

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

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

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

Для регистрации выполните команду:

Для успешного прохождения процедуры вам потребуется всего-лишь согласиться с условиями использования. Учетная информация будет сохранена в каталог /etc/letsencrypt/accounts, если содержимое данной директории будет утрачено, то вы не сможете продлить сертификаты и вам придется получать их заново, создав новый аккаунт. Это следует учитывать, например, при переносе системы на новый сервер.

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

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

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

Наконец-то мы подошли к самому главному — получению сертификата, но не стоит спешить, количество запросов на сертификат в единицу времени ограничено (20 запросов на регистрацию в неделю и 5 неудачных запросов в час), поэтому следует убедиться, что все сделано правильно. Для этого следует использовать возможность тестового запуска Certbot, наберем в консоли:

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

При удачном прохождении теста вы получите краткий ответ:

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

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

Сертификат получен, отлично! Но где нам его искать? Перейдем в /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:

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

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

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

Поэтому основное назначение Certbot — это именно автоматическое продление сертификатов. Производится оно одной простой командой renew. Если мы заглянем в /etc/cron.d то найдем там файл certbot в котором дважды в день запланирован запуск команды:

Как видим, никаких дополнительных параметров не передается, и Cerbot сам определяет что нужно продлевать. Каким образом он это делает? Вернемся в /etc/letsencrypt и заглянем еще в одну директорию renewal, там мы обнаружим некие конфигурационные файлы с именами доменов, например, example.com.conf, откроем его. В начале будут перечислены файлы сертификата и пути к ним, эта информация нас мало интересует, гораздо интереснее вторая часть файла, которая выглядит примерно так:

Секция renewalparams указывает основные параметры получения сертификата: плагин — webroot, инсталлятор сертификата — в нашем случае отсутствует и аккаунт, к которому привязаны данные сертификаты. В секции webroot_map перечислены требующие продления домены и указан путь к корневой папке для Let’s Encrypt.

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

Затем доменов стало больше, и вы перешли на единую точку подтверждения сертификатов /var/www/letsencrypt, но в конфигурационном файле по-прежнему останется /var/www/example.com и такой домен автоматически продлиться не сможет.

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

Как и в случае с получением сертификата ключ —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 для различных приложений.

источник