Как исправить ошибку Zimbra «Невозможно запустить TLS: Сбой рукопожатия SSL»

Это сообщение Unable to start TLS: SSL handshake failedозначает, что клиент и сервер не смогли завершить согласование, которое запускает зашифрованное соединение. В Zimbra сообщение может поступать из разных мест. Часто встречается вариант, zmcontrol statusуказывающий на то, что соединение с главным сервером LDAP не прошло проверку сертификата. Почтовый клиент или SMTP-ретранслятор также могут сообщать о проблеме с установлением соединения на общедоступном почтовом порту.

Решение зависит от того, какое именно соединение не удалось установить. Начните с определения службы и имени хоста в окружающих строках журнала. Затем проверьте сертификат, цепочку его выдачи, системные часы и конечную точку TLS. Избегайте отключения TLS в качестве первого шага: это может скрыть симптом, ослабив или нарушив внутреннюю связь между почтовым сервером и сервером.

Что нужно знать, прежде чем что-либо менять

TLS — это протокол, который шифрует сетевое соединение. TLS-рукопожатие — это начальный обмен данными, в ходе которого две системы согласовывают параметры шифрования и проверяют сертификат сервера. STARTTLS начинается как соединение по обычному протоколу, а затем переключается на TLS, когда обе стороны запрашивают это. LDAP и SMTP могут использовать STARTTLS, поэтому эта ошибка сама по себе не указывает на неисправную службу.

Перед выполнением команд восстановления запишите версию Zimbra, тип установки (одноузловая или многоузловая), точную команду или клиент, вызвавшие ошибку, и полную строку журнала. Запланируйте развертывание сертификатов или перезапуск служб на период технического обслуживания. Сохраните резервную копию файлов сертификатов и конфигурации перед их редактированием.

  • Выполняйте административные команды от имени учетной записи и с правами, необходимыми для вашей версии Zimbra.
  • Не вставляйте закрытые ключи, пароли или неотредактированные журналы электронной почты в заявки или на публичные форумы.
  • Не изменяйте флаги безопасности LDAP или настройки протокола, пока не выясните, какая конечная точка вышла из строя, и не проверите ее сертификат.

Шаг 1: Определите неисправное TLS-соединение.

Сначала воспроизведите проблему и прочтите полное сообщение. Если оно появляется при проверке состояния службы Zimbra и содержит формулировку, подобную этой when connecting to ldap master, исследуйте внутренний LDAP TLS. Если сбой происходит только при отправке SMTP-запроса почтовым клиентом, исследуйте общедоступную конечную точку SMTP, а также имя хоста, порт и режим шифрования клиента.

su - zimbra
zmcontrol status

Просмотрите последние записи в журнале Zimbra с той же меткой времени. Во многих системах основной журнал находится по адресу /var/log/zimbra.log; используйте местоположение журнала, настроенное на вашем сервере.

grep -Ei 'Unable to start TLS|SSL handshake|certificate|ldap|STARTTLS' /var/log/zimbra.log | tail -n 80

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

При внутренней ошибке LDAP проверьте, какие хосты LDAP настроены для использования этим сервером. Запросите локальные ключи конфигурации по отдельности и сравните их имена хостов с DNS и сертификатом сервера:

zmlocalconfig ldap_url
zmlocalconfig ldap_master_url
zmlocalconfig ldap_starttls_supported
zmlocalconfig ldap_starttls_required

Доступность ключей и вывод данных могут различаться в зависимости от версии Zimbra и роли узла. Это диагностические данные; не изменяйте значение только потому, что оно появилось в выводе. В документации Zimbra описана роль настроек LDAP STARTTLS и рекомендуется оставлять внутренний TLS включенным: значения локальной конфигурации Zimbra TLS и STARTTLS .

Шаг 2: Проверьте системные часы, DNS и доступность.

Проверка сертификата зависит от времени сервера. Если время сильно отстаёт или опережает время, действительный сертификат может отображаться как недействительный или просроченный. Проверьте время на хосте Zimbra, а также на любом LDAP-мастере или реплике, участвующих в соединении.

date -u
getent hosts ldap.example.com

Замените ldap.example.comна имя хоста LDAP, найденное в конфигурации или журнале. Убедитесь, что оно разрешается в ожидаемый адрес сервера и что настроенный порт LDAP доступен через брандмауэр и сеть хоста. В многоузловых установках проверьте соединение с узла Zimbra, который зарегистрировал сбой, и с фактического узла LDAP — а не только с вашей рабочей станции.

