Проблема чередования SSL-сертификатов в MailCow

Проблема чередования просроченных и новых SSL-сертификатов на сервере MailCow после их обновления — распространенная ситуация, вызванная несколькими техническими причинами. Основная проблема заключается в том, что контейнер acme-mailcow не перезапускается автоматически после обновления сертификатов, продолжая использовать старый файл, пока не будет принудительно перезапущен. Также возможны конфликты конфигураций SAN-сертификатов, когда при включенном ENABLE_SSL_SNI создаются несколько сертификатов, и Nginx/Dovecot обслуживают разные сертификаты в зависимости от SNI-запросов.

Содержание

• Основные причины чередования SSL-сертификатов в MailCow
• Диагностика проблем с SSL-сертификатами в MailCow
• Решение проблемы с перезапуском контейнера acme-mailcow
• Настройка SNI и дополнительных доменов в MailCow
• Проблемы с сетевыми проверками и DNS-записями
• Дополнительные методы принудительного обновления сертификатов
• Заключение

Основные причины чередования SSL-сертификатов в MailCow

Проблема с перезапуском контейнера acme-mailcow

Самая распространенная причина чередования сертификатов заключается в том, что после успешного обновления SSL-сертификата контейнер acme-mailcow не перезапускается автоматически. Это приводит к ситуации, когда:

1. Сертификат успешно обновлен в файловой системе
2. Но контейнер продолжает использовать старый кэшированный сертификат в памяти
3. Пользователи получают либо старый, либо новый сертификат в зависимости от времени подключения

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

Конфигурационные проблемы с SNI и SAN

Другой важной причиной является некорректная настройка SNI (Server Name Indication) и SAN (Subject Alternative Names) в конфигурации mailcow. Когда параметр ENABLE_SSL_SNI включен, система создает несколько сертификатов для разных доменов, и Nginx/Dovecot могут обслуживать разные сертификаты в зависимости от SNI-запросов.

Вы можете столкнуться с ситуацией, когда:

• Сертификат для основного домена (MAILCOW_HOSTNAME) успешно обновлен
• Но сертификат для дополнительного домена из ADDITIONAL_SAN остался старым
• Или наоборот — сертификат для основного домена не обновился, а для дополнительных доменов обновился

Проблемы с путями к файлам сертификатов

Иногда проблема заключается в неправильных путях к файлам сертификатов. Путь к cert.pem может использовать первый домен из списка SAN вместо MAILCOW_HOSTNAME, указанного в mailcow.conf. Это приводит к тому, что контейнер acme не находит правильный сертификат и продолжает использовать просроченный.

Диагностика проблем с SSL-сертификатами в MailCow

Проверка логов контейнера acme-mailcow

Первым шагом в диагностике является проверка логов контейнера acme-mailcow. Это поможет выявить ошибки при обновлении сертификатов:

docker compose logs --tail=200 -f acme-mailcow

В логах вы можете увидеть следующие типичные ошибки:

• “Challenge did not pass” с указанием “Timeout during connect” — проблема с сетевыми проверками
• Ошибки DNS-валидации — отсутствие необходимых DNS-записей
• Ошибки доступа к файлам — проблемы с правами на чтение/запись

Проверка содержимого файлов сертификатов

Второй важный шаг — проверка фактического содержимого файлов сертификатов:

# Просмотр основного сертификата
cat data/assets/ssl/cert.pem | openssl x509 -noout -text

# Просмотр приватного ключа
openssl rsa -in data/assets/ssl/key.pem -check -noout

Обратите внимание на:

• Дату истечения срока действия сертификата
• Список Subject Alternative Names (SAN)
• Сертификата, который используется для вашего основного домена

Проверка через OpenSSL

Чтобы увидеть, какой сертификат实际上 используется при подключении к вашему серверу, выполните:

openssl s_client -connect MAILCOW_HOSTNAME:443 | openssl x509 -noout -text

Эта команда покажет вам актуальный сертификат, который сервер отдает клиентам в данный момент.

