Behebung eines Kopano-SSL-Handshake-Fehlers auf einem benutzerdefinierten Port

Definieren Sie, wie eine erfolgreiche Lösung aussieht

Ein Kopano-SSL-Handshake-Fehler bedeutet, dass Client und Server keine TLS-Verbindung herstellen oder diese nicht abschließen konnten. Der benutzerdefinierte Port kann für einen Teil der Konfiguration korrekt, für einen anderen jedoch falsch sein. Bevor Sie Zertifikate oder Protokolleinstellungen ändern, ermitteln Sie, welcher Dienst den Port verwendet und ob dort TLS erwartet wird.

Für eine funktionierende Konfiguration akzeptiert der vorgesehene Port eine TLS-Verbindung, stellt ein für den Hostnamen des Clients gültiges Zertifikat bereit und ermöglicht den Abschluss des nächsten Protokollschritts. Ein Browser sollte die Anmeldeseite der Webanwendung ohne Zertifikatswarnung erreichen. Ein Kopano Core-Client sollte sich über den entsprechenden TLS-Port und, sofern konfiguriert, über sein vertrauenswürdiges Clientzertifikat verbinden. Eine erfolgreiche TLS-Prüfung allein beweist jedoch nicht, dass die Anmeldung bei der Webanwendung, die Kopano-Authentifizierung oder die E-Mail-Zustellung funktionieren.

Zuerst trennen wir die beiden gängigen Portkonfigurationen.

Für Kopano Core verifiziert: Das Kopano Core Administrator Manual 8.0 beschreibt einen nativen TLS-Listener, der von Kopano Core gesteuert wird server_listen_tls. Das Beispiel verwendet Port 237, gibt an, dass der Port geändert werden kann, und konfiguriert Zertifikats- und CA-Dateien in der Konfigurationsdatei /etc/kopano/server.cfg. Das Handbuch zeigt außerdem, wie Clients einen https://Server-Socket mit dem passenden Port und Client-Zertifikat verwenden. Siehe Kopano Core: SSL-Verbindungen und -Zertifikate sowie Kopano Core-Spezialkonfigurationen .

Für den Zugriff auf Webanwendungen gilt Folgendes: Benutzer öffnen üblicherweise eine Browser-URL, die von Apache, Nginx oder Kopano Web bereitgestellt wird. TLS kann auf diesem Frontend-Server beendet werden, während er Anfragen an die Kopano-Dienste weiterleitet. Das Kopano-Handbuch beschreibt das HTTP-Proxying zum Core-Listener auf Port 236, während die Kopano-Web-Anleitung die TLS-Zertifikatseinstellungen beschreibt /etc/kopano/kwebd.cfg. Der HTTPS-Port des Frontends ist nicht automatisch identisch mit dem Core-TLS-Port. Weitere Informationen finden Sie im Core-Reverse-Proxy-Beispiel und in der Kopano-Web-Installationsanleitung .

Aktion: Notieren Sie die Client-URL, den benutzerdefinierten Port, den Prozess, der dort lauschen soll, und ob die TLS-Verschlüsselung am Proxy oder im Kopano-Kern endet. Ändern Sie nicht beide Listener gleichzeitig.

1. Überprüfen Sie, welche Dienste am benutzerdefinierten Port lauschen.

Ersetzen Sie auf dem Kopano-Host 8443unten stehende Ports durch den Port, bei dem der Fehler auftritt:

sudo ss -ltnp | grep ':8443'

Eine entsprechende Zeile sollte einen Listening-Socket anzeigen. Fehlt eine Zeile, ist der Dienst nicht an diesen Port gebunden oder an eine andere Adresse. Gehört der Port zu einem lokalen Reverse-Proxy, überprüfen Sie dessen virtuellen Host. Handelt es sich um den nativen TLS-Port von Kopano Core, überprüfen Sie die Konfiguration server_listen_tls. /etc/kopano/server.cfgEin Prozess, der nur auf diesem Port lauscht, 127.0.0.1kann keine direkten Remote-Verbindungen annehmen; dies kann beabsichtigt sein, wenn ein Proxy vorgeschaltet ist.

Prüfen Sie außerdem die Host-Firewall, die Cloud-Firewall sowie alle Load Balancer- und NAT-Regeln. Der öffentliche Port muss den vorgesehenen internen Listener erreichen können. Ein Timeout oder eine Verbindungsablehnung deutet auf Probleme mit der Erreichbarkeit oder der Listener-Konfiguration hin; sie bedeutet nicht zwangsläufig ein ungültiges Zertifikat.

2. TLS-Prüfung auf dem exakten Hostnamen und Port

Testen Sie von einem Client-Rechner aus den öffentlichen Endpunkt mit OpenSSL. Verwenden Sie den im Zertifikat angegebenen DNS-Namen, nicht eine nicht zugehörige IP-Adresse:

openssl s_client -connect mail.example.com:8443 -servername mail.example.com -showcerts