Для клиентского SMTP-соединения STARTTLS в руководстве по устранению неполадок SMTP от Zimbra показано тестирование порта 25 с помощью OpenSSL. Порт 587 также часто используется для отправки сообщений с помощью STARTTLS. Используйте имя хоста и порт, настроенные в почтовом клиенте:

openssl s_client -starttls smtp -connect mail.example.com:587 -servername mail.example.com -showcerts

Для SMTP на порту 25 замените 587на 25. Порт 465 использует неявный TLS, поэтому не добавляйте -starttls smtpпри тестировании этого порта. Успешное TCP-соединение само по себе не доказывает, что сертификат является доверенным или что клиент использует правильный режим безопасности. См. руководство Zimbra по устранению неполадок SMTP и OpenSSL .

Шаг 3: Проверьте сертификат, фактически развернутый в Zimbra.

Сертификат — это подписанный документ, подтверждающий личность сервера. Сертификат должен быть действителен для имени хоста, используемого клиентами, находиться в пределах срока его действия и иметь цепочку сертификатов, которым доверяет подключаемый компонент. Сертификат может выглядеть корректно в браузере, в то время как на узле LDAP, Postfix или прокси-сервере развернут другой сертификат.

В качестве администратора Zimbra просмотрите сертификат, который, по данным Zimbra, развернут:

/opt/zimbra/bin/zmcertmgr viewdeployedcrt

Проверьте имя субъекта (SAN) или альтернативное имя субъекта (SAN), издателя, дату истечения срока действия и службы каждого указанного сертификата. SAN должно содержать имя хоста, фактически используемое для подключения к LDAP или почте. Также убедитесь, что все узлы в многосерверной конфигурации имеют ожидаемый сертификат и цепочку сертификатов. Zimbra отмечает, что просмотр развернутых сертификатов осуществляется локально на сервере, поэтому выполните проверку на каждом соответствующем узле.

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

openssl x509 -in /tmp/commercial.crt -noout -dates -subject -issuer -ext subjectAltName

Замените указанный в примере путь к файлу сертификата, который вы проверяете. Отсутствие SAN, просроченный конечный или промежуточный сертификат, неправильное имя хоста или сертификат, выданный для другого сервера, — все это может привести к сбою проверки.

Шаг 4: Проверка закрытого ключа и цепочки сертификатов.

Цепочка сертификатов — это набор сертификатов эмитентов, позволяющий клиенту отследить сертификат сервера до доверенного центра сертификации. Если в файле цепочки отсутствует промежуточный сертификат или содержится неверная цепочка, клиенты могут отклонить сервер, даже если конечный сертификат актуален. Сертификат и закрытый ключ также должны представлять собой совпадающую пару.

Для коммерческого сертификата инструменты сертификации Zimbra предоставляют этап проверки. Адаптируйте пути к файлам в соответствии с вашей установкой и центром сертификации:

/opt/zimbra/bin/zmcertmgr verifycrt comm   /opt/zimbra/ssl/zimbra/commercial/commercial.key   /tmp/commercial.crt   /tmp/ca_chain.crt

Продолжайте только в том случае, если проверка подтвердит совпадение сертификата и закрытого ключа, а также действительность цепочки сертификатов. Не развертывайте сертификат после неудачной проверки. Используйте промежуточную цепочку, предоставленную центром сертификации, и формат цепочки, ожидаемый вашей версией Zimbra; не создавайте цепочку путем угадывания или добавления несвязанных корневых сертификатов.

В руководстве по сертификатам Zimbra описана последовательность проверки и развертывания, включая цепочку центров сертификации: Установка сертификатов Zimbra и инструменты командной строки . На странице устранения неполадок с цепочкой сертификатов также объясняются ошибки проверки цепочки издателей: Руководство по цепочке сертификатов Zimbra .

Шаг 5: Исправьте и безопасно разверните сертификат.

Если проверка показывает просроченный сертификат, неверный ключ, отсутствие промежуточного сертификата или несоответствие имени хоста, получите или сгенерируйте правильные файлы перед развертыванием. Следуйте процедуре, соответствующей вашей версии Zimbra и типу сертификата. Для коммерческого сертификата документированная команда имеет следующий общий вид:

/opt/zimbra/bin/zmcertmgr deploycrt comm /tmp/commercial.crt /tmp/ca_chain.crt

