Wie man den Zimbra-Fehler „TLS konnte nicht gestartet werden: SSL-Handshake fehlgeschlagen“ behebt

Diese Meldung Unable to start TLS: SSL handshake failedbedeutet, dass Client und Server die Aushandlung zum Aufbau einer verschlüsselten Verbindung nicht abschließen konnten. In Zimbra kann diese Meldung von verschiedenen Stellen stammen. Eine häufige Variante tritt auf zmcontrol statusund besagt, dass die Zertifikatsprüfung der Verbindung zum LDAP-Master fehlgeschlagen ist. Auch ein Mail-Client oder ein SMTP-Relay kann ein Handshake-Problem an einem öffentlichen Mail-Port melden.

Die Lösung hängt davon ab, welche Verbindung fehlgeschlagen ist. Beginnen Sie damit, den Dienst und den Hostnamen in den zugehörigen Protokollzeilen zu identifizieren. Überprüfen Sie anschließend das Zertifikat, die zugehörige Zertifikatskette, die Systemuhr und den TLS-Endpunkt. Vermeiden Sie es, TLS als erste Maßnahme zu deaktivieren: Dadurch kann das Problem verschleiert werden, während die interne Kommunikation des Mailservers geschwächt oder unterbrochen wird.

Was Sie wissen sollten, bevor Sie etwas ändern

TLS ist das Protokoll zur Verschlüsselung von Netzwerkverbindungen. Ein TLS-Handshake ist der erste Datenaustausch, bei dem sich die beiden Systeme auf die Verschlüsselungsparameter einigen und das Serverzertifikat validieren. STARTTLS beginnt als unverschlüsselte Verbindung und wechselt zu TLS, sobald beide Seiten dies anfordern. Sowohl LDAP als auch SMTP können STARTTLS verwenden, daher lässt sich aus dieser Fehlermeldung allein nicht der fehlerhafte Dienst identifizieren.

Notieren Sie sich vor der Ausführung von Reparaturbefehlen die Zimbra-Version, ob es sich um eine Einzel- oder Mehrknoteninstallation handelt, den genauen Befehl oder Client, der den Fehler verursacht, sowie die zugehörige Protokollzeile. Planen Sie die Zertifikatsbereitstellung oder den Neustart von Diensten während eines Wartungsfensters. Erstellen Sie vor der Bearbeitung von Zertifikatsdateien und Konfigurationen eine Sicherungskopie.

• Führen Sie administrative Befehle als das Konto und mit den Berechtigungen aus, die für Ihre Zimbra-Version erforderlich sind.
• Fügen Sie keine privaten Schlüssel, Passwörter oder ungeschwärzte E-Mail-Protokolle in Tickets oder öffentliche Foren ein.
• Ändern Sie die LDAP-Sicherheitsflags oder Protokolleinstellungen erst, wenn Sie wissen, welcher Endpunkt ausgefallen ist und dessen Zertifikat überprüft haben.

Schritt 1: Identifizieren Sie die fehlerhafte TLS-Verbindung

Reproduzieren Sie zunächst das Problem und lesen Sie die vollständige Fehlermeldung. Tritt diese auf, wenn Zimbra den Dienststatus prüft und Formulierungen wie „“ enthält when connecting to ldap master, untersuchen Sie die interne LDAP-TLS-Verschlüsselung. Schlägt die SMTP-Übermittlung nur bei einem E-Mail-Client fehl, überprüfen Sie den öffentlichen SMTP-Endpunkt sowie Hostname, Port und Verschlüsselungsmodus des Clients.

su - zimbra
zmcontrol status

Überprüfen Sie die letzten Zimbra-Protokolleinträge mit demselben Zeitstempel. Bei vielen Installationen befindet sich das Hauptprotokoll unter `/etc/log/` /var/log/zimbra.log; verwenden Sie den auf Ihrem Server konfigurierten Protokollspeicherort.

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

Achten Sie auf den Prozessnamen, den Remote-Host, den Port und weitere spezifische OpenSSL-Details wie Zertifikatsprüfungsfehler, abgelaufenes Zertifikat, unbekannter Aussteller oder Protokollwarnungen. Diese Details unterscheiden ein Zertifikatsvertrauensproblem von einer Netzwerk- oder Protokollabweichung.

Bei einem internen LDAP-Fehler prüfen Sie, welche LDAP-Hosts dieser Server verwendet. Fragen Sie die lokalen Konfigurationsschlüssel einzeln ab und vergleichen Sie deren Hostnamen mit DNS und dem Serverzertifikat.

