Работа с Let's Crypt на CentOS 7

После перевода официальной документации, можно приступить к непосредственной работе с letsencrypt.

Итак, устанавливаем Let's Crypt на CentOS 7. Для этого нам нужен репозиторий epel. Если он не установлен, выполните, команду:

yum install epel-release

Иначе, сразу ставим нужный пакет:

yum install letsencrypt

Первое, что можно сразу же заметить, что директория /etc/letsencrypt не существует, хотя она явно должна быть:

[root@] rpm -ql letsencrypt
/etc/letsencrypt
...
[root@] ls -d /etc/letsencrypt
ls: невозможно получить доступ к /etc/letsencrypt: Нет такого файла или каталога

Ну... не страшно, определённо необходимо запустить процесс инициализации клиента, чтобы создались ключи, которые будут зарегистрированы в УЦ Let's Crypt.

Для начала рассмотрим основные команды, которые нам предлагаются в описании --help:

  • (default) run - выписать и установить сертификат в ваш текущий веб-сервер;
  • certonly - выписать сертификат, но не устанавливать его (aka "auth");
  • install - установить ранее выписанный сертификат на сервер;
  • renew - обновить ранее выпущенные сертификаты, у которых заканчивается срока действия;
  • revoke - отозвать ранее выпущенный сертификат;
  • rollback - откат изменения конфигурации сервера, выполненного во время установки;
  • config_changes - показать изменения конфигурации сервера, выполненные во время установки;
  • plugins - показать информацию об установленных расширениях.

Теперь можно приступить непосредственно к работе.
Итак, Вариант №1. Сайт уже работает на https другого провайдера, но мы хотим всё сделать через Let's Encrypt и настроить автоматический перевыпуск ключа.

Предположим, мы ещё никогда не запускали letsencrypt. Предположим впереди (frontend) у нас веб-сервер nginx (Нет?.. вы что-то делаете не так ;-) ), который для работы по защищённому протоколу должен иметь, как минимум, следующие строки:

server {
  listen 443 ssl;
  server_name domain.ru;
 
  ssl on;
  ssl_certificate /etc/ssl/certs/domain.ru.crt;
  ssl_certificate_key /etc/ssl/certs/domain.ru.key;
...

Разумеется имя сайта и пути к ключам у вас свои.

Теперь нам надо, чтобы клиент:

  1. Создал пару открытый-закрытый ключи
  2. Зарегистрировал её в УЦ
  3. Сгенерировал и зарегистриировал сертификат

Если мы выполним команду

letsencrypt auth

(аналог certonly) будет запущен интерактивный режим и letsencrypt попытается провести вас по шагам от "регистрации" до получения сертификата. Нам, к сожалению, такой способ не подходит, так как эта команда работает с расширением standalone, которая проверяет работу клиента по 80 и 443 портам (которые уже используются запущенным nginx'ом).
Поэтому запустим генерацию ключа для интересующего нас доменного имени следующей командой:

letsencrypt certonly --webroot --rsa-key-size 4096 --email admin@domain.ru --agree-tos -w /var/www/domain.ru/ -d domain.ru -d www.domain.ru

, где:

  • letsencrypt certonly --webroot - команда на получение сертификата с использованием расширения webroot, т.е. размещение файлов в скрытой директории .well-known/ в корне сайта
  • --rsa-key-size 4096 - устанавливаем размер ключа 4096, так как по умолчанию 2048, что маловато
  • --email admin@domain.ru - указываем почту, на которую, в случае утери, могут быть отправлены действующие сертификаты
  • -w /var/www/domain.ru/ - указываем корневую директорию сайта
  • -d domain.ru -d www.domain.ru - указываем доменное имя и сразу же включаем сразу www., если это необходимо;
  • --agree-tos - автоматически соглашаемся с условиями лицензионного соглашения.

Итого получаем:

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at
   /etc/letsencrypt/live/domain.ru/fullchain.pem. Your cert will
   expire on 2016-05-30. To obtain a new version of the certificate in
   the future, simply run Let's Encrypt again.

Ну вот - ура! У нас есть сертификат. Что следует отметить:

  1. В корневой директории сайта появилась скрытая директория .well-known/. Не сломайте git ;-) ;
  2. Появилась директория /etc/letsencrypt/, в которой хранится информация о ключах, сертификатах и информация по способу автоматического обновления успешного полученного сертификата (конфигурационный файл) в директории renewal;
  3. В директории /etc/letsencrypt/live/domain.ru находятся ссылки на файлы актуальных сертификатов и ключа. Т.е. один раз настроив веб-сервер, больше возвращаться к этому не придётся - клиент автоматически будет пересоздавать ссылки.

Теперь подправим конфигурационный файл nginx:

server {
  listen 443 ssl;
  server_name domain.ru;
 
  ssl on;
  ssl_certificate /etc/letsencrypt/live/domain.ru/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/domain.ru/privkey.pem;
...

Проверка, перезапуск:

nginx -t
systemctl reload nginx

И последнее - нам надо добавить задачу в планировщик задач, чтобы процесс перевыпуска сертификата был полностью автоматическим. Сертификат выдаётся на 3 месяца. Так как в этом примере я создавал сертифкат всего для одного доменного имени (и его синонима), мне нет смысла ставить задачу на проверку окончания срока действия сертификата на каждый день. Думаю, два раза в месяц - достаточно и попозже ночью, на всякий случай. Открывает файл планировщика задач /etc/crontab и добавляем строчку:

0 2 1,15 * * root /usr/bin/letsencrypt renew; systemctl reload nginx

Обратите внимание, что мы так же перезапускаем веб-сервер nginx, чтобы, при изменении ключа, он сразу же подхватил изменённые файлы. Это абсолютно безопасно для установленных соединений.

Кстати, если интересно, что будет, если сейчас сразу запустить процедуру обновления:

letsencrypt renew
Processing /etc/letsencrypt/renewal/domain.ru.conf
 
The following certs are not due for renewal yet:
  /etc/letsencrypt/live/domain.ru/fullchain.pem (skipped)
No renewals were attempted.

Всё, первый вариант разобран.

Вариант №2. Сайт работает на http, необходимо настроить nginx и сгенерировать новые ключи для https соединения.

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

letsencrypt certonly --webroot --rsa-key-size 4096 --email admin@domain.ru --agree-tos -w /var/www/domain.ru/ -d domain.ru -d www.domain.ru

Не буду останавливаться на правильной настройке nginx. Очень рекомендую отличную статью на Хабре. Так сказать, must have, для использования.

После того, как вы настроили и запустили nginx по https протоколу, добавьте задачу в планировщик задач из первого варианта.

Готово.

Вариант №3. Необходим сертификат на сервис, который расположен за nginx'ом, но не имеет своей "корневой директории".

Нуу... вот, возьмём, например, веб-панель администрирования rabbitmq. Nginx перенаправляет все запросы к ней на соответствующий порт 15672. Как же быть в этом случае?

Вспомним, что процесс подтверждения - разовый, с точки зрения самого процесса. То, что он будет автоматически выполнятся с определённой периодичностью - сейчас не интересно. Вспомним также, что у нас есть два варианта подтверждения - через порт 80 или 443 и размещение контента. Порт мы освободить не можем, потому что там уже сейчас висит nginx. Разместить файл не может, потому что передаём все запросы сразу в сервис, минуя файловую систему.

Самый простой вариант, который приходит в голову - создать в конфигурационном файле nginx соответствующий location и направить его на файловую систему. Просто? Задача выполняется? Вроде бы, вполне. Приступим.
Открываем соответствующий конфигурационный файл nginx и добавляем:

location ~ /.well-known/acme-challenge {
  root /var/www/html;
  allow all;
}

,где:

  • location ~ /.well-known/acme-challenge - адрес, по которому обращается УЦ Let's Encrypt, для проверки доменного имени. Обратите внимание, что стоит "~", что означает "регулярное выражение без учёта регистра. Это не обязательно, но полезно, если у вас есть другие регулярные выражения (например, запрет отдавать любые скрытые объекты), которые могут перекрыть это правило. И, конечно же, правило для letsencrypt должно стоять первым, так как nginx обрабатывает их по порядку (сначала по порядку "регулярные", потом остальные);
  • root /var/www/html - корневая папка, в которой будет создан файл для проверки (после проверки файл удаляется, остаётся только директория .well-known/acme-challenge);
  • allow all - разрешить для всех. Опять же может быть полезно, если вы закрываете по каким-либо причинам каким-либо способов свой сайт или его часть.

Проверка, перезапуск:

nginx -t
systemctl reload nginx

Запускаем генерацию ключа:

letsencrypt certonly --webroot --rsa-key-size 4096 --email admin@domain.ru --agree-tos -w /var/www/html/ -d rabbit.domain.ru -d www.rabbit.domain.ru

Не забываем добавить правило в планировщик задач.

Итого:
Разумеется, вариантов может быть сколь угодно много.
Если у вас совсем ничего не установлено, наверное, лучше всё же начать с установки LAMP и после вернуться к варианту №2.
Многие проблемы можно решить с помощью варианта №3.
Ну, а в скором времени обещают расширить и функционал самого ПО.

Как обычно - всем успехов!

Добавить комментарий

CAPTCHA
Этот вопрос задается для того, чтобы выяснить, являетесь ли Вы человеком или представляете из себя автоматическую спам-рассылку.
Target Image