Меню Рубрики

Установка корневого сертификата debian

Вики IT-KB

Пошаговые руководства, шпаргалки, полезные ссылки.

Инструменты пользователя

Инструменты сайта

Боковая панель

Добавление в Linux корневых сертификатов X.509 локального корпоративного Центра сертификации

Некоторые службы и приложения в Linux могут использовать в своей работе сетевые соединения, защищаемые с помощью SSL/TLS. Иногда требуется, чтобы цифровой сертификат, используемый для защиты соединений и предоставляемый каким-то удалённым сервером из локальной сети, принимался локальной Linux-системой как доверенный. Для этого в Linux-систему может потребоваться добавить корневой сертификат Центра сертификации (ЦС), которым были выданы сертификаты, используемые для защиты соединений. Типичный пример, когда локальная Linux-система для механизмов аутентификации и авторизации подключается с помощью ldap-клиента (например OpenLDAP) к контроллеру домена Active Directory (AD) и контроллер домена предоставляет ldap-клиенту для защиты соединения сертификат, выданным локальным корпоративным ЦС.

Здесь мы рассмотрим простой пример того, как в Linux-систему добавить корневые сертификаты локального корпоративного ЦС.

О том, как «выуживать» корневые сертификаты ЦС, которыми подписаны сертификаты контроллеров домена AD, я приводил пример ранее. Если под руками есть доменная Windows-машина, то можно выгрузить корневой сертификат из оснастки управления сертификатами из раздела корневых сертификатов доверенных ЦС. Если корневой сертификат не один, а несколько (цепочка), то каждый корневой сертификат цепочки выгрузим в файл в кодировке Base-64, сразу присвоив им расширение PEM вместо CER

В результате такой выгрузки в нашем примере получится пара файлов AD-RootCA.pem (корневой сертификат ЦС верхнего уровня) и AD-SubCA.pem (корневой сертификат подчинённого ЦС). Скопируем полученные pem-файлы на наш Linux-сервер, например с помощью утилиты pscp, во временный каталог.

Перейдём на консоль Linux-сервера и переместим файлы коневых сертификатов из временного каталога в каталог, который мы создадим специально для хранения наших корневых сертификатов и подправим на эти сертификаты права (если требуется)

Теперь обработаем содержимое каталога с нашими сертификатами утилитой OpenSSLc_rehash:

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

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

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

В качестве примера рассмотрим клиента OpenLDAP, для которого можно указать созданный нами каталог в конфигурационном файле ldap.conf ( /etc/ldap/ldap.conf ) в дополнительной опции TLS_CACERTDIR, таким образом, чтобы эта опция шла после имеющейся по умолчанию опции TLS_CACERT (подробнее об этих опциях можно найти в man ldap.conf ):

Примечание.
В Debian GNU/Linux параметр TLS_CACERTDIR может игнорироваться, о чём сказано в man ldap.conf .

Specifies the path of a directory that contains Certificate Authority certificates in separate individual files. The TLS_CACERT is always used before TLS_CACERTDIR. This parameter is ignored with GnuTLS. On Debian openldap is linked against GnuTLS…

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

Собрать все нужные доверенные корневые сертификаты Центров сертификации в бандл можно простой склейкой содерживого PAM-файлов в колировке Base-64:

Соответственно, применительно к ранее упомянутому клиенту OpenLDAP в Debian GNU/Linux настройка конфигурации будет такой:

Автор первичной редакции:
Алексей Максимов
Время публикации: 25.03.2017 17:36

Обсуждение

Пытаюсь проделать такие же операции на CentOS, но нет такой команды «c_rehash»:

источник

Information Security Squad

🧡 Как установить сертификаты CA на сервере Ubuntu

Возникли проблемы с установкой и распознаванием сертификатов CA на Ubuntu сервере?

Узнайте, как это делается с помощью нескольких быстрых команд.

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

Для тех, кому поручено управление сертификатами CA, вы знаете, насколько это сложно.

Надеюсь, мы сможем успокоить ваш разум (и нервы).

Почему? Потому что управление этими сертификатами на Ubuntu Server не должно быть таким уж сложным.

Давайте сделаем это простым способом.

