FileZilla - Primärverbindungs- und Datenverbindungszertifikate stimmen nicht überein

1784
G_Hosa_Phat

Einer meiner Clients hat vor kurzem die oben genannte Fehlermeldung in der FileZilla Client- Software (unter Windows 7) erhalten, wenn ich eine Verbindung zu meinem FTP-Server ( WS_FTP-Server von Ipswitch ) herstelle. Bevor ich mich an die bisherige Problembehandlung halte, sind hier einige Punkte zu diesem Problem aufgeführt:

  • Dies ist der einzige meiner Kunden, bei dem dieses Problem aufgetreten ist (oder zumindest berichtet), und ich weiß, dass es andere Clients gibt, die die FileZilla-Client- Software verwenden.
  • Ich verwende die FileZilla Client- Software selbst und kann den Fehler beim Verbinden mit demselben Server nicht reproduzieren.
  • Dieser Fehler ist erst vor kurzem aufgetreten (innerhalb der letzten Tage). Zuvor konnte sich der Benutzer ohne Fehler mit demselben Server verbinden.
  • Die WS_FTP Server- Protokolle zeigen an, dass der Benutzer erfolgreich eine Verbindung hergestellt hat, zeigen jedoch keine Fehler an, die auf Probleme mit dieser Verbindung hinweisen.

Um dieses Problem zu beheben, habe ich Folgendes versucht:

  1. Verifiziert, dass das SSL-Zertifikat für meinen FTP-Server noch gültig ist (es läuft in ungefähr 10 Monaten ab).
  2. Alle Einstellungen bezüglich SSL / TLS in der WS_FTP-Serverkonfiguration wurden überprüft .
  3. Überprüfen Sie die Verbindungseinstellungen in der FileZilla Client- Software des Benutzers, indem Sie sie mit den Einstellungen in meinem Site Manager vergleichen.
  4. Befolgen Sie die Anweisungen in mehreren Beiträgen in den FileZilla-Foren und löschen Sie die "zwischengespeicherten Zertifikate", indem Sie die trustedcerts.xmlDatei umbenennen ( %APPDATA%\FileZilla\trustedcerts.xml) und die FileZilla-Client- Software das erneute Erstellen zulassen.
  5. Aktualisierte die FileZilla Client- Software des Benutzers auf die neueste Version.

Ich habe diese Informationen von der FileZilla-Forumseite aus gepostet. Da mir jedoch bewusst ist, dass das Problem möglicherweise die Client-Software, etwas im Netzwerk des Benutzers oder etwas in meinem Server ist, wollte ich das Netz etwas erweitern. Zu diesem Zeitpunkt bin ich nicht sicher, was ich sonst noch anschauen soll, und ich hoffe, dass mich wenigstens jemand in die richtige Richtung weisen kann. Ich neige zu etwas im Netzwerk des Benutzers, was möglicherweise zu dem Problem führt, aber ich möchte versuchen, Beweise dafür zu bekommen, bevor ich eine andere IT-Abteilung beschuldige. Jede Hilfe, die Sie leisten können, wäre sehr dankbar.

UPDATE: Ich habe eine Verbindung zur Workstation meines Kunden hergestellt und die von @Martin Prikryl in den Kommentaren vorgeschlagenen Elemente geprüft . Ich habe festgestellt, dass der Client eine domänengesteuerte Installation der Webroot SecureAnywhere® Business Endpoint Protection- Software verwendet. Sie können immer noch keine Verbindung herstellen, daher habe ich die Protokollinformationen dieses Mal aus dem FileZilla- Hauptfenster kopiert :

Status: Resolving address of ftp.company.com Status: Connecting to XX.XX.XX.86:21... Status: Connection established, waiting for welcome message... Status: Initializing TLS... Status: Verifying certificate... Status: TLS connection established. Status: Logged in Status: Retrieving directory listing... Status: Server sent passive reply with unroutable address. Using server address instead. Command: MLSD Response: 150 Transferring directory Error: Primary connection and data connection certificates don't match. Error: Transfer connection interrupted: ECONNABORTED - Connection aborted Response: 226 Transfer completed Error: Failed to retrieve directory listing

