Verständnisfrage: ist das von der SmartCard verwendete Zertifikat ein X.509 (S/Mime) Zertifikat ?

[#1]

Hallo Community,

zur Verschlüsselung von E-Mails verwenden wir gerne das von der Datev-SmartCard zur Verfügung gestellte S/Mime-Zertifikat.

Am liebsten würden wir auch mit diversen Banken dieses Zertifikat für den Austausch verschlüsselter E-Mails verwenden.

Verständnisfrage:

Ist dieses "Datev-S/Mime-Zertifikat" gemeint, wenn die Bank von "X.509 (S/Mime) Zertifikat" spricht ?

Falls ja, müssten wir wahrscheinlich nur eine signierte E-Mail an die Bank senden oder eine E-Mail mit der entsprechenden ".CER"-Datei als Anlage.

[#2 · Accepted solution]

Ja, das funktioniert wenn die Bank X.509 S/MIME verwendet. Diese Zertifikate sind immer auf die im Zertifikat enthaltene Mailadresse bezogen, daher muss jeder Empfänger, an den verschlüsselt gesendet werden soll, sein Zertifikat / seinen öffentlichen Schlüssel mit Ihnen tauschen (bzw. zentral mit einem Gateway):

Zwischen meiner Sparkasse und der Datev würde das dann so laufen:

1.) Jeder Ansprechpartner an den verschlüsselt gesendet werden soll (bzw. Sammeladressen wie info@ , wenn für diese ein Zertifikat vorliegt), schickt einmal eine signierte Mail an  schluesselimport@datev.de . Dort wird sein Zertifikat dadurch hinterlegt, gespeichert und er erhält eine verschlüsselte Mail zurück. Sie brauchen jetzt sein Zertifikat auch nicht mehr bei sich zu importieren: wenn Sie über Datev verschlüsselt senden muss er sich nicht mehr im Portal einloggen sondern erhält die E-Mail durchgleitet.

2.) Je nachdem wie Ihre Bank vorgeht, müssen Sie noch Ihr Zertifikat an die Bank übermitteln damit diese verschlüsselt an Sie senden kann. Meine Sparkasse hat mich dafür in deren Mailportal angelegt, ich musste mich dort einloggen (wie Kunden ohne Kenntnisse über Mailverschlüsselung) und konnte dann mein Zertifikat hochladen und in den Einstellungen als Übertragungsweg festlegen. Jetzt werden mir auch Mails von neuen Ansprechpartnern (z. B. Urlaubsvertretung meines Geschäftskundenberaters) direkt verschlüsselt in Outlook zugestellt, ohne dass die sendende Person selber mein Zertifikat importieren müsste (läuft übers Gateway - das ich dort angelegt werden und mein Zertifikat hinterlegen mußte, ist für beide Seiten jeweils 2 Minuten Aufwand... spart dafür aber den Aufwand, mit 30 Ansprechpartnern einzeln Zertifikate zu tauschen).
Alternativ würde es bei anderen Banken ggf. reichen, das Sie die besagte signierte Mail senden und dann jeder Mitarbeiter, der an Sie verschlüsselt senden können soll, mit dem Rechtsklick auf Ihren Absendernamen den Kontakt in Outlook (und damit Ihr Zertifikat) speichert. So maile z. B. ich den Mitarbeitern der mich betreuenden StB-Kanzlei auch direkt verschlüsselt per S/MIME.