Используйте точно указанный синтаксис команды и права доступа, соответствующие вашей установленной версии. Интерфейс командной строки Zimbra может устанавливать сертификаты для таких компонентов, как MTA, LDAP и прокси-сервер, поэтому развертывание может повлиять на несколько служб. В многоузловой среде убедитесь, что сертификат корректно развернут на каждом соответствующем сервере, включая главный сервер LDAP.

После проверки развертывания перезапустите службы Zimbra во время планового технического обслуживания, если этого требует процедура выпуска, затем подтвердите состояние служб и развернутые сертификаты:

su - zimbra
zmcontrol restart
zmcontrol status
/opt/zimbra/bin/zmcertmgr viewdeployedcrt

Перезапуск прерывает доступ к почте и веб-сайтам, пока службы останавливаются и возобновляют работу. Не следует запускать его бездумно на загруженном производственном сервере. В руководстве по сертификатам Zimbra описано использование zmcontrol restartпосле развертывания и проверка результата с помощью viewdeployedcrt.

Шаг 6: Проверьте конфигурацию доверия LDAP, не отключая TLS.

Если сам сертификат проходит проверку, но LDAP-клиент Zimbra по-прежнему его отклоняет, проверьте доверенные материалы LDAP и неисправный узел. В архивных рекомендациях Zimbra по устранению неполадок MTA в /opt/zimbra/conf/caчисле возможных причин сбоев LDAP STARTTLS указаны недействительная цепочка центров сертификации, просроченные сертификаты центров сертификации и неожиданные файлы. Рассматривайте это как диагностическую подсказку, а не как причину для удаления файлов: сравните каталог с заведомо исправной резервной копией или рекомендациями для конкретной версии и сохраните его содержимое, прежде чем вносить изменения.

Для простой проверки LDAP STARTTLS клиент OpenLDAP может запросить StartTLS и обратиться к корневому DSE без предоставления учетных данных:

ldapsearch -x -ZZ -H ldap://ldap.example.com:389 -b "" -s base namingContexts

Используйте фактический хост и порт LDAP в вашей системе развертывания. С помощью инструментов OpenLDAP -ZZзапросите StartTLS и рассматривайте неудачу в его установлении как ошибку. Если проверка завершится с ошибкой доверия или сертификата, сравните сертификат, возвращенный конечной точкой LDAP, с развернутым сертификатом и доверием к центру сертификации, доступным клиенту. Если проверка проходит успешно с одного узла, но завершается с ошибкой с другого, исследуйте различия в DNS, файлах центра сертификации или локальной конфигурации.

Шаг 7: Совместимость протокола следует рассматривать только после проверки сертификатов.

Установочное соединение также может завершиться неудачей, если клиент и сервер не могут согласовать версию протокола TLS или набор шифров. Это может произойти с устаревшими клиентами, пользовательскими мерами безопасности или настройками по умолчанию, специфичными для конкретной версии. Проверьте конечную точку с помощью актуального клиента OpenSSL и проверьте настройки TLS в Zimbra, чтобы узнать точную версию продукта. Избегайте копирования старых команд протокола с архивных страниц в более новую установку; конфигурация шифров и протокола может меняться между выпусками.

Не следует «исправлять» ошибку, включая SSLv3, ослабляя проверку или глобально отключая LDAP STARTTLS. В одной из тем на форуме Zimbra приводится исторический обходной путь, заключавшийся в отключении LDAP STARTTLS, но другой участник обсуждения справедливо предупредил, что отключение функции безопасности не является надежным способом восстановления сертификата. В собственных рекомендациях Zimbra по локальной конфигурации рекомендуется оставлять включенными межпроцессный TLS и LDAP STARTTLS. Используйте такое изменение только в качестве строго контролируемой, временной диагностики, если служба поддержки Zimbra посоветует вам это сделать, и немедленно восстановите безопасные настройки.

Как подтвердить ремонт

  • zmcontrol statusЗавершается без ошибки LDAP TLS, если именно она была причиной сбоя.
  • Затронутая конечная точка LDAP или SMTP предоставляет ожидаемый, действующий сертификат и полную цепочку издателей.
  • Проверка с того же хоста и по тому же сетевому пути проходит успешно в нужном режиме TLS.
  • В журналах Zimbra больше не отображаются ошибки проверки сертификатов или рукопожатия во время тестирования.
  • Для протокола SMTP отправьте тестовое сообщение в обоих направлениях и подтвердите доставку в соответствующих очередях или журналах.