Ich habe auch die Zertifikatdetails zwischen seiner und meiner Maschine verglichen. Hier ist ein Screenshot meines Dialogfelds " Zertifikatsdetails ": My Certificate Details Dialog

Und hier ist ein Screenshot seines Dialogs " Zertifikatsdetails ": Client Certificate Details Dialog

Ich habe die URLs in den Bildern überarbeitet, aber sie passen alle zusammen. Betrachtet man die Fingerprint- Werte und die Details des Zertifikatsausstellerblocks, gibt es jedoch offensichtlich einige Abweichungen. Ich ließ den Benutzer den Webroot-Schutz vorübergehend deaktivieren (jemand aus seiner IT-Abteilung war zum Glück da, um uns zu helfen) und versuchte es erneut. Leider trat dasselbe Problem auf, und als ich das Zertifikat erneut überprüfte, zeigte es immer noch die gleichen Abweichungen, wenn es mit dem auf meinem Computer aufgelisteten verglichen wurde.

Ihr IT-Mitarbeiter versuchte auch, die Verbindung von einer Neuinstallation der FileZilla Client-Software auf einem anderen PC im selben Netzwerk herzustellen. Diese Verbindung ergab den gleichen Fehler. Ich habe die Möglichkeit vorgeschlagen, die FileZilla Client-Software auf einem Laptop zu konfigurieren, der mit einem anderen Netzwerk verbunden ist (z. B. der WLAN-Hotspot eines Mobiltelefons), um zu sehen, ob das Problem weiterhin besteht, aber dies war bisher noch nicht möglich.

Unser SSL - Zertifikat IST ein COMODO PositiveSSL Zertifikat, so dass jetzt nur muß ich bestimmen, was sein System / Netzwerk verursacht den Emittenten als Fortinet zu pflücken.

EDIT: Aus einer Laune heraus, habe ich eine neue Verbindung in meinem FileZilla - Client, wo ich ausdrücklich die IP - Adresse aus dem Benutzerverbindungsprotokoll angegeben ich oben geschrieben, nur um sicherzustellen, dass es war nichts anderes über die Art und Weise war ich zu verbinden. Ich habe keine Fehler erhalten, und das Dialogfeld " Zertifikatsdetails " zeigt dasselbe wie zuvor (außer dass der Host als IP-Adresse anstelle des DNS-Namens aufgeführt ist). Hier ist das Protokoll von meiner letzten Sitzung:

13:35:44 Status: Connecting to XX.XX.XX.86:21... 13:35:44 Status: Connection established, waiting for welcome message... 13:35:44 Status: Initializing TLS... 13:35:44 Status: Verifying certificate... 13:35:44 Status: TLS connection established. 13:35:45 Status: Logged in 13:35:45 Status: Retrieving directory listing...

UPDATE # 2: Ich habe gerade einen Rückruf vom Kunden erhalten, der mich darüber informiert, dass seine IT-Abteilung die Ursache des Problems gefunden und intern Änderungen vorgenommen hat, damit seine Verbindung funktioniert. Hier ist eine Zusammenfassung:

Vor mehr als einem Jahr hat unser Unternehmen die IP-Adresse unseres FTP-Servers geändert. Zu dieser Zeit haben wir an alle unsere Kunden und Partner eine E-Mail gesendet, um sie über diese Änderung zu informieren. Anscheinend bekam die IT-Abteilung dieses Kunden dieses Memo jedoch nicht, weil sie die IP-Adresse nicht erkannten und keine entsprechenden Regeln in ihrer Firewall hatten, um diesen Datenverkehr zuzulassen.

Die Tatsache, dass es seit über einem Jahr ohne Fehler funktioniert, stumpft mich immer noch ein bisschen aus, aber solange es jetzt funktioniert, lasse ich es (vorerst) los. Ich werde später eine Zusammenfassung zur Fehlerbehebung als Antwort posten, aber ich muss mich wieder an die Arbeit machen.

