Certbot где лежат сертификаты

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

Получаем сертификаты Let’s Encrypt при помощи Certbot

• Автор: Уваров А.С.
• 03.04.2017

Начиная цикл статей о шифровании при помощи сертификатов Let’s Encrypt мы упоминали Certbot как официальный клиент. Несмотря на простоту, его установка и использование может таить некоторые подводные камни, особенно для начинающих, и поэтому мы решили посвятить ему отдельную статью, чтобы более не возвращаться к данному вопросу. Также мы рекомендуем ознакомиться с данной статьей и более опытным пользователям, особенно если вы планируете в дальнейшем использовать наши материалы по SSL.

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Что такое Certbot? Это клиент протокола ACME предназначенный для автоматического управления SSL-сертификатами от Let’s Encrypt, он позволяет полностью автоматизировать процесс получения и продления сертификата, а при использовании соответствующих плагинов даже может автоматически конфигурировать веб-сервер или иное, использующее сертификат приложение.

Все дальнейшие инструкции будут предназначены для пользователей актуальных версий Debian и Ubuntu, но многое будет справедливо и для иных дистрибутивов Linux.

Установка в Debian 8 Jessie

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

Откроем файл /etc/apt/sources.list и добавим в него следующую строку:

deb http://ftp.debian.org/debian jessie-backports main

Затем обновим список пакетов:

apt-get update

Теперь установим пакет с явным указанием репозитория:

apt-get install certbot -t jessie-backports

Так как Certbot написан на Python при его установке будет автоматически подтянуто довольно большое количество python-пакетов по зависимостям, однако это не должно вызвать каких-либо проблем.

Установка в Debian 9 Stretch

В новом выпуске Debian все просто, отныне Certbot представлен в официальном списке пакетов и для его установки достаточно выполнить одну простую команду:

apt-get install certbot

В остальном процесс ничем не отличается от Jessie, также будет подтянуты необходимые python-зависимости.

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

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

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

apt-get install software-properties-common

Затем добавим нужный PPA:

add-apt-repository ppa:certbot/certbot

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

apt-get update

и установим Certbot:

apt-get install certbot

Последовательность действий для всех дистрибутивов Ubuntu одинаковая, при подключении PPA автоматически определяется выпуск Ubuntu и добавляются нужные репозитории. Точно также можно установить Certbot на промежуточные релизы (16.10 или 17.04) но мы не рекомендуем их использование в производственных средах.

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

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

В случае с одним доменом это не вызывает проблем, но если их много или вам требуется сертификат сразу на несколько доменов (основной домен и поддомены), корневые директории у которых отличаются, то у вас возникнут затруднения. Поэтому сам 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.x

Apache является самым распространенным и популярным веб-сервером, актуальной версией является 2.4.x, для его подготовки к работе с Certbot добавьте в основной конфигурационный файл /etc/apache2/apache2.conf следующую секцию:

Alias /.well-known/acme-challenge/ /var/www/letsencrypt/.well-known/acme-challenge/

 
Options None 
AllowOverride None 
ForceType text/plain 
Require all granted 
RedirectMatch 404 "^(?!/\.well-known/acme-challenge/[\w-]$)"

Для устаревшей версии Apache 2.2 данный блок должен выглядеть следующим образом:

Alias /.well-known/acme-challenge/ /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-]$)"

Данная секция создает для любого запроса к /.well-known/acme-challenge алиас (псевдоним), указывающий на физическую директорию /var/www/letsencrypt/.well-known/acme-challenge, а ее расположение в основном конфигурационном файле позволит распространить действие директив для любого обслуживаемого домена. Остальные параметры задают необходимые параметры безопасности.

Nginx

Nginx — второй по популярности веб-сервер (и первый среди продвинутых пользователей) предполагает несколько иной подход к настройке. Для каждого виртуального хоста в секцию server следует добавить блок:

location ^~ /.well-known/acme-challenge/ < default_type "text/plain"; root /var/www/letsencrypt; >location = /.well-known/acme-challenge/

Если вы настраивали сервер по нашей инструкции, то мы рекомендуем вынести указанный блок в отдельный шаблон, например, /etc/nginx/templates/letsencrypt.conf и впоследствии подключать в конфигурацию виртуального хоста именно его и в общих чертах это должно выглядеть так:

server server_name example.com 
.. 
include /etc/nginx/templates/letsencrypt.conf;
>

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

Lighttpd

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

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

$HTTP["url"] =~ "^/.well-known/" server.document-root = "/var/www/letsencrypt/.well-known/" 
alias.url = ( "/.well-known/" => "/var/www/letsencrypt/.well-known/" ) 
dir-listing.activate = "enable"
>

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

Регистрация в 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.

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

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

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

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 для различных приложений.

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Дополнительные материалы:

1. Let’s Encrypt — криптография становится ближе
2. Получаем сертификаты Let’s Encrypt при помощи Certbot

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

Или подпишись на наш Телеграм-канал:

Certbot где лежат сертификаты

Сегодня редко какой сервер общается с клиентом по незащищённому каналу, через 80-й порт. Такие сервера устанавливают, как правило, локально, где шифровать данные особого смысла не имеет. Другое дело — WWW. Правилом хорошего тона на текущий момент является использование защищённого соединения, чаще всего через 443-й порт Для того, чтобы веб-сервер мог начать работу в таком режиме, необходимо каким-то образом получить SSL сертификаты и указать серверу, где они лежат. Для локальных задач можно использовать самоподписанные сертификаты. Однако, если таким сертификатом пользоваться в интернете, браузер заблокирует показ страниц, закодированных с помощью самоподписанного сертификата. И далеко не каждый пользователь сможет открыть такие страницы. Поэтому возникает задача получения сертификата, подписанного доверенной организацией, известной браузеру. Раньше эта услуга была платной. Теперь с конца 2015 года появилась возможность получить на 90 дней бесплатный криптографический сертификат от открытого Центр Сертификации Let’s Encrypt. Я расскажу, как можно получить и установить такой сертификат у себя на сайте. Веб-сервер — Nginx, ОС — Ubuntu Server 18.04.

При выдаче сертификата выполняется проверка домена. Чтобы такая проверка прошла успешно, необходимо либо создать TXT-запись на DNS-сервере, либо использовать привязанный к этому имени web-сервер. Мы рассмотрим второй случай. Его немного труднее конфигурировать чем первый, зато легко настроить на автоматическое обновление сертификата по прошествии 60 дней.

Итак, пусть наш веб-сервер обслуживает домен example.com. Простейшая конфигурация Nginx будет такой (файл nginx.conf)

server < listen 80; server_name example.com; root /var/nginx/html; >

/var/nginx/html — корень сайта (исправить на свой вариант!). Добавим в этот корень каталог .well-known и допишем в секцию server следующие строки:

location ~ /.well-known < root /var/nginx/html; allow all; >

Проверяем конфигурацию, перезапускаем nginx:

sudo systemctl reload nginx

Устанавливаем пакет letsencrypt. Менеджер пакетов apt подтянет необходимые зависимости:

sudo apt install letsencrypt

Получаем сертификат в первый раз для нашего домена. В общем случае запрос выглядит так:

sudo certbot certonly —webroot —agree-tos —email —webroot-path -d -d .

В нашем случае этот запрос будет таким:

sudo certbot certonly —webroot —agree-tos —email admin@example.com —webroot-path /var/nginx/html/ -d example.com -d www.example.com

После успешного выполнения запроса сертификаты будут созданы в каталоге /etc/letsencrypt/archive/example.com, а также символические ссылки в каталоге /etc/letsencrypt/live/example.com. Именно их и используем в конфигурационных файлах nginx. Публичный ключ будет называться fullchain.pem, приватный — privkey.pem.

Чтобы nginx проходил все тесты на SSLLabs, необходимо сгенерировать новый Diffie-Hellman сертификат:

sudo openssl dhparam -out dh2048.pem 2048

Теперь можно настроить ssl-секцию для nginx:

server < listen 443 ssl http2; listen [::]:443 ssl; server_name example.com; # поменять на свой домен! ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; # поменять на свой домен! ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem; # поменять на свой домен! ssl_session_timeout 1d; ssl_session_cache shared:MozSSL:10m; # about 40000 sessions ssl_session_tickets off; ssl_dhparam /etc/nginx/dh2048.pem; ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384; ssl_prefer_server_ciphers off; ssl_stapling on; ssl_stapling_verify on; >