zmlocalconfig ldap_url
zmlocalconfig ldap_master_url
zmlocalconfig ldap_starttls_supported
zmlocalconfig ldap_starttls_required

Die Verfügbarkeit und Ausgabe der Schlüssel können je nach Zimbra-Version und Knotenrolle variieren. Es handelt sich hierbei um Diagnosewerte; ändern Sie keinen Wert, nur weil er in der Ausgabe erscheint. Die Zimbra-Dokumentation beschreibt die Rolle der LDAP-STARTTLS-Einstellungen und empfiehlt, internes TLS aktiviert zu lassen: Lokale Konfigurationswerte für Zimbra TLS und STARTTLS .

Schritt 2: Systemuhr, DNS und Erreichbarkeit prüfen

Die Zertifikatsvalidierung ist von der Serveruhr abhängig. Bei einer deutlichen Abweichung kann ein gültiges Zertifikat fälschlicherweise als ungültig oder abgelaufen angezeigt werden. Überprüfen Sie daher die Uhrzeit auf dem Zimbra-Host sowie auf allen an der Verbindung beteiligten LDAP-Master- oder Replikatservern.

date -u
getent hosts ldap.example.com

Ersetzen Sie ldap.example.com<LDAP-Hostname> durch den in der Konfiguration oder im Protokoll gefundenen LDAP-Hostnamen. Stellen Sie sicher, dass dieser zur erwarteten Serveradresse aufgelöst wird und dass der konfigurierte LDAP-Port über die Host-Firewall und das Netzwerk erreichbar ist. Bei Installationen mit mehreren Knoten testen Sie die Verbindung vom Zimbra-Knoten, der den Fehler protokolliert hat, zum tatsächlichen LDAP-Knoten – nicht nur von Ihrer Workstation aus.

Für eine clientseitige SMTP-STARTTLS-Verbindung zeigt die SMTP-Fehlerbehebungsanleitung von Zimbra das Testen von Port 25 mit OpenSSL. Port 587 wird ebenfalls häufig für die Nachrichtenübermittlung mit STARTTLS verwendet. Verwenden Sie den im E-Mail-Client konfigurierten Hostnamen und Port.

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

Für SMTP auf Port 25 ersetzen Sie [hier fehlende Angabe ] 587durch [hier fehlende Angabe 25]. Port 465 verwendet implizites TLS, daher fügen Sie -starttls smtpbei Tests dieses Ports keine [hier fehlende Angabe] hinzu. Eine erfolgreiche TCP-Verbindung beweist nicht automatisch, dass das Zertifikat vertrauenswürdig ist oder dass der Client den richtigen Sicherheitsmodus verwendet. Weitere Informationen finden Sie im Zimbra-Leitfaden zur Fehlerbehebung bei SMTP und OpenSSL .

Schritt 3: Überprüfen Sie das von Zimbra tatsächlich bereitgestellte Zertifikat

Ein Zertifikat ist ein signiertes Identitätsdokument für einen Server. Es muss für den von Clients verwendeten Hostnamen gültig sein, innerhalb seines Gültigkeitszeitraums liegen und von einer Zertifizierungsstelle stammen, der die Verbindungskomponente vertraut. Ein Zertifikat kann im Browser korrekt angezeigt werden, obwohl auf LDAP, Postfix oder einem Proxy-Knoten ein anderes Zertifikat verwendet wird.

Als Zimbra-Administrator können Sie das von Zimbra als bereitgestellt gemeldete Zertifikat einsehen:

/opt/zimbra/bin/zmcertmgr viewdeployedcrt

Prüfen Sie für jedes aufgeführte Zertifikat den Betreff bzw. den alternativen Subjektnamen (SAN), den Aussteller, das Ablaufdatum und die Dienste. Der SAN sollte den Hostnamen enthalten, der tatsächlich für die LDAP- oder Mailverbindung verwendet wird. Stellen Sie außerdem sicher, dass alle Knoten in einer Multi-Server-Umgebung über das erwartete Zertifikat und die zugehörige Zertifikatskette verfügen. Zimbra weist darauf hin, dass die Anzeige der bereitgestellten Zertifikate serverseitig erfolgt. Führen Sie die Prüfung daher auf jedem relevanten Knoten durch.

Falls Sie die Quellzertifikatsdateien besitzen, überprüfen Sie deren Datum und Namen vor der Bereitstellung:

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

Ersetzen Sie den Beispielpfad durch die Zertifikatsdatei, die Sie auswerten. Ein fehlender SAN, ein abgelaufenes End- oder Zwischenzertifikat, ein falscher Hostname oder ein für einen anderen Server ausgestelltes Zertifikat können allesamt dazu führen, dass die Validierung fehlschlägt.