Prüfen Sie das vorgelegte Zertifikat, das ausgehandelte Protokoll und die Verschlüsselung sowie etwaige Verifizierungsfehler. Diese -servernameOption sendet den TLS-SNI-Hostnamen; dies ist relevant, wenn ein Server mehrere TLS-Sites hostet. OpenSSL dokumentiert diese Optionen im Handbuch zu s_client . Drücken Sie Strg+C, um die interaktive Prüfung zu beenden.

Fehlt das Zertifikat, verwendet der Endpunkt möglicherweise unverschlüsseltes HTTP, der falsche Dienst belegt den Port oder ein Proxy leitet an den falschen Upstream-Server weiter. Ist ein Zertifikat vorhanden, dessen Name, Aussteller oder Ablaufdatum jedoch falsch sind, korrigieren Sie die Zertifikatsauswahl oder -kette am TLS-Endpunkt. Ein Hostnamenkonflikt lässt sich nicht durch Ändern des Kopano Core-Listener-Ports beheben.

Für einen browserseitigen Endpunkt fahren Sie mit Folgendem fort:

curl -v https://mail.example.com:8443/webapp/

Die ausführliche Ausgabe hilft, die TLS-Verifizierung von HTTP-Antworten wie Weiterleitungen, 404- oder 502-Fehlern zu unterscheiden. Ein 404-Fehler nach erfolgreichem Handshake deutet auf ein Pfad- oder Routingproblem hin, nicht auf einen TLS-Aushandlungsfehler. Zur einmaligen Diagnose curl -vkkann angezeigt werden, ob das Umgehen der Zertifikatsprüfung das Ergebnis ändert. Deaktivieren Sie die Zertifikatsprüfung niemals in Browsern, Clients oder Proxys.

Wichtiger Hinweis: Kopano Core verwendet natives TLS mit Clientzertifikaten. Ein einfacher s_clientTest ohne Clientzertifikat kann abgelehnt werden, selbst wenn der TLS-Listener korrekt funktioniert. Falls der Server eine Clientauthentifizierung anfordert, wiederholen Sie den Test mit dem autorisierten Clientzertifikat und -schlüssel oder verwenden Sie den konfigurierten Kopano-Serviceclient. Geben Sie niemals einen privaten Schlüssel in einem Befehlsprotokoll oder Support-Ticket preis.

3. Das Protokoll dem Listener zuordnen

Ein häufiger Fehler bei der Konfiguration benutzerdefinierter Ports besteht darin, einen HTTPS-Client so zu konfigurieren, dass er einen einfachen HTTP-Listener kontaktiert, oder HTTPS-Datenverkehr an einen Upstream-Server weiterzuleiten, der HTTP erwartet. Schema und Port müssen denselben Endpunkt beschreiben.

• https://mail.example.com:8443/webapp/Das bedeutet, dass der Browser TLS auf Port 8443 erwartet.
• Das dokumentierte Beispiel von Kopano Core sendet HTTP-Anfragen über einen Proxy an 127.0.0.1:236. Wenn Ihre Bereitstellung dieses Muster verwendet, muss der vorgelagerte Proxy verwenden http://, obwohl die öffentliche Browserverbindung HTTPS nutzt.
• Für natives Kopano Core TLS verwendet das Beispiel im Handbuch server_listen_tls = *:237eine Client-URL, die mit „237“ beginnt https://. Wenn Sie Port 237 durch einen benutzerdefinierten Port ersetzen, müssen Sie alle abhängigen Clients und Proxys auf denselben Wert aktualisieren.

Prüfen Sie, ob kopierte Konfigurationszeilen hinsichtlich Port oder Schema voneinander abweichen. Überprüfen Sie in einer Multi-Server-Umgebung auch die veröffentlichte Server- oder Proxy-URL: Ein Client kann eine anfängliche Verbindung herstellen, diese aber abbrechen, nachdem Kopano ihn auf einen alten Hostnamen oder Port umgeleitet hat.

4. Reparieren Sie die Listener- und Zertifikatskonfiguration.

Falls es sich um den nativen TLS-Listener von Kopano Core handelt, bearbeiten Sie die bestehende Konfiguration, anstatt doppelte Direktiven hinzuzufügen. Im Folgenden finden Sie ein vereinfachtes Beispiel für einen benutzerdefinierten Port; passen Sie die Zertifikatspfade und die Zertifizierungsstelle an Ihre Installation an:

server_listen_tls = *:1237
server_ssl_ca_file = /etc/kopano/ssl/ca.pem
server_ssl_key_file = /etc/kopano/ssl/server.pem
server_ssl_key_pass = your-key-passphrase

