RuWeb.net Forum

ISPmanager 4: После установки SSL-сертификата сайт стал работать медленнее. Что делать?
timru - 27.1.2018 в 15:46

Забегая вперед, скажу что установка сертификата никоим образом не должна увеличивать нагрузку на сайте, дело тут совершенно в другом.

Для начала немного теории. В самом простом случае, есть веб-сервер apache, который висит на 80-м порту и отдает посетителю весь контент, как статический (изображения, js, css и т.д.), так и динамический (обрабатывает php-скрипты с помощью php-модуля). В целях снижения нагрузки, на 80-й порт можно повесить более легкий веб-сервер nginx, который будет отдавать статику, а php-скрипты передавать на обработку более тяжелому веб-серверу apache, который будет висеть скажем на порту 8080. Что же делать в случае c SSL, для работы которого используется порт 443 (https-протокол)? По-логике, нужно заставить nginx слушать оба порта - и 80, и 443, и пусть он в случае необходимости работает и SSL-сертификатами, а apache пусть так и остается на порту 8080.

Но в ISPmanager-4 изначально это было реализовано неправильно. В случае с одним только apache, он слушал порты 80 и 443. А в случае связи nginx + apache получалась такая картина:
- для http-протокола nginx висел на 80-м порту, а apache на 8080-м;
- для https-протокола порт 443 обслуживал только один apache, а nginx из связки вообще выпадал.

Проблема долгое время не была актуальной среди наших клиентов, поэтому никто не придал ей особого значения. Но в сентябре 2016-го Google опубликовал предупреждение о том, что начиная с января 2017-го Chrome будет помечать HTTP-страницы, на которых посетители вводят пароли или иные секретные данные, как небезопасные:
https://security.googleblog.com/2016/09/moving-towards-more-secure-web.html
А начиная с 2017-го года все больше и больше клиентов начало переходить на SSL.

И вот тут обнаружилась проблема, которую в первую очередь заметили владельцы выделенных серверов с сильно нагруженными сайтами: до использования SSL сайт работал нормально, а после установки SSL-сертификата и настройки перенаправления посетителей на HTTPS-протокол, нагрузка неожиданно возросла. Но виноват в этом вовсе не сертификат, а тот факт что по HTTPS-протоколу сайт стал обслуживать только один apache, а nginx выпал из связки.

Поэтому возник вопрос, как в этом случае задействовать nginx. Но все не так просто.
Оказывается, в каком-то 201X году разработчики ISPmanager выпустили исправление данной проблемы. Для того чтобы привести файлы конфигурации в "актуальное состояние", необходимо в разделе "Настройки сервера" -> "Возможности" выделить строчки "Веб-сервер Apache" и "nginx [engine x] — HTTP и прокси-сервер." и переактивировать их, нажав кнопку "Вкл." Ни в коем случае не пытайтесь сделать это!
По факту, данная функция не работает так как надо. Очень часто все это заканчивается тем, что ISPmanager выключает SSL на всех сайтах и удаляет все сертификаты. И, к сожалению, техподдержка ISPsystem не желает решать эту проблему, ссылаясь на что поддержка ISPmanager-4 завершена 01.12.2016.

К сожалению, решения на данный момент нет. Иногда после некорректной переактивации удавалось вручню "допилить" файлы конфигурации так, чтобы панель управления ISPmanager продолжала успешно работать и создавать новые домены уже в новом формате. Иногда нет. Если у вас на сервере много сайтов, а также внесены ручные правки в httpd.conf и nginx.conf, с большой долей вероятности ничего не получится даже с нашей помощью. Необходимо задумываться о переезде на сервер с Linux, т.к. ISPmanager-5 уже не поддерживает FreeBSD.


[Отредактировано 27.1.2018 кто timru]


timru - 20.2.2018 в 09:33

Как повесить nginx на 443-й порт на сервере с ISPmanager-4 и включить поддержку протокола HTTP/2 самостоятельно.

