Как заменить самоподписанный SSL-сертификат VestaCP на нормальный от letsencrypt?

Question

[altai2013]

На VPS-хостинге имеется сервер с Ubuntu 16.04, установлена панель управления VestaCP на Nginx, создано доменное имя, через панель управления VestaCP прописано получение (и, насколько я понимаю, автоматическое обновление) SSL-сертификата от letsencrypt.
Всё работает нормально, к подключению через https к домену претензий нет, но сама панель VestaCP по-прежнему открывается на https://mydomain.com:8083 с штатным самоподписанным SSL-сертификатом, а не полученным от letsencrypt сертификатом mydomain.com
Вопрос: как правильнее и проще заменить самоподписанный сертификат VestaCP на валидный от letsencrypt? Сертификат не домена, а именно самой панели VestaCP? Перерыл все настройки панели - не вижу такого пункта.
Можно вручную поправить пути к сертификату в файле настроек VestaCP (/usr/local/vesta/nginx/conf/nginx.conf), но я боюсь, что ручные правки будут затёрты после очередного автоматического обновления кода самой VestaCP.
Можно прописать в планировщике задач копирование сертификата letsencrypt в папку, где VestaCP хранит свой самоподписанный, но мне кажется это какой-то костыльный способ. Должна же быть какая-то штатная процедура у VestaCP для замены сертификата самой панели?

Answer 1

[altai2013]

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

1) Создаём в папке /etc/cron.daily/ файл под именем vesta_ssl:
nano /etc/cron.daily/vesta_ssl

2) пишем в файл скрипт и сохраняем его, предварительно заменив [USER] на имя пользователя, создававшего домен в VestaCP (например admin) и заменив [DOMAIN] на доменное имя, для которого получен валидный SSL-сертификат (например mydomain.com):

#!/bin/bash

cert_src="/home/[USER]/conf/web/ssl.[DOMAIN].pem"
key_src="/home/[USER]/conf/web/ssl.[DOMAIN].key"
cert_dst="/usr/local/vesta/ssl/certificate.crt"
key_dst="/usr/local/vesta/ssl/certificate.key"

if ! cmp -s $cert_dst $cert_src
then
        # Copy Certificate
        cp $cert_src $cert_dst

        # Copy Keyfile
        cp $key_src $key_dst

        # Change Permission
        chown root:mail $cert_dst
        chown root:mail $key_dst

        # Restart Services
        service vesta restart &> /dev/null
        service exim4 restart &> /dev/null
fi

3) делаем скрипт исполняемым файлом:
chmod +x /etc/cron.daily/vesta_ssl

4) запускаем скрипт вручную, чтобы применить его немедленно, не дожидаясь расписания cron:
./vesta_ssl

Answer 2

[ky0]

1) Выкинуть панель управления...

Comments

[altai2013]

К сожалению, не всем проектам подходит схема работы "один раз настроил и забыл". Многим требуются постоянные правки, изменения, добавление-удаление пользователей, почтовых ящиков и т.д., что без панели управления выполнять слишком трудозатратно.

[ky0]

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

Постоянное изменение конфигурации компонентов при наличии прослойки в виде ПУ рано или поздно приведёт ровно к тому, что случилось у вас - невозможности сделать что-либо непосредственно из панели, пришлось лезть в консоль. И такое возникает постоянно - на Тостере масса вопросов вида "как сделать что-то в %CPNAME%?", при том, что аналогичные операции без панелей делаются элементарно.

Нисколько не выступая против полезности ПУ в целом - они упрощают и делают намного продуктивнее многие рутинные операции, понимать, как работает веб-сервер, PHP и прочие компоненты "под капотом" всё-таки нужно.

[altai2013]

Согласитесь, что в 100 раз проще ответить на вопрос "как сделать что-то в %CPNAME%?", чем, например, на такой: "как завести веб-почту с антиспамом на своём сервере без панели управления"? :)

[ky0]

altai2013, нет, таким образом мы только маскируем проблему. После настройки по гайду из интернета у горе-админа наверняка возникнут и другие вопросы в процессе эксплуатации (если всё вообще заведётся в принципе). А так как под капот он не залазил - производительность и безопасность такого сервиса под большим вопросом.