Sicherheitsausnahmeregel nicht nötig - aber Warnfenster bleibt


  • * Thunderbird-Version: 50.0
    * Betriebssystem + Version: Windows 10 Pro V1607
    * Kontenart (POP / IMAP): IMAP
    * Postfach-Anbieter (z.B. GMX): Wolfsland
    * Eingesetzte Antiviren-Software: Avira Free Antivirus
    * Firewall (Betriebssystem-intern/Externe Software): intern
    * Router-Modellbezeichnung (bei Sende-Problemen): Fritzbox 7390


    In jüngster Zeit erhalte ich in kürzeren Abständen (z.B. wenn ich mal kurz Thunderbird minimiere um mit anderen Programmen zu arbeiten) die folgende Meldung.


    Das macht auf mich den Eindruck, als wenn Thunderbird selbst gemerkt hat, dass eine ursprünglich für nötig befundene Ausnahmeregel nun doch nicht erforderlich ist.


    Wäre es dann nicht konsequent, wenn Thunderbird die Meldung gleich wieder löschen würde? Das ständige abbrechen nervt etwas!
    Vorsorglich noch der Hinweis, dass in meinem Virenschutz die Option "eMail-Schutz" deaktiviert ist.


    Gruß
    Nanuk

  • Hallo,

    Vorsorglich noch der Hinweis, dass in meinem Virenschutz die Option "eMail-Schutz" deaktiviert ist.

    wenn du das deaktivierst, dürfte dein Problem behoben sein.


    Nebenbei hast du wohl die Versionsnummer vom Firefox notiert und nicht die vom Thunderbird.


    MfG
    Drachen

  • Weshalb nicht? Schließlich möchte der TB ja auch eine Ausnahme für ein angeblich gültiges Zertifikat. :mrgreen:


    Spaß beiseite. Die Meldung sieht aus als hätte der Zertmanager des TB sich verschluckt. Wozu gehört das Zertifikat denn? Ich würde das Zertifikat einfach mal löschen und neu installieren.

  • Sorry meinerseits, da hat die Bilderkennung des Auges nicht funktioniert und hat die Vorsilbe "de" glatt unterschlagen und nicht mit ans ans Gehirn gemeldet :-/


    Mit freundlichen Grüßen
    Drachen

  • Hallo SusiTux,

    Wozu gehört das Zertifikat denn? Ich würde das Zertifikat einfach mal löschen und neu installieren.

    das Zertifikat ist von dem Mailserver, der mein Postfach hat oder vom CalDAV-Server, wo mein Kalender liegt oder vom CardDAV-Server, wo meine Kontakte liegen. Da alle auf dem selben Rechner sind, kann ich nicht erkennen, was gerade abgefragt wird. Ich müsste dazu Kontakt mit dem Admin aufnehmen. Aber sehr überzeugend scheint mit das nicht zu sein.


    Wie kann man denn der Entwicklergemeinde raten, die Erkenntnis, dass das Zertifikat OK ist, gleich in die Löschung der Meldung umzusetzen?


    Gruß
    Nanuk

    Einmal editiert, zuletzt von Nanuk ()

  • Hallo ...


    So richtig verstehe ich das Problem nicht.


    das Zertifikat ist von dem Mailserver, der mein Postfach hat. Ich müsste dazu Kontakt mit dem Postmaster aufnehmen.

    Es handelt sich dabei immer um ein öffentliches (!) Zertifikat. Ein jeder seriöser Provider hat dieses zum Vergleichen oder bei Bedarf zum Herunterladen auf seiner Webseite veröffentlicht.
    Bedingung ist natürlich, dass das herausgebende Trustcenter ein "etablierter" Herausgeber ist und dessen Herausgeberzertifikat in den diversen Browsern oder Mailclients bereits von Hause aus installiert wurde. Sollte das allerdings nicht der Fall sein (also ein so genanntes selbstsigniertes Zertifikat vorliegen => deutet auf "Billigheimer hin!), dann sollte dieses Herausgeberzertifikat ebenfalls auf der Webseite dieses Herausgebers zu finden sein. Alles andere ist arg unseriös, da die Nutzer keine Möglichkeit zu einer eigenen Prüfung haben.


    Und dann sollten natürlich auch sämtliche Zertifikatsdaten exakt mit den Gegebenheiten (CommonName, Gültigkeit von-bis, Verwendungszweck, eingetragenes Signaturzertifikat mit dem tatsächlichen Herausgeberzertifikat) übereinstimmen. DAS kann aber wirklich jeder Nutzer zumindest im Fehlerfall selbst überprüfen. Einfach das Zertifikat anzeigen lassen ... .


    Auf jeden Fall ist es richtig, dieses Zertifikat einfach aus dem Zertifikat-Manager zu löschen (vorher suchen). Wenn alles wie o.g. stimmt, wird das Herausgeberzertifikat geprüft und fertig ist ... .



    MfG Peter

    Thunderbird 45.8.x, Lightning 4.7.x, openSUSE Tumbleweed, 64bit
    S/MIME, denn ich will bestimmen, wer meine Mails lesen kann.
    Nebenbei: die Benutzung der (erweiterten) Suche, und von Hilfe & Lexikon ist völlig kostenlos - und keinesfalls umsonst!
    Und: Ich mag kein ToFu und kein HTML in E-Mails!

  • Die Meldung ist auf jeden Fall witzig. "Sicherheits-Ausnahme hinzufügen" - "Gültiges Zertifikat. Es gibt keinen Grund, eine Ausnahmeregel hinzuzufügen"


    Wie kann man denn der Entwicklergemeinde raten, die Erkenntnis, dass das Zertifikat OK ist, gleich in die Löschung der Meldung umzusetzen?


    Das ist etwas zu kurz gedacht. Gut, der TB ist, was die Meldung angeht, etwas unspezifisch. Sagen wir meinetwegen sogar arg unspezifisch. Aber wer sagt Dir denn, dass das Zertifikat inklusive der Kette ok ist? Um das festzustellen, musst Du schon in die Zertifikate reinschauen. Vermutlich stimmt da etwas nicht. Einfach ignorieren sollte der TB das deshalb nicht.


    das Zertifikat ist von dem Mailserver, der mein Postfach hat oder vom CalDAV-Server, wo mein Kalender liegt oder vom CardDAV-Server, wo meine Kontakte liegen

    Der Port 8443 ist etwas ungewöhnlich. Vermutlich handelt es sich um eine Port Redirection des SSL- / VPN-Ports 443. Von den öffentlichen Providern kenne ich das nicht. Bei Symantex Endpoint Security habe ich das schon einmal gesehen. Aber das verwendest Du ja nicht.
    Deshalb nehme ich mal an, dass es sich, wie Peter schon angedeutet hat, um selbst erstellte Zertifikate handelt. Das wiederum würde bedeuten, dass der TB von Haus aus den Herausgeber nicht kennt. In diesem Fall muss er sich melden.


    Gruß


    Susanne

  • Hallo,

    So richtig verstehe ich das Problem nicht.

    das Problem besteht darin, dass Thunderbird alle 20 Minuten eine Meldung produziert, die wieder gelöscht werden muss. In der Meldung steht, dass es kein Problem gibt, sondern das Zertifikat OK ist (siehe Post 1). Muss das sein? Ist das normal? Muss ich mich damit abfinden - oder lässt sich das verbessern?


    Das Zertifikat, das hier erst bemängelt und dann für OK befunden wird, ist von StartCom; die ausstellende CA ist im Thunderbird als Zertifizierungsstelle enthalten.
    Kein Mensch muss beim Verbindungsaufbau zu einem Rechner dessen Zertifikat von seiner Webseite herunterladen. Deswegen ist das Zertifikat auch nicht in meinem Zertifikatsspeicher enthalten und kann demzufolge auch nicht gelöscht werden.


    Ich sehe auch keinen großen Sinn darin, Zertifikatsinhalte zu checken - solange Thunderbind selbst zur Erkenntnis kommt, dass das Zertifikat tauglich ist und keine Ausnahmeregel erforderlich ist.


    Gruß
    Nanuk

  • Dann bitte ich dich untertänigst um Entschuldigung, dass ich versucht habe, dir gewisse Zusammenhänge zu erklären.
    Wird nicht wieder vorkommen.
    P.

    Thunderbird 45.8.x, Lightning 4.7.x, openSUSE Tumbleweed, 64bit
    S/MIME, denn ich will bestimmen, wer meine Mails lesen kann.
    Nebenbei: die Benutzung der (erweiterten) Suche, und von Hilfe & Lexikon ist völlig kostenlos - und keinesfalls umsonst!
    Und: Ich mag kein ToFu und kein HTML in E-Mails!

  • Der Port 8443 ist etwas ungewöhnlich. Vermutlich handelt es sich um eine Port Redirection des SSL- / VPN-Ports 443.

    Hallo SusiTux,
    das ist richtig. Ich habe inzwischen auch festgestellt, dass dieser Port nur für den Sync der Kontakte verwendet wird. Bei IMAP und CalDAV werden andere Ports benutzt.
    Vielleicht liegt es an meinem AddOn "CardBook". Ich werd mal mit Philippe Vigneau Kontakt auf nehmen.
    Gruß
    Nanuk

  • Dann bitte ich dich untertänigst um Entschuldigung, dass ich versucht habe, dir gewisse Zusammenhänge zu erklären.
    Wird nicht wieder vorkommen.

    Hallo Peter,
    das ist nicht das Problem. Wir leben hier alle von gegenseitger Unterstützung. Jeder nach bestem Wissen. Ich wollte Dir nur sagen, dass Deine Vernutung, es wird bei jedem https-Kontakt das Zertifikat gespeichert, nicht zutrifft.
    Gruß
    Nanuk

  • Vielleicht liegt es an meinem AddOn "CardBook". Ich werd mal mit Philippe Vigneau Kontakt auf nehmen.

    Das zumindest kannst Du Dir sparen. Philippe hat darauf keinen Einfluss.


    Die Funktionsweise ist ja grundsätzlich die, dass ein Server einen Dienst anbietet, nach dem sich die ihn nutzende Applikation richten muss. In diesem Fall ein CardDav-Server. Unter welchem Port dieser zu erreichen ist, ist allein die Angelegenheit dieses Servers, wobei es natürlich Standardports gibt, z.B. den Port 80 für http.
    In CardBook muss man einen abweichenden Port entsprechend einstellen. Bei mir, für meinen privaten Radicale-Server ist das z.B. der Port 5232. In Deinem Fall ist die Redirection auf den Port 8443 also von dem Admin so gewollt. Wenn das der gültige CardDav-Port ist, dann muss CardBook entsprechend eingestellt werden - nicht umgekehrt.


    Wenn Du nicht weißt, woher dieser Port in Deinem Fall stammt, dann frage den Admin. Vielleicht kommt er am Ende ja doch aus einer AV-Software?


    Zurück zum eigentlichen Problem. Meiner Meinung nach ziehst Du einen voreiligen Schluss. Die widersprüchliche Meldung des TB lässt ja zwei Möglichkeiten zu: Entweder es ist eine Ausnahme nötig oder sie ist es nicht. Du hast Dich offenbar bereits auf den zweiten Fall festgelegt, ohne dass es dafür klare Fakten gäbe.
    Ich kann aus der Ferne auch nicht beurteilen, welche der beiden Möglichkeiten zutrifft. Ich würde aber nicht gleich ausschließen wollen, dass in der Zertifikatskette etwas nicht stimmt.


    das Problem besteht darin, dass Thunderbird alle 20 Minuten eine Meldung produziert,

    Das könnte einen Hinweis geben, welcher Dienst diese Meldung verursacht. Was wird denn alle 20 Minuten gepollt, die Mails, der Kalender oder Kontaktdaten?


    Gruß


    Susanne

  • Wenn das der gültige CardDav-Port ist, dann muss CardBook entsprechend eingestellt werden - nicht umgekehrt.


    Wenn Du nicht weißt, woher dieser Port in Deinem Fall stammt, dann frage den Admin.

    Ja, das ist der richtige Port, der Sync klappt ja regelmäßig. Ich hab als Intervall 30 Minuten eingestellt. Wenn ich mir das Protokoll ansehe, dann steht dort immer in der 11. und 41. Minute jeder Stunde "Synchronisiere aufgrund des periodischen Syncs ...". Und weil CardBook als einzigste Anwendung diesem Port verwendet (IMAP nimmt 143 und CalDAV geht auf 5006) war meine Vermutung, dass es von dort kommt. Möglicherweise gibt es da Timeout-Parameter für die Prüfungen.


    Gruß
    Nanuk

  • Jetzt wird es interessant:


    Ja, das ist der richtige Port, der Sync klappt ja regelmäßig.

    von welchem Sync sprichst Du? Du hattest ja oben geschrieben:



    das Zertifikat ist von dem Mailserver, der mein Postfach hat oder vom CalDAV-Server, wo mein Kalender liegt oder vom CardDAV-Server, wo meine Kontakte liegen. Da alle auf dem selben Rechner sind, kann ich nicht erkennen, was gerade abgefragt wird.

    Dann beachte noch diesen Punkt:


    Und weil CardBook als einzigste Anwendung diesem Port verwendet (IMAP nimmt 143 und CalDAV geht auf 5006)

    Wenn CardBook diesen Port verwendet, dann nur, weil Du es so eingestellt hast. Daraus ergibt sich die Frage, ob dieser Port überhaupt der richtige ist. Hat der Admin den so vorgegeben?

  • Zur Information:
    Philippe Vigneau meint dazu:


    Hi


    this windows is shown when CardBook cannot connect to the server (status = 0)... this is something I should change...

    Philippe


    Ich nutze derzeit Version 15.1 von CardBook. Warte jetzt auf das nächste Release.


    Gruß
    Nanuk

    Einmal editiert, zuletzt von Nanuk ()

  • Hallo,


    ich habe jetzt mal ein wenig mit Philippe "gechattet". Schließlich sollte die Überprüfung der Zertifikate ja durch den TB erfolgen und nicht durch eine Erweiterung. Das ist natürlich auch so.


    Zum Problem: Laut Philippe ist es so, dass der TB bzw. dessen Zertifikatsprüfung bei Aufruf einer https-Verbindung eigentlich einen Status Code zurückgeben sollte, der etwas über das Ergebnis der Prüfung aussagt. Zum Beispiel:


    3: SSL_ERROR_NO_CERTIFICATE
    4: SSL_ERROR_BAD_CERTIFICATE
    8: SSL_ERROR_UNSUPPORTED_CERTIFICATE_TYPE
    9: SSL_ERROR_UNSUPPORTED_VERSION
    12 :SSL_ERROR_BAD_CERT_DOMAIN


    siehe auch https://developer.mozilla.org/…n_XMLHTTPRequest_over_SSL


    Das funktioniert aber nicht richtig. Deshalb kann CardBook nicht ohne weiteres unterscheiden, ob es tatsächlich ein Problem mit dem Zertifikat gab oder ob zum Bespiel nur die LAN/WLAN-Verbindung unterbrochen ist. CardBook erhält in beiden Fällen einen Return Code 0 und ruft dann den gezeigten TB-Dialog auf.
    Philippe überlegt, ob er das verbessern kann.


    @Nanuk,


    Wenn das alles so stimmt, dann bedeutet das in Deinem Fall zwei Dinge.

    • Es liegt entweder ein Problem mit der Verbindung vor. Das solltest Du bemerken.
    • Mit dem Zertifikat stimmt etwas nicht.

    In beiden Fällen bricht CardBook laut den Philippe den Versuch zu synchronisieren ab. Das steht aber im Widerspruch zu Deiner Aussage:


    Ja, das ist der richtige Port, der Sync klappt ja regelmäßig.


    Ich will damit sagen: Die Meldung erscheint nicht, wenn alles ok ist. Es gibt also u.U. Handlungsbedarf auf Deiner Seite.


    Etwas verwirrend sind für mich auch nach wie vor Deine beiden Aussagen:


    Da alle auf dem selben Rechner sind, kann ich nicht erkennen, was gerade abgefragt wird.

    und


    IMAP nimmt 143 und CalDAV geht auf 5006

    Ich nehme deshalb an, Du hast erst später herausgefunden, dass nur CardBook auf den Port 8443 geht?

  • Ich nehme deshalb an, Du hast erst später herausgefunden, dass nur CardBook auf den Port 8443 geht?

    So ist es. Anfangs wusste ich nicht, welche Verbindung die Meldung auslöst.


    Nach dem, was Philippe mir geschrieben hat, bin ich auch nicht mehr sicher, ob die Synchronisation klappt. CardBook meldet zwar "Kontakt xxx, yyy erfolgreich aktualisiert", meint damit aber wohl den lokalen Cache, nicht den Eintrag auf dem Server.


    Ich kann mir ehrlich gesagt nicht vorstellen, dass es am Zertifikat liegt. Ich greife ja auch mit anderen verschlüsselten Verbindungen auf diesen Server zu. Allerdings ist das Zertifikat auch für "subject alternative names" ausgestellt und einer davon wird in diesem Fall benutzt. Dies ist aber schon von Anfang an so und die Meldungen kommen erst seit etwa 3-4 Wochen.


    Jedenfalls vielen Dank für Dein Engagement in dieser Sache.


    Gruß
    Nanuk

  • Ich kann mir ehrlich gesagt nicht vorstellen, dass es am Zertifikat liegt.


    [...]


    Meldungen kommen erst seit etwa 3-4 Wochen

    Ich rate mal ins blaue, aber da ein Thunderbird-Beta verwendet wird: StartCom wurde seitens Mozilla das Vertrauen entzogen, da die CA falsche Zertifikate ausgestellt hatte. Die Änderung sollte im 51er Release von Firefox live gehen. Vielleicht ist sie in Thunderbird 50 bereits enthalten, oder deine Zertifikate wurden von StartCom rückdatiert und sind nun via OneCRL zurückgerufen worden?


    In jedem Fall wirst du neue Zertifikate von StartCom nicht lange mit Mozilla-basierender Software verwenden können.