Коллеги, а кто как решает вопрос с централизованным получением и раздачей бесплатных сертификатов от Let's Encrypt внутри инфраструктуры? Например, у вас есть веб сервер, который принимает все HTTP запросы, а внутри инфраструктуры есть какой-нибудь почтовый сервер, которому тоже нужен сертификат. Либо это может быть внутренний сервис вообще без доступа в интернет, но ему тоже хочется дать валидный сертификат, чтобы браузеры не ругались. Да и просто удобно управлять всем этим делом из одного места.
Я обычно использую 2 разных способа.
1️⃣ Настраиваю получение сертификатов на одном сервере. Всем, кому нужны сертификаты, подключаю директорию /etc/letsencrypt по nfs. В целом, нормальный вариант, но бывают проблемы, когда инфраструктуру погасят, а потом запустят. Сервис может подняться раньше, чем загрузится виртуалка с сертификатами. Тогда будет ошибка и надо будет вручную сходить и разобраться с проблемой.
2️⃣ Конечные сервера регулярно с помощью rsync синхронизируют директорию со своим сертификатом. Тут немного больше хлопот, так как надо скрипты в cron класть и следить за ними, чтобы всё ок было.
В обоих случаях надо следить на конечном сервере за обновлением сертификатов и перезапускать службы, которые их используют. Это реализуется с помощью incron. Когда служба видит изменение файла, выполняет перезапуск сервиса.
В голову приходит и третий вариант. Настроить с веб сервера, где обновляются сертификаты, доступ по ssh к целевым серверам. Через хук letsencrypt после обновления сертификата копировать его на сервер и перезапускать там службу. По идее, тут будет проще всего настройка, плюс она полностью централизована, но мне кажется это небезопасно. На всякий случай я так не делаю.
А вы как решаете эту задачу? Она вообще для кого-то актуальна или я её сам себе придумал? Частенько приходится с этим разбираться. Сейчас сертификаты везде нужны.
#letsencrypt
Я обычно использую 2 разных способа.
1️⃣ Настраиваю получение сертификатов на одном сервере. Всем, кому нужны сертификаты, подключаю директорию /etc/letsencrypt по nfs. В целом, нормальный вариант, но бывают проблемы, когда инфраструктуру погасят, а потом запустят. Сервис может подняться раньше, чем загрузится виртуалка с сертификатами. Тогда будет ошибка и надо будет вручную сходить и разобраться с проблемой.
2️⃣ Конечные сервера регулярно с помощью rsync синхронизируют директорию со своим сертификатом. Тут немного больше хлопот, так как надо скрипты в cron класть и следить за ними, чтобы всё ок было.
В обоих случаях надо следить на конечном сервере за обновлением сертификатов и перезапускать службы, которые их используют. Это реализуется с помощью incron. Когда служба видит изменение файла, выполняет перезапуск сервиса.
В голову приходит и третий вариант. Настроить с веб сервера, где обновляются сертификаты, доступ по ssh к целевым серверам. Через хук letsencrypt после обновления сертификата копировать его на сервер и перезапускать там службу. По идее, тут будет проще всего настройка, плюс она полностью централизована, но мне кажется это небезопасно. На всякий случай я так не делаю.
А вы как решаете эту задачу? Она вообще для кого-то актуальна или я её сам себе придумал? Частенько приходится с этим разбираться. Сейчас сертификаты везде нужны.
#letsencrypt
👍40👎2
Недавно затрагивал тему централизованного управления сертификатами Lets's Encrypt. Получил в TG много советов, всем спасибо за них. В VK предложили необычный вариант - хранить серты в GIT. Идея отличная, а мне даже в голову не приходила. Ведь действительно удобно. Я пока сам ещё не пробовал, но общая концепция в голове сложилась.
1️⃣ Получаем новый сертификат, хуком его отправляем в репозиторий. Можно сразу сделать скрипт, который будет создавать готовую цепочку сертификатов в зависимости от софта, который будет использовать сертификат. Postfix и Dovecot, к примеру, хотят готовую цепочку. Думаю, удобно будет под каждый домен свою ветку держать.
2️⃣ На целевом сервере создаём локальный репозиторий и копируем туда содержимое ветки с актуальными сертификатами.
3️⃣ С помощью git fetch и сравнения $(git rev-parse HEAD) с $(git rev-parse @{upstream}) проверяем наличие новых коммитов в нужной ветке репозитория. Если есть обновление, делаем git pull и запускаем какой-то скрипт, который скопирует новый сертификат в заданное место и выполнит необходимые действия для того, чтобы софт применил новый сертификат.
Это пример последовательности действий для ручной настройки на нескольких серверах. Если у вас есть какая-то система для CI/CD, можно то же самое через неё реализовать. Сертификаты можно хранить не в GIT, а в каком-то хранилище секретов. У меня нет опыта работы с ними, так что конечную реализацию не представляю, но смысл там будет тот же.
Если придётся где-то настраивать подобное, реализую такую схему.
#letsencrypt #devops
1️⃣ Получаем новый сертификат, хуком его отправляем в репозиторий. Можно сразу сделать скрипт, который будет создавать готовую цепочку сертификатов в зависимости от софта, который будет использовать сертификат. Postfix и Dovecot, к примеру, хотят готовую цепочку. Думаю, удобно будет под каждый домен свою ветку держать.
2️⃣ На целевом сервере создаём локальный репозиторий и копируем туда содержимое ветки с актуальными сертификатами.
3️⃣ С помощью git fetch и сравнения $(git rev-parse HEAD) с $(git rev-parse @{upstream}) проверяем наличие новых коммитов в нужной ветке репозитория. Если есть обновление, делаем git pull и запускаем какой-то скрипт, который скопирует новый сертификат в заданное место и выполнит необходимые действия для того, чтобы софт применил новый сертификат.
Это пример последовательности действий для ручной настройки на нескольких серверах. Если у вас есть какая-то система для CI/CD, можно то же самое через неё реализовать. Сертификаты можно хранить не в GIT, а в каком-то хранилище секретов. У меня нет опыта работы с ними, так что конечную реализацию не представляю, но смысл там будет тот же.
Если придётся где-то настраивать подобное, реализую такую схему.
#letsencrypt #devops
👍59👎4