Был почтовый домен mail.example.com с сервером и на него же посадили веб интерфейс, что не очень удобно. Не рекомендую так делать. Делайте для него отдельный домен, типа webmail.example.com или как-то ещё. Я веб интерфейс перекинул на отдельный веб сервер, и для домена mail.example.com в настройках nginx сделал переадресацию на webmail.example.com, а чтобы продолжать обновлять сертификат оставил
location /.well-known без переадресации. Сделал и забыл. Прилетает от мониторинга через пару недель оповещение, что через 10 дней сертификат для mail протухает. А должен обновиться раньше. Иду разбираться и не понимаю, в чём проблема. На вид всё сделано корректно, как я обычно делаю. Смотрю логи ошибок certbot и вижу, что проверка домена mail идёт не по https, а по http. Я честно говоря почему-то думал, что сначала проверка всегда идёт по https, и если там всё ОК, то этого достаточно. Оказывается нет. Не обращал на это внимание.
У меня получилось так, что по http шла сразу переадресация всех запросов mail -> webmail, а последний хостился на другом сервере, поэтому проверка не проходила. Поправил правила nginx. Оставил
location /.well-known и для http, и для https, чтобы в любом случае проверка домена проходила успешно. Что-то типа такого:server { listen 80; server_name mail.example.com; location /.well-known { root /var/www/mail.example.com; } location / { return 301 https://webmail.example.com$request_uri; }}Для https аналогично.
Без мониторинга очень часто протухают сертификаты. Сколько раз это видел даже у крупных компаний. Помню у Rebrain когда-то давно был анонс вебинара про мониторинг. Переходишь по ссылке, а там браузер даёт ошибку на протухший сертификат. Получилось забавно. Поправили сразу, но сам факт. Либо не было мониторинга, либо за ним никто не следил. На протухшие домены и сертификаты лучше всего делать повторяющие уведомления, которые будут раз в сутки прилетать, пока не продлишь.
#zabbix #мониторинг