Ungültiges Serverzertifikat für GMail

  • Hallo, Ich habe seit heute gleiches Problem. The Bat 8.8.9 (64-Bit)
    Was kann man machen, kann man irgendwo ein gültiges Zertifikat herunterladen ?

    Code
    09.04.2020, 20:41:29: FETCH - Connecting to POP3 server pop.googlemail.com on port 995
     09.04.2020, 20:41:29: FETCH - Initiating TLS handshake
    >09.04.2020, 20:41:29: FETCH - Certificate S/N: 8991F54E268142CF080000000035ED42, algorithm: ECC (256 bits), issued from 3/24/2020 6:48:05 AM to 6/16/2020 6:48:05 AM, for 1 host(s): pop.googlemail.com.
    >09.04.2020, 20:41:29: FETCH - Owner: "US", "California", "Mountain View", "Google LLC", "pop.googlemail.com".
    >09.04.2020, 20:41:29: FETCH - Issuer: "US", "Google Trust Services", "GTS CA 1O1". Valid from 6/15/2017 12:00:42 AM to 12/15/2021 12:00:42 AM.
    >09.04.2020, 20:41:29: FETCH - Root: "GlobalSign Root CA - R2", "GlobalSign", "GlobalSign". Valid from 12/15/2006 8:00:00 AM to 12/15/2021 8:00:00 AM.
    !09.04.2020, 20:41:29: FETCH - TLS handshake failure. Invalid server certificate (The certificate cannot be used for this purpose).
  • Im Ritlabs Forum wird über dasselbe Problem seit 6.4. geschrieben, viele mit verschiedenen Antiviren-Programmen. Dort habe ich eben folgendes gefunden:

    "You may disable (uncheck) the option "Do not put The Bat! to Windows Task Bar" and restart The Bat!, until we fix this issue."
    Ein user hat das in der V 9.1.12 versucht und sagt es funktioniert jetzt wieder bei ihm.

    Ich sitze schon voll auf der Leitung und weiß im Moment nicht, was ich da umstellen sollte. Ist das hier:

    Man muss nur lange genug am Ufer sitzen und irgendwann schwimmt der Feind Rücken nach oben vorbei.

  • Also ich sehe jetzt technisch nicht den Zussammenhang mit der Taskbar und dem Zertifikatsfehler.
    Habs aber mal probeweise gemacht.

    Resulttat mit der 8 er keine Besserung.

    Was mich allerdings stutzig macht ist, woher kommt das Zertifikat?
    Ich meine laut Austeller sollte es von Google stammen.
    Über die Seriennummer hab ich derzeit noch nichts herrausfinden können, ob es tatsächlich von denen kommt.

    Soweit ich das richtig erkenne, bekomme ich es ja von Google und nicht umgekehrt.

    Gruß Christian

  • Danke Christian!

    Punkto Google Zertifikate habe ich vorhin auch etwas gefunden, aber das ist für mich nur ein Wald voller Bäume und bei den ersten wird mir gesagt, daß die schon installiert sind wenn ich auf die DER-Links klicke.

    https://pki.goog/

    Man muss nur lange genug am Ufer sitzen und irgendwann schwimmt der Feind Rücken nach oben vorbei.

  • Ja bin ich auch schon gewesen.
    Ja wenn du mit Firefox draufgehts sagt dir die Meldung nur, dass die im Firefox sind.
    Firefox hat seinen eigenen Zertifikatsspeicher und nutzt nicht den von Windows.

    Die müssen aber im Windows unter vertrauenswürdige Stammzertifikate stehen.
    In dem Fall mit Rechtsklick speichern und dann anklicken.

    Bin auch grade dabei. Die Haupt CA sind aber schon drin wie ich festgestellt habe.
    Der import der GTS Root r1-4 bringt aktuell auch nichts.

    Bin nicht so überzeugt das es daran liegt.

    Die Meldung sagt ja, "Das zertifikat kann nicht für diesen Zweck genutzzt werden",
    heisst für mich , das es nicht für TLS Email gedacht ist.

    Also die Schlüsselverwendung ist nicht dafür ausgelegt.

    Gibts in TheBat den nicht ein Debuglog mit einstellbaren Verbose-level, wo man sich das Zertifikat mal anschauen kann?
    Im VerbindungsLog (POP) sieht man garnix.

    Gruß Christian

  • @smith007
    Ich fuhrwerke da gar nicht herum, weil das alles so fremd für mich ist. Ich lasse jetzt die ein- und ausgehenden Mails einfach nicht mehr von Avast überprüfen, damit ich alles bekomme von gmail. Keine zufriedenstellende Lösung, aber im Moment wohl die einzige für mich. Vielleicht ergibt sich in den nächsten Tagen im Ritlabs Forum was.
    Schönen Abend, bleib gesund

    Man muss nur lange genug am Ufer sitzen und irgendwann schwimmt der Feind Rücken nach oben vorbei.

  • Verstehe ich das richtig das bei dir Avast die Ursache war ?
    Heisst du klammerst den googleaccount aus und dann gehts?

    Ich hab hier den FortiClient aber der macht nix im Emailverkehr.
    Hab ich auch schon abgeschaltet, selbes Problem.

    Deep Inspection (SSL) in der Fortigate (FireWall) ist aus und auch keine IPS-Protection aktiv.
    Auch die Certificate Inspection ist aus. Bin da schon soweit alles durch.

    Aber so schnell gebe ich nicht auf ;)

    Gruß Christian

  • Ich habe ein paar Tests gemacht. Der Zerifikatsfehler tritt erst seit v8.4 auf. Alle Versionen davor sind nicht betroffen. So kann man z.B. ohne Probleme eine Verbindung zu GMail in v8.3 aufbauen. Es wird ständig das richtige 2048-Bit Zertifikat verwendet.

    In v8.4 gab's verschiedene Änderungen bezüglich TLS etc. Ich habe leider keine Betas mehr, die zwischen v8.3 und v8.4 erschienen sind. Es gab immerhin ca. 34 Stück davon. In irgendeiner wurde wohl etwas verändert. Offensichtlich hat Google erst neulich etwas bei sich umgestellt, so dass es erst jetzt mit TB!-Versionen größer als 8.3 zu Problemen führt. Der Fehler wurde den Berichten von vielen Usern zufolge in der letzten v9.1.12 behoben.

    Daraus folgt, dass wenn man auf GMail angewiesen ist, man entweder v9.1.12 oder eine vor v8.4 nutzen muss. Bei Bedarf kann ich v8.3 hochladen. Dann muss man natürlich auch auf alle Fixes und Neuerungen seit v8.4 verzichten.

    Vielleicht kann man Ritlabs noch überzeugen, eine gefixte v8 zu erstellen. Betroffen ist leider auch die letzte v8.8.9.12.

  • Hallo Sanyok,

    recht vielen Dank für deine Tests.
    Dann wissen wir zumindest schon mal, dass die Ursache Im Programm selber zu suchen ist.

    Nun wäre für mich jetzt kein Beinbruch auf die 9er zu Upgraden wenn es denn 100% geht und nicht wieder wo
    was anderes aufgerissen wird.

    Müsste mal schauen was den so alles gefixed wurde seit der 8.3er wenn es nur Kleinigkeiten sind wäre es zumindest erstmal ein Workaround.

    Gruß Christian

    PS: Wenn du die 8.3er hochladen würdest wäre das sehr nett.

  • Stimmt - yay mit der tb83032-32 klappt es tadellos. Also warten ob TB ne 8.x fixt oder auf der alten 8.3 bleiben oder auf 9.x gehen - vielen DAnk Sanyok

    Viele Grüsse Yaqwa
    The Bat! Home 11.x (32bit) NAU | Win 11 Pro x64 | ...seit Version 1.47 dabei...... (Gott bin ich alt) :bat:

  • Verstehe ich das richtig das bei dir Avast die Ursache war ?
    Heisst du klammerst den googleaccount aus und dann gehts?

    Ich hab hier den FortiClient aber der macht nix im Emailverkehr.
    Hab ich auch schon abgeschaltet, selbes Problem.

    Deep Inspection (SSL) in der Fortigate (FireWall) ist aus und auch keine IPS-Protection aktiv.
    Auch die Certificate Inspection ist aus. Bin da schon soweit alles durch.

    Aber so schnell gebe ich nicht auf ;)

    Gruß Christian

    Heute war es das erste Mal morgens, daß dam im Protokoll Avast aufschien, ich müßte schauen, was die Tage zuvor war.
    Ein- und Ausgang des Mailchecks durch Avast betrifft alle Mailkonten. Jetzt habe ich aber endlich über die engl. Hilfeseite von Avast gefunden, wie ich einstellen kann, daß ich SSL in Avast deaktiviere. Die Überprüfung von Ein- und Ausgang habe ich wieder aktiviert und im Moment kann ich empfangen - senden habe ich noch nicht versucht.

    Beste Grüße

    Man muss nur lange genug am Ufer sitzen und irgendwann schwimmt der Feind Rücken nach oben vorbei.

  • Ich habe mir mal eben die Changellogs angesehen.
    Hier mal die der 8.4
    https://www.ritlabs.com/de/products/th…n-history/7122/

    Da gibt ei paar interessante Schalter die eingeführt wurden.

    (...)

    • New command-line parameter "/TLS_VERSION_RANGE:0-3" to specify lowest and highest SSL/TLS version minor byte number that The Bat! should support. "0" means SSL 3.0, "1" means TLS 1.0, "2" means TLS 1.1 and "3" means "TLS 1.2". For example, to disable SSL 3.0, use "/TLS_VERSION_RANGE:1-3". Another example to only allow TLS 1.2 is "/TLS_VERSION_RANGE:3-3"
    • New command-line parameter "/TLS_DISABLE_PERFECT_FORWARD_SECRECY" to disable perfect forward secrecy

    (...)

    Ich glaube da spiel ich mal ein bischen mit rum ;)

    ich tippe mal darauf:
    Added support for TLS Server Name Indication (SNI) Extension.
    It is useful when multiple servers are sharing the same IP address.
    For more information on SNI, see https://en.wikipedia.org/wiki/Server_Name_Indication


    Gruß Christian

    PS: Hab die 8.3 bei mir noch gefunden. Man löscht ja nix ;)

    Nachtrag:
    Also mit den Schaltern für die TLS Version erreicht man nix.
    Ich hab jetzt die 8.3er Exe getauscht und nun rennt alles schön sauber.

    Ist jetzt zwar nicht die Lösung aber aktuell war mit GMAIL kein Blumenpott mehr zu gewinnen.
    Wurde immer schlimmer von 10 versuchen war vielleicht 1mal ein Erfolg zu sehen.


    Nachtrag2:
    Ich hab mal den Schalter hier probiert:

    /TLS_DISABLE_PERFECT_FORWARD_SECRECY

    Und bis jetzt gehts auch mit der 8.8.9 er. Jeder Abruf ohne Fehler.
    Hatte mich jetzt nur auf die TLS Versionen konzentriert gehabt.
    Ist der Schalter draussen dann Peng.

    Inspiriert durch den Changelog der 9.1.12
    https://www.ritlabs.com/de/products/th…n-history/7354/


    The Bat! did require "Key Encipherment" or "Key Agreement" in "Key Usage" certificate attribute for TLS even
    if the certificate was only used to sign ephemeral keys to provide perfect forward secrecy.
    If a server only supports perfect forward secrecy TLS cipher suites,
    the certificate used by this server may have no "Key Encipherment" or "Key Agreement" in the "Key Usage" attribute

  • Ich hab mal den Schalter hier probiert:

    /TLS_DISABLE_PERFECT_FORWARD_SECRECY

    Und bis jetzt gehts auch mit der 8.8.9 er. Jeder Abruf ohne Fehler.

    Ich kann bestätigen, dass es mit diesem Kommandozeilenparameter auch in der letzten v8.8.9 bzw. v8.8.9.12 in Bezug auf GMail klappt. Jedoch ist die Frage, ob's auch mit Mailservern funktionieren wird, die PFS erfordern. Das sind vor allem die, die komplett auf TLS 1.2 und/oder TLS 1.3 umgestellt haben. Sollte dann jeder selbst testen.

  • Ich kann bestätigen, dass es mit diesem Kommandozeilenparameter auch in der letzten v8.8.9 bzw. v8.8.9.12 in Bezug auf GMail klappt. Jedoch ist die Frage, ob's auch mit Mailservern funktionieren wird, die PFS erfordern. Das sind vor allem die, die komplett auf TLS 1.2 und/oder TLS 1.3 umgestellt haben. Sollte dann jeder selbst testen.

    Sorry, für einen PC-Dummy, wie/was/.. stellt man da ein?

    Man muss nur lange genug am Ufer sitzen und irgendwann schwimmt der Feind Rücken nach oben vorbei.

  • @Briard
    Die Desktopverknüpfung für The Bat! suchen
    einfach drauf klicken
    Alt+Return drücken
    Im Feld Ziel am Ende das einfügen (Leerzeichen vor dem / und am Ende von .._SECRECY nicht vergessen!!!)
     /TLS_DISABLE_PERFECT_FORWARD_SECRECY 
    Mit OK bestätigen

    Nun kannst du The Bat! mit dem neuen Parameter starten.


    The Bat! Pro 11.x BETA (32bit) | Win 11 Pro x64 | GnuPG 2.4.x | XMP + Regula

    Wer mich Er oder der Drache nennt, bekommt von der Drachin Pratze und Feuer zu spüren.

    2 Mal editiert, zuletzt von GwenDragon (10. April 2020 um 12:27)

  • Ein Leerzeichen sollte aber dazwischen sein.


    Sieht bei mir dann z.B. so aus: "C:\Program Files\The Bat!\thebat64.exe" /TLS_DISABLE_PERFECT_FORWARD_SECRECY


    Gruß Christian

    Nachtrag:
    Ups hattest du ja geschrieben ;)

  • Irgendwie ergibt das keinen Sinn. Laut yaqwa funktioniert es in v8.3.0.32. Vor der v8.4, in der es ja nicht mehr funktioniert, kamen noch die beiden .33 und .34 Betas. Offensichtlich gibt's Probleme bereits seit einer dieser beiden Versionen.

    Im Changelog zu .33 steht, dass PFS in den früheren Versionen stets deaktiviert gewesen sei, selbst wenn man den Kommandozeilenparameter /TLS_DISABLE_PERFECT_FORWARD_SECRECY, der PFS deaktiviert, nicht benutzte. Also hat man wohl in .33 PFS aktiviert. Das führte aber wahrscheinlich zu Problemen mit einigen Mailservern, so dass man in der nächsten .34 PFS wieder deaktivierte und den neuen Kommandozeilenparameter /TLS_FORCE_PERFECT_FORWARD_SECRECY einführte, der PFS bei Bedarf wieder aktivieren soll.

    Dadurch muss man doch die gleiche Situation wiederhergestellt haben, die auch schon vor .33 herrschte. Wieso muss man dann aber jetzt plötzlich diesen Kommandozeilenparameter verwenden und in den Versionen vor .33 nicht? ?(

    Außerdem braucht man doch PFS für TLS 1.2 und GMail unterstützt doch auch TLS 1.2. Wieso muss man es dann extra ausschalten? ?(

    Vielleicht wurde PFS in TB! von Anfang an nicht korrekt implementiert und, da es früher auch ohne PFS klappte, es niemanden gejuckt hat. Korrigiert wurde das erst jetzt in v9.1.10/9.1.12, als es bei vielen oder gar allen ohne den entsprechenden Kommandozeilenparameter, den früher bestimmt kaum jemand benutzte, nicht mehr mit GMail und womöglich auch anderen Mailprovidern klappte. Wäre v8 noch aktuell, hätte man's bestimmt auch die gefixt. So muss man aber mit dem Kommandozeilenparameter auskommen.