- Dieses Thema hat 12 Antworten sowie 2 Stimmen und wurde zuletzt vor vor 7 Jahren, 10 Monaten von
aktualisiert.
-
Beiträge
-
Hallo,
wie ist der Emailabruf eines Clients eigentlich organisiert?
Wenn ich es richtig sehe, erfolgt der Emailabruf eines Users zwar auf Grundlage der auf dem Server gespeicherten Zugangsdaten aber der Abruf wird direkt vom Client erledigt? Wo werden dann die abgerufenen Emails gespeichert?Ich habe das Problem, dass auf einem Client der Emailabruf nicht funktioniert, der mit dem selben User auf einem anderen Client und auch mit einem Client direkt auf dem Server problemlos läuft.
Der Client meldet, dass er den Email-Server nicht erreichen kann. Die genaue Fehlermeldung kann ich leider gerade nicht angeben, da ich zurzeit keinen Zugriff auf dem Client habe. Das Problem hat sich erst gestern, beim abschließenden Test in der Kanzlei gezeigt.
Um den Fehler eingrenzen zu können, wären die obigen Informationen hilfreich.
Viele Grüße
bjkPS. Auf dem PC auf dem der Client läuft, können Thunderbird und Outlook das selbe Email-Postfach problemlos abrufen, weshalb ich davon ausgehe, das keine grundsätzlichen Probleme am PC bestehen.
Senden und Empfangen (SMTP, IMAP/POP) finden komplett auf dem Client statt. Mails werden nicht gespeichert, der Dialog zeigt immer den Zustand auf dem Server an. Es gibt allerdings ein clientseitiges Caching – bemerkbar bspw. wenn man eine einmal angesehene Email erneut öffnet – in dem Fall wird nicht nochmals vom Server geladen.
Auf welchem Betriebssystem läuft der Client?
Bitte mal die Logs des Clients per Mail zur Verfügung stellen – die liegen in einem Verzeichnis „.j-lawyer-client“ im Verzeichnis des Nutzers.
Grüße,
Jens
(j-lawyer.org)Das Betriebssystem auf dem PC ist Windows 7. Logs kann ich erst morgen zusenden, dann komme ich wieder an den PC. Dann kann ich auch die genaue Fehlermeldung angeben.
Die Logs dann per Email an die Impressums-Email?Grüße
bjkBei Windows würde ich immer auch einen Blick auf eventuell genutzte Desktop-Firewalls werfen.
Ja, bitte die Logs an info@… senden – danke!
Grüße,
Jens
(j-lawyer.org)Fehlermeldung laut Logs:
sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested targetAugenscheinlich vertraut die Java-Installation auf dem Client nicht dem SSL-Zertifikat das der IMAP-Server sendet. Handelt es sich um ein self-signed-Zertifikat?
Hat einer der Clients eine eigene separate Java-Installation? Eventuell überschreiben die Einstellungen diejenigen des im j-lawyer.org Client mitgelieferten Javas.
auch mal vergleichen auf beiden PCs:
echo %JAVA_HOME%
Datei „cacerts“ unter jre/lib/security im j-lawyer-client – VerzeichnisAuf dem PC ist ein Java 8 Update 111 installiert. Die Variable JAVA_HOME scheint nicht definiert zu sein, „echo %JAVA_HOME%“ liefert nur ein „%JAVA_HOME%“ zurück. Das ist aber auf dem anderen PC auch so.
Was soll ich an den cacerts-Dateien vergleichen? Das Öffnen im Editor zeigt nur Zeichensalat.
Das SSL-Zertifikat ist nicht selbstsigniert aber der Domainnamen stimmt nicht mit dem Namen im Zertifikat überein. Normalerweise bringen die Clients nur eine Zertifikatswarnung und auf den anderen Rechnern läuft j-lawyer ja auch mit diesen Einstellungen.
Trotzdem habe ich nun den Servernamen geändert, sodass keine Warnung mehr ausgegeben werden sollte. Starte ich den Client direkt auf dem Server, funktioniert der Abruf weiterhin problemlos, auf dem PC kommt weiterhin die gleiche Fehlermeldung.Viele Grüße
bjkHandelt es sich bei beiden PCs um Windows-PCs? Ein offensichtlicher Unterschied zw. dem Client auf Windows und dem Client auf Linux ist dass ich unter Windows die Java-Runtime mitliefere, unter Linux aber diejenige der Distribution verwende.
Nochmal zum Hintergrund:
Verschlüsselte Verbindungen werden vom Client entsprechend geprüft (die Zertifikate) – vereinfacht ausgedrückt: Ist die ausstellende CA vertrauenswürdig (sowas wie Verisign, Comodo, …)? Und: ist das Zertifikat vertrauenswürdig?
Eine dieser Prüfungen geht auf dem PC schief.In der cacerts – Datei stehen alle vertrauenswürdigen CAs. Wenn die CA die für Euren IMAP-Server relevant ist, nicht in dieser Datei enthalten ist, kommt bspw. der Fehler.
cacerts vergleichen:
<JAVA-VERZEICHNIS>\bin>keytool -list -v -keystore ..\lib\security\cacerts > c:\Temp\cacerts.txtleeres Passwort, falls gefragt wird.
Danach hast Du eine textuelle Reprästention der vertrauenswürdigen CAs. Es reicht auf das „Owner“-Attribut zu schauen – also ggf. das Textfile weiter zusammendampfen.
Dann mal ein Diff machen für die beiden cacerts.Sollten die Dateien identisch sein, können wir als nächsten Schritt noch die Zertifikate selbst prüfen und/oder schauen ob eine cacerts einer evtl. parallel installierten Java-Runtime gezogen wird.
Gruß,
Jens
(j-lawyer.org)Ja, beide sind Windows PCs, der Zweite mit Windows 10.
Ich habe zurzeit nur Fernzugriff auf den Problem-PC und den Server und vergleiche mit meinem Notebook, welches ich während der Installation als Test-Client genutzt habe. Auf dem lief der Emailabruf auch problemlos.Reicht der Autausch der cacerts auf dem Problem-PC gegen die cacerts-Datei von meinem Notebook? (Habe ich schon testweise durchgeführt, ändert nichts)
Wenn Du schreibst, dass Du unter Windows die Java-Runtime nicht mitlieferst, würde ich da die Unterschiede sehen. Die cacerts im j-lawyer-Verzeichnis sind ja erst durch die Installation des j-lawyer-Clients auf beide PCs gekommen und wurden, so nehme ich an, nicht verändert. Bleibt also nur die Java-Runtime.Zum Verständnis, was im j-lawyer-Verzeichnis unter jre liegt, ist nicht die runtime, die der Client nutzt? Genutzt wird die extra installierte Runtime (C:\Program Files (x86)\Java\jre1.8.0_111\bin)? Ist dann nicht die in diesem Verzeichnis liegende cacerts relevant und kann ich diese vielleicht mit der gesichert funktionierenden cacerts irgendwo auf dem Server austauschen?
Andersherum: unter Windows wird sie mitgeliefert, unter Linux nicht.
Reicht der Autausch der cacerts auf dem Problem-PC gegen die cacerts-Datei von meinem Notebook?
Nicht unbedingt. Wie gesagt kann es noch am Zertifikat selbst liegen (keystore der Java-Installation), oder daran daß sich ein parallel installiertes Java „vordrängelt“.
Kannst Du mal den Ordner „jre“ auf dem Problem-PC umbenennen und anschließend den jre-Ordner vom funktionierenden PC rüberkopieren?
Gruß,
Jens
(j-lawyer.org)Problem gefunden. Der Avast Antivirus klingt sich (scheinbar mit einem eigenen Zertifikat) in die SSL-Verbindung ein. Bei Thunderbid scheint das zu klappen, bei j-lawyer nicht. Das Deaktivieren dieses Schutzes der SSL-Verbindung in den Einstellungen des Antivirenprogramms ermöglicht dann den Email-Abruf über j-lawyer.
Danke erst einmal für die schnelle Hilfe und Unterstützung! 🙂
Genauer untersuche ich das, wenn ich wieder direkt vor Ort am PC bin.Viele Grüße
bjkDer Avast Antivirus klingt sich (scheinbar mit einem eigenen Zertifikat) in die SSL-Verbindung ein
OH. MY. GOD!
- Du musst angemeldet sein, um zu diesem Thema eine Antwort verfassen zu können.