[#3]

Zertifikat hochladen - noch eine Warnung als Ergänzung NUR FÜR DEN SONDERFALL, dass Sie Zertifikate statt per signierter Mail durch direktes Hochladen hinterlegen möchten - in den Infodokumenten findet sich aus diesem Grund immer der Hinweis mit der signierten Mail als richtiger Vorgehensweise (das Ganze wirkt etwas kompliziert und aufwendig, und das ist Mailverschlüsselung mit vielen verschiedenen Empfängern, die verschiedene Systeme nutzen, in manchen dabei auftretenden Spezialfällen leider auch. Ich versuche es im Folgenden mal verständlich zu erklären ohne das es zu gruselig wirkt, und zum Glück sollte das ganze Problem in wenigen Wochen behoben sein).

Ihr Zertifikat ist Ihr "öffentlicher Schlüssel", mit dem Mails an Sie verschlüsselt (und von Ihnen signierte Mails auf Echtheit geprüft) werden können. Wenn Ihr Zertifikat beim Absender manuell hochgeladen wird, nutzt z. B. Outlook (mit Ausnahme der alten Versionen von/vor 2013) AES256 als Verschlüsselungsverfahren. Beim Tausch per signierter Mail hingegen verwendet Outlook stattdessen 3DES.

Leider ist es aber aktuell wohl noch nicht möglich, per AES verschlüsselte Mails mit dem Datev-Sicherheitspaket wieder zu entschlüsseln, da nur 3DES unterstützt wird.... Für Datev 14 (voraussichtlich ca. September 2020) ist Abhilfe geplant (siehe https://apps.datev.de/dnlexka/document/1015724 fast ganz unten über Punkt 3).

Es gab hier an anderer Stelle schon ausführliche Diskussionen darüber, dass das - kulant ausgedrückt - sehr ungünstig ist (diese Ansicht teile ich zu 100%), doch zum Glück sollte es bald soweit sein das es mit Datev 14 dann läuft.

Je nachdem wie Ihre Bank arbeitet gibt es also die Variante
a.) mit dem Schlüsseltausch per signierter Mail,
b.) mit Hochladen des Zertifikats das auch immer dann funktioniert, wenn z. B. die Bank am Gateway 3DES nutzt
c.) und nur im schlimmsten Fall (Hochladen erforderlich UND Bank verwendet AES) können erst mit Datev 14 verschlüsselte Mails von der Bank in Outlook entschlüsselt werden.

Bei meiner Sparkasse müsste ich mich in diesem worst case c.) bis dahin wie zur Zertifikatshinterlegung im Webmailsystem einwählen (wo die Sparkasse mich als Nutzer hinterlegt hat), dort oben den Reiter Einstellungen und dann links außen "Kanal für sichere Nachrichten" wählen und dort wieder auf Webmail umstellen, bis Datev 14 da ist; danach hier andersrum wieder auf "Ihr Postfach mit S/MIME Zertifikat" (ich kann es leider für die Sparkasse nicht testen ob aktuell Fall b oder c vorliegt, da ich selber kein Datev-Nutzer bin).

Ihr Zertifikat ist und bleibt völlig in Ordnung, das Problem liegt kurz zusammengefasst darin, dass das Datev-Sicherheitspaket eine veraltete Treibertechnologie nutzt, die nicht in der Lage ist, mit aktuellen Outlook-Versionen per AES zu entschlüsseln (Ihr Zertifikat ist prima - wenn der Absender eine bestimmte Variante der Verschlüsselung wählt, versagt aber aktuell die Datev-Software, die den privaten Schlüssel von der Smartcard verwenden und damit in Outlook die entschlüsselte Mail liefern soll. Und ohne die Datev-Software kommt Outlook nicht an den entschlüsselten Inhalt. Offenbar wurde hier zwecks Rückwärtskompatibilität mit Windows 7 auf die alte Technik gesetzt, Details siehe https://www.datev-community.de/...- Info von Datev-Mitarbeiter mit Hintergrunddetails ). Aber das sollte wie gesagt hoffentlich bald Geschichte sein. Und wenn wie in den oben verlinkten Dokumenten/Statements angekündigt mit Datev 14 der neue Treiber vorliegt, sollte Outlook damit in allen aktuellen Versionen sofort in der Lage sein, per AES verschlüsselte Mails nun auch endlich zu entschlüsseln (auch die per AES verschlüsselten Mails, die ggf. vor dem Update auf Datev 14 eingetroffen waren).

Ja, trotz Vereinfachung finde ich diesen  Beitrag schon lang und die Situation ist - sofern sie denn auftritt - wirklich ##!!///%%! . Jetzt das große ABER:
- Erstens ist der Zustand hoffentlich bald behoben.
- Zweitens tritt das Problem bis dahin auch nur in bestimmten, klar definierten Fällen auf (je nach Einstellung beim Absender & Art des Schlüsseltausches entweder immer oder aber niemals): wenn der Absender an Sie per AES verschlüsselt (beim Schlüsseltausch per signierter Mail verhalten sich hingegen schon jetzt auch die neuen Outlook-Versionen kompatibel).

- Und drittens: Wenn jetzt kurz vor Abhilfe doch nochmal dieser Fall bei jemandem eintritt, der jetzt die Schlüssel mit anderen Absendern austauschen möchte (also bisher noch anders gearbeitet hat) und das in einem Spezialfall z. B. beim Gateway seiner Bank so nicht klappt, dann würde ich persönlich noch bis Datev 14 warten und bis dahin wie vorher arbeiten.

Soviel also zu diesem komplizierten aber seltenem (und zudem zeitlich befristetem) Sonderfall, zur Motivation zum Schluss "Mailverschlüsselung in 3 Sätzen":
In den meisten Fällen ist es ganz einfach - wer Ihnen eine signierte Mail (mit der kleinen Schleife wie bei DHL-Paketankündigungen) senden kann, mit dem können Sie Mails per S/MIME verschlüsselt austauschen. Dafür sendet er eine signierte Mail an schluesselimport@datev.de und Sie eine signierte Mail an ihn, aus der heraus er Sie dann mit Rechtsklick in seinen Outlook-Kontakten speichert.
Und schon können Sie gegenseitig an sich versendete Mails verschlüsseln - fertig.

[#4]

Hallo @HW ,

vielen Dank für Ihr Feedback.

Das Thema hat so seine 'Haken und Ösen'. Sie scheinen sich ja schon tief in die Materie hineingekniet zu haben.

Aktuell habe ich in diesem Bereich einen neuen, sehr störenden und unerwarteten Effekt.

Nach der Deinstallation von "MS Office 2010" und der anschließenden Neu-Installation von "MS Office 2019" funktionierte auf den ersten Blick alles wie gewohnt, auch Outlook.

Neue digital signierte E-Mails und auch S/MIME-verschlüsselte E-Mails konnten versandt werden.

Es stellte sich jedoch bald heraus, dass der Absender seine eigene, selbst verschlüsselte und per Outlook 2019 gesendeten E-Mails nicht mehr öffnen konnte. 

... unnötig zu erwähnen, dass auch der/die Empfänger diese verschlüsselten E-Mails nicht öffnen konnte(n).

Die 'Gegenverkehr' funktioniert übrigens, empfangene, S/MIME-verschlüsselte E-Mails können nach wie vor geöffnet werden.

Das Austauschen von neuen signierten E-Mails und das Aktualisieren der Outlook-Kontakte brachte keine Lösung, nicht mal das Löschen und Neuanlegen der Outlook-Kontakte.

Was ist hier los ?

Hat sich bei "MS Outlook 2019" gegenüber "MS Outlook 2010" das S/MIME-Verschlüsselungsverfahren geändert. Kann ich das reparieren (z.B. altes Zertifikat löschen, neues Zertifikat erstellen oder importieren) ? 🤔 

... und wenn ja, an welcher Stelle, im TrustCenter oder woanders ?

... habe festgestellt, dass man S/MIME-Zertifikate offenbar in fünf verschiedenen Formaten exportieren kann (siehe Screenshot).

Die Anzahl aller Möglichkeiten, an irgendwelchen 'Schräubchen' zu drehen, ist sehr groß.

Solche Tests sind verdammt zäh.

Vielleicht hat ja jemand diese kryptischen kryptographischen Themen 'im Griff' und kann mir einen Tipp geben.

[#5]

Nachtrag: 

'der englische Patient' hat erste Anzeichen einer Besserung gezeigt.

Ich habe den Verschlüsselungs-Algorithmus von "AES 256bit" auf "3DES" umgestellt und siehe da, der Absender der E-Mail kann seine eigene Krakelei selbst wieder lesen. Wow, ein toller Erfolg ! 😀

Nachtrag 2:

... muss doch nochmal korrigieren:

Die Umstellung von "AES 256bit" auf "3DES" wird zwar angeboten und akzeptiert.

Beim nächsten Aufruf der "E-Mail-Sicherheit" --> "Einstellungen" wird aber wieder AES (256bit) angezeigt.

... habe noch keinen Weg gefunden "3DES" dauerhaft zu speichern.

... aber witzigerweise funktioniert jetzt trotzdem das Verschlüsseln bzw. das Öffnen neu verschlüsselter E-Mails.

... vielleicht lag es ja daran, dass ich bei "Sicherheitskennzeichen" "neu" angeklickt hatte.

Diese Verschlüsselungsverfahren sind wirklich mysteriös und kapriziös.

Solange es funktioniert, soll es mir (momentan) egal sein 😋

Nachtrag 3:

bei einem weiteren Umstellungs-Kandidaten (von Office 2010 auf Office 2019) hatte ich die gleichen Effekte (und die gleiche Lösung)

... das heißt :  "Trustcenter" --> "E-Mail-Sicherheit" --> "Einstellungen" --> "Sicherheitskennzeichen" "Neu", dann nimmt das Gute seinen Lauf. Ansonsten kann/konnte "Qutlook 2019" seine eigenen gesendeten, verschlüsselten E-Mails nicht mehr öffnen/lesen.

Übrigens:

offenbar muss das 'neue' Zertifikat auch wieder per digital signierter E-Mail mit den E-Mail-Mail-Partnern ausgetauscht und in deren Outlook-Kontakte aufgenommen werden, damit auch der 'Gegenverkehr' fließen kann.

[#6]

---

@vogtsburger  schrieb:

Diese Verschlüsselungsverfahren sind wirklich mysteriös und kapriziös.

Solange es funktioniert, soll es mir (momentan) egal sein 😋

---

https://www.datev.de/dnlexom/client/app/index.html#/document/1003617

Kurzfassung: SiPa no good.

[#7]

danke @cwes für den Link.

Ja, es betrifft genau diesen Effekt und ich hätte dieses InfoDB-Dokument früher lesen sollen, dann hätte ich mir nicht soviel selbst aus den Fingern saugen müssen.

Aber ich glaube, dass bei mir noch ein zusätzlicher Schritt zur endgültigen Lösung geführt hat. Die anderen Punkte hatte ich, meine ich, alle schon im Vorfeld getestet.

Beim nächsten Umstellungs-Kandidaten geht es vermutlich deutlich schneller. 

... und wenn man erst mal in Fahrt ist, will man gar nicht mehr aufhören mit dem (Böcke-)Schießen bzw. dem (Trouble-)Shooting 😀

[#8]

Nachtrag:

... nur bei einem 'Kandidaten' funktionierte die von Datev im InfoDB-Dokument https://www.datev.de/dnlexom/client/app/index.html#/document/1003617 beschriebene Lösung. Bei drei anderen nicht.

... ich würde aber auch gerne verstehen, was da backstage in "MS Outlook 2019" vor sich geht.

Nach der Umstellung auf "MS Office 2019" sind die "alten" Outlook-Kontakte (aus Office2010-Zeiten) inkl. ihrer Zertifikate ja noch vorhanden. Beim Verschlüsseln und Versenden werden diese Zertifikate akzeptiert, aber ein Öffnen der versandten E-Mails ist nicht mehr möglich.

... vermutlich wird die Mail mit AES256 verschlüsselt und kann daher von SiPa nicht mehr gelesen werden.

Aber was passiert nach dem neuen Austausch der Digitalen Signatur ?

Bleibt dann die 3DES-Signatur (also das neu ausgetauschte 'alte' 3DES-Zertifikat) unangetastet und wird auch so von "Outlook 2019" zur Verschlüsselung verwendet ?

... es scheint so ...

Da es vermutlich auch nach dem September 2020 (Datev-DVD 14) noch Outlook2010-Anwender geben wird, werden sich diese Verschlüsselungs-Probleme wohl nicht alle in Luft auflösen.

Nachtrag:

... habe soeben mehr Antworten auf meine Frage erhalten als ich gestellt hatte, einfach nur durch Lesen des Beitrags Nr. 2 von 6 im Thread https://www.datev-community.de/t5/Technisches-zu-Software/Berufspflichtverletzung-durch-Smartcard-Zertifikat/m-p/150676/highlight/true 😊

... wenn es einem mal langweilig ist, kann man die Zeit zwischen zwei Ruhephasen sinnvoll nutzen 😁