Проверка состояния контейнеров

Убедитесь, что все контейнеры работают корректно:

docker compose ps

Обратите внимание на статус контейнера acme-mailcow. Он должен быть в состоянии “running” без ошибок.

Решение проблемы с перезапуском контейнера acme-mailcow

Принудительный перезапуск контейнера

Самое простое и эффективное решение — принудительный перезапуск контейнера acme-mailcow после обновления SSL-сертификата:

docker compose restart acme-mailcow

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

Создание файла force_renew

Если стандартный перезапуск не помогает, можно использовать файл принудительного обновления:

1. Создайте файл force_renew в директории контейнера:

touch data/assets/ssl/force_renew

2. Перезапустите контейнер acme-mailcow:

docker compose restart acme-mailcow

3. Удалите файл force_renew после успешного обновления:

rm data/assets/ssl/force_renew

Важно: Если файл force_renew остается на месте после перезапуска, это может указывать на проблему с правами доступа или неправильной конфигурацией.

Проверка путей к сертификатам

Убедитесь, что путь к сертификату соответствует вашему MAILCOW_HOSTNAME, указанному в mailcow.conf. Проверьте содержимое директории data/assets/ssl/ и убедитесь, что сертификаты находятся в правильных местах.

Настройка SNI и дополнительных доменов в MailCow

Понимание работы SNI в MailCow

SNI (Server Name Indication) — это расширение протокола TLS, которое позволяет веб-серверу отображать несколько SSL-сертификатов на одном IP-адресе. В контексте mailcow это означает, что для каждого домена из списка ADDITIONAL_SAN может создаваться отдельный сертификат.

Когда параметр ENABLE_SSL_SNI включен:

• MailCow создает отдельные сертификаты для каждого домена
• Nginx использует SNI для определения, какой сертификат отдать клиенту
• Dovecot также использует SNI для определения сертификата для IMAP/SMTP соединений

Оптимизация конфигурации SAN

Чтобы избежать проблем с чередованием сертификатов, оптимизируйте конфигурацию SAN в вашем mailcow.conf:

1. Убедитесь, что MAILCOW_HOSTNAME указан первым в списке доменов
2. Проверьте, что все домены из ADDITIONAL_SAN имеют корректные DNS-записи
3. Удалите ненужные домены из списка ADDITIONAL_SAN

Отключение Let’s Encrypt при использовании обратного прокси

Если вы используете обратный прокси (например, Cloudflare), рассмотрите возможность отключения Let’s Encrypt в mailcow:

# В файле mailcow.conf
SKIP_LETS_ENCRYPT=y

В этом случае:

• MailCow не будет пытаться обновлять сертификаты самостоятельно
• Вы будете управлять сертификатами через свой обратный прокси
• Это устраняет проблемы с синхронизацией сертификатов между прокси и сервером

Важно: При использовании обратного прокси отключение Let’s Encrypt требует ручного управления сертификатами.

Проблемы с сетевыми проверками и DNS-записями

Ошибки валидации ACME

Часто проблемы с обновлением SSL-сертификатов в MailCow связаны с ошибками валидации ACME. В логах может появляться ошибка “Challenge did not pass” с указанием “Timeout during connect”, что обычно означает проблему с брандмауэром или сетевыми настройками.

Проверка открытых портов

Убедитесь, что порты 80 и 443 открыты и правильно направлены на ваш сервер:

# Проверка порта 80
telnet ваш_сервер 80

# Проверка порта 443
telnet ваш_сервер 443

Если порты недоступны, это может привести к ошибкам валидации ACME.

Проблемы с обратным прокси

Если вы используете Cloudflare или другой обратный прокси, убедитесь, что он правильно обрабатывает запросы к .well-known/acme-challenge. Обратные прокси могут блокировать или изменять эти запросы, что приводит к ошибкам валидации.

Настройка SKIP_IP_CHECK и SKIP_HTTP_VERIFICATION

При наличии сетевых проблем можно настроить параметры в mailcow.conf:

SKIP_IP_CHECK=y
SKIP_HTTP_VERIFICATION=y

Эти параметры отключают проверки IP-адреса и HTTP-верификацию при обновлении сертификатов, что может помочь при работе за NAT или с обратным прокси.

Добавление публичного IP в loopback

При работе за NAT может возникнуть проблема, когда сервер не может подключиться к своему публичному IP. В этом случае добавьте ваш публичный IP в loopback интерфейс:

ip a a ВАШ_ПУБЛИЧНЫЙ_IP/32 dev lo

Дополнительные методы принудительного обновления сертификатов

Использование утилиты acme-mailcow

Для принудительного обновления сертификатов можно использовать встроенную утилиту mailcow:

docker compose exec acme-mailcow bash -c "acme-mailcow issue"

Эта команда запустит процесс обновления сертификатов вручную.

Полная пересборка контейнеров

В сложных случаях можно попробовать полностью пересобрать контейнеры:

docker compose down
docker compose up -d

Внимание: Этот метод может временно прервать работу почтовых сервисов.

Проверка прав доступа

Убедитесь, что у пользователя, от которого работает контейнер acme-mailcow, есть права на чтение и запись в директорию data/assets/ssl/:

ls -la data/assets/ssl/

Правильные права должны быть:

• Для директории: 755
• Для файлов сертификатов: 644
• Для приватного ключа: 600

Ручное копирование сертификатов

В крайних случаях можно вручную скопировать свежие сертификаты:

# Копирование нового сертификата
cp data/assets/ssl/cert.pem data/assets/ssl/cert.pem.bak

# Копирование нового ключа
cp data/assets/ssl/key.pem data/assets/ssl/key.pem.bak

Заключение

Проблема чередования SSL-сертификатов в MailCow после их обновления — это комплексная техническая проблема, вызванная несколькими факторами. Основная причина заключается в том, что контейнер acme-mailcow не перезапускается автоматически после обновления сертификатов, продолжая использовать старый кэшированный сертификат.

Для диагностики проблемы необходимо проверить логи контейнера, содержимое файлов сертификатов и фактический сертификат, который отдает сервер. Основное решение — принудительный перезапуск контейнера acme-mailcow после обновления сертификатов с помощью команды docker compose restart acme-mailcow.

Также важно правильно настроить параметры SNI и SAN в конфигурации mailcow, обеспечить корректные DNS-записи для всех доменов и решить сетевые проблемы, которые могут мешать валидации ACME. При использовании обратного прокси рекомендуется отключить Let’s Encrypt в mailcow и управлять сертификатами через прокси.

Следуя этим рекомендациям, вы сможете эффективно диагностировать и устранить проблему чередования SSL-сертификатов в вашем почтовом сервере MailCow.

Источники

1. Официальная документация MailCow — Основные причины и решения проблем с SSL-сертификатами: https://docs.mailcow.email/post_installation/firststeps-ssl/
2. Форум сообщества MailCow — Обсуждение проблем с обновлением SSL-сертификатов и валидацией ACME: https://community.mailcow.email/d/3609-acme-problem-with-renewing-ssl-certificate
3. GitHub Issues — Информация о проблемах с путями к файлам сертификатов в MailCow: https://github.com/mailcow/mailcow-dockerized/issues/3438
4. Форум сообщества MailCow — Проблемы с синхронизацией сертификатов при использовании обратного прокси: https://community.mailcow.email/d/4388-ssl-certificate-expired-not-renewed
5. Форум сообщества MailCow — Вопросы работы watchdog и проверки сертификатов: https://community.mailcow.email/d/3885-mailcow-watchdog-certcheck-ssl-critical-certificate-expired
6. Форум сообщества MailCow — Проблемы с DNS-записями и валидацией ACME: https://community.mailcow.email/d/3325-mailcow-have-lost-its-ssl-and-doesnt-renew-it