Внимание!!! Используйте эту инструкцию только на свой страх и риск. На практике положительный результат достигался меньше чем в половине случаев.

Вместо IP 185.12.92.111 подставляйте основной IP вашего сервера.


Эта тема посвящена сразу 2-м проблемам, и решает сразу обе.
1) Все больше людей перееводят свои сайты на HTTPS. Но у нас на серверах с ISPmanager-4 в большинстве случаев все настроено таким образом, что при включении SSL для какого-то сайта, его начинает обслуживать только apache, без участия nginx. Из-за этого растет нагрузка.
2) Все больше людей хотят новый протокол HTTP/2. Но apache 2.2 его не поддерживает, требуется обновление до 2.4. Но ISPmanager-4 не поддерживает apache 2.2, так что apache обновлять нельзя. А вот nginx можно. Начиная с версии 1.10 nginx поддерживает HTTP/2. Опять же, для этого требуется чтобы на 443-м порту висел именно nginx, а не apache.

ISPmanager-4 не умеет сам корректно переключить nginx на 443-й порт. Поэтому придется поработать ручками.

Для начала, нам нужно изучить конфиги. Есть 2 варианта,

"новый формат конфигов":
- apache висит на порту 81, а не на 8080 (смотрите httpd.conf)
- в ispmgr.conf присутствуют строчки:
Option WebNginxNoSSL
WebModules nginx apache

"старый формат конфигов":
- apache висит на порту 8080, а не на 81 (смотрите httpd.conf)
- в ispmgr.conf отсутствует строчка "WebModules nginx apache"

Если у нас новый формат конфигов, то задача намного упрощается. Для начала, рассматриваем его.

1. Нужно слегка модифицировать сертификаты

В apache для сертификатов используются такие строчки
Для неподписанных:
SSLCertificateFile /home/httpd-cert/polzovatel/nashdomen.ru.crt
SSLCertificateKeyFile /home/httpd-cert/polzovatel/nashdomen.ru.key

Для подписанных:
SSLCertificateFile /home/httpd-cert/polzovatel/nashdomen.ru.crt
SSLCertificateKeyFile /home/httpd-cert/polzovatel/nashdomen.ru.key
SSLCertificateChainFile /home/httpd-cert/polzovatel/nashdomen.ru.bundle
(тут есть цепочка сертификатов)

В nginx нет отдельного файла для цепочки, поэтому если она у нас была в apache, то нам нужно объединить nashdomen.ru.crt и nashdomen.ru.bundle в один файл nashdomen.ru.chained.crt
# cat nashdomen.ru.crt nashdomen.ru.bundle > nashdomen.ru.chained.crt
Аналогичную операцию проделываем для всех сертификатов.

2. Редактируем nginx.conf
В глобальных параметрах (до первого блока server{}) прописываем строчку:
--------------
include /usr/local/ispmgr/etc/nginx.domain;
--------------

