Problem mit Zertifikat teknik.io

  • Hallo.
    Habe ein Problem mit TB 8.6.
    Bei Mailaccount kommt immer folgende Fehlermeldung:

    Zitat


    >19.02.2019, 19:47:06: FETCH - Zertifikat S/N: 04B0F87155EC5CC209615ED9022CA491E3EA, Algorithmus: ECC (256 Bits), ausgestellt von 03.02.2019 07:50:42 bis 04.05.2019 07:50:42, für 2 Host(s): *.teknik.io, teknik.io.
    >19.02.2019, 19:47:06: FETCH - Besitzer: "*.teknik.io".
    >19.02.2019, 19:47:06: FETCH - Aussteller: "US", "Let's Encrypt", "Let's Encrypt Authority X3". Gültig ab 17.03.2016 16:40:46 bis 17.03.2021 16:40:46.
    >19.02.2019, 19:47:06: FETCH - Root: "Digital Signature Trust Co.", "DST Root CA X3" Gültig ab 30.09.2000 21:12:19 bis 30.09.2021 14:01:15.
    !19.02.2019, 19:47:06: FETCH - TLS-Handshakefehler. Ungültiges Serverzertifikat (Das Zertifikat kann für diesen Zweck nicht genutzt werden)


    Habe den Account dann in Voyager 7.4.x.x angelegt und dort kam diese Fehlermeldung nicht -> hat einwandfrei funktioniert.

    Kann mir jemand auf die Sprünge helfen wie ich das auch in 8.6 wieder gerade gebogen bekomme?

    Gruß, L.S.

  • Benutzt du das The Bat! Adressbuch für Zertifikate oder Windows?
    Also unter Einstellungen → S/MIME und TLS → Windows API oder Interne?


    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.

  • Code
    Algorithmus: ECC (256 Bits)
    [...]
    TLS-Handshakefehler. Ungültiges Serverzertifikat (Das Zertifikat kann für diesen Zweck nicht genutzt werden)

    Vielleicht kommt TB! nicht mit ECC zurecht? Die Fehlermeldung deutet jedenfalls darauf hin, dass das Zertifikat ungeeignet ist bzw. dass TB! das annimmt.

    Das Zertifikat ist auch neu, erst seit Anfang Februar 2019. Damals im November 2018 gab's ja ausweislich des Protokolls noch eins mit RSA 2048 Bits, was wohl fast alle Mailprovider verwenden.

    Kannst du es testweise mit z.B. Thunderbird testen? Klappt's dort?

  • Dass die bei teknik.io nur noch ECDH/ECDSA verwenden ist wohl der Grund.

    Warum die nur die allerneusten Chiffren benutzen für ihre Mailserver ist mir unbekannt, aber das sperrt garantiert auch ältere Mailclients aus.


    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.

  • Das Problem ist nicht das Zertifikat per se sondern dass das Zertifikat mit dem Algorithmus ECC anstatt RSA signiert ist. Ich nehm' an The Bat! kann das Zertifikat dann nicht zum Verschlüsseln der SSL-Verbindung nehmen.

    Bitte melde das an den Ritlabs-Support als wichtigen Bug dass die bei The Bat! die Chiffren/Algorithmen verbessern!


    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.

  • 1. Kann bei Ritlabs keine Fehler melden
    2. Mit 8.8 selbes Problem
    3. Voyager 7.4.4.1
    Empfang geht!
    Log:


    Senden geht!
    Log:

    Voyager bringt folgende Fenster. Wenn ich OK klicke dann wird trotzt Warnung Email empfangen und versendet. Kann ich in 8.8 auch wieder einen Zustand herstellen, dass diese Warnfenster kommen und ich das abnicke?

  • FETCH - Verbinde mit POP3-Server mail.teknik.io auf Port 995

    Ich habe den Link zu der Seite mit Einstellungen bereits gepostet. Dort sind mehrere Möglichkeiten genannt. Versuche es mal mit STARTTLS und Port 110 und/oder ganz ohne Verschlüsselung (in TB! Verbindungstyp auf Standard setzen).


    Senden geht!

    Ich meinte, ob das Senden mit TB! geht.


    Voyager 7.4.4.1
    Empfang geht!

    Es klappt zwar im Ergebnis, aber ein Problem mit dem Zertifikat gibt's ausweislich des Protokolls auch in Voyager. Sonst würde auch das Fenster nicht erscheinen.

    Die Fehlermeldung "Das Zertifikat der Stammzertifizierungsstelle ist nicht vertrauenswürdig, da sie sich nicht im Adressbuch vertrauenswürdiger Stamm-ZAs befindet" bedeutet wohl, dass du zwar das Zertifikat "DST Root CA X3" hast, jedoch am falschen Ort. Vielleicht wird es deswegen bei dir als ungültig angezeigt. Ich habe nämlich dasselbe Zertifikat und bei mir ist es gültig. Im Reiter "Zertifizierungspfad" (letzter Screenshot) ist es bei mir nur einmal aufgeführt.

    Befindet es sich bei dir sowohl in Voyager als auch in TB! auch tatsächlich im Adressbuch "Trusted Root CA" (damit's erscheint, muss man im Menü "Ansicht | Zertifikatsdatenbanken" aktivieren) und nicht woanders?

    Wenn ja, wird es in TB! ebenfalls als ungültig angezeigt?

    Wenn alles richtig ist, dann musst du es wohl erneut importieren. Am besten es löschen und dann unter https://www.identrust.com/support/downloads herunterladen (dort im Abschnitt "TrustID X3"). Das Problem wirst du wohl haben, solange dieses Zertifikat bei dir ungültig ist.

  • Außerdem sollte man die TB!-Sprache auf Englisch umschalten, eine erneute Verbindung zum Server aufbauen und die Logdatei dann auf Englisch in BT posten, da die Fehlermeldung die Programmierer bestimmt interessieren würde.