Настройка Reverse Proxy Apache (Debian 8) с автоматической выдачей Let's Encrypt

[foxyovovich]

Советую попробовать haproxy. Как раз для этих целей

[SAMbI4]

Спасибо, посмотрю

[Faight]

Почему не nginx в качестве прокси? Он легче и удобнее апача в этой роли. К тому же, если что-то пойдет не так, сервис не упадет после nginx reload.

Как я понял, на время выпуска сертификата certbot останавливает апач и запускает свой сервис для подтверждения сертификата — не очень удобно. Как быть, если за проксей несколько сайтов, certbot сам для них выпустит сертификаты?

У себя использую сервис продления в отдельном докер контейнере, как в этом примере — http://www.automationlogic.com/using-lets-encrypt-and-docker-for-automatic-ssl/
очень удобно.

[kilgur]

certbot --renew перевыпускает (при необходимости) все сертификаты, выданные текущему хосту.
Чтобы не останавливать текущий веб-сервер, можно использовать режим webroot с указанием каталога, который должен обслуживать (по http) веб-сервер самостоятельно.

[SAMbI4]

Так исторически сложилось с Apache.
По поводу certbot Вам ответили ниже.

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

[Jedi-Knight]

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

[YourChief]

вот это вообще не в кассу было

[selivanov_pavel]

cp /root/certbot/certbot /usr/lib/python2.7/dist-packages/

Почему бы тогда не воспользоваться pip install? Обновление пакета certbot перезатрёт ваши локальные изменения

[SAMbI4]

так это ведь хорошо! особенно если в репозитарии появиться новая версия.
проблема в том, что в репо версия 0.10.2, а на гите уже 0.16.0, собственно как обычно

[selivanov_pavel]

В репозитории появится какая-нибудь 0.10.2~ubuntu1, в которой исправили опечатку, и она затрёт вашу 0.16.0.
Не стоит заставлять разные каналы получения софта писать в один каталог.

[Jedi-Knight]

хммм… а зачем крон пытается запустить обновление сертификатов каждый понедельник в 2:30?)))
я может не туда смотрю, но если необходимо запускать крон каждые 3 месяца, то это
* * * */3 * certbot renew

[grossws]

Лучше запускать раз в месяц или чаще, он обновляет только те сертификаты, которые истекают скоро.

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

[wrewolf]

Мы пришли к режиму, пусть пробует обновится раз в день.
Сами летсенкритпы обещали в итого время жизни до 1 месяца уменьшить

[grossws]

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

[SAMbI4]

а вот это мысль! пойду реализую!

[Jedi-Knight]

ага. ну… тогда наверняка его можно раз в 20 минут запускать

[wrewolf]

Я только не понял про certbot. С официального сайта предлагается скачать только 1 питон скрипт, зачем тянуть весь репозиторий?
И сам certbot отвечает только за обновление и запуск скриптов работы с сертификатами.

[SAMbI4]

Так ведь никто и не спорит, но если вы загуглите ошибку

ERROR:letsencrypt_apache.configurator:No vhost exists with servername or alias of: sambi4.ru. No vhost was selected. Please specify servernames in the Apache config

то увидите, что проблема кроется как раз в .py скриптах, кои мы и заменили.

[Dorlas]

В статье был упомянут MS TMG — но тема его замены на Apache/Nginx Reverse Proxy не раскрыта.

Если кратко — MS TMG умел и умеет публиковать WEB-сервисы, авторизация в которых родная от Microsoft (Kerberos/NTLMv2 — т.е. Windows Integrated). Это всякие Exchange (с пачкой разных служб), SharePoint, Lync/Skype for Business и т.д. Собственно у многих Заказчиков оно стоит до сих пор, публикуя ресурсы. При этом как правило на TMG один единственный белый IP-адрес.

И основная проблема перехода с TMG на другой Reverse (Apache/Nginx и т.д.) в том, что мало кто умеет Kerberos/NTLM из коробки. Буду очень рад, если кто-то кинет пруфом, если ситуация тут меняется со временем.

Пока единственная адекватная замена именно функции Reverse — это использование MS IIS + компонента ARR (Application Request Routing)… что автоматом требует Windows. Работает, не спорю. Но хочется адекватной альтернативы и других вариантов (причем OpenSource).

[SAMbI4]

Я с Вами согласен и на одной из площадок под S4b поднимал TMG специально, ибо без Reverse Proxy он вообще не работает, а на IIS мне не нравить.
Ну и вообще, TMG как продукт Microsoft является лучшим решение в работе в сетях Microsoft. Жаль что мелкомягкие сняли с поддержки, ведь за продуктом было большое будущее.

Ну как реализованно на другой инфраструктуре, стоит на границе TMG, на нем публикации Exchange, VPN, и прочее.
Проброс 80,443 до Apache Reverse, на котором публикуются сайты компании и работает certbot.
Я-бы с удовольствием ушел с Apache и остался на TMG, но certbot под windows — это выше моего понимания (бзик такой, ага), вот и приходиться изворачиваться.

Я так и не нашел альтернативы, куда уйти с TMG, либо дорого, либо не подходит.

[kvaps]

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

[SAMbI4]

всегда во всем можно разобраться, вопрос только цены :)