Далее, ищем блоки, для которых нужно включить SSL. Например:
--------------
server {
server_name nashdomen.ru http://www.nashdomen.ru;
listen 185.12.92.111;
--------------
после этой строчки дописываем такую строчку:
--------------
listen 185.12.92.111:443 ssl http2;
--------------
а также в конце блока дописываем
--------------
ssl_certificate /home/httpd-cert/polzovatel/nashdomen.ru.chained.crt;
ssl_certificate_key /home/httpd-cert/polzovatel/nashdomen.ru.key;
--------------
Аналогичную операцию проделываем для всех блоков.

3. Редактируем httpd.conf

Комментируем эти строчки:
#LoadModule ssl_module libexec/apache22/mod_ssl.so
#Include etc/apache22/extra/httpd-ssl.conf

Удаляем такие строчки:
NameVirtualHost 185.12.92.111:443

Удаляем все блоки с виртуалхостами :443
<VirtualHost 185.12.92.111:443 >
бла-бла-бла
</VirtualHost>

4. Редактируем /usr/local/ispmgr/etc/ispmgr.conf

Удаляем строчку:
Option WebNginxNoSSL

5. Редактируем /usr/local/ispmgr/etc/nginx.domain

Как правило, в этом файле прописан левый IP, нужно заменить его на основной IP сервера везде, где он встречается.

6. Редактируем /etc/rc.local

Тут должна быть строчка:
/usr/local/ispmgr/sbin/ihttpd 185.12.92.111 1500
Если ее нет - добавляем.
IP должен быть основным IP сервера. Если IP левый - исправляем.

7. Выполняем команды:
# killall ispmgr
# /usr/local/ispmgr/sbin/ihttpd 185.12.92.111 1500
# /usr/local/etc/rc.d/apache22 restart
# /usr/local/etc/rc.d/nginx restart


Для усиления безопасности и повышения рейтингов в ssllabs нужно также сделать следующее:

# cd /usr/local/etc/nginx/ && openssl dhparam -out dhparam.pem 4096
Внимание! Эта команда выполняется реально долго, вплоть до 1 часа.

Также добавляем в глобальный блок nginx:
ssl_prefer_server_ciphers on;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH;
ssl_dhparam /usr/local/etc/nginx/dhparam.pem;

И перезапускаем nginx.

Полезные ссылки:

Проверка наличия поддержки HTTP/2:
https://tools.keycdn.com/http2-test

Проверка безопасности SSL:
https://www.ssllabs.com/ssltest/analyze.html?d=nashdomen.ru

---------------------------------------------------------------------------------
Если у нас старый формат конфигов, нужно сначала перейти на новый формат, а затем все делать по инструкции выше.
Что именно нужно править вручную в httpd.conf, nginx.conf и ispmgr.conf - я детально не изучал, но правок очень много. (Недостаточно исправить порт с 8080 на 81, изменений там в разы больше.)
Поэтому, как вручную переделать конфиги - я пока не знаю, и предлагаю вариант с использованием ISPmanager.

Переход на новый формат может осуществить сам ISPmanager, при условии что у нас до сих пор лежит старая база пэкеджей (папки с названиями пакетов в /var/db/pkg) и до сих пор есть в системе программы типа pkg_*.
И САМОЕ ВАЖНОЕ: ПРИ ТАКОМ ПЕРЕХОДЕ ISPMANAGER УДАЛИТ ИЗ APACHE ВСЕ ЧТО КАСАЕТСЯ SSL, ВКЛЮЧАЯ ФАЙЛЫ СЕРТИФИКАТОВ, И НИЧЕГО НЕ ДОБАВИТ В NGINX!!!!!

Поэтому обязательно делаем бэкапы:
# cd /home && cp -pr httpd-cert httpd-cert.bak
# cd /usr/local/etc && cp -pr apache22 apache22.bak
# cd /usr/local/etc && cp -pr nginx nginx.bak
# cd /usr/local/ispmgr/etc && cp -pr ispmgr.conf ispmgr.conf.bak

Затем идем в ISPmanager в раздел "Возможности", выделяем там apache и nginx, и нажимаем кнопку "Включить", невзирая на то что они и так уже включены. После этого ждем минуты 3. Возвращаемся на сервер. Ужасаемся от того, что натворил ISPmanager. Возвращаем все обратно:
# cd /home && mv httpd-cert httpd-cert.new && httpd-cert.bak httpd-cert
# cd /usr/local/etc && mv nginx nginx.new && mv nginx.bak nginx && /usr/local/etc/rc.d/nginx restart
# cd /usr/local/etc && mv apache22 apache22.new && mv apache22.bak apache22 && /usr/local/etc/rc.d/apache22 restart
# cd /usr/local/ispmgr/etc && mv ispmgr.conf ispmgr.conf.new && mv ispmgr.conf.bak ispmgr.conf && killall ispmgr

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



[Отредактировано 20.2.2018 кто timru]