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

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

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/generalinforma…patibility.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:

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

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:

--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 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?

redmercury2006@zenarcade:~$ openssl smime -decrypt -in smime.p7m -inkey privkey.pem -inform der
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256;
    boundary="0000000000005da3f205c08c2b80"

--0000000000005da3f205c08c2b80
Content-Type: multipart/alternative; boundary="00000000000059372605c08c2b0b"

--00000000000059372605c08c2b0b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

---------- Forwarded message ---------

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

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

Viele liebe Grüße,

Florian

Hallo,

Zitat von Susi to visit

Zitat von redmercury2006

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:

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

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

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