Так как зачастую, сайтов в организации много, а 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

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

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

Удачи, админы!
Поделиться с друзьями
-->

Комментарии (22)


  1. foxyovovich
    10.06.2017 23:11

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


    1. SAMbI4
      11.06.2017 10:47

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


  1. Faight
    10.06.2017 23:14
    +2

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

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

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


    1. kilgur
      11.06.2017 07:48

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


    1. SAMbI4
      11.06.2017 10:50

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

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


      1. Jedi-Knight
        11.06.2017 19:08
        -3

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


        1. YourChief
          11.06.2017 21:47
          +1

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


  1. selivanov_pavel
    11.06.2017 16:43

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

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


    1. SAMbI4
      12.06.2017 10:11

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


      1. selivanov_pavel
        12.06.2017 17:32

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


  1. Jedi-Knight
    11.06.2017 18:52

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


    1. grossws
      11.06.2017 18:56

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


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


      1. wrewolf
        11.06.2017 19:00

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


        1. grossws
          11.06.2017 21:01

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


          1. SAMbI4
            12.06.2017 10:12

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


      1. Jedi-Knight
        11.06.2017 19:02
        -2

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


  1. wrewolf
    11.06.2017 18:59

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


    1. SAMbI4
      12.06.2017 10:14

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

      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. Dorlas
    11.06.2017 21:19
    -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).


    1. SAMbI4
      12.06.2017 10:22

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

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

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


      1. kvaps
        12.06.2017 10:37

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


        1. SAMbI4
          12.06.2017 19:37

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