Anzeige von ics per webdav funktioniert nicht mehr, evtl. wegen SEC_ERROR_UNTRUSTED_ISSUER?

Um Rückfragen vorzubeugen, bitten wir um folgende Angaben:
* Thunderbird-Version: 45.2.0 (Icedove/Debian testing)
* Lightning-Version: 4.7.2 (Iceowl/Debian testing)
* Betriebssystem + Version: Debian testing
* Eingesetzte Antivirensoftware: keine
* Firewall (Betriebssystem-intern/Externe Software): keine

Hallo,

seit einigen Tagen kann ich einen ics-Kalender nicht mehr sehen. Auf dem ipad und Android-Phone funktioniert es wie bisher problemlos.

Der Kalender ist auf meinem privaten Server hinterlegt und wird per webdav zugegriffen (mittels nginx). Das Ganze läuft ssl-verschlüsselt ab mit einem Zertifikat von letsencrypt.

Ich habe zum Test bereits ein neues Profil angelegt. Danach musste ich mein ssl-Zertifikat in Thunderbird/Icedove in den Einstellungen importieren: Screenshot. Nun bekomme ich folgende Ausgabe (mit aktiviertem debug-logging):

[calBackendLoader] Using libical backend at /usr/lib/icedove/extensions/{e2fda1a4-762b-4020-b5ad-a41df1933103}/components/libical-manifest
[calSleepMonitor] Starting sleep monitor.
[calTimezoneService] Loading resource://calendar/timezones/zones.json
[calTimezoneService] Timezones version 2.2016c loaded
[calICSCalendar] Refreshing birthdaysSMO
[calICSCalendar] Unable to load stream - status: 2153390060
*** BUG ***
In pixman_region32_reset: Malformed region region
Set a breakpoint on '_pixman_log_error' to debug

Der "status: 2153390060" bedeutet "SEC_ERROR_UNTRUSTED_ISSUER". D.h. das Zertifikat ist von einem nicht vertrauenswürdigem Aussteller? In meinem Fall ist das letsencrypt.

Was kann ich tun, damit das Zertifikat akzeptiert wird? Oder bin ich auf dem Weg?

Danke und Gruß
smo

Hallo,

danke für die Antwort.

Das Ergebnis von ssllabs sieht ok aus, oder? Unter "Certification Paths" tauchen die Zertifikate auf, wenn ich es richtig lese.

Testweise habe ich gerade Thunderbird 45.3.0 unter Windows installiert, dort funktioniert der Zugriff per Webdav sofort (nach Einrichten per Wizard). Allerdings kommt dort eine Abfrage bezgl. Username/PW die ich unter Debian nicht (mehr) bekomme, auch nicht wenn ich ein neues Profil anlege. Wenn ich den Thunderbird-Passwort-Manager öffne, dann sind auch unter Debian keine Passwörter hinterlegt.

Unter Debian bekomme ich ohne Import des Zertifikats diesen Fehler, was einem NS_ERROR_ABORT entspricht:

[calICSCalendar] Unable to load stream - status: 2147500036

Hm, was kann ich noch versuchen? Evtl. fehlt einfach nur die PW-Abfrage? Scheint fast so, also ob es nicht am Profil liegt, sondern irgendwo anders noch ein Setting nicht passt?

Gruß
smo

Hallo,

ein neues Profil hatte ich schon versucht (siehe mein vorheriger Kommentar), hat nichts geholfen. Unter einem anderen Linux-User tritt das Problem ebenfalls auf..

Leider kann ich kein JS, aber ich gebe mein Bestes.. Der Fehler tritt wie von dir vermutet in calICSCalendar.js in Zeile 226 auf (ich hatte den Kommentar dort mal testweise angepasst und dann diese Anpassung auch im log gesehen):

onStreamComplete: function(loader, ctxt, status, resultLength, result)
     {
         let forceRefresh = ctxt.QueryInterface(Components.interfaces.nsISupportsPRBool).data;
         let cont = false;
         if (Components.isSuccessCode(status)) {
             // Allow the hook to get needed data (like an etag) of the channel
             cont = this.mHooks.onAfterGet(loader.request, forceRefresh);
             cal.LOG("[calICSCalendar] Loading ICS succeeded, needs further processing: " + cont);
         } else {
             // Failure may be due to temporary connection issue, keep old data to
             // prevent potential data loss if it becomes available again.
             cal.LOG("[calICSCalendar] Unable to load stream - status: " + status);
}
[...]

Wann er hier reinläuft habe ich aber leider nicht verstanden. Wenn ich mit dem Addon "Tiny JavaScript Debugger" debugge, dann bleibt er an diesem Breakpoint nie stehen (an anderen schon).

Wenn ich einen Refresh auf den Kalender auslöse, dann läuft er in "doRefresh: function calICSCalendar_doRefresh(aForce)". Dort fällt mir auf, dass this.mUri zwar die richtig URL enthält, aber kein "username" und "password". Ich habe auch nicht verstanden wo diese beiden Werte herkommen sollten..

Viele Grüße
smo

Mit User/Passwort in der URL ändert sich das Verhalten leider auch nicht.

Hallo,

Zitat von SusiTux

Daraus schließe ich, dass es zuvor funktioniert hat. Die erste Frage lautet also: "Was hat sich verändert?" Hattest Du dieses Zertifikat zuvor auch schon in Benutzung?

Hab ich gemacht, bin aber zu keinem Ergebnis gekommen, da ich nicht sagen kann, wie lang dieser Kalender schon nicht mehr funktioniert. Thunderbird wurde zwischenzeitlich möglicherweise über die Paket-Aktualisierung erneuert, ebenso nginx (der den Kalender über webdav ausliefert), das Zertifikat habe ich vor ner Weile auch mal verlängern müssen..

Zitat von SusiTux

Zum Debugging:

Wenn Du da einen Breakpoint gesetzt hast, sollte die Ausführung an dieser Stelle stoppen. Wenn der Debugger richtig funktioniert und die Ausführung an dieser Stelle nicht unterbrochen wird, dann hast Du nicht die richtige Stelle erwischt.
Der Fehler selbst tritt übrigens nicht in Zeile 226 auf. Dort wird er nur geloggt. Wenn das überhaupt die richtige Stelle ist, dann wurde der Fehler bereits vorher festgestellt und zwar daran, dass in Zeile 219 der Wert von (Components.isSuccessCode(status)) den Fehler anzeigt. Wenn Du weiter debuggen willst, musst Du also die Stelle finden, an der dieser Wert gesetzt wird.

Tja, nur wie finde ich dir richtige Stelle?
Dass die Code-Zeile nur eine Log-Ausgabe ist, ist mir klar, das hatte ich schlecht formuliert. Daher ja meine Frage wer denn überhaupt die jeweiligen functions (s.o.) aufruft.. Ob der Debugger richtig funktioniert, kann ich nicht sagen, benutze ihn das 1. Mal..

Aktueller Stand:
-- ssl deaktiviert: Funktioniert über Chrome in neuem private Tab, aber nicht in Thunderbird
-- htaccess deaktiviert: Funktioniert über Chrome ein neuem private Tab (ohne Username/PW-Abfrage) aber nicht in Thunderbird (jetzt mit https://james-ross.co.uk/mozilla/misc/nserror?0x804B000D)

Workaround
Zum Test habe ich die 3 Debian-Versionen stable, testing, unstable gegeneinander in VirtualBox antreten lassen und herausgefunden, dass der Kalender nur mit dem Icedove aus stable funktioniert.
D.h. nach Downgrade auf die Icedove-Version aus Debian stable (1:45.2.0-1~deb8u1) funktioniert es wie gewünscht! Es scheint also definitiv an meiner Thunderbird-Version zu liegen (unter Windows hat der Kalender ja auch mit Thunderbird funktioniert).

Gruß
smo

Ich habe einen bug report bei Debian erstellt. Mal schauen was dabei herauskommt. Als Workaround kann ich übergangsweise mit der Version aus Debian stable arbeiten..

Vielen Dank für eure Hilfe!

Gruß
smo