Проверяем настройки nginx и перезапускаем его:

sudo systemctl reload nginx

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

У меня она выдала /usr/bin/certbot. Эта утилита с параметром renew попытается обновить установленные в системе letsencrypt сертификаты. Если у какого-то из них осталось меньше 30 дней срока действия, произойдет обновление. После обновления необходимо перезапустить nginx. Удобно все эти действия поставить под управление cron-а. Допустим, что мы хотим проверять и если нужно обновлять сертификаты два раза в неделю, в воскресение и среду в 3 часа ночи. Тогда делаем следующее. Открываем для редактирования файл конфигурации cron-а:

и вносим следующую строку

0 3 * * 0,3 /usr/bin/certbot renew && systemctl reload nginx

Установку сертификатов для Nginx можно считать законченной.

Получение SSL-сертификатов с помощью Certbot

Let’s Encrypt — это сервис, который предоставляет бесплатные SSL-сертификаты через автоматизированный API. Самый популярный клиент Let’s Encrypt — Certbot от EFF .

В Certbot существуют разные способы проверки домена, получения сертификатов, автоматической настройки Apache и Nginx. В этом туториале мы рассмотрим автономный режим (standalone mode) Certbot и как с помощью него защитить другие сервисы: почтовый сервер или брокер сообщений (например RabbitMQ).

Мы не будем вникать в детали конфигурации SSL, но по окончании работы у вас будет действующий сертификат, который автоматически обновляется. Вы также сможете автоматизировать перезапуск сервиса для загрузки обновленного сертификата после его апдейта.

Требования

Для выполнения этого мануала вам понадобится:

• Сервер Ubuntu с пользователем sudo и базовой настройкой брандмауэра, это подробно описано в мануале по конфигурации сервера Ubuntu.
• Домен, который указывает на ваш сервер. В этом туториале он будет называться условно your_domain.
• Порт 80 или 443 не должны использоваться на вашем сервере. Если сервис, который вы хотите защитить, находится на машине с веб-сервером и он занимает оба этих порта, вам нужно будет использовать другой режим Certbot, например webroot .

1: Установка Certbot

Устанавливать Certbot рекомендуется с помощью snap-пакета. Пакеты snap совместимы практически со всеми дистрибутивами Linux, но для управления этими пакетами сначала необходимо установить snapd. В Ubuntu он уже есть по умолчанию, поэтому первым делом нужно проверить, что ядро snapd обновлено до последней версии:

sudo snap install core; sudo snap refresh core

Если вы работаете на сервере, на котором стоит старая версия certbot, то ее следует удалить:

sudo apt remove certbot

После этого можно установить пакет certbot:

sudo snap install —classic certbot

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

sudo ln -s /snap/bin/certbot /usr/bin/certbot

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

2: Запуск Certbot

Certbot должен ответить на криптографический вызов от API Let’s Encrypt, чтобы подтвердить, что это наш домен. Для этого он использует порты 80 (HTTP) или 443 (HTTPS). Откройте их в брандмауэре:

sudo ufw allow 80
sudo ufw allow 443

Rule added Rule added (v6)

Чтобы получить сертификат, мы запустим Certbot с опцией –standalone, которая указывает клиенту обработать запрос с помощью встроенного веб-сервера . С помощью флага -d мы задаем домен, для которого запрашивается сертификат. Вы можете добавить несколько опций -d для охвата нескольких доменов в одном сертификате.

sudo certbot certonly —standalone -d your_domain

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

IMPORTANT NOTES: Successfully received certificate. Certificate is saved at: /etc/letsencrypt/live/your_domain/fullchain.pem Key is saved at: /etc/letsencrypt/live/your_domain/privkey.pem This certificate expires on 2022-10-02. These files will be updated when the certificate renews. Certbot has set up a scheduled task to automatically renew this certificate in the background. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - If you like Certbot, please consider supporting our work by: * Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate * Donating to EFF: https://eff.org/donate-le

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

3: Настройка приложения

