Как с помощью Letsencrypt и Nginx получить сертификат — один домен с двумя IP адресами?

Question

[localhost]

Есть две A-записи в DNS на example.myapp.com, например, 1.1.1.1 и 2.2.2.2 (то есть балансировка через DNS). К DNS-серверу доступа нет.

Как на обоих серверах получить сертификат для example.myapp.com через letsencrypt? То есть, при вызове на хосте 1.1.1.1:

letsencrypt certonly -a webroot -w /var/www/acme -d example.myapp.com

благодаря балансировке DNS у нас проверяющий бот от letsencrypt может рандомно попасть как на 1.1.1.1, так и на 2.2.2.2, и будет ошибка.

Какие способы решения есть? Я нагуглил про схему с редиректом на одной ноде на другу при обращении на location /.well-known:

return 301 http://node2.myapp.com$request_uri;

чтобы типа бот letsencrypt всегда попадал на вторую ноду для проверки. Я сделал так и у меня ничего не получилось, да и я не пойму логики: ну вот средиректится он на второй хост, а дальше то что? как он создаст там временный файл в /.well-known/acme-challenge/<token> для подтверждения права владения сервером? Так бы получилось если у letsencrypt была возможность не генерировать случайный файл, а использовать какой-нибудь статический файл для подтверждения, который я положу и он проверит на второй ноде, но такого я что-то не нашел, либо плохо смотрел.

Comments

[Валентин]

К DNS-серверу доступа нет.

ну значит нужно его получить и использовать валидацию через TXT запись. Это лучше, чем костылить.

чтобы типа бот letsencrypt всегда попадал на вторую ноду для проверки. Я сделал так и у меня ничего не получилось, да и я не пойму логики: ну вот средиректится он на второй хост, а дальше то что?

Как что? Дальше там в этой директории и будет лежать сгенерированный файл с токеном. Т.е. запускаешь certbot или что там у тебя, он кладет файл куда-то, откуда nginx этот файл отдаст по урлу .well-known/acme-challenge и вуаля. А второй nginx спроксирует запрос до первого, на котором этот файл есть.

Answer 1

[Виктор Таран]

1. Вариант
синхронизируйте папку /var/www/acme между серверами, можно в принципе даже не париться и подмонтировать одну к другой через fstab
2. Вариант в location /.well-known впишите прокси пасс на соседний сервер но поскольку может быть и тут и там, то
не просто прокси а в 404 ошибку, в таком случае вы будите отдавать его локально, если 404 то оттуда .
Или челез upstream.

Comments

[localhost]

Хм, попробую вечером, спасибо за идею

[Виктор Таран]

добавил еще вариант

Answer 2

[Дмитрий Александров]

Все довольно просто.
У вас 2 хоста:
-на первом делаете редирект для acme
-на втором у вас сам acme. И тут же крутится бот certbot . Он по шедулеру запускается когда надо обновить сертификаты и создает тот самый /.well-known/acme-challenge/ , Сторона le идет по ссылке и всегда попадает на этот токен.
Дальше дело техники, удобным вам способом перетащить сертификаты на хост1 и рестаратануть там nginx или других демонов чтобы они подцепили сертификаты.
Сделать это можно прям через хуки бота certbot ,
Скажем такая схема:
-он обновил успешно сертификаты
-сработал post-hook который дернул ваш скрипт.
-в скрипте простенькие команды чтобы перекинуть по scp сертификаты, и после по ssh дать команду на рестарт нужных демонов на хосте1.
-опционально помахать хвостиком и через телеграм отправить админу чтобы спал спокойно, можно еще и с логом.

Comments

[Дмитрий Александров]

Ну и да, монтировать каталоги не лучшая идея, у вас всетаки 2 машинки и это балансировка + резервирование. В случае с подмонтированными каталогами если рухнет один сервер где собственно все лежало то другой тоже встанет.

[localhost]

Тоже вариант. Хочу попробовать еще способ с обработкой 404 ошибки и редиректом/прокси как писали выше в ответе. Тут получается при 404 ошибке (когда DNS пустил LE не на нужную ноду и на ней естественно отсутствует .well-known/acme-challenge/) делать редирект на нужную (то есть на ту на которой запустили получение сертификата). Я пока не могу проверить, но вот думается если на обеих нодах так настроить - будет ли работать получение сертификата нормальное на обеих нодах, то есть напрямую получить серт и не переносить его скриптами потом? Или может быть бесконечный редирект? Пока не могу представить

[Дмитрий Александров]

localhost, немного помозговал и еще один вариант надумал.
Можно поднять еще один очень мелкий сервер чисто для сертификатов. Он чисто будет отвечать за le.
На нем расшариваете по nfs в режиме RO каталог где лежат сертификаты. И на нем же будет крутиться certbot.
На обоих серверах делаете proxy_pass ".well-known/acme-challenge/" на этот сервер с сертификатами чтобы обновления проходили. И на каждом сервере монтируете каталог с сертификатами в режиме только чтение.
Единственное как то без ssh дергать на рестарт nginx на обоих серверах.
В такой ситуации у вас безопасность повыше будет т.к. сервера друг к друга не ходят. Сервер с сертификатами самый дохлый пойдет т.к. нагрузки на него вообще никакой не будет.
Но это все так, размышления.

[localhost]

Дмитрий Александров, Спасибо за Ваш вариант, интересный

К слову, я проверил вариант с 404 ошибкой и последующим редиректом (в location .well-known задан error_page 404 = @testlocation, в этом @testlocation осуществляется редирект на другую ноду) и вроде как все работает с двумя хостами. То есть, я запустил получение сертификата на node1, DNS кинул LE на node2, вместо node1. На node2 сработал редирект на node1 и я получил сертификат на node1. То же самое потом повторил на node2. Если DNS кинет LE на правильный хост, на котором и запрашивали, то просто будет локальное получение, без редиректов. Либо я не вижу косяков данной схемы по неопытности, либо схема рабочая (ну, кроме того что только с двумя хостами она рабочая?)

Answer 3

[ky0]

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

Comments

[localhost]

Да, я знаю про этот способ и хотел бы его использовать, но к DNS нет доступа как я указал.

Answer 4

[Keffer]

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

Comments

[localhost]

Это для меня сейчас не вариант. Я бы вообще мог скопировать сертификат с одной ноды на другую и все. Но задача стоит чтобы работал перевыпуск сертификата например потом. Я подозреваю, что с редиректом схема рабочая, так как нашел несколько комментариев в сети с кратким упоминанием этой схемы, но я не пойму как это сработает :(

[ky0]

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

[Виктор Таран]

Вы отстали от действительностии, LE по факту стандарт.

[Валентин]

Keffer наоборот - лучшее решение сейчас это не покупать убогую байду за деньги, а использовать бесплатный LE. Его ж умные люди делали и именно поэтому там сертификаты не на 10 лет - это плохо, чем короче срок действия сертификата, тем безопаснее всё в целом. Соответственно 1 раз разобравшись с автовыпуском сертификатов получаешь стабильно работающий безопасный вебсервер.

Answer 5

[Роман Данилов]

Для nginx есть плагин, делающий всю низкоуровневую работу по обновлению SSL-сертификатов Letsencrypt за вас. Разве нет?

Comments

[Дмитрий Александров]

Вот только он зачастую не подходит из за особенностей конфигов у каждого админа.