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

Так как зачастую, сайтов в организации много, а IP адресов мало, нужно иметь решение с Reverse Proxy. Для моих целей раньше всегда выступал Microsoft TMG, но у него есть свои недостатки, как и плюсы. Один из основных минусов, это то что на TMG нужно подгружать сертификаты публикуемого ресурса, что с Let's Encrypt довольно неудобно, ввиду обновления сертификатов каждые 90 дней.

Решение было найдено: поднять Reverse Proxy на Apache и сделать так, чтобы работала автовыдача сертификатов Let's Encrypt. А после чего спокойно публиковать его на Firewall, при этом порты буду перенаправляться с http на https.

За основу берем что у нас стоит чистый Debian GNU/Linux 8 (jessie). Подробнее под катом.

Ну что-ж, поехали.

aptitude install -y build-essential
aptitude install -y libapache2-mod-proxy-html libxml2-dev
aptitude install -y apache2

После чего активируем следующие модули:

a2enmod proxy
a2enmod proxy_http
a2enmod proxy_ajp
a2enmod rewrite
a2enmod deflate
a2enmod headers
a2enmod proxy_balancer
a2enmod proxy_html
a2enmod proxy_ftp
a2enmod proxy_connect
a2enmod ssl

и рестартуем Apache:

service apache2 restart

Тут нас поджидает первая неудача, Apach'у для правильной работы не хватает модуля mod_xml2enc, НО! в Jessie этот модуль не работает, нам последовательно нужно внести следующие команды:

aptitude install apache2-prefork-dev libxml2 libxml2-dev apache2-dev
mkdir ~/modbuild/ && cd ~/modbuild/
wget http://apache.webthing.com/svn/apache/filters/mod_xml2enc.c
wget http://apache.webthing.com/svn/apache/filters/mod_xml2enc.h
apxs2 -aic -I/usr/include/libxml2 ./mod_xml2enc.c
cd ~
rm -rfd ~/modbuild/
service apache2 restart

После чего, все у нас хорошо, модуль стоит. Едем дальше )

Так как мы хотим опубликовать HTTPS сайт, до того момента пока мы не установим Let's Encrypt, нам нужно сделать самоподписанный сертификат для нашего сайта, вводим комманду:

mkdir /etc/apache2/ssl
cd /etc/apache2/ssl
openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout server.key -out server.crt

Нам нужно создать файл конфигурации и назвать его понятным именем:

touch /etc/apache2/sites-available/sambi4.conf

И задаем файлу примерно такое содержание:

<VirtualHost *:80>
ServerName sambi4.ru
Redirect permanent / https://sambi4.ru/ #отвечает за перенаправление на https
</VirtualHost>

<VirtualHost *:443>
SSLEngine On
SSLProxyEngine On
ProxyRequests Off
ProxyPreserveHost On
ProxyVia full

SSLCertificateFile /etc/apache2/ssl/server.crt #указываем путь к нашему самоподписанному сертификату
SSLCertificateKeyFile /etc/apache2/ssl/server.key #указываем путь к нашему самоподписанному ключу сертификата

ProxyHTMLInterp On
ProxyHTMLExtended On

<proxy *>
Order deny,allow
Allow from all
</proxy>

ProxyPass / https://192.168.199.78/ #IP адрес публикуемого ресурса.
ProxyPassReverse / https://192.168.199.78/ #IP адрес публикуемого ресурса.
ServerName sambi4.ru
ServerAdmin sambi4@sambi4.ru #считается хорошим тоном указывать email админа
DocumentRoot "/var/www/html" #эта строка нужна для того чтобы апач запустился, без нее он не сможет опубликовать ваш ресурс.
</VirtualHost>

После завершения создания, не забываем включить наш сайт:

a2ensite /etc/apache2/sites-available/sambi4.conf

перезапускаем Apache:

service apache2 restart

После всех проделанных процедур, мы имеем настроеный Reverse Proxy на Apache2, теперь можно приступить к настройке Let's Encrypt:

Из всех бесплатных сертификатов, жив остался только Let's Encrypt, но его особенность в том, что сертификат выдается сроком на 3 месяца.

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

echo 'deb http://ftp.debian.org/debian jessie-backports main' | tee /etc/apt/sources.list.d/backports.list

после:

aptitude update

ну а теперь ставим сам Let's Encrypt:

aptitude install -y python-certbot-apache -t jessie-backports

Дожидаемся процесса установки, и пробуем выпустить сертификат:

certbot --apache

И вот тут нас поджидает неудача:
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

Связано это с тем, что в репозитариях до сих пор старая версия (на момент написания 0.10.2), в которой наблюдаются ошибки. А именно ошибки в python-скриптах. Решение как обычно просто:
Качаем свежую версию certbot:

git clone https://github.com/certbot/certbot.git

После чего, идем по пути:

 cd /usr/lib/python2.7/dist-packages

Удаляем папки (а лучше делаем бэкап):

acme
certbot
certbot_apache
И копируем файлы из нового релиза:

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

Теперь можно со спокойной душой запускать процесс выпуска сертификата:

certbot --apache

Отвечаем на вопросы и все!

Поздравляю, сертификат мы выпустили, теперь нужно добавить скрипт автопродления сертификата, т.к. Let's Encrypt выдает сертификаты сроком только на 90 дней (мы об этом помним).

Все просто. Нам в cron нужно добавить строчку:

30 2 * * 1 /usr/bin/certbot renew >> /var/log/le-renew.log

Т.е. набираем:

crontab -e

И добавляем нашу строку (обязательно перейти на следующую срочку, иначе не сохранится)

И все, повторить бесконечное множество раз с Вашими другими ресурсами.

Удачи, админы!
Share post
AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 22

    0
    Советую попробовать haproxy. Как раз для этих целей
      0
      Спасибо, посмотрю
      +2
      Почему не nginx в качестве прокси? Он легче и удобнее апача в этой роли. К тому же, если что-то пойдет не так, сервис не упадет после nginx reload.

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

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

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

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

          У меня к счастью, нет высоконагруженных серверов, поэтому можно продлевать не боясь что какой-то сервис упадет, более того, пару не хитрых манипуляций с cron, и задача будет стартовать по ночам, когда нагрузки практически нет. Ну и статья в общем и целом расчитана на не большие нагрузки.
            –3
            то, что у Вас нет высоконагруженных серверов, я понял из того, что вы дебианом пользуетесь:))
              +1
              вот это вообще не в кассу было
          0
          cp /root/certbot/certbot /usr/lib/python2.7/dist-packages/

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

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

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

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

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


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

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

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

                    0
                    а вот это мысль! пойду реализую!
                  –2
                  ага. ну… тогда наверняка его можно раз в 20 минут запускать
                0
                Я только не понял про certbot. С официального сайта предлагается скачать только 1 питон скрипт, зачем тянуть весь репозиторий?
                И сам certbot отвечает только за обновление и запуск скриптов работы с сертификатами.
                  0
                  Так ведь никто и не спорит, но если вы загуглите ошибку
                  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 скриптах, кои мы и заменили.
                  –1
                  В статье был упомянут 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).
                    0
                    Я с Вами согласен и на одной из площадок под S4b поднимал TMG специально, ибо без Reverse Proxy он вообще не работает, а на IIS мне не нравить.
                    Ну и вообще, TMG как продукт Microsoft является лучшим решение в работе в сетях Microsoft. Жаль что мелкомягкие сняли с поддержки, ведь за продуктом было большое будущее.

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

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

                  Only users with full accounts can post comments. Log in, please.