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):

    Code
    1. [calBackendLoader] Using libical backend at /usr/lib/icedove/extensions/{e2fda1a4-762b-4020-b5ad-a41df1933103}/components/libical-manifest
    2. [calSleepMonitor] Starting sleep monitor.
    3. [calTimezoneService] Loading resource://calendar/timezones/zones.json
    4. [calTimezoneService] Timezones version 2.2016c loaded
    5. [calICSCalendar] Refreshing birthdaysSMO
    6. [calICSCalendar] Unable to load stream - status: 2153390060
    7. *** BUG ***
    8. In pixman_region32_reset: Malformed region region
    9. 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

    Einmal editiert, zuletzt von smmmo ()

  • Du solltest dein Zertifikat nicht installieren müssen. Ich habe Debian stable und Let's encrypt funktioniert direkt.


    Ich vermute, dein Server ist falsch konfiguriert. Wenn du die URL hier nicht posten willst (zum Server, nicht zum Kalender!), schaue doch selber mal auf einer SSL-Test-Seite (z.B. https://www.ssllabs.com/ssltest/index.html), ob du auch die intermediate-certs sendest. Wenn der Server diese Zertifikate nicht sendet, kann das (gültige) Let's-encrypt-Zertifikat nicht überprüft werden (im Browser geht's oft dennoch, da dieser die intermediate-certs von anderen Seiten eventuell noch im Cache hält).

  • 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:

    Code
    1. [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

  • Das Ergebnis von ssllabs sieht ok aus, oder?

    Ja, da passt alles. Ich hatte den verdacht nur geäußert, da das ein häufiges Konfigurationsproblem ist :)


    [calICSCalendar] Unable to load stream - status: 2147500036

    Gibt es zu der Fehlermeldung eine Zeilennummer und ggf. einen Dateinamen (ich vermute calICSCalendar.js)? Dann kann man vielleicht nachvollziehen, an welcher stelle das Problem auftritt. Mit etwas Pech müsstest du aber selbst Hand anlegen, du kannst nicht zufällig ein bisschen JS?


    Ansonsten könntest du testhalber mal ein neues Profil versuchen, den Profil-Manager öffnet man auf der Konsole via (das --no-remote ist nur nötig, wenn dein Hauptprofil im Hintergrund weiterlaufen soll)

    Code
    1. icedove --no-remote -p


    Wenn es im neuen Profil auch nicht geht, hätten wir das Profil schonmal ausgeschlossen.

  • 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):


    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

  • Es kann sein, dass Services.io.* bereits automatisch auf Passwörter greifen kann. Zumindest testhalber könntest du das Passwort aber mal in der URL inkludieren, also im Sinne von

    Code
    1. https://username:password@domain.example.com/path/to/ics

    Funktioniert es dann? Nachteil ist natürlich, dass das Passwort hierbei im Klartext auf der Platte landet (ggf. Testaccount nehmen).

  • Ich würde versuchen, den Fehler systematisch weiter einzukreisen. Zunächst ein Test ohne verschlüsselte Verbindung. Wenn der funktioniert, dann erhärtet das den Hinweis auf eine Problematik mit dem Zert. Dann im nächsten Schritt der Fehlermeldung genauer nachgehen. Die besagt, der Herausgeber sei nicht bekannt. Also überprüfe, ob das Herausgeberzertifikat im TB korrekt bekannt ist und ihm auch vertraut wird.


    Zuvor denke nochmals über folgendes nach:


    seit einigen Tagen kann ich einen ics-Kalender nicht mehr sehen.

    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?


    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.

  • 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

  • Dann klingt es fast nach einem Thunderbird / Debian Bug. Vielleicht ein Seiteneffekt vom neu geplanten Branding (soll ja wohl wieder Thunderbird werden...)?


    Da es auch ohne SSL nicht geht, vermute ich, dass die Zertifikate allesamt in Ordnung sind.


    Ansonsten könnte man höchstens mal sicherstellen, dass nicht iptables oder andere Sicherheitsmaßnahmen greifen (z.B. wäre denkbar, dass sich der Name der binaries geändert hat, und Filterregeln darauf geachtet hatten). Zwecks Debugging würde ich (zumindest zusätzlich) auf Components.utils.reportError("LOGMESSAGE") zurückgreifen, da das meiner Erfahrung nach am häufigsten durchkommt. Mit Debuggern für Chrome-JS habe ich lange nicht mehr herumgespielt; damals (vor 3-5 Jahren) waren sie mir zu unzuverlässig.

  • Hallo smo,


    sieht aus, als wärst Du einen guten Schritt weiter. Dass im Stable Release alles funktioniert, ist eine gute Nachricht.


    Zu den beiden genannten Komponenten TB und Debian würde ich explizit noch das Lightning selbst nennen. Lightning ist insofern sensibel, als dass man stets die passende Version zur jeweiligen Version des TB benötigt. Da ist also vielleicht gar kein bug sondern nur ein Bundle aus Versionen, die (noch) nicht zusammenpassen.


    Das macht die Sache nicht einfacher, weil nicht klar ist, welche der Komponenten den Fehler bringt. Wo sollte man also einen Bug eröffnen? Ich würde es zunächst mal bei Debian melden. Die sind sicher daran interessiert zu erfahren, wenn im Umfeld des Testing Release etwas nicht funktioniert, bzw. welche Versionsstände zusammengepackt werden müssen, damit es funktioniert. Außerdem sind sie letztendlich für Icedove zuständig.


    Hast Du es eigentlich mal mit dem nativen Thunderbird + Lightning anstatt Icedove versucht?


    Tja, nur wie finde ich dir richtige Stelle?

    Falls Du noch weiter Debuggen willst, dann kannst Du natürlich immer so vorgehen, dass Du per Breakpoint möglichst früh in den Code einspringst und Dich dann in Einzelschritten vorarbeitest. Je nach Debugger kann man sich die Werte der Variablen in einem Fenster und/oder durch Darüberfahren mit der Maus anzeigen lassen. Dann solltest Du sehen können, wo und weshalb ein Fehler auftritt.


    Gruß


    Susanne

  • 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