Вопрос или проблема
Каждый раз, когда я обновляю SSL сертификат на сервере (Alma Linux), я перезапускаю Postfix. Обычно я делаю это за несколько дней или за неделю до истечения срока действия сертификата. Однако соединения с почтой всегда перестают работать в день истечения старого сертификата, и в этот момент я вынужден перезапускать Postfix второй раз.
Это происходит каждый раз, и мне пришлось делать это как минимум 5 раз. Каждый раз просто перезапуск Postfix решает проблему. Ссылка на сертификат в Postfix указывает на папку Let’s Encrypt, и больше ничего не изменяется в конфигурации Postfix при обновлении сертификата. Ниже приведена конфигурация в main.cf:
#SSL
smtpd_use_tls = yes
smtpd_tls_auth_only = yes
smtp_tls_security_level = may
smtpd_tls_security_level = may
smtpd_tls_cert_file = /etc/letsencrypt/live/mail.example.net/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/mail.example.net/privkey.pem
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
Так как же заставить Postfix использовать новый сертификат после его установки? В противном случае мне придется ждать, пока почта перестанет работать, и делать перезапуск, что приведет к простоям для клиентов.
Certbot всегда обновляет символические ссылки в /etc/letsencrypt/live/ на последние файлы в /etc/letsencrypt/archive/ при обновлении сертификата Let’s Encrypt, так что этого не должно происходить, если Postfix либо перезапускается, либо перезагружается после обновления.
Однако перезагрузка также должна быть автоматизирована. Обычно это делается с помощью хуков Certbot, но в вашей ситуации может потребоваться альтернативный подход, где может быть полезна SystemD.
Хук развертывания Certbot
Когда Certbot обнаруживает, что срок действия сертификата подходит к концу, хуки
--pre-hookи--post-hookвыполняются до и после каждой попытки его обновить. Если вы хотите, чтобы ваш хук выполнялся только после успешного обновления, используйте--deploy-hookв команде, как показано ниже.certbot renew --deploy-hook /path/to/deploy-hook-script
Вы могли бы разместить скрипт перезагрузки в /etc/letsencrypt/renewal-hooks/deploy/, так как пути в вашем вопросе предполагают, что эта структура каталогов используется.
#!/bin/sh
systemctl reload postfix
Unit-файлы пути SystemD
Если вы не доверяете Certbot выполнять это действие, когда сертификат обновляется и становится пригодным, вы можете использовать Unit-файлы пути SystemD для мониторинга /etc/letsencrypt/live/mail.example.com/fullchain.pem и перезагружать Postfix всякий раз при изменении.
-
/etc/systemd/system/mail-certificate-watcher.service:[Unit] Description=Reload Postfix on mail.example.com certificate changes After=network.target [Service] Type=oneshot ExecStart=/usr/bin/systemctl reload postfix.service [Install] WantedBy=multi-user.target -
/etc/systemd/system/mail-certificate-watcher.path:[Path] PathModified=/etc/letsencrypt/live/mail.example.com/fullchain.pem [Install] WantedBy=multi-user.target -
Не забудьте включить и запустить его:
systemctl enable mail-certificate-watcher.path systemctl start mail-certificate-watcher.path
В моем случае я сделал следующее:
- systemctl restart postfix : не работает
- service dovecot restart : работает (SSL успешно обновлен и прочитан)
Ответ или решение
Обеспечение бесперебойной работы почтового сервера — это задача, требующая внимания к деталям и глубоких знаний системного администрирования, особенно в контексте использования SSL-сертификатов для защиты соединений. Ваш случай с Postfix и Let’s Encrypt демонстрирует довольно распространенную проблему, с которой сталкиваются многие администраторы систем. Давайте подробнее разберемся в причинах и возможных решениях.
Теория
Let’s Encrypt использует Certbot для автоматического обновления SSL-сертификатов. Каждый раз, когда сертификат обновляется, Certbot обновляет символьные ссылки, указывающие на файлы в директории /etc/letsencrypt/live/. Однако, для того чтобы изменения вступили в силу, службы, использующие эти сертификаты, должны быть перезапущены или как минимум перезагружены. Postfix, как правило, считывает файлы сертификатов только на этапе старта, поэтому после обновления сертификатов перезапуск или перезагрузка Postfix необходимы.
Пример
Судя по вашему описанию конфигурации, вы правильно указываете пути к файлам сертификатов и ключей в main.cf. Однако, проблема возникает из-за того, что Postfix не загружает новые файлы после их обновления без аутентичного сигнала о необходимости перезагрузки. Ваша текущая практика — ожидать истечения старого сертификата и затем вручную перезапускать службу — приводит к простоям и неудобствам для клиентов. Это может быть оптимизировано.
Применение
Есть несколько подходов к автоматизации этого процесса и устранению проблемы:
-
Hooks Certbot:
- Использование
--deploy-hookCertbot обеспечивает запуск определенного скрипта после успешного обновления сертификата. Вы можете создать скрипт, который содержит командуsystemctl reload postfix, и поместить его в каталог/etc/letsencrypt/renewal-hooks/deploy/. Это гарантирует, что Postfix будет перезагружен сразу после обновления сертификата.
#!/bin/sh systemctl reload postfix - Использование
-
SystemD Path Units:
- SystemD позволяет отслеживать изменения в файлах и реагировать на них с помощью Path Units. В этом случае, вы можете создать SystemD Unit, который будет отслеживать изменения в файле вашего сертификата и автоматически выполнять команду перезагрузки Postfix.
Создайте unit-файлы для SystemD:
/etc/systemd/system/mail-certificate-watcher.service:
[Unit] Description=Перезагрузка Postfix при изменении сертификата mail.example.com After=network.target [Service] Type=oneshot ExecStart=/usr/bin/systemctl reload postfix.service [Install] WantedBy=multi-user.target/etc/systemd/system/mail-certificate-watcher.path:
[Path] PathModified=/etc/letsencrypt/live/mail.example.com/fullchain.pem [Install] WantedBy=multi-user.targetПосле создания файлов, выполните:
systemctl enable mail-certificate-watcher.path systemctl start mail-certificate-watcher.path -
Регулярная проверка и мониторинг:
- Можно внедрить более широкую концепцию мониторинга, когда системные журналы и состояние сертификатов проверяются регулярно. Это может быть реализовано через скрипты, которые регулярно выполняются с помощью cron. Эти скрипты могут проверять дату окончания действия сертификата и, при необходимости, самостоятельно инициировать обновление или перезагрузку служб.
Заключение
Автоматизация процесса обновления и принятия сертификатов является ключевым аспектом для минимизации простоя сервера и обеспечения бесперебойной работы сервисов. Внедрение надежного механизма наблюдения и автоматической реакции может значительно улучшить надежность вашей ИТ-инфраструктуры и сократить необходимость ручного вмешательства. Это не только снизит вероятность неожиданных остановок, но и повысит доверие клиентов к вашему техническому обслуживанию.