Мы не будем рассматривать настройку приложения для SSL в этой статье, поскольку каждое приложение имеет разные требования и параметры. Давайте просто посмотрим, что загрузил Certbot. С помощью ls выведем содержимое каталога, в котором хранятся ключи и сертификаты:

sudo ls /etc/letsencrypt/live/your_domain

cert.pem chain.pem fullchain.pem privkey.pem README

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

• privkey.pem: это закрытый ключ сертификата. Он должен храниться в надежном месте, поэтому большая часть каталога /etc/letsencrypt имеет ограниченные разрешения и доступна только пользователю root. Конфигурации большинства программ будут ссылаться на этот файл как на ssl-certificate-key или ssl-certificate-key-file.
• fullchain.pem: это сертификат, объединенный со всеми промежуточными сертификатами. Большинство программ будут использовать этот файл в качестве фактического сертификата и ссылаться на него в своей конфигурации как на ssl-certificate.

Для получения дополнительной информации о других файлах обратитесь к разделу “ Where are my certificates ” в документации Certbot.

Некоторым программам нужны сертификаты в других форматах, местах или с другими правами доступа.

Права доступа в каталоге letsencrypt желательно не менять (они все равно будут перезаписаны при апдейте), но в некоторых случаях изменение этих прав может быть необходимо . Тогда вам нужно написать скрипт, который будет перемещать файлы и менять разрешения по мере необходимости. Этот скрипт нужно будет запускать каждый раз, когда Certbot обновляет сертификаты, об этом мы и поговорим далее.

4: Настройка автоматического продления Certbot

Сертификаты Let’s Encrypt действительны только 90 дней. Это сделано для того, чтобы пользователи автоматизировали процесс обновления своих сертификатов. Установленный нами пакет certbot позаботится об этом за нас, он добавит скрипт апдейта в /etc/cron.d. Этот скрипт запускается дважды в день и обновляет любой сертификат, срок действия которого истекает через 30 дней.

Поскольку сертификаты обновляются автоматически, нужно найти способ запуска других задач после апдейта. Чтобы установить новые сертификаты, нам нужно как минимум перезапустить или перезагрузить сервер и, как мы упоминали в пункте 3, нам может потребоваться изменить файлы сертификатов таким образом, чтобы они работали с нашим программным обеспечением . Для этого в Certbot существует опция renew_hook.

Чтобы добавить renew_hook, мы изменим конфигурационный файл обновления Certbot. Certbot запоминает все детали того, как вы впервые получили сертификат, и будет запускаться с теми же опциями при апдейте. Нам просто нужно добавить hook. Откройте файл с помощью любого редактора:

sudo nano /etc/letsencrypt/renewal/your_domain.conf

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

renew_hook = systemctl reload your_service

Измените приведенную выше команду так, как вам нужно, чтобы перезагрузить сервер или запустить скрипт для обработки файлов. Обычно в Ubuntu для перезагрузки сервиса используется systemctl. Сохраните и закройте файл, затем сделайте тестовый запуск Certbot, чтобы убедиться, что синтаксис в порядке:

sudo certbot renew —dry-run

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

Подводим итоги

В этом туториале мы установили клиент Let’s Encrypt под названием Certbot, загрузили SSL-сертификат в автономном режиме и включили автоматическое обновление с помощью hook-ов. Это даст вам возможность начать использовать сертификаты Let’s Encrypt с другими службами помимо вашего обычного веб-сервера.

Для получения дополнительной информации обратитесь к документации Certbot .

просто блог

Подписаться на RSS

QR CODE для записи

Получение ключей SSL-сертификата Let’s Encrypt через certbot и DNS для шаред-хостинга

В настоящее время существует куча инструкций по получение SSL-сертификата, а многие хостинги предоставляют эти возможности в один клик. Но у меня оказался исключительный случай. ISP не хотела получать сертификат в один клик. Имеющиеся инструкции по получению SSL-сертификата от Let’s Encrypt через файл не работали, потому что на хостинге ограничен доступ к папке well-known/acme-challenge/. Поэтому было необходимо найти решение получения через DNS, ведь это доступно Let’s Encrypt. А ещё с этого года появится возможность получать сертификат для поддоменов по маске, а это доступно будет только через DNS.

Ниже инструкция актуальна для людей с Unix-подобными OS и установленным GIT. Если вы не знаете что такое GIT, то, вероятно, эта статья не для вас.

Внимание! Если у вас будут появляться ошибки
certbot: error: unrecognized arguments: ‑‑manual ‑‑preferred-challenges dns
— удалите дефисы и наберите их вручную. Движок сайт их ломает!

Первым делом надо клонировать себе с GIT пакет certbot, любезно предоставленный EFF. Открываем консоль и вставляем:

git clone https://github.com/certbot/certbot

Далее запускаем его:
./certbot-auto certonly —manual —preferred-challenges dns
certonly — только получение, без установки;
manual — для ручного создания (на самом деле не это значит, но смысл тот же);
dns — указываем, что через DNS записи.

Далее следуем инструкциям certbot’а:

Он попросит указать домены:

Please enter in your domain name(s) (comma and/or space separated) (Enter ‘c’ to cancel):

Are you OK with your IP being logged?
(Y)es/(N)o:

Далее самое главное и мучительное — указать для каждого указанного ранее домена новую текстовую (TXT) запись на своём DNS сервере.

Please deploy a DNS TXT record under the name
_acme-challenge.ВАШ.ДОМЕН with the following value:
УНИКАЛЬНЫЙ КОД
Before continuing, verify the record is deployed.
Press Enter to Continue

У регистратора r01.ru выглядит это так:


После того, как добавите последний домен (считайте!) — не жмите ENTER, необходимо подождать некоторое время, пока новые записи вступят в силу. У регистратора r01 предположительно может занять до 40 минут. Поэтому 1-2 час лучше подождать. И только потом нажать ENTER, иначе можете увидеть вот такую ошибку:

Ничего страшного в этом нет. Только вот после этого вам придётся заново прописывать (редактировать имеющиеся, не надо новые создавать) TXT записи и снова ждать. И, говорят, что количество попыток в сутки/неделю ограничено.

Если вы всё правильно сделали, то вы увидите надпись «Cleaning up challenges». Поздравляю, вы получили сертификат на 3 месяца. На Linux они лежат в папке /etc/letsencrypt/live/ВАШДОМЕН/. Расположение сертификатов должно появиться в консоли.

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

Заходим в папку с правами админа (я делаю это через MC) и видим 4 наших файла. Далее я их вставил в ISP: в поле «SSL-сертификат» текст из cert.pem, в «Ключ SSL-сертификата» — privkey.pem и «Цепочка SSL-сертификатов» — fullchain.pem.

Не забудьте, что сертификат Let’s Encrypt действителен только 4 месяца! После этого его надо продлевать! Дата окончания написана в последних строчках, в случае удачного создания.

UPDATE 1 (02.06.2018)

К сожалению на данный момент продлить аттестат у меня не получилось и я его пересоздаю. Предположительная проблема — динамический IP адрес.

UPDATE 2 (02.06.2018)

Команда, чтобы не вводить домены отдельно
./certbot-auto certonly —manual —preferred-challenges dns -d Ваши,домены,через,запятую

Пожертвовать

1. Евгений 11.08.2022 в 15:11 # link У меня ничего не выходит
2. BaNru 13.08.2022 в 07:50 # link На каком этапе возникает проблема?

Свежие записи

• Заглушка рассылки e-mail для OpenCart (ocStore)
• UltraWide виджет для KDE. Разделение экрана и свои размеры
• 12 причин почему не стоит покупать UltraWide монитор
• Конвертация TSV (CSV) в JSON на PHP
• Самая удобная упаковка…
• LESS: mixin и цикл замены цвета фона, шрифта и svg по массивам
• Рыба-матрёшка или матрёшка-рыба
• Концепция игры буктрис/letris/chartris
• Расширение Aliexpress Improve
• Универсальная лента анонсов для WP без темы через get_posts()

Список рубрик

• Bad Genius (5)
• FlowPlayer (2)
• JavaScript (6)
• jQuery (10)
• jQuery Tools (1)
• WordPress (13)
• Короткой строкой (26)
• Новости (14)
• Разное (52)

Tags

Готовятся к публикации

• jCarouselLite и резиновая верстка
• Скрипт смены стиля пользователем в WP и не только. Часть 2