Schritt 4: Überprüfen Sie den privaten Schlüssel und die Zertifikatskette.

Die Zertifikatskette ist die Abfolge von Ausstellerzertifikaten, anhand derer ein Client das Serverzertifikat zu einer vertrauenswürdigen Zertifizierungsstelle zurückverfolgen kann. Fehlt in der Kettendatei ein Zwischenzertifikat oder enthält sie die falsche Kette, kann der Client den Server ablehnen, selbst wenn das Endzertifikat aktuell ist. Zertifikat und privater Schlüssel müssen zudem zusammengehören.

Für ein kommerzielles Zertifikat bieten die Zertifikatstools von Zimbra einen Verifizierungsschritt. Passen Sie die Dateipfade an Ihre Installation und Zertifizierungsstelle an:

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

Fahren Sie nur fort, wenn die Überprüfung bestätigt, dass Zertifikat und privater Schlüssel übereinstimmen und die Zertifikatskette gültig ist. Stellen Sie nach einer fehlgeschlagenen Überprüfung kein Zertifikat bereit. Verwenden Sie die von der Zertifizierungsstelle bereitgestellte Zwischenzertifikatskette und das von Ihrer Zimbra-Version erwartete Kettenformat. Erstellen Sie keine Kette durch Raten oder Anhängen nicht zugehöriger Stammzertifikate.

Der Zertifikatsleitfaden von Zimbra dokumentiert die Verifizierungs- und Bereitstellungssequenz, einschließlich der CA-Kette: Zimbra-Zertifikatinstallation und CLI-Tools . Die zugehörige Seite zur Fehlerbehebung bei Zertifikatsketten erläutert außerdem Fehler bei der Ausstellerkettenverifizierung: Leitfaden zur Zimbra-Zertifikatskette .

Schritt 5: Zertifikat korrigieren und sicher bereitstellen

Wenn die Überprüfung ein abgelaufenes Zertifikat, einen falschen Schlüssel, ein fehlendes Zwischenzertifikat oder eine Hostnamenabweichung ergibt, beschaffen oder generieren Sie die korrekten Dateien vor der Bereitstellung. Befolgen Sie die Vorgehensweise für Ihre Zimbra-Version und Ihren Zertifikatstyp. Für ein kommerzielles Zertifikat hat der dokumentierte Befehl im Allgemeinen folgende Form:

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

Verwenden Sie exakt die für Ihre installierte Version dokumentierte Befehlssyntax und Berechtigungen. Die Zimbra-Befehlszeilenschnittstelle (CLI) kann Zertifikate für Komponenten wie MTA, LDAP und Proxy installieren, daher kann die Bereitstellung mehrere Dienste beeinträchtigen. Stellen Sie in einer Umgebung mit mehreren Knoten sicher, dass das Zertifikat auf jedem relevanten Server, einschließlich des LDAP-Masters, korrekt bereitgestellt wurde.

Nach einer verifizierten Bereitstellung sollten die Zimbra-Dienste während des geplanten Wartungsfensters neu gestartet werden, falls dies im Rahmen des Release-Verfahrens erforderlich ist. Anschließend sollten der Dienststatus und die bereitgestellten Zertifikate überprüft werden:

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

Ein Neustart unterbricht den E-Mail- und Webzugriff, während die Dienste angehalten und wiederhergestellt werden. Führen Sie ihn nicht ohne Weiteres auf einem stark ausgelasteten Produktivserver aus. Die Zimbra-Zertifikatsanleitung beschreibt die Verwendung zmcontrol restartnach der Bereitstellung und die Überprüfung des Ergebnisses viewdeployedcrt.

Schritt 6: LDAP-Vertrauenskonfiguration prüfen, ohne TLS zu deaktivieren.

Wenn das Zertifikat selbst verifiziert wird, der LDAP-Client von Zimbra es aber dennoch ablehnt, überprüfen Sie die LDAP-Vertrauensstellung und den fehlerhaften Knoten. In der archivierten MTA-Fehlerbehebungsnotiz von Zimbra werden eine ungültige CA-Kette, abgelaufene CA-Zertifikate und unerwartete Dateien als /opt/zimbra/conf/camögliche Ursachen für LDAP-STARTTLS-Fehler aufgeführt. Betrachten Sie dies als diagnostischen Hinweis und nicht als Grund, Dateien zu löschen: Vergleichen Sie das Verzeichnis mit einer bekannten, funktionierenden Sicherung oder versionsspezifischen Anweisungen und sichern Sie dessen Inhalt, bevor Sie Änderungen vornehmen.