Das Kopano-Handbuch beschreibt die Einstellungen für Listener, Zertifizierungsstelle, Serverschlüssel und Schlüsselpasswort und erfordert kopano-servernach dieser Änderung des nativen Listeners einen Neustart. Stellen Sie sicher, dass die installierte Version die angezeigten Optionen unterstützt; Paketstrukturen und Anweisungen können abweichen. Schützen Sie das Schlüsselverzeichnis und vergewissern Sie sich, dass das Kopano-Dienstkonto die erforderlichen Dateien lesen kann.

Stellen Sie sicher, dass das Zertifikat für den tatsächlich von Clients verwendeten Hostnamen ausgestellt ist, innerhalb seines Gültigkeitszeitraums liegt und alle erforderlichen Zwischenzertifikate enthält. Das Kopano-Handbuch weist darauf hin, dass die Komponenten den allgemeinen Namen und die alternativen Antragstellernamen des Zertifikats überprüfen. In einer TLS-Umgebung mit mehreren Servern muss der Server der Zertifizierungsstelle vertrauen, die die Clientzertifikate signiert hat, und autorisierte Clientzertifikate müssen konfiguriert sein. Verwenden Sie für einen öffentlichen Browserdienst nicht vorschnell ein selbstsigniertes Zertifikat anstelle eines bestehenden.

Wenn TLS bei Apache, Nginx oder Kopano Web terminiert, konfigurieren Sie Zertifikat und benutzerdefinierten listenPort stattdessen auf diesem Frontend. Legen Sie anschließend Upstream-Schema und -Port entsprechend dem tatsächlichen Listener des Backends fest. Aktivieren Sie Upstream-TLS nicht allein deshalb, weil die öffentliche Seite HTTPS verwendet; vergewissern Sie sich zuerst, dass der Backend-Port ebenfalls TLS unterstützt.

5. Überprüfen und laden Sie den richtigen Dienst neu.

Führen Sie vor dem Neustart eines Webservers eine Konfigurationsprüfung durch, beispielsweise sudo nginx -tfür Nginx oder sudo apachectl configtestApache. Falls der Test einen Fehler meldet, beheben Sie diesen vor dem Neustart. Verwenden Sie den auf Ihrer Distribution installierten Dienstnamen; zum Beispiel:

sudo systemctl restart kopano-server
sudo systemctl status kopano-server --no-pager

Starten Sie Kopano Core nur neu, wenn Sie dessen Konfiguration geändert haben. Bei einer Änderung des Ports oder Zertifikats, die nur im Frontend vorgenommen wurde, validieren und laden Sie stattdessen den Frontend-Dienst neu. Überprüfen Sie unmittelbar nach der Änderung dessen Journal oder Fehlerprotokoll und wiederholen Sie den exakten OpenSSL-Handshake vom Client-Netzwerk aus. Der Handshake sollte nun das erwartete Zertifikat anzeigen. Testen Sie anschließend die eigentliche WebApp-URL oder die Kopano-Client-Verbindung, da ein erfolgreicher TLS-Handshake allein weder die Anwendungsroute noch die Authentifizierung validiert.

Lesen Sie das Ergebnis, bevor Sie weitere Änderungen vornehmen.

• Kein Listening-Socket: Überprüfen Sie den konfigurierten Listener, den Dienststatus und die Bindungsadresse.
• Verbindung abgelehnt oder Zeitüberschreitung: Überprüfen Sie Firewall, NAT, Load Balancer und ob der Zielport erreichbar ist.
• Falsches Zertifikat: Überprüfen Sie das auf dem Endpunkt konfigurierte Zertifikat, das auf diesen Port antwortet, einschließlich der SNI-Auswahl und der Zertifikatskette.
• TLS funktioniert lokal, aber nicht remote: Vergleichen Sie den Pfad des öffentlichen Proxys oder Load Balancers mit dem lokalen Listener und überprüfen Sie die weitergeleiteten Host- und Portwerte.
• Der Handshake war erfolgreich, die Webanwendung jedoch nicht: Überprüfen Sie den HTTP-Status, den Proxy-Pfad, die PHP-/Webanwendungsprotokolle und die Kopano-Core-Verbindung. Fahren Sie auf der Anwendungsebene fort.
• Nur Core-Clients schlagen fehl: Überprüfen Sie deren server_socketEinstellungen für benutzerdefinierten Port, vertrauenswürdige Zertifizierungsstelle und Clientzertifikat. Der Core-TLS-Pfad erfordert möglicherweise eine gegenseitige Zertifikatsauthentifizierung.

Eine zuverlässige Lösung ändert nur den Endpunkt, der den fehlgeschlagenen Handshake ausführt. Das für dieses Verfahren verfügbare Kopano Core Administrator Manual ist Version 8.0.0. Die darin enthaltenen Beispiele sollten mit den installierten Paketen und den lokalen Handbuchseiten abgeglichen werden. Wenn Ihre Bereitstellung eine andere Kopano-Version, einen Container oder einen verwalteten Reverse-Proxy verwendet, überprüfen Sie die aktuelle Konfiguration dieser Komponente, bevor Sie die Beispielanweisungen anwenden.