1
Wenn Sie auf die Sperre der FileZilla-Statusleiste doppelklicken, erhalten Sie auf Ihrem Computer dieselben Informationen (Fingerabdrücke usw.) wie auf dem Client-Computer? Martin Prikryl vor 6 Jahren 2
Ich habe versucht, mir das alles anzuschauen, kann mich aber an diesen Punkt nicht erinnern. Ich muss den Client kontaktieren und um Erlaubnis bitten, die Fernbedienung auf seinem Computer zu überprüfen, um sicher zu gehen, aber ich werde mir das unbedingt ansehen. Zur Klarstellung möchte ich noch einmal betonen, dass das Problem erst vor kurzem begann und das SSL-Zertifikat auf meinem Server sich zwischen seiner letzten erfolgreichen Verbindung und den jetzt aufgetretenen Fehlern nicht geändert hat. Schlagen Sie vor, dass der Zertifikat-Cache des Benutzers zwischen diesen beiden Ereignissen irgendwie beschädigt wurde? G_Hosa_Phat vor 6 Jahren 0
Ich glaube nicht, dass das irgendeinen Cache hat. Es ist eher so, dass einige Sicherheitssoftware als MITM fungiert, sich aber entweder nur auf die Kontrollverbindung oder nur auf die Datenverbindung auswirkt oder nicht dasselbe Zertifikat für sie generiert. Martin Prikryl vor 6 Jahren 1
Das macht Sinn. Möglicherweise verursacht eine kürzlich durchgeführte Aktualisierung der Sicherheitssoftware des Benutzers während der TLS-Aushandlung eine "Fehlinterpretation" des Zertifikats, die dann irgendwie die wahrgenommene Diskrepanz zwischen den Primär- und Datenkanalzertifikaten verursacht. Natürlich weiß ich nicht, welche Sicherheitssoftware der Client verwendet, aber ich werde dies zu meiner Liste hinzufügen, um zu überprüfen, wann ich das nächste Mal eine Verbindung zu seinem Computer herstelle. G_Hosa_Phat vor 6 Jahren 0

1 Antwort auf die Frage

0
G_Hosa_Phat

Bei meiner Suche nach der Fehlermeldung " Primäre Verbindung und Datenverbindungszertifikate stimmen nicht überein ", die von der FileZilla Client- Software gemeldet wird, deuten die meisten Lösungen auf eine falsche Konfiguration des FTP-Servers hin. Dies ist sicherlich ein gültiger "Schritt" zur Fehlerbehebung, es gibt jedoch einige weitere Schritte, die untersucht werden müssen - insbesondere, wenn der Endbenutzer zuvor erfolgreich eine Verbindung herstellen konnte.

Dieser spezifische Fehler bedeutet, dass eine grundlegende Internetverbindung zwischen der FileZilla Client- Software und dem FTP-Server hergestellt wurde. Das Problem liegt nicht in der Verbindung mit dem FTP-Server, sondern in der Aushandlung der SSL / TLS-Verschlüsselung der Kommunikation. Die (Release-) FileZilla-Client-Software lässt keine Fortsetzung der TLS-Verbindung zu, wenn Zweifel hinsichtlich der Gültigkeit des SSL-Zertifikats bestehen.

Die folgenden Schritte zur Fehlerbehebung sollten dazu beitragen, die Fehlerursache zu ermitteln und / oder zu beheben, oder zumindest einige Möglichkeiten beseitigen:

CLIENT-SEITIGE FEHLERSUCHE

  1. Überprüfen Sie die Verbindungseinstellungen des FTP-Clients, einschließlich:
    • Hostname / IP und Port
    • SSL / TLS-Option (en)
    • Anmeldeinformationen für FTP-Server (Benutzername / Passwort)
    • Server Typ
    • Übertragungsmodus (aktiv / passiv)
  2. Überprüfen oder löschen Sie alle zwischengespeicherten Zertifikatsinformationen auf dem Clientcomputer.
    • In der FileZilla Client- Software wird dazu die XML-Datei, in der diese Zertifikate gespeichert sind, gelöscht / umbenannt ( %APPDATA%\FileZilla\trustedcerts.xml).
  3. Stellen Sie sicher, dass die FTP-Client-Software auf dem neuesten Stand ist. Es ist möglich, dass andere Änderungen (FTP-Server-Updates, Änderungen der Netzwerkkonfiguration, Updates der Sicherheitssoftware usw.) ein Problem in der Kommunikation verursachen.
  4. Wenn sich der FTP-Client in einem lokalen Netzwerk befindet, versuchen Sie, eine Verbindung von einem anderen Computer im selben Netzwerk herzustellen. Wenn dieser andere Computer eine Verbindung herstellen kann, gilt das Problem für einen (oder mehrere) Computer.
  5. Deaktivieren Sie auf dem Client-Computer installierte Sicherheitssoftware. Einige A / V- oder andere Internet Security-Anwendungen können als "Man-in-the-Middle" fungieren, der die Kommunikation zwischen dem FTP-Client und dem FTP-Server stören kann.
  6. Versuchen Sie nach Möglichkeit, eine andere Internetverbindung für den Zugriff auf den FTP-Server zu verwenden.
    • Die "einfachste" Methode, die ich zum Testen gefunden habe, besteht darin, den WLAN-Hotspot meines Handys zu aktivieren und einen Laptop mit diesem Netzwerk zu verbinden.
  7. Wenn sich der FTP-Client hinter einer Firewall befindet, stellen Sie sicher, dass diese Firewall den FTP-Verkehr nicht blockiert oder auf andere Weise stört. Abhängig von der Firewall kann dies das Öffnen von Ports in der Firewall, das Auflisten der IP-Adresse des FTP-Servers oder andere Konfigurationsoptionen bedeuten.

WENN SIE DEN FTP-SERVER KONTROLLIEREN

Abhängig von der verwendeten FTP-Serversoftware gibt es natürlich eine Vielzahl von Dingen, die Sie überprüfen müssen. Ich führe hier nur die "Grundlagen" an.

  1. Überprüfen Sie die FTP-Serverprotokolle auf weitere Details zur fehlgeschlagenen Verbindung.
  2. Stellen Sie sicher, dass das auf dem FTP-Server installierte SSL-Zertifikat nicht abgelaufen ist und noch gültig ist.
  3. Überprüfen Sie die SSL / TLS-Konfigurationseinstellungen auf dem FTP-Server.
  4. Überprüfen Sie die öffentlichen (und / oder internen) DNS-Einträge und -Konfigurationen, die auf den FTP-Server verweisen.
  5. Stellen Sie sicher, dass der FTP-Server den Benutzer weder nach Benutzername noch nach IP-Adresse gesperrt / gesperrt hat. Dies kann (möglicherweise) auch Dinge enthalten, wie z. B. das Benutzerkonto, für das ein Kennwort aktualisiert / zurückgesetzt werden muss, oder andere interne Sicherheitseinstellungen.

WENN SIE DEN FTP-SERVER NICHT STEUERN

Wenden Sie sich an die für den FTP-Server zuständige Person / Firma. Stellen Sie ihnen die Ergebnisse der clientseitigen Problembehandlung zur Verfügung, um den Administrator bzw. die Administratoren bei der Fehlerbehebung beim Verbindungsende zu unterstützen.

  • HINWEIS: Da FileZilla ein Open-Source-Projekt ist, ist es möglich, den Quellcode abzurufen und zu ändern, sodass die Software diese potenzielle Gefahr ignoriert. Die Erklärung, welche Änderungen vorgenommen werden müssen, finden Sie in den FileZilla-Foren . Bitte beachten Sie jedoch, dass, während ich diesen Link bin auch, es sei denn, Sie sind nur diese Software in einer mit sehr kontrollierten Umgebung, würde ich nicht empfehlen, diesen Schritt.

Abhängig von der lokalen Umgebung des Clients müssen möglicherweise auch andere Schritte zur Problembehandlung ausgeführt werden. Wenn ich in meinen Schritten hier etwas offensichtliches übersehen habe, kommentieren Sie es bitte, damit ich es hinzufügen kann, falls jemand anderes auf dieses Problem stößt.

Verwandte Probleme