Für eine einfache LDAP STARTTLS-Abfrage kann ein OpenLDAP-Client StartTLS anfordern und die Root-DSE abfragen, ohne Anmeldeinformationen anzugeben:

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

Verwenden Sie den tatsächlichen LDAP-Host und -Port Ihrer Umgebung. OpenLDAP-Tools -ZZfordern StartTLS an und behandeln einen Fehler bei der Verbindungsherstellung als solchen. Schlägt diese Prüfung mit einer Vertrauens- oder Zertifikatsmeldung fehl, vergleichen Sie das vom LDAP-Endpunkt zurückgegebene Zertifikat mit dem bereitgestellten Zertifikat und der für den Client verfügbaren CA-Vertrauensstellung. Wenn der Test auf einem Knoten erfolgreich ist, auf einem anderen jedoch fehlschlägt, untersuchen Sie Unterschiede in DNS, CA-Dateien oder der lokalen Konfiguration.

Schritt 7: Protokollkompatibilität erst nach Zertifikatsprüfungen berücksichtigen

Ein Handshake kann auch fehlschlagen, wenn sich Client und Server nicht auf eine TLS-Protokollversion oder eine Verschlüsselungssuite einigen können. Dies kann bei veralteten Clients, benutzerdefinierten Sicherheitsmaßnahmen oder versionsspezifischen Standardeinstellungen vorkommen. Testen Sie den Endpunkt mit einem aktuellen OpenSSL-Client und überprüfen Sie die TLS-Einstellungen von Zimbra für die jeweilige Produktversion. Vermeiden Sie es, alte Protokollbefehle aus archivierten Seiten in eine neuere Installation zu kopieren; die Konfiguration von Verschlüsselung und Protokoll kann sich zwischen den Versionen ändern.

Beheben Sie den Fehler nicht, indem Sie SSLv3 aktivieren, die Verifizierung schwächen oder LDAP STARTTLS global deaktivieren. In einem Thread im Zimbra-Forum findet sich zwar ein älterer Workaround, der LDAP STARTTLS deaktivierte, doch ein anderer Nutzer warnte zu Recht davor, dass die Deaktivierung einer Sicherheitsfunktion keine zuverlässige Zertifikatsreparatur darstellt. Zimbra empfiehlt in seinen eigenen Konfigurationshinweisen, Interprozess-TLS und LDAP STARTTLS aktiviert zu lassen. Verwenden Sie eine solche Änderung nur als streng kontrollierten, temporären Diagnosetest, wenn Sie vom Zimbra-Support dazu aufgefordert werden, und stellen Sie die sicheren Einstellungen umgehend wieder her.

Wie man die Reparatur bestätigt

• zmcontrol statuswird ohne den LDAP-TLS-Fehler abgeschlossen, falls dies die fehlgeschlagene Operation war.
• Der betroffene LDAP- oder SMTP-Endpunkt stellt das erwartete, nicht abgelaufene Zertifikat und die vollständige Ausstellerkette bereit.
• Ein Test vom selben Host und Netzwerkpfad aus ist im vorgesehenen TLS-Modus erfolgreich.
• Die Zimbra-Protokolle zeigen zum Testzeitpunkt keine Zertifikatsprüfungs- oder Handshake-Fehler mehr an.
• Senden Sie für SMTP eine Testnachricht in beide Richtungen und überprüfen Sie die Zustellung in den entsprechenden Warteschlangen oder Protokollen.

Falls der Fehler weiterhin besteht, erfassen Sie bitte die vollständige Fehlermeldung, die Zimbra-Version, den betroffenen Dienst und Hostnamen, die Zertifikatsdaten und den SAN, die Verifizierungsausgabe sowie die relevanten Protokollzeilen. Schwärzen Sie vor der Weitergabe private Schlüssel, Anmeldeinformationen, Benutzeradressen und sensible Hostdetails. Die genaue Fehlermeldung ist ein Symptom, keine vollständige Diagnose; der zugehörige Dienstname und die OpenSSL-Fehlerursache bestimmen die richtige Lösung.

Dokumentationshinweis: Die Seiten zu öffentlichen Zertifikaten und TLS von Zimbra enthalten Material aus mehreren Versionen, und einige Seiten zur Fehlerbehebung sind explizit archiviert. Die hier aufgeführten Befehle entsprechen dem dokumentierten CLI-Muster. Zertifikatspfade, Berechtigungen und Neustartvoraussetzungen sollten jedoch anhand der Dokumentation der installierten Zimbra-Version überprüft werden. Geprüft am 6. Oktober 2026.