Handshakefehler bei all meinen all-inkl.com E-Mailadressen

    Hallo.

    Folgende Fehlermeldung bekomme ich seit heute bei all meinen E-Mailadressen die ich bei all-inkl.com habe:

    Wie kann ich TB das fehlende Zertifikat unterjubeln?

    Zitat von Liquid Soul

    Wie kann ich TB das fehlende Zertifikat unterjubeln?

    Wie? Wat? Gar nicht!

    Zitat von Liquid Soul

    Verbinde mit POP3-Server xxx.kasserver.com auf Port 995

    Du verbindest dich mit dem POP3-Server auf einem dezidierten Port. Die Fledermaus versucht eine mit TLS-verschlüsselte Verbindung auf zu bauen. Bitte prüf' doch mal deine Einstellungen beim E-Mail-Empfang, ob das dort auch passend eingestellt ist:



    Könnte dann so aussehen.

    Wenn das bei Dir genauso aussieht, dann wende dich an den All-Inkl-Support und schick denen einen Screenshot Deiner Einstellungen und das Übertragungsprotokoll, das Du hier ja schon gepostet hast.

    (Evtl. ist das ein Fehler in der Zertifikatskette des von All-Inkl benutzen Zertifikates zum Absichern der TLS-Verbindung - ist dann nicht Dein Problem!)

    produktiv: The Bat! pro v12.x (64bit) - wine(at)Devuan64 :bat: Testumgebung: (32bit + 64bit): The Bat! pro - letzte Beta-Versionen
    wine: v11.x - Devuan64(freia/ceres): v7.1.9-1 (2026-08-21) :bat: Emulierte Windows-Version ("build number"): v11.0 (26H2)

    Einmal editiert, zuletzt von letos (9. August 2026 um 18:42)

    Code
    >09.08.2026, 17:37:23: FETCH - Aussteller: "GB", "Sectigo Limited", "Sectigo Public Server Authentication Root E46". Gültig ab 22.03.2021 bis 18.01.2038 23:59:59. Der Aussteller dieser Zertifikatskette wurde nicht gefunden! 
>09.08.2026, 17:37:23: FETCH - Zertifikataussteller fehlt: "US", "New Jersey", "Jersey City", "The USERTRUST Network", "USERTrust ECC Certification Authority". 
!09.08.2026, 17:37:23: FETCH - TLS-Handshakefehler. Ungültiges Serverzertifikat (Der Aussteller dieser Zertifikatskette wurde nicht gefunden)

    Du kannst auch bei der internen Implementierung bleiben und das fehlende Wurzelzertifikat selbst in Trusted Root CA importieren. Mehr unter

    Thema

    Zertifikat für SSL importieren

    Manchmal fehlen SSL-Zertifikate im Adressbuch.

    Hier beispielhaft der Weg für Zertifikate von Let's Encrypt, um es ins Adressbuch zu holen.

    • Zertifikate holen
    1. Seite https://letsencrypt.org/certificates/ öffnen
    2. ISRG Root X1 (self-signed) herunter laden und als .pem speichern
    3. Let’s Encrypt Authority X3 (IdenTrust cross-signed) und Let’s Encrypt Authority X3 (Signed by ISRG Root X1) herunter laden und als .pem speichern
    4. Seite https://www.identrust.com/support/downloads
    5. Download von TrustID…
    GwenDragon
    24. November 2018 um 09:57

    Ansonsten bedeutet die MS CryptoAPI Option, dass auf die in Windows vorhandene Zertifikatsdatenbank zugegriffen wird. Dort ist das Zertifikat wohl vorhanden, so dass es darüber funktioniert.

    wo ich genau das fehlende zertifikat nun finden kann um es in tb zu importieren erschließt sich mir derzeit noch nicht so ganz. GwenDragon

    hier protokollauszug mit interner zertifikatshandhabung:

    Code
     10.08.2026, 06:09:18: FETCH - Empfange Nachrichten
 10.08.2026, 06:09:18: FETCH - Verbinde mit POP3-Server .kasserver.com auf Port 995
 10.08.2026, 06:09:18: FETCH - Einleitung TLS-Handshake
>10.08.2026, 06:09:18: FETCH - Zertifikat S/N: 63AE132D6E3DB91DEA506E2B28B1AA50, Algorithmus: ECC (256 Bits), ausgestellt von 07.08.2026 bis 21.02.2027 23:59:59, für 2 Host(s): *.kasserver.com, kasserver.com.
>10.08.2026, 06:09:18: FETCH - Besitzer: "*.kasserver.com".
>10.08.2026, 06:09:18: FETCH - Aussteller: "GB", "Sectigo Limited", "Sectigo Public Server Authentication CA DV E36". Gültig ab 22.03.2021 bis 21.03.2036 23:59:59.
>10.08.2026, 06:09:18: FETCH - Aussteller: "GB", "Sectigo Limited", "Sectigo Public Server Authentication Root E46". Gültig ab 22.03.2021 bis 18.01.2038 23:59:59. Der Aussteller dieser Zertifikatskette wurde nicht gefunden!
>10.08.2026, 06:09:18: FETCH - Zertifikataussteller fehlt: "US", "New Jersey", "Jersey City", "The USERTRUST Network", "USERTrust ECC Certification Authority".
!10.08.2026, 06:09:18: FETCH - TLS-Handshakefehler. Ungültiges Serverzertifikat (Der Aussteller dieser Zertifikatskette wurde nicht gefunden)

    hier protokollauszug mit ms crypto:

    Zitat von Liquid Soul

    wo ich genau das fehlende zertifikat nun finden kann...

    Auf der Sectigo-Webseite:

    Sectigo Root Certificates | Sectigo® Official
    This article lists Sectigo's four modern root certificates, explains how they are cross-signed for backward compatibility, and notes the new roots Sectigo is…
    www.sectigo.com

    Es geht wohl um dieses - "USERTrust ECC Certification Authority", vgl. Zeile 2 bei meinem Zitat des Protokolls bzw. Zeile 8 bei deinem.

    Zitat von sanyok

    Es geht wohl um dieses - "USERTrust ECC Certification Authority",

    Habe jetzt nachgeschaut, "USERTrust RSA Certification Authority" ist zwar in Trusted Root CA enthalten. ECC jedoch nicht. Der Download-Link auf der o.g. Sectigo-Webseite scheint defekt zu sein, aber das Zertifikat bekommt man z.B. auch von hier:

    USERTrust ECC Certification Authority - Root certificate

    Im Übrigen ist es wohl eine Geschmackssache, ob man die interne oder die Windows-Datenbank nutzt. Eventuell bei der Signierung von Nachrichten könnte es eine Rolle spielen.

    x

    den openssl befehl kann ich bei windows nicht aufrufen.

    Zitat von Liquid Soul

    das kasserver.com Zertifiakt ist ein EC Zertifikat, bis vor wenigen Tagen war es noch ein RSA Zertifikat.

    Dann ist es jetzt klar, wieso die Verbindung plötzlich nicht mehr funktionierte. RSA ist bereits in The Bat! und ECC eben (noch) nicht. Da man es aber manuell importieren kann, ist es überhaupt kein Problem. Ich habe es bei mir vorsichtshalber auch getan.

    Zitat von Liquid Soul

    den openssl befehl kann ich bei windows nicht aufrufen.

    Dafür braucht man OpenSSL. Das ist aber nicht erforderlich. Ich habe oben einen zweiten Link gepostet. darüber lädst du die Datei USERTrustECCCertificationAuthority.crt herunter und importierst sie nach der Anleitung von Gwen. Geht ruck zuck.

    Zitat von sanyok

    Dann ist es jetzt klar, wieso die Verbindung plötzlich nicht mehr funktionierte. RSA ist bereits in The Bat! und ECC eben (noch) nicht. Da man es aber manuell importieren kann, ist es überhaupt kein Problem. Ich habe es bei mir vorsichtshalber auch getan.

    Dafür braucht man OpenSSL. Das ist aber nicht erforderlich. Ich habe oben einen zweiten Link gepostet. darüber lädst du die Datei USERTrustECCCertificationAuthority.crt herunter und importierst sie nach der Anleitung von Gwen. Geht ruck zuck.

    habe ich so gemacht. danke nochmal für den link. nun wieder die lokale cert-verwaltung von the bat aktiv.

    Zitat von Liquid Soul

    den openssl befehl kann ich bei windows nicht aufrufen.

    Da hat dir ChatGPT falsche Möglichkeiten für den Test vorgeschlagen, es sollte aber wissen, dass The Bat! ein Windows-Programm ist. Und dann schlägt es dir eine Linux-Kommandozeile vor. KI halluziniert eben. Nicht vertrauenswürdig, was da geantwortet wird.

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

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

    Zitat von sanyok

    Ich glaube, das war der echte all-inkl.com Support. :)

    Der benutzt KI-Links von ChatGPT!? Oha! Wird ja immer schlimmer mit schlechten Antworten eines "Support"-Bots

    So wie diese sieht nach KI aus:

    Code
    https://www.ritlabs.com/de/products/thebat/download.php?utm_source=chatgpt.com#whatsnew
    The Bat! Pro 12.x BETA (32bit) | Win 11 Pro x64 | GnuPG 2.5.x | XMP + Regula

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

    Zitat von GwenDragon

    Da hat dir ChatGPT falsche Möglichkeiten für den Test vorgeschlagen, es sollte aber wissen, dass The Bat! ein Windows-Programm ist. Und dann schlägt es dir eine Linux-Kommandozeile vor. KI halluziniert eben. Nicht vertrauenswürdig, was da geantwortet wird.

    hatte gehofft das es ein mensch war der bei all-inkl arbeitet und mails beantwortet.

    Zitat von Liquid Soul

    hatte gehofft das es ein mensch war der bei all-inkl arbeitet und mails beantwortet.

    War kein Vorwurf an dich ☮️.

    Es ist nicht immer gewährleistet, dass noch ein Mensch antwortet oder wenn, die Person Fachwissen hat und keine dumme KI nutzt.

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

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

    Zitat von GwenDragon

    Der benutzt KI-Links von ChatGPT!?

    Ich habe erst neulich gelesen, dass sogar Richter in ihren Entscheidungen ChatGPT verwenden. Es wurde ebenfalls anhand von solchen speziellen Links in Urteilen herausgefunden. Also wenn schon Gerichte und bestimmt auch Behörden das tun, was will man dann vom Support eines Privatunternehmens mit nur 100 Mitarbeitern erwarten? Es war außerdem höchstwahrscheinlich so, dass der betreffende Mitarbeiter keine Ahnung von The Bat! hatte. Also musste er KI konsultieren. Oder es gibt dort tatsächlich keine Menschen beim Support, sondern nur noch KI.

    Die persönliche Anrede sowie Gegenfragen und solche Textstellen wie "Laut meiner Recherche" deuten aber eher darauf hin, dass ein Mensch geantwortet hat.

    Wichtig ist aber in jedem Fall, dass seit dem 02.08.2026 die KI-Kennzeichnungspflicht nach Art. 50 KI-VO gilt, die auch Texte umfasst. Gibt es also bei all-inkl.com nur Support-Bots, muss das vor der Kontaktaufnahme erkennbar sein. Und wenn ein menschlicher Mitarbeiter unter Verwendung von KI-generierten Texten antwortet, muss er das ebenfalls ausdrücklich kennzeichnen. Ein Link mit einem KI-Zusatz reicht dabei nicht aus. Auch ein irgendwo im Impressum oder einer anderen Seite versteckter Hinweis sowie ein Hinweis auf Englisch in einem deutschsprachigen Raum sind unzureichend.

    Liquid Soul sollte das mal genauer unter die Lupe nehmen und ggfs. beanstanden.