Posts by redmercury2006

    Hallo in die Runde,


    danke thomas >Danke! Ich werd verrückt - es hat bei mir auch funktioniert!


    Ich habe zwischenzeitlich die Beta getestet und gemerkt, dass bei OAuth2 ein neuer Client sich vom Admin freischalten lassen wollte. Dazu habe ich dann diesen Blogbeitrag finden können: https://blog.thunderbird.net/2…ice-365-enterprise-users/ - es scheint also, dass es einiges unter der Haube gibt und der jeweilige Admin von M365 den

    Quote


    client ID 9e5f94bc-e8a4-4e73-b8be-63364c29d753 for Mozilla Thunderbird (it may appear to admins as “Mzla Technologies Corporation”)

    erlauben muss. Das werde ich auch noch einmal testen, aber ich bin leider nur der leidtragende Client in diesem Fall und muss auf den Admin warten ;)


    Viele Grüße

    Hallo zusammen,


    ich schließe mich dem Beitrag an und bestätige den gleichen Fehler, der ebenfalls seit 2 Tagen (seit dem 27.12.) bei mir auftritt.


    Nachtrag: Firefox 102.6.1 auf macOS 12.6.1


    OAuth2 für M365 ist aktiviert. Ich habe bereits das Passwort zurückgesetzt und eine neue Auth angestoßen (ohne Erfolg). Logfiles zeigen mir ebenfalls bei diversen Aufrufen:


    Code
    [Parent 78842: IMAP]: I/IMAP 149c07800:outlook.office365.com:A:CreateNewLineFromSocket: 35 BAD User is authenticated but not connected.
    [Parent 78842: IMAP]: I/IMAP 149c07800:outlook.office365.com:A:CreateNewLineFromSocket: 36 BAD User is authenticated but not connected.
    [Parent 78842: IMAP]: I/IMAP 149c08000:outlook.office365.com:A:CreateNewLineFromSocket: 26 BAD User is authenticated but not connected.
    [Parent 78842: IMAP]: I/IMAP 149c08000:outlook.office365.com:A:CreateNewLineFromSocket: 27 BAD User is authenticated but not connected.
    [Parent 78842: IMAP]: I/IMAP 149c08800:outlook.office365.com:A:CreateNewLineFromSocket: 91 BAD User is authenticated but not connected.
    [Parent 78842: IMAP]: I/IMAP 149c08800:outlook.office365.com:A:CreateNewLineFromSocket: 92 BAD User is authenticated but not connected.

    (mittels grep; Es spielt keine Rolle, welcher Befehl ausgeführt wird)


    Weiterer Auszug aus den Logs:


    Diesen Fehler habe ich nur bei Thunderbird, mein iOS Mailagent funktioniert (leider) weiterhin.


    Vielen Dank für jeden Tipp im Voraus!


    Viele Grüße

    okay. Der Unterschied - auf den ersten und zweiten Blick - zwischen #1 und #3 ist der verwendete E-Mail Client.


    #1 hat eine gültige Signatur, via Apple Mail - keine Verschlüsselung

    #3 wird via GSuite versendet, ungültige Signatur - Verschlüsselung (funktioniert zumindet von Hand, TB weigert sich, diese zu entschlüsseln, wegen der ungültigen Signatur, was ja auch richtig ist - Outlook kann hingegen dies "ignorieren auf Wunsch" und entschlüsselt dann.


    Next step on my part: ich analysiere die Signaturen.


    Ich kann ja theoretisch den base64 encoded Text in eine Datei umleiten und dann mal herumbasteln.


    Was ist das nervig...


    Liebe Grüße,


    Florian

    Danke für deine Mühen, fürchte auch, dass wir es nicht weiter analysiert bekommen. Es muss schlicht daran liegen, dass Thunderbird sich gar nicht erst an das Entschlüsseln macht. Outlook macht dies, meiner Recherche zu Folge liegt dies aber daran, dass es einfach alles öffnet, was ein Anhang ist und nicht darauf achtet, wie es eingebettet ist, einmal salopp ausgedrückt.


    Ich vergleich jetzt einmal die Unterschiede zwischen #1 und #2 und komme nochmal zurück. Danach können wir das Thema aber wohl schließen, ich glaub, dann ist hier Ende im Gelände und es ist halt, wie es ist ;)


    Liebe Grüße,


    Florian

    Hallo,


    Erste Testdurchläufe per openssl cli waren erfolgreich - also richtige Schlüssel.

    Das besagt, dass du für openssl den richtigen Schlüssel angegeben hast. Ob das auch im Thunderbird der Fall ist, lässt sich daraus nicht ableiten.

    Da war ich schwammig, es ist exakt dieser Schlüssel natürlich. Auch auf einen Umweg, nämlich aus Thunderbird heraus exportiert, damit da keine Probleme auftreten. Dieser Schlüssel entschlüsselt auch andere verschlüsselte E-Mails korrekt.


    Sobald ich mir selbst Mails schicke, wird auf eine Angabe von SHA verzichtet.


    Die fehlerhaften E-Mails sind allesamt (der eine Absender) mit diesem hier signiert:

    Code
    micalg=sha-256

    Also vielleicht ist dies - narrowed down - das Problem?


    Ich führe eine neue mögliche Fehlerquelle einmal ins Feld: der Microsoft 365 Exchange Server - kann es sein, dass dieser etwas "ummodelliert"? Ich traue dem Club nicht, aber bin beruflich gezwungen, den einzusetzen (ich arbeite da noch an den Verantwortlichen.).


    Vielleicht hat die Community Ideen?


    Ich suche einmal weiter...

    Hallo Susi to visit,


    merci vielmals. Soweit, so klar die Technik.


    Kreuztest geht (zumindest kein Feedback, dass der Empfänger die Nachricht nicht lesen konnte) > ich verwende also den korrekten öffentlichen Schlüssel.


    EDIT:


    Erste Testdurchläufe per openssl cli waren erfolgreich - also richtige Schlüssel. Irgendetwas ist also doch wohl in der Mail kurios, dass Thunderbird sich weigert?

    Wobei hierbei privkey.pem mein privater Schlüssel ist.

    Code
    -----BEGIN PRIVATE KEY-----
    MIIEvQIBA [...]
    -----END PRIVATE KEY-----



    Viele liebe Grüße,


    Florian

    Nachtrag, Quelltext der E-Mail, die laut Thunderbird "nicht verschlüsselt" ist - und ich glaube, hier liegt der Hund begraben:


    Code
    --000000000000c96dce05c179b7f2
    Content-Type: application/pkcs7-mime; name="smime.p7m"; smime-type=enveloped-data
    Content-Transfer-Encoding: base64
    Content-Disposition: attachment; filename="smime.p7m"
    Content-Description: S/MIME Encrypted Message
    
    MII/ZAYJKoZIhvcNAQcDoII [...]

    Noch ein Nachtrag:


    Ich konnte im Quelltext der "fehlerhaften" Mail noch folgende Zeile - deutlich weiter oben - erkennen

    Code
    Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256;
        boundary="000000000000c1a3d005c17d3fae"

    Nach der verschlüsselten Nachricht, also dem Inhalt, folgt ein Block mit:


    Code
    --000000000000c1a3d005c17d3fae
    Content-Type: application/pkcs7-signature; name="smime.p7s"
    Content-Transfer-Encoding: base64
    Content-Disposition: attachment; filename="smime.p7s"
    Content-Description: S/MIME Cryptographic Signature


    Ist hier irgendwo der Fehler beim Absender? Nicht korrekter E-Mail Aufbau oder sowas in der Art? Das ist zumindest der Unterschied, den ich vom Aufbau zwischen "korrekten" und den Mails vom besagten Absender erkenne.

    Hallo und zunächst vielen Dank!


    Ich habe die gesamte Zertifikatskette importiert und mein Vertrauen ausgesprochen (natürlich in Thunderbird und nicht nur im macos Keyring; dort aber auch).


    Gibt es eine Möglichkeit, Zertifikate zu analysieren, welche Kette wirklich erforderlich ist? Auf der DigiCert Website konnte ich nachlesen, dass ein "cross root" Zertifikat der CA irgendwie besteht (Link: https://knowledge.digicert.com…t-root-compatibility.html).

    Ich habe versucht nachzuvollziehen, welche "recommended chain" sinnvoll ist. Aber auch hier komme ich nicht weiter.


    Es ist wirklich immens kurios. Ich erhalte vom Absender teilweise auch E-Mails "unverschlüsselt" und nur signiert - und dort zeigt mir Thunderbird korrekte Signatur an:



    sobald allerdings wohl der Absender verschlüsselt (über das GSuite Interface) - dann passiert folgendes:


    Als Anhang gibt Thunderbird "smime.p7m" aus - also den verschlüsselten Inhalt der Nachricht; Thunderbird verweigert aber die Entschlüsselung



    Laut dem Zertifikat des Absenders, das in meinem Schlüsselbund bei Thunderbird hinterlegt ist, ist der Aussteller "DigiCert SHA2 Assured ID CA", dieser ist laut DigiCert Website die Intermediate CA. Diese ist aber auch hinterlegt und als vertrauenswürdig markiert, ebenso, dass diese für E-Mails gelten soll.


    Ich vermute, dass der Absender (und damit die 'tolle' GSuite) irgendwie die E-Mail falsch signiert/verschlüsselt.


    Hatte gehofft, dass hier jemand Erfahrungswerte hat.


    Gibt es vielleicht in Thunderbird eine Einstellung, mit der man das Entschlüsseln auch von "ungültiger Signaturen" oder dergleichen erzwingen kann? Alternativ irgendwo weitere Debuglogs filtern?


    Für jede Hilfe bin ich mehr als nur dankbar - soll ich evtl. etwas zur Fehlersuche im Quelltext der Mail heraussuchen?


    Kurios ist auch am Rande, dass in iOS Mail es funktioniert - warum auch immer; ich muss allerdings "Nachrichten herunterladen" aktivieren, damit es geht.


    Danke!!


    Liebe Grüße,


    Florian

    Um Rückfragen vorzubeugen, bitten wir um folgende Angaben:

    • Thunderbird-Version (konkrete Versionsnummer:( 78.10.0 (64-bit)
    • Betriebssystem + Version: macOS 11.2.3
    • Kontenart (POP / IMAP): IMAP
    • Postfachanbieter (z.B. GMX): Microsoft 365
    • Eingesetzte Antivirensoftware: keine
    • Firewall (Betriebssystem-intern/Externe Software): macos intern


    Hallo in die Runde,


    seit Wochen treibt mich ein Problem mit einem Kommunikationspartner herum, der auf Google Suite, jetzt Google Workspace setzt. Einige Mitarbeiter haben dort wohl ein S/MIME Zertifikat erhalten. Aussteller CA ist jeweils DigiCert SHA2 Assured ID CA.


    Bei den Absendern habe ich die jeweiligen Zertifikate im Zertifikatsspeicher sichtbar, die CA ist mit Vertrauen für E-Mails ausgestattet (Download des Intermediate Zertifikats von der Website https://www.digicert.com/kb/digicert-root-certificates.htm ist erfolgt und händisch importiert, da nicht standardmäßig aktiviert).


    Die E-Mails kann ich nicht entschlüssen, Tb zeigt mir den smime.p7m Anhang an und es erfolgt die Fehlermeldung:



    Dies ist etwas vertrackt, da ich glaube, dass der Absender definitiv etwas falsch "absendet" - beispielsweise die iOS Mail App lässt mich die Mail öffnen, aber nur nach Bestätigung einer Sicherheitsfrage ("Download zulassen").


    Microsoft Outlook öffnet und entschlüsselt die Mail hingegen - das Programm will ich aber partout nicht öffnen, das ist eine Zumutung.


    Hat vielleicht jemand eine Idee?


    Vielen Dank im Voraus!


    Liebe Grüße,


    Florian