Я собираюсь продемонстрировать, как установить сертификаты корневого CA на Ubuntu Server 18.04.

Для тех, кто не уверен о чем речь, корневым сертификатом является тот, который был подписан доверенным центром сертификации (например, приобретенным у подобных Globalsign).

У вас могут быть приложения или службы, установленные на сервере Ubuntu, для правильной работы которых требуются авторизованные SSL-соединения.

Такие приложения, как Apache, зависят от CA для обслуживания HTTPS-соединений.

Как только у вас есть CA (и он распознан), вы можете настроить эти приложения и службы на использование файлов сертификатов.

Что вам нужно

Чтобы это работало, вам нужно следующее:

  • Запущенный Ubuntu Server 18.04.
  • Корневой сертификат, приобретенный у доверенного CA
  • Учетная запись пользователя с привилегиями sudo.

Со всем этим наготове, пришло время для установки.

Установка

Первое, что нужно сделать, это установить пакет ca-Certificates, инструмент, который позволяет приложениям на основе SSL проверять подлинность соединений SSL.

Чтобы установить это программное обеспечение, откройте окно терминала и введите команду:

Копирование файлов

Затем нам нужно скопировать этот купленный файл .cer или .crt в нужное место.

Начиная работать с этим файлом сертификата на сервере Ubuntu скопируйте его в нужный каталог с помощью команды:

Где CERTIFICATE — это имя файла CA, который нужно скопировать.

Конвертирование из PEM

Если ваш сертификат представляет собой файл PEM, он должен быть сначала преобразован в формат .crt.

Для этого вы должны использовать команду openssl следующим образом:

Где CERTIFICATE — это имя вашего файла сертификата.

После преобразования файла PEM в формат .crt его можно скопировать в нужный каталог (как показано выше).

Обновите свой сертификат

Последний шаг — обновить ваши сертификаты.

С помощью одной команды вы можете обновить сертификаты и сгенерировать файл ca-certificate.crt (который представляет собой объединенный список всех установленных сертификатов).

И это все, что нужно сделать.

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

источник

Сертификаты

Содержание

Сертификаты

Одной из наиболее распространенных форм криптографии сегодня является криптография на открытых ключах. Криптография на открытых ключах использует открытый (public) и закрытый (secret) ключи. Система выполняет шифрование с использованием открытого ключа. Расшифрована такая информация может быть только с использованием закрытого ключа.

Сертификат — это метод, используемый для распространения открытого ключа и другой информации о сервере и организации, ответственной за него. Сертификаты могут иметь цифровую подпись, сделанную Центром сертификации или CA. CA — это третья сторона, которая подтверждает, что информация, содержащаяся в сертификате, верна.

Типы сертификатов

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

Читайте также:  Установка usb для ccc bmw

Продолжая пример с HTTPS, сертификат, подписанный CA, предоставляет два важных свойства в отличие от самоподписанного сертификата:

Браузеры (обычно) автоматически распознают такой сертификат и позволяют устанавливать защищенные соединения без предупреждения пользователя.

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

Процесс получения сертификата из CA довольно прост. Короткий обзор его приведен ниже:

Создайте пару из открытого и закрытого ключей.

Создайте запрос на сертификат на основе открытого ключа. Запрос на сертификат содержит информацию о вашем сервере и управляющей им компании.

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

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

Установите это сертификат на ваш защищенный сервер и настройте соответствующие приложения на его использование.

Создание запроса на подпись сертификата (CSR)

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

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

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

Для генерации ключей CSR запроса, запустите следующую команду из терминала:

Теперь вы можете ввести вашу кодовую фразу. Для лучшей безопасности рекомендуется использовать не менее восьми символов. Минимальная длина при использовании -des3 — 4 символа. Фраза должна включать цифры и/или знаки препинания и не должно быть словом из словаря. Также не забывайте, что ваша фраза будет чувствительна к регистру.

Повторите ввод для проверки. В случае корректного ввода ключ сервера будет создан и записан в файл server.key.

Теперь создадим небезопасный ключ, без кодовой фразы и поменяем имена ключей:

Небезопасный ключ теперь называется server.key и вы можете использовать его для создания CSR без кодовой фразы.

Для создания CSR выполните следующую команду в терминале:

У вас будет запрошена кодовая фраза (при использовании ключа с паролем — прим. пер.). Если введена корректная фраза, у вас запросят название компании, имя сайта, email и пр. Как только вы введете все эти подробности, будет создан запрос CSR и сохранен в файл server.csr.

Теперь вы можете оправить CSR файл в центр сертификации для обработки. CA использует этот файл для выпуска сертификата. С другой стороны, вы можете создать и самозаверенный сертификат, используя этот же CSR.

Создание самоподписанного сертификата

Для создания самоподписанного сертификата, запустите следующую команду в терминале:

Эта команда попросит вас ввести кодовую фразу. Как только вы введете корректную фразу, ваш сертификат будет создан и сохранен в файл server.crt.

Установка сертификата

Вы можете установить файлы ключа server.key и сертификата server.crt (или файл сертификата, выданный вашим CA), запуском следующих команд в терминале:

Теперь просто настройте любое приложение с возможностью использования криптографии на открытых ключах для использования этих файлов ключа и сертификата. Например, Apache может предоставить HTTPS, Dovecot предоставляет IMAPS и POP3S, и т.д.

Центр сертификации

Если сервисы вашей сети требуют больше чем самозаверенные сертификаты, может быть полезным дополнительное усилие по установке вашего собственного внутреннего центра сертификации (CA). Использование сертификатов, подписанных вашим центром, позволяют различным сервисам использовать сертификаты для простого доверия другим сервисам, использующих сертификаты, выданные тем же CA.

1. Сначала создайте каталоги для хранения сертификата CA и необходимых файлов:

2. Центр сертификации требует несколько дополнительных файлов для своей работы; один для хранения последнего серийного номера, использованного CA, другой для записи какие сертификаты были выпущены:

3. Третий файл — это файл настроек CA. Хотя он не строго обязателен, но очень удобен для выпуска множества сертификатов. Отредактируйте /etc/ssl/openssl.cnf, изменив секцию [ CA_default ]:

4. Далее создайте самоподписанный сертификат:

Вам будут заданы вопросы по деталям сертификата.

5. Теперь установим корневой сертификат и ключ:

6. Теперь вы готовы приступить к выпуску сертификатов. Первое, что вам потребуется — запрос на сертификат (CSR). Смотрите детали в разделе Создание запроса на подпись сертификата (CSR). Получив CSR, введите следующую команду для создания сертификата, подписанного нашим центром:

После ввода пароля для ключа CA у вас запросят подтверждение на подпись сертификата и еще одно на сохранение нового сертификата. Затем вы сможете увидеть нечто с объемным выводом, относящееся к созданию сертификата.

7. Теперь у вас должен появиться новый файл /etc/ssl/newcerts/01.pem, с таким же содержанием, что и в предыдущем выводе. Выделите и скопируйте все, начиная со строки ——BEGIN CERTIFICATE—— и до строки ——END CERTIFICATE—— в файл с названием по сетевому имени сервера, где он будет установлен. Например, mail.example.com.crt — вполне хорошее описательное имя.

Последующие сертификаты будут иметь имена 02.pem, 03.pem и т.д.

8. Наконец, скопируйте новый сертификат на компьютер, для которого он выпущен, и настройте соответствующие приложения на его использование. Место по умолчанию для установки сертификатов — каталог /etc/ssl/certs. Это позволяет многим сервисам использовать один и тот же сертификат без чрезмерного усложнения прав доступа к файлу.

Для приложений, которые могут быть настроены на использование сертификата CA, вы можете скопировать файл /etc/ssl/certs/cacert.pem в каталог /etc/ssl/certs/ на каждом сервере.

Ссылки

Для более детальных инструкций по использованию криптографии смотрите SSL Certificates HOWTO на tlpd.org.

Страница Википедии HTTPS содержит больше относительно HTTPS.

Для дополнительной информации по OpenSSL смотрите домашнюю страницу OpenSSL.

Также хорошее глубокое руководство Network Security with OpenSSL от O’Reilly.

источник

1С и Linux

Пишу для себя, чтобы не забыть как делал. 95 % рабочее. На комментарии отвечаю, когда увижу.

пятница, 14 декабря 2018 г.

Установка сертификатов используя КриптоПРО в Linux

Для установки в uRoot админиских прав больше не нужно. Ради этого их с mRoot и разделили. Работает так: если ставить в uRoot — видно будет только текущему пользователю, даже если он root, но права не нужны и будет диалог с предупреждением. Если ставить в mRoot, то нужны права, видно будет всем и предупреждения не будет.

Установка корневого сертификата удостоверяющего центра:
$ /opt/cprocsp/bin/amd64/certmgr -inst -cert -file

/Загрузки/ .cer -store uRoot
$ /opt/cprocsp/bin/amd64/certmgr -inst -cert -file

/Загрузки/guts_2012.cer -store uRoot

Просмотор корневых сертификатов:
$ /opt/cprocsp/bin/amd64/certmgr -list -store uRoot

Удалить:
$ /opt/cprocsp/bin/amd64/certmgr -delete -store uRoot
$ /opt/cprocsp/bin/amd64/certmgr -delete -all -store uRoot

Установка списка отозванных сертификатов:
$ /opt/cprocsp/bin/amd64/certmgr -inst -crl -file

Установка цепочки промежуточных сертификатов:
$ /opt/cprocsp/bin/amd64/certmgr -inst -cert -file

$ /opt/cprocsp/bin/amd64/certmgr -inst -cert -file

/Загрузки/fk_2012.cer -store uca

Просмотор промежуточных сертификатов:
$ /opt/cprocsp/bin/amd64/certmgr -list -store uca

Удалить:
$ /opt/cprocsp/bin/amd64/certmgr -delete -store uca

Установка сертификата с рутокена:
$ /opt/cprocsp/bin/amd64/certmgr -inst -cont ‘ ‘ -store uMy

Установка сертификата из контейнера:
$ /opt/cprocsp/bin/amd64/certmgr -inst -store uMy -cont ‘\\.\HDIMAGE\test’

Просмотор личных сертификатов:
$ /opt/cprocsp/bin/amd64/certmgr -list -store uMy

Просмотр контейнеров, рутокенов
$ /opt/cprocsp/bin/amd64/csptest -keyset -enum -verifycontext -fqcn

Читайте также:  Установка имплантата alpha dent

Экспорт в файл сертификата из хранилища
$ /opt/cprocsp/bin/amd64/certmgr -export -cert -dn «CN=» -dest ‘cert.crt’
$ /opt/cprocsp/bin/amd64/cryptcp -copycert -dn CN=’Фёдорова Галина Борисовна’ -df

$ CP_PRINT_CHAIN_DETAIL=1 /opt/cprocsp/bin/amd64/cryptcp -copycert -dn CN=’Фёдорова Галина Борисовна’ -df

$ CP_PRINT_CHAIN_DETAIL=1 /opt/cprocsp/bin/amd64/cryptcp -copycert -dn CN=’Фёдорова Галина Борисовна’ -df

$ /opt/cprocsp/bin/amd64/cryptcp -verify -f cert.crt cert.txt
$ /opt/cprocsp/bin/amd64/cryptcp -verify -u

/cert.txt
$ /opt/cprocsp/bin/amd64/cryptcp -verify -u

/cert.txt | iconv -f cp1251
$ /opt/cprocsp/bin/amd64/cryptcp -verify -errchain -f

Установка сертификатов zakupki.gov.ru

$ /opt/cprocsp/bin/amd64/certmgr -inst -cert -file ‘Сертификат Головного удостоверяющего центра.cer’ -store uRoot
$ /opt/cprocsp/bin/amd64/certmgr -inst -cert -file ‘Сертификат Удостоверяющего центра Федерального казначейства.cer’ -store uRoot

$ /opt/cprocsp/bin/amd64/certmgr -inst -cert -file root2013.cer -store uRoot

$ CP_PRINT_CHAIN_DETAIL=1 /opt/cprocsp/bin/amd64/cryptcp -copycert -dn CN=’Фёдорова Галина Борисовна’ -df

источник

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

источник