Если сбой сохраняется, соберите полную информацию об ошибке, версию Zimbra, затронутую службу и имя хоста, даты сертификатов и SAN, результаты проверки и соответствующие строки журнала. Перед тем как делиться информацией, удалите закрытые ключи, учетные данные, адреса пользователей и конфиденциальные данные хоста. Точное сообщение является симптомом, а не полным диагнозом; имя службы и причина сбоя OpenSSL определяют правильный способ устранения проблемы.

Примечание к документации: страницы Zimbra, посвященные публичным сертификатам и TLS, содержат материалы для нескольких версий, а некоторые страницы с инструкциями по устранению неполадок специально заархивированы. Приведенные здесь команды соответствуют описанной в документации схеме командной строки, однако пути к сертификатам, права доступа и требования к перезапуску следует сверять с документацией для установленной версии Zimbra. Проверено 6 октября 2026 г.

Оставить комментарий

Устранение проблемы высокой загрузки ЦП в Jitsi Meet в браузерах клиентов.

Устранение проблемы высокой загрузки ЦП в Jitsi Meet в браузерах клиентов.

Диагностика скачков загрузки ЦП в браузере Jitsi Meet и снижение нагрузки на клиентское приложение путем проверки видеофайлов, эффектов камеры, графики браузера и настроек хоста.

Как отслеживать метрики Jitsi Videobridge с помощью Prometheus и Grafana

Как отслеживать метрики Jitsi Videobridge с помощью Prometheus и Grafana

Отслеживайте состояние Jitsi Videobridge, загрузку конференций и трафик с помощью встроенной точки доступа Prometheus, а затем анализируйте и отображайте данные в виде графиков в Grafana.

Как настроить пользовательское доменное имя для Jitsi Meet Docker

Как настроить пользовательское доменное имя для Jitsi Meet Docker

Настройте собственный домен для Jitsi Meet Docker с указанием DNS, PUBLIC_URL, HTTPS, Let's Encrypt, портов брандмауэра, настроек NAT и сквозной проверки.

Fix Zimbra Admin Console 404 Not Found After SSL Renewal

Fix Zimbra Admin Console 404 Not Found After SSL Renewal

Fix Zimbra Admin Console 404 errors after SSL renewal by checking the correct URL and port, proxy routing, service status, deployed certificates, and logs.

Исправлено предупреждение Nextcloud «Неправильно настроен PHP OPcache».

Исправлено предупреждение Nextcloud «Неправильно настроен PHP OPcache».

Узнайте, как диагностировать и устранять предупреждение Nextcloud о конфигурации PHP OPcache, проверив активные параметры PHP SAPI, ограничения размера, комментарии и настройки повторной проверки.

Исправление ошибок миграции базы данных Kopano после обновления версии MySQL.

Исправление ошибок миграции базы данных Kopano после обновления версии MySQL.

Для устранения неполадок, возникающих при миграции базы данных Kopano после обновления MySQL или MariaDB, проверьте резервные копии, версии серверов, режимы SQL, кодировку, состояние схемы и журналы.

Как настроить аутентификацию LDAP и Active Directory в Nextcloud

Как настроить аутентификацию LDAP и Active Directory в Nextcloud

Подключите Nextcloud к LDAP или Active Directory с помощью защищенного канала связи, фильтров пользователей и групп, атрибутов входа в систему и проверенной процедуры развертывания.

Как исправить уведомления Element Android без сервисов Google: руководство по UnifiedPush

Как исправить уведомления Element Android без сервисов Google: руководство по UnifiedPush

Исправление проблем с уведомлениями Element Android на телефонах без привязки к Google путем настройки UnifiedPush, разрешений Android, параметров батареи и надежных тестов проверки.

Исправлено предупреждение Nextcloud «В базе данных отсутствуют некоторые индексы».

Исправлено предупреждение Nextcloud «В базе данных отсутствуют некоторые индексы».

Удалите предупреждение Nextcloud об отсутствии индексов в базе данных с помощью официальной команды occ. Сначала сделайте резервную копию, просмотрите изменения, выполните восстановление и проверьте результат.

Как настроить единый вход (SSO) с помощью Keycloak в Element Web

Как настроить единый вход (SSO) с помощью Keycloak в Element Web

Настройте единый вход Keycloak для Element Web, подключив OIDC к Synapse, задав точный URL-адрес обратного вызова, сопоставив данные пользователя и протестировав выход из системы.