Entschlüsselung nicht möglich - trotz vertrautem Zertifikat (Google Workspace / GSuite Absender)

Wenn Sie plötzlich keine E-Mails mehr empfangen können

Bitte lesen Sie die Hinweise zu den beiden derzeit häufigsten Problemursachen!

Hier bitte klicken!

Diese rote Box verschwindet, wenn Sie in der rechten oberen Ecke auf das X klicken.

  • 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

  • graba

    Approved the thread.
  • Prüfe zunächst einmal, ob du die gesamte Zertifkatskette importiert hast und den Zertifikaten auch vertraust. Die Fehlermeldung ist mit dem Hinweis auf ein unbekanntes Problem leider wenig hilfreich.


    Immerhin, einen Hinweis gibt es vielleicht. Die Fehlermeldung besagt, die E-Mail selbst sei nicht verschlüsselt. Das sieht also so aus, als sei lediglich ein verschlüsselter Anhang beigefügt. Genaueres sollte dir der Absender dazu sagen können.

    Wer wenig oder gar nichts kann, schiebt's auf den Antiviruskram.

    (Compuzius, Buch 5)

  • 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

  • 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.

  • Die Code-Blöcke sehen völlig korrekt aus. Darin kann ich keinen Fehler erkennen. Auffällig ist aber folgendes:


    In deinem ersten Screenshot in #1 wird angezeigt, dass die Signatur ungültig sei. Der Screenshot in #3 zeigt aber eine gültige Unterschrift. Irgendetwas muss also "in der Zwischenzeit" passiert sein. Entweder der Absender hat ein anderes Zertifikat verwendet oder du hast im Thunderbird etwas geändert.

    Jedenfalls ist das zur Unterschrift verwendete Zertifikat aus #3 bei dir gültig. Um dessen Zertifikatskette musst du dir keine Gedanken machen.


    Bleibt die Frage, weshalb die Verschlüsselung nicht klappt. Während der Absender zur Unterschrift sein Zertifikat (seinen privaten Schlüssel) benutzt, benötigt er zum Verschlüsseln deines (deinen öffentlich Schlüssel). Umgekehrt benötigst du für die Bestätigung der Signatur sein Zertifikat (seinen öffentlichen Schlüssel) und zum Entschlüsseln deinen privaten Schlüssel.

    Da die Signatur in #3 gültig ist, die Verschlüsselung aber nicht funktioniert, deutet alles auf ein Problem mit deinem Zertifikat hin.

    Es kann sein, dass der Absender nicht den korrekten öffentlichen Schlüssel von dir hat. Ebenso kann es sein, dass du bei dir dein eigenes Zertifikat nicht importiert hast oder eine anderes verwendest als der Absender.


    Führe mal den Kreuztest durch: Sende deinem Partner eine verschlüsselte und signierte Mail. Wenn du seinen korrekten öffentlichen Schlüssel hast, wird er sie entschlüsseln können. Hat er von dir nicht den passenden öffentlichen Schlüssel, bekommt er eine ungültige Unterschrift angezeigt.


    Gleich zur Vorwarnung: Für den Fall, dass ihr mehrere Zertifikate ausgetauscht habt, z.B. zum Experimentieren, wird es komplex. Da mag ich dann aus der Ferne nicht einsteigen. Ihr müsstet ggf. alte Zertifikaten entfernen, was aber dazu führt, dass damit verschlüsselte Mails nicht mehr lesbar sind.

    Wer wenig oder gar nichts kann, schiebt's auf den Antiviruskram.

    (Compuzius, Buch 5)

  • 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

  • Die Ausschnitte aus der E-Mail sehen für mich völlig korrekt aus. Zum Vergleich aus zwei E-Mails, die ich mir mit selbsterstellten Zertifikaten gesendet habe:


    Verschlüsselt + signiert:

    Code
    User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
    Thunderbird/78.7.1
    MIME-Version: 1.0
    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


    Nur signiert:


    Code
    User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
    Thunderbird/78.7.1
    MIME-Version: 1.0
    Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="... "
    [...]
    Content-Type: application/pkcs7-signature; name="smime.p7s"
    Content-Transfer-Encoding: base64
    Content-Disposition: attachment; filename="smime.p7s"
    Content-Description: S/MIME Cryptographic Signature


    Was vielleicht auffällt ist der Hash für die Signatur. Bei dir SHA-256. Bei mir SHA1, obwohl das Zertifikat, wenn ich auf den Button "anschauen" klicke, für den Signaturalgorithmus SHA-512 with RSA Encryption zeigt. So habe ich es auch erzeugt. Diesen Punkt kann ich grad nicht erklären. Das wäre dann auch gleich meine Frage an die Community hier. Kann das jemand erklären?


    Ich habe hier im Forum mal gelesen, Thunderbird würde nur SHA1 unterstützen. Da habe ich aber zumindest Zweifel. Jedenfalls erkennt der Thunderbird bei mir auch Signaturen mit SHA-256, auch von Google:


    Code
    DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
    d=xxx.com; s=google;
    [...]
    Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256;


    Die Signatur scheint gemäß #3 auch nicht das Problem. Wobei du noch nicht geklärt hast, weshalb sie in #1 ungültig war. Da stimmt etwas nicht.


    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.

    Wer wenig oder gar nichts kann, schiebt's auf den Antiviruskram.

    (Compuzius, Buch 5)

  • 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...

  • Also vielleicht ist dies - narrowed down - das Problem?

    Möglich ist alles. Ich halte das für aber unwahrscheinlich. Nicht nur, weil es bei mir kein Problem ist sondern vielmehr weil der Hash nur für die Signatur benötigt wird. Und eben die funktioniert ja. Womit wir wieder bei der immer noch ungeklärten Frage von oben wären. Das ist der einzige Hauch von Spur, den ich sehe, obwohl man den ja eigentlich spürt. Ansonsten bin ich überfragt.

    Ich führe eine neue mögliche Fehlerquelle einmal ins Feld: der Microsoft 365 Exchange Server - kann es sein, dass dieser etwas "ummodelliert"?

    Auch das kann ich mir nur schwerlich vorstellen.

    Wer wenig oder gar nichts kann, schiebt's auf den Antiviruskram.

    (Compuzius, Buch 5)