Über die letzten zwei Jahrzehnte hat sich die gesicherte, das heißt verschlüsselte Übertragung von Webseiten via HTTPS als Standard durchgesetzt. Genauso lange existiert das Pendant für verschlüsselte Emails, S/MIME, aber von einer flächendeckenden Verbreitung kann hier noch immer keine Rede sein. Der Grund dafür dürfte hauptsächlich darin bestehen, dass bei Websites nur deren Betreiber ein die Verschlüsselung ermöglichendes digitales Zertifikat benötigen, bei Emails hingegen sich beide Seiten ein solches Zertifikat besorgen müssen. Das steht seit jeher in dem Ruf, zu kompliziert und zu teuer zu sein.

Das ist mittlerweile aber definitiv nicht mehr der Fall; ein Email-Zertifikat bekommt man bei dreijähriger Laufzeit schon für 9€ pro Jahr (12€ bei einjähriger Laufzeit) und kompliziert ist es auch nicht, wenn man weiß, wie es geht. Für Letzteres will ich hier sorgen, damit es endlich mal an dieser Stelle mit der Digitalisierung vorangeht, statt dass Behörden, Anwälte, Ärzte etc. immer noch ellenlange Disclaimer verfassen, dass ihre vertraulichen Emails unverschlüsselt versandt werden oder, schlimmer noch, sie stattdessen Papierpost senden.

Bei einer ähnlichen Anleitung für das (kompliziertere) digitale Unterschreiben von PDFs, den ich zu Jahresbeginn hier veröffentlicht hatte, habe ich freilich bei einigen Lesern die Reaktion ausgelöst, die Anleitung bestätige nur, dass das alles viel zu kompliziert sei – dabei kam dieser Eindruck nur wegen der Ausführlichkeit der Anleitung auf.

Also versuche ich es diesmal anderes herum: die Anleitung beschränkt sich auf das Wesentliche, statt alle Eventualitäten von vornherein abfangen zu wollen, und Erläuterungen zum technischen Hintergrund gibt es nur ganz rudimentär in einem Anhang, den niemand lesen muss, um Emails verschlüsseln zu können. Wenn diese Anleitung dennoch lang scheint, dann nur wegen der Screenshots.



1. Kauf und Installation eines Email-Zertifikats

Um Emails verschlüsselt versenden zu können, benötigen beide Seiten ein digitales Email-Zertifikat. Solche Zertifikate kann man bei Zertifizierungsstellen kaufen; das sind Unternehmen, die eine Lizenz besitzen, solche Zertifikate technisch vertrauenswürdig zu erstellen.

In dieser Anleitung nutzen wir Certum als Zertifizierungsstelle, da das polnische Unternehmen dem strengen EU-Datenschutz unterliegt, sehr preisgünstig und bei der Zertifikatserstellung technisch zudem besonders sicher ist. Ich persönlich habe keinerlei Verbindung zu Certum, die über das Kundenverhältnis hinausgeht.

Bevor wir den Bestellvorgang auslösen, müssen wir allerdings eine Zertifikatsanforderung erstellen, die festlegt, welche Email-Adresse gesichert werden soll. Dazu starten wir in macOS die Schlüsselbundverwaltung, wählen, falls nicht schon der Fall, den Schlüsselbund Anmeldung aus und starten dann den Zertifikatsassistenten:


In das sich öffnende Assistenten-Fenster tragen wir die zu schützende Email-Adresse ein und pro forma unseren Namen, auch wenn der für das Zertifikat keine Rolle spielt, und wählen schließlich bei Anfrage: die Option Auf der Festplatte sichern:


Nach einem Klick auf Fortfahren sichern wir die Zertifikatsanforderung an einem beliebigen Ort auf der Festplatte. Den generischen, voreingestellten Namen CertificateSigningRequest.certSigningRequest sollte man dabei der Übersichtlichkeit halber durch einen spezifischen wie MaxMustermann.certSigningRequest ersetzen:


Schließlich öffnen wir MaxMustermann.certSigningRequest, das de facto eine reine Textdatei ist, in TextEdit:

Den Dateiinhalt brauchen wir sogleich für die Bestellung und können ihn dann aus dem TextEdit-Fenster kopieren.


Nun geht es ans Bestellen.

Dazu legen wir, damit danach alles reibungslos vonstatten geht, zunächst ein Nutzerkonto mit den üblichen Angaben an: Die hierbei anzugebende Email-Adresse wird für den Ablauf der Bestellung verwendet, muss aber nicht die Email-Adresse sein, für die das Zertifikat erstellt werden soll (man kann von einem Kundenkonto aus Email-Zertifikate für beliebig viele verschiedene Email-Adressen bestellen). Sodann ergänzen wir noch Rechnungs- und (pro forma) Lieferadresse: Ein Kundenkonto muss natürlich nur bei der ersten Bestellung angelegt werden, weshalb dieser Absatz violett markiert ist und nach der ersten Bestellung ignoriert werden kann.

Nun gehen wir auf die Bestellseite für das Zertifikat:

Da es sich nicht um die Verlängerung, sondern die Neuausstellung eines Zertifikats für unsere Email-Adresse handelt, wählen wir als Typ new. Die Gültigkeitsdauer des Zertifikats kann man zwischen 1 und 3 Jahren wählen; 3 Jahre sind am preisgünstigsten. (Die angezeigten Preise sind noch ohne deutsche Mehrwertsteuer.)

Dann legen wir unser Produkt in den Einkaufswagen und durchlaufen den in Online-Shops typischen Bestellprozess, in dessen Rahmen wir wieder nur die Email-Adresse für die Bestellabwicklung angeben müssen, die nicht identisch mit der Email-Adresse für das Zertifikat sein muss. Denn was wir hier kaufen, ist nur das Anrecht auf die Ausstellung eines Zertifikats; deshalb müssen wir während des gesamten Kaufprozesses noch nicht angeben, für welche Email-Adresse das Zertifikat sein soll.

Nach erfolgreichem Abschluss der Bestellung erhalten wir eine Email mit dem Betreff Activate the certificate, die einen großen blauen Knopf Begin activation enthält. Auf den klicken wir und landen auf folgendem Formular:

Alles, was wir hier tun müssen, ist auf den Activate-Knopf zu klicken. Das öffnet folgendes Formular:

Hier wählen wir als delivery method of key pair CSR aus und klicken auf Next.

In das sich nun öffnende Formular kopieren wir jetzt die Daten aus dem TextEdit-Fenster, in dem wir MaxMustermann.certSigningRequest geöffnet hatten, und klicken dann erneut auf Next:

Dadurch teilen wir Certum mit, für welche Email-Adresse das Zertifikat aktiviert werden soll. Dies wird uns nun zur Kontrolle nochmals angezeigt:

Die Applicant data in der oberen Formularhälfte stammen aus dem eingangs angelegten Kundenkonto. Sie spielen für ein Email-Zertifikat, das lediglich die Echtheit der Email-Adresse (und nicht etwa die Identität einer Person) bezeugt, keine Rolle. Den im Screenshot rot überlagerten Text können wir daher ignorieren; er hätte nur Gültigkeit, wenn auch die Identität einer Person zertifiziert werden sollte. Die Gültigkeit der Email-Adresse hingegen wird schlicht dadurch sichergestellt, dass an die zu zertifizierende Email-Adresse ein zu bestätigender Link gesandt wird. Wichtig für uns ist einzig, dass die Email-Adresse im unteren Teil, den Certificate Data, korrekt ist.

Stimmt alles, klicken wir auf Next und erhalten eine letztmalige Überprüfungsmöglichkeit:

Mitte einem Klick auf Activate wird das Zertifikat generiert. Im Zuge dessen werden zunächst eine Email mit dem Betreff Certificate request has been created an die zur Bestellabwicklung verwendete Email-Adresse und direkt danach eine Email mit dem Betreff Email verification an die Email-Adresse gesandt, für die das Zertifikat erstellt werden soll; deren Gültigkeit muss durch einen Klick auf Verify the email address in der zweiten Email bestätigt werden.

Ist dies erfolgt, wird die Zertifikatsgenerierung abgeschlossen und wir erhalten eine Email mit dem Betreff Certificate has been created, die einen Link zu einer Webseite zum Herunterladen des Zertifikats enthält:

Wir wählen für unser Certificate das Binary-Format und ebenfalls für das erste der beiden Zertifikate der Certificate chain (die macOS braucht, um die Gültigkeit unseres Email-Zertifikates beurteilen zu können). Falls wir schon einmal eine mit einem Cerium-Zertifikat signierte Email bekommen haben, wäre letzteres Zertifikat (Certum Digital Identification CA SHA2) schon in der Schlüsselbundverwaltung vorhanden und eine erneute Installation unnötig; eine doppelte Installation schadet aber auch nicht. Das dritte, unterste Zertifikat brauchen wir in keinem Fall, da es in macOS standardmäßig vorhanden ist.

Die Zertifikate werden im Downloads-Ordner gespeichert und haben Namen wie 6f1f3e58c31d0678b4276db62f796c6f.cer. Mit einem Doppelklick werden sie in der Schlüsselbundverwaltung installiert. Es kann noch bis zu 1 Minute dauern, bis Mail begriffen hat, dass unsere Email-Adresse jetzt digital abgesichert ist, was sich an zwei zusätzlichen Knöpfen zum Signieren und Verschlüsseln im Fenster zum Verfassen von Emails zeigt (siehe nächstes Kapitel).



2. Verwendung in Mail

Sobald man nach Installation des Zertifikats eine neue Email mit der zugehörigen Email-Adresse als Absender erstellt, sind in dem Neue E-Mail-Fenster rechts neben dem Priorität-Popup zwei neue Knöpfe sichtbar:

Der eine davon, das Schloss, ist noch ausgegraut, solange man nicht vom Empfänger der Email schon eine Email mit dessen Zertifikat erhalten hat, denn nur dann lässt sich eine Email verschlüsseln. Der andere Knopf, dessen Icon ein Zertifikat symbolisieren soll, lässt sich aber einschalten. Tut man das das erste Mal, fragt Mail, ob es auf das Zertifikat aus dem Schlüsselbund zugreifen darf:

Hier gilt es nun abzuwägen: wählt man Immer erlauben, so kann man ab diesem Moment stets ohne weiteres digital signierte Emails versenden – aber jemand anderes, der in einem unbeaufsichtigten Moment auf den Mac mit angemeldetem Nutzer Zugriff hat, könnte das auch. Wählt man Erlauben, kann das nicht passieren, aber auch man selbst muss dann jedesmal erneut das Passwort eingeben. Unter normalen Bedingungen sollte daher Immer erlauben vorzuziehen sein.

Hat man den Zugriff auf den Schlüsselbund bestätigt, wird die eigene Email digital mit der eigenen Email-Adresse signiert. Beim Empfänger sieht das dann so aus:

Dadurch kann sich der Empfänger darauf verlassen, dass die Email tatsächlich von dieser Email-Adresse abgesandt wurde und es sich nicht um einen betrügerischen Fake der Email-Adresse handelt, wie er bei Spammail ja laufend vorkommt. Allein das erhöht schon Vertrauenswürdigkeit und Sicherheit.

Antwortet nun der Empfänger mit einer seinerseits digital signierten Email, so können wir ihm ab diesem Moment verschlüsselte Emails senden, wie der jetzt aktivierte Knopf mit dem Schloss zeigt:


Schalten wir die Verschlüsselung ein, so kann die Email nur noch vom Empfänger gelesen werden:


Bei dem schaut die empfangene verschlüsselte Email dann so aus:


Für weitere Details, etwa, wie Ihr gegebenenfalls die Einstellung Immer erlauben für den Zugriff auf das Zertifikat rückgängig machen könnt, könnt Ihr den ausführlichen Email-Artikel aus PDFs digital signieren – eine Anleitung zurate ziehen.

Zum theoretischen Hintergrund

Die folgenden Erläuterungen dienen dem Verständnis der Funktionsweise, sind aber für die Nutzung verschlüsselter Emails nicht erforderlich.


1. Die Funktionsweise von Zertifikaten

Die verschlüsselte Übertragung von Emails – wie auch von Websites – basiert auf sogenannten asymmetrischen Schlüsselpaaren.

Digitale Schlüssel sind einfach lange Ziffernfolgen. Ein asymmetrisches Schlüsselpaar besteht aus zwei solchen zusammengehörenden Schlüsseln, einem privaten Schlüssel und einem öffentlichen Schlüssel.

Digitale Verschlüsselung erfolgt dadurch, dass mit einem entsprechenden Algorithmus die ursprüngliche Zeichenfolge – der zu verschlüsselnde Text – unter Einbeziehung des spezifischen Schlüssels in eine andere, von dem Schlüssel abhängige, unleserliche Zeichenfolge transformiert wird. Wiederum unter Einbeziehung des Schlüssels kann diese unleserliche Zeichenfolge dann wieder in die ursprüngliche, lesbare zurücktransformiert werden.

Die mathematische Pointe bei einem asymmetrischen Schlüsselpaar ist nun, dass ein Text, der mit dem öffentlichen Schlüssel verschlüsselt wurde, nur mit dem privaten Schlüssel wieder entschlüsselt werden kann, es aber keinerlei Möglichkeit gibt, aus dem öffentlichen Schlüssel den privaten Schlüssel zu errechnen. Der öffentliche Schlüssel kann daher frei an alle Welt verteilt werden; nur den privaten gilt es strikt geheim zu halten. Wer den öffentlichen Schlüssel kennt – und der ist prinzipiell jedem zugänglich –, kann also eine Mitteilung verschlüsseln, die nur der Inhaber des zugehörigen privaten Schlüssels lesen kann.

Ein Problem bleibt dabei aber bestehen: Aus dem öffentlichen Schlüssel ist in keiner Weise ersichtlich, wer denn derjenige ist, der den zugehörigen privaten Schlüssel besitzt. Um sicher einer ganz bestimmten Person vertrauliche Informationen zukommen zu lassen, reicht also der öffentliche Schlüssel noch nicht aus.

Hier kommt nun die Zertifizierung ins Spiel, die an den öffentlichen Schlüssel die Metadaten anhängt, wem der Schlüssel gehört und wie lange er gültig sein soll (das ist aus Sicherheitsgründen immer begrenzt). Ein digitales Zertifikat ist nichts weiter als ein öffentlicher Schlüssel mit angehängten Metadaten.

Natürlich muss gewährleistet werden, dass die angehängten Metadaten korrekt sind. Hier kommen nun die Zertifizierungsstellen (in unserem Fall Certum) ins Spiel, die durch geeignete Identifikationsverfahren (in unserem Fall die Email an die zu verifizierende Email-Adresse mit dem Verifikationslink) feststellen, dass die angegebene Identität (in unserem Fall die Email-Adresse) korrekt ist. Für diese Kombination aus öffentlichem Schlüssel und Metadaten verbürgt sich die Zertifizierungsstelle dann ihrerseits durch Signierung mit ihrem eigenen Zertifikat.

Dieses Zertifikat der Zertifizierungsstelle, von dem die Gültigkeit aller von ihr ausgegebenen Zertifikate abhängt, das sogernannte Root-Zertifikat, ist sozusagen das Allerheiligste einer Zertifizierungsstelle, denn ihm müssen (auf der Grundlage der Lizenz, die die Zertifizierungsstelle erhalten hat) ohne weitere technische Möglichkeit der Überprüfung alle „blind“ vertrauen. Würde der private Schlüssel, der zu dem Root-Zertifikat gehört, kompromittiert, würden alle von dieser Zertifizierungsstelle ausgestellten Zertifikate unbrauchbar. Um dieses Risiko zu mindern, nutzen Zertifizierungsstellen in aller Regel zur Bestätigung der Gültigkeit der von ihnen ausgestellten Zertifikate nicht direkt ihr Root-Zertifikat, sondern auf bestimmte Zertifikatstypen (Email, Webbrowser, PDF, …) eingegrenzte und mit geringerer Laufzeit versehene sogenannte Zwischenzertifikate, die dann ihrerseits durch das Root-Zertifikat bestätigt werden. Dadurch entstehen sogenannte Zertifikatsketten, die dem Muster Für den Kunden ausgestelltes Zertifikat ← abgesichert durch Zwischenzertifikat 1 … ← abgesichert durch Zwischenzertifikat n ← abgesichert durch Root-Zertifikat folgen und die Sicherheit erhöhen, insofern bei Kompromittierung eines Zwischenzertifikats immer nur ein Teilbereich der von der Zertifizierungsstelle ausgestellten Zertifikate unbrauchbar würde.

Die Root-Zertifikate aller namhaften Zertifizierungsstellen (englisch Certificate Authorities oder kurz CAs) sind im Schlüsselbund System-Roots in macOS von Haus aus vorhanden, so auch die von Certum. Daher mussten wir beim Installationsprozess das dritte der zum Download angebotenen Zertifikate (eben das Root-Zertifikat) nicht herunterladen. Das zweite zum Download angebotene Zertifikat, ein Zwischenzertifikat, müssen wir hingegen installieren, um signierte Emails verschicken zu können. Haben wir freilich schon einmal von jemandem eine signierte Email bekommen, der ebenfalls ein Zertifikat von Certum nutzt, dann hat macOS dieses Zwischenzertifikat (Certum Digital Identification CA SHA2) bereits automatisch heruntergeladen und dem Schlüsselbund hinzugefügt, um das Email-Zertifikat via Zertifikatskette überprüfen zu können; in diesem Fall wäre das Herunterladen des Zwischenzertifikats beim Installationsprozess unnötig beziehungsweise würde zu einer Dublette in der Schlüsselbundverwaltung führen, was aber nicht schadet.


2. Die Bestellung eines Zertifikats

Einige Zertifizierungsstellen bieten ihren Kunden einen sehr simplen, untechnischen Bestellvorgang an, in dem er lediglich in einem normalen Web-Formular die zu zertifizierende Email-Adresse angeben muss, und liefern ihm Zertifikat und dazugehörigen privaten Schlüssel im sogenannten .p12-Format zurück. Das ist bequem, hat aber einen gravierenden prinzipiellen Nachteil: Das benötigte Schlüsselpaar, also beide, öffentlicher wie privater Schlüssel, werden von der Zertifizierungsstelle generiert. Der private, geheime Schlüssel sollte aber eigentlich den Rechner des Zertifikatsinhabers nie verlassen. Natürlich sichern all diese Zertifizierungsstellen zu, den privaten Schlüssel nach Abwicklung des Auftrags und Übersendung an den Kunden sofort zu löschen, aber auf diese Zusicherung muss man sich eben schlicht verlassen. Trifft sie nicht zu, gibt es jemanden, der alle verschlüsselten, vermeintlich sicheren Emails mitlesen kann.

Anders bei Certum (und diesbezüglich vergleichbaren Anbietern): Hier benötigen wir den zuvor im Zertifikatsassistenten der Schlüsselbundverwaltung erstellten CSR (Certificate Signing Request = Zertifikatsanforderung). Dieses scheinbar umständlichere Verfahren, Certum die zu zertifizierende Email-Adresse mitzuteilen, tut in Wahrheit viel mehr: Die Schlüsselbundverwaltung erstellt nämlich selbst per Zufallsgenerator bereits das Schlüsselpaar aus öffentlichem und privatem Schlüssel und sichert es automatisch schon im Schlüsselbund Anmeldung. Im CSR wird Certum dann nur der öffentliche Schlüssel und die dazugehörige Email-Adresse mitgeteilt; der private Schlüssel verlässt also den eigenen Mac nie, gelangt nie in Certums Hände und ist daher, was er sein sollte: vollständig privat. Ein Missbrauch seitens Certum ist folglich prinzipiell ausgeschlossen.

Das Datenformat, in dem Certum dann das Zertifikat zurückliefert, wird durch Doppelklick von der Schlüsselbundverwaltung vollautomatisch dem schon gespeicherten privaten Schlüssel zugeordnet.

Danke Weia, Du bist einer der Gründe, weshalb ich dieses Forum liebe.

Aber leider ist es bei dieser Verschlüsselung das gleiche, wie bei PGP: Damit es funktioniert muss die andere Seite aktiv werden, sich ebenfalls ein Zertifikat besorgen und installieren, sich um den Verfall kümmern und (sic!) das ganze auch benutzen. Selbst der Klick auf den Verschlüsselungs-Button ist für viele Normal-User schon zu viel.

Ich hab‘ lange mit PGP in mehreren Versionen gearbeitet und es letztlich aufgegeben. Viele verschlüsselte Mails wurden von den Empfängern gar nicht gelesen und nur wenige haben PGP überhaupt benutzt, obwohl ich das auf deren Rechnern komplett eingerichtet hatte.

Es ist, wie mit WhatsApp und anderen, sicheren Messengers: „Geht doch auch ohne und ist viel einfacher. Ich hab‘ doch nix zu verbergen.“

Hier wäre zB. Apple am Zuge: In Mail gleich entsprechende Zertifikate einbauen, die mit einem Klick benutzbar sind. Die Kosten könnten über iCloud abgerechnet werden, sprich: Bereits bei der kleinen Speichererweiterung enthalten sein.

Doch wenn Otto Normaluser etwas installieren und auch noch bezahlen soll, sinkt die Bereitschaft leider gegen Null: „Du immer mit Deinen Freak-Ideen, das brauchen wir doch nicht.“

Trotzdem: Nochmals Danke für die tolle Anleitung!

Herzlichen Dank für den Beitrag, Weia.

Ich verschlüssele meine E-Mails schon seit Jahrzehnten.
Früher habe ich, wie sehr viele Leute aus der Mac-Szene, OpenPGP mit dem Plugin für mail.app verwendet.

Beruflich versende ich mittlerweile via ProtonMail.
Einfacher geht’s halt nicht.

Es wird heutzutage ungern irgendwas »installiert«, dabei ist es so einfach, wie Du es beschreibst.

Wie kommst du dabei der revisionssicheren Archivierungspflicht nach?

Schöne Anleitung. Allerdings sehe ich dabei immer noch ein Problem.

E-Mail Verschlüsselung sollte eigentlich 2 Bereiche abdecken: Erstens den Inhalt der Mail schützen und zweitens die Echtheit des Absenders bestätigen. Und letzteres ist bei dem o.g. Bestellvorgang offenbar nicht gegeben.

Somit kann jeder für jede Mail Adresse ein S/MIME Zertifikat kaufen. Eine Überprüfung, ob das wirklich "meine" Mail Adresse ist und ich der echte, reale und vor allem berechtigte Nutzer dieser Mail Adresse bin fehlt hier.

Und damit ist S/MIME so wie oben beschrieben meiner Ansicht nach nutzlos. Genau wie bei GnuPG/PGP nutzt das alles nur dann etwas, wenn die Identität des Nutzers überprüft und bestätigt wird.

Ein weiteres Problem ist das bereits erwähnte Akzeptanzproblem. Es ist den allermeisten Nutzers einfach viel zu kompliziert, zu umständlich. Selbst wenn GPG Keys vorhanden sind, nutzt sie kaum jemand. Leider.

hawk

Ja, das ist sicher ein Problem, das die Website-Verschlüsselung eben nicht hat.

Aber immer dran denken: Für den gesamten Rest der Welt ist man selbst die andere Seite.

Im Gegensatz zum Verschlüsseln ist das Signieren der eigenen Emails (zur Beglaubigung des Absenders) ja möglich, sobald man selbst ein Zertifikat hat. Für 27€, die nun wirklich kein großer Betrag sind, kann man also 3 Jahre lang alle Welt wissen lassen, dass man selbst auch verschlüsselte Emails empfangen könnte. Man kann nur hoffen, dass das seine Wirkung nicht verfehlt – es müssen halt immer einige Menschen anfangen, etwas zu tun, damit es dann immer mehr tun. Anders lassen sich solche Henne-Ei-Probleme nicht lösen.
Der ist auch gar nicht nötig. Hast Du den Button einmal eingeschaltet, wird ab da automatisch jede Email verschlüsselt, wo das Zertifikat des Empfängers bekannt ist, und andere halt nicht. Drei Jahre lang musst Du also überhaupt nichts tun.

Aber Du hast natürlich insofern recht, als jene „Normal-Nutzer“, denen das schon alles zu viel ist, das auch nicht machen würden, wenn sie vor das Zertifikat getragen würden. Das ist halt so, aber von den Langsamsten darf man sich nicht ausbremsen lassen.

Es gibt mittlerweile doch immer mehr Behörden, Ärzte, Anwälte etc., die S/MIME-Emails nutzen. Das sind die Kommunikationspartner, an die ich zuerst denken würde, denn dort geht es oft genug um vertrauliche Dokumente, bei denen die Alternative nicht der ungesicherte Email-Versand ist – wie gleichgültig das Otto-Normalnutzer auch sein würde –, sondern gar kein Email-Versand. Und da wird es dann häufig deutlich umkomfortabler.

Je mehr Behörden, Freiberufler und Unternehmen digital signierte Emails empfangen, desto eher wird der Punkt erreicht werden, an dem sie die Entscheidung fällen, dass es sich nun auch für sie lohnt, S/MIME zu unterstützen (wenn sie es nicht bereits tun).
Das (subjektiv) vielleicht nicht, aber wenn sich die Gegenseite aus Datenschutzgründen weigert, entsprechende PDF-Dokumente über unverschlüsselte Emails zu versenden und dann andere Kommunikationswege fordert, kann es schnell deutlich umkomfortabler werden.
Das Zertifikat muss ja die eigene Email-Adresse enthalten – wie also sollte das gehen? Apple könnte den Vorgang bestenfalls unter Rückgriff auf die Apple ID für @icloud.com-Email-Adressen automatisieren und das auch nur, wenn der Apple-Nutzer schon eine @icloud.com-Email-Adresse angelegt hat. Für alle anderen Email-Adressen geht das nicht.

Ich bin die Das ist alles so teuer und kompliziert!- und Aber die anderen machen ja nicht mit!-Reaktionen in einer Gesellschaft, die sich andererseits beschwert, dass bei der Digitalisierung in Deutschland nichts vorangeht, auch ein wenig leid.

Nicht groß drüber nachgrübeln, einfach 27€ in drei Jahre Zukunft investieren, in Mail Signieren und bei der ersten Gelegenheit auch Verschlüsseln einschalten, nicht weiter drüber nachdenken und in drei Jahren nachsehen, wo die Email-Welt mittlerweile angekommen ist.

Wenn ich es richtig verstehe, ist das Beispiel eine Installation auf einem Mac. Wenn ich meine E-Mail Konten auch auf dem iphone und dem ipad in mail nutze, muss ich sie auf dem jeweiligen Gerät separat anlegen? Geht das überhaupt in der mail-Anwendung für ios?

Genau. Beides muss gewährleistet sein.
Doch, ist es:Nur wer Emails an die zu zertifizierende Email-Adresse empfangen kann, ist in der Lage, den Zertifikatserstellungsprozess abzuschließen.

Das ist doch der ganze Gag mit der Zertifizierungsstelle. Ohne diesen Punkt wäre sie komplett unnötig. Man kann Zertifikate auch selbst signieren, statt das von einer Zertifizierungsstelle erledigen zu lassen. Das kostet zwar nichts, aber dann kann man in der Tat in das Zertifikat natürlich schreiben, was man will. Wenn Mail eine Email empfängt, die mit einem selbsterstellten Zertifikat signiert ist, warnt das Programm daher unübersehbar davor, dass dem Absender nicht getraut werden kann.

Zertifizierungsstellen bieten im übrigen auch S/MIME-Zertifikate an, in denen nicht nur die Echtheit der Email-Adresse, sondern auch die Identität der dahinterstehenden natürlichen Person bestätigt wird. Das sind dann identitätsvalidierte Zertifikate oder kurz Personenzertifikate und nicht bloß Email-validierte Zertifikate. Dazu muss die Zertifizierungsstelle diese Identität aber natürlich ebenfalls überprüfen, und das geht dann nicht vollautomatisiert wie bei einer Email-Adresse, sondern der Personalausweis muss manuell überprüft oder ein Video-Ident durchgeführt werden. Das ist dann natürlich aufwändiger und entsprechend teurer. Erwerb und Installation von (auch zur Email-Signierung via S/MIME geeigneten) Personenzertifikaten sind in PDFs digital signieren – eine Anleitung beschrieben.
Nein, eben nicht. Er muss Emails an diese Adresse empfangen können.
Das Konzept eines Rechts auf eine bestimmte Email-Adresse gibt es nicht. Beglaubigt wird, dass derjenige, der Emails an diese Adresse empfangen kann (wer auch immer das ist), auch der tatsächliche Absender der signierten Mail ist und die Absender-Email-Adresse nicht gefälscht wurde.

Wenn es Dir freilich um die Identität der hinter einer Email-Adresse steckenden Person geht, weil Du befürchtest, dass Emails an max.mustermann@domain.tld gar nicht Max Mustermann, sondern in Wahrheit Erika Mustermann erreichen, dann braucht Max Mustermann eben ein identitätsvalidiertes Zertifikat.
Da ist Deine Ansicht falsch. Erstens reicht in den allermeisten Fällen ein Email-validiertes Zertifikat als Vertrauensbasis für die Email-Verschlüsselung vollkommen aus und falls nicht, nimmt man eben ein identitätsvalidiertes Zertifikat für S/MIME. Und im Gegensatz zu GnuPG/PGP ist da überhaupt nichts kompliziert, sobald man das Zertifikat erworben. Zwei Doppelklicks reichen und die Sache läuft; S/MIME ist vollständig in macOS integriert. Der Bestellvorgang für das Zertifikat liest sich vielleicht kompliziert, weil er Schritt für Schritt beschrieben ist, aber auch er ist in der Praxis eine Sachen von wenigen Minuten.
Es geht hier aber ausdrücklich nicht um GPG, sondern um S/MIME, und dessen Verbreitung (langsam, aber sicher) zu.

Erstmal vielen Dank, dass du dir so eine Arbeit machst.
Deine Anleitung ist wirklich für Blöde geschrieben, und dazu zähle ich mich auch. Gebe ich gerne zu.

Die andere Anleitung aus Januar 22 und deine Ergänzung letzte Woche bin ich noch am durcharbeiten. Dazu hätte ich aber eine Frage:
Die Emailverschlüsselung (Anleitung) von heute ist also der "kleine Bruder" deiner Ausführungen von Januar?

Tschööö

Lässt sich ein E-Mail-Zertifikat für mehrere (Alias-)Mailadressen nutzen?

Meine/unsere E-Mails werden rechtskonform archiviert, was auch immer das bedeuten mag.
Ist nicht mein Bier, das machen andere für mich, die sich damit auskennen.

Falsch. Die Validierung schließt eine Bestätigungsmail des Zertifikatsanbieters an die betreffende E-Mail ein. Du mußt also schon in der Lage sein, sie zu empfangen, und damit bist Du (idealerweise) der Inhaber der E-Mail-Adresse. Nichts anderes bestätigt das Zertifikat.

Eine andere Situation ist die, wenn der Zugang zu dem betreffenden E-Mail-Account kompromittiert ist, also jemand unautorisiert Mail empfangen kann. Der könnte sich dann ein Zertifikat für den Mailaccount ausstellen lassen und damit dann Mail signieren. Nur wird das natürlich früher oder später auffliegen, und dann läßt sich der Eindringling über den Bestellvorgang (insbesondere die Bezahlung des Zertifikats) auch noch viel besser dingfest machen ... also eher eine hypothetische Gefahr.
Identität des Nutzers und Kontrolle über den E-Mail-Account sind zwei verschiedene Dinge - ein wie von Weia beschrieben erzeugtes Zertifikat hat gar nicht den Zweck, eine Benutzeridentität zu bestätigen, sondern dient lediglich der Mailverschlüsselung. Und diesen Zweck erfüllt es.

GPG krankt an ganz anderen Dingen: Die Verwaltung der Schlüssel und die Verfolgung der Trust Chain, eben das, was X/509 mit Hilfe von Zertifikaten löst (die wieder eigene Probleme mit sich bringen, das sei unbestritten). Und ein ganz großes Manko bei GPG ist die mangelnde out-of-the-box-Unterstützung durch die Standardsoftware, z.B. auch Apple Mail. Nicht jeder installiert sich ein kostenpflichtiges Add-on wie GPGmail, das braucht man aber leider dafür, weil Apple Mail keine GPG-Unterstützung mitbringt.
Wenn ein Zertifikat installiert ist, ist der Vorgang bei X/509 vollkommen transparent und macht eigentlich keine Probleme mehr. Wessen es eigentlich bedarf ist eine Plattform wie LetsEncrypt für Mail, die den Vorgang der Zertifikatserstellung und -erneuerung ähnlich schmerzlos macht wie LE das für HTTP/SMTP etc. getan hat.

Pretty Easy Privacy hat bislang leider nicht so richtig die Füße in Sachen breiter Plattformunterstützung und Kompatibilität mit den Standard-Clients hochbekommen, sonst wäre das auch ein guter Ansatz.

Grundsätzlich ja. Der Zertifikatsaussteller muß das aber anbieten.

Yep; ich habe es nicht probiert, aber ich glaube, in der beschriebenen Form ginge die Zertifikat-Erstinstallation auf iOS/iPadOS nicht.
Wenn Du den iCloud-Schlüsselbund nutzt, musst Du gar nichts tun; das Zertifikat befindet sich dann automatisch auch im Schlüsselbund von iOS/iPadOS und sollte sofort funktionieren.

Wenn Du den iCloud-Schlüsselbund nicht nutzt, wählst Du auf dem Mac in der Schlüsselbundverwaltung Dein Zertifikat aus, wählst Ablage → Objekte exportieren und sicherst Dein Zertifikat im Dateiformat Personal Information Exchange (.p12). Da in dieser Datei auch Dein privater Schlüssel enthalten ist, musst Du dir ein Passwort ausdenken, mit dem Du die Datei sicherst.

Dann schickst Du Dir auf iPhone bzw. iPad eine signierte Email mit der .p12-Datei als Anhang. iPhone bzw. iPad sollten Dich nach dem Empfang fragen, ob Du diese .p12-Datei installieren willst, das bejahst Du und gibst das Passwort für die Datei ein. Das war’s.
Problemlos.

Wenn man das Zertifikat auch noch auf einem weiteren Mac ohne iCloud-Schlüsselbund installieren will, kopiert man einfach die .p12-Datei auf diesen Mac, vergewissert sich, dass in der Schlüsselbundverwaltung der Schlüsselbund Anmeldung aktiv ist, macht einen Doppelklick auf die .p12-Datei und gibt das Passwort für sie ein – fertig.

Sozusagen. Zum einen ist die Anleitung vom Januar viel ausführlicher und versucht, alle denkbaren Eventualitäten und Probleme vorauszuahnen, um sie „abzufangen“, was den Text aber eben so lang macht.

Zum anderen geht es dort um ein identitätsvalidiertes und nicht bloß Email-validiertes Zertifikat (siehe meinen Beitrag heute von 11:29 Uhr), das also nicht nur bestätigt, dass die Absender-Email-Adresse nicht gefälscht, sondern tatsächlich max.mustermann@domain.tld ist, sondern auch, dass hinter dieser Email-Adresse tatsächlich Max Mustermann steckt. Der Bestellprozess ist hier etwas aufwändiger, weil ja die personale Identität des Bestellers durch Personalausweis oder Video-Ident bestätigt werden muss, und das Zertifikat entsprechend teuerer (70€ für zwei Jahre statt 27€ für drei).

Damit ist dann nicht nur garantiert, dass die Email von der Person Max Mustermann gesandt wurde, sondern, viel wichtiger, dass man, jedenfalls mit dem spezifischen, in der Anleitung besprochenen Zertifikat, auch PDF-Dokumente signieren („digital unterschreiben“) kann, was weit rechtssicherer ist als das heutige Ausdrucken, Unterschreiben, wieder Einscannen oder gar Bilddatei mit Unterschrift ins PDF kopieren. Das geht allerdings nur mit dem Adobe Reader und dessen diesbezügliche Konfiguration ist etwas frickelig, was die Anleitung nochmals länger macht.

Hmm... ich habe mein Zertifikat im "Anmeldung"-Schlüsselbund gespeichert (auf meinem Mac Mini) und hatte mich selbstverständlich darauf verlassen, das Zertifikat auch auf meinem MacBook vorzufinden. Dem war aber nicht so.

Hab' ich da jetzt was falsch gemacht? Es scheint mir, dass nur das Schlüsselbund "iCloud" wirklich in der iCloud liegt, die anderen Schlüsselbunde hingegen lokal sind. Und "Ja", im obigen Zitat sprichst Du davon, im initialen Text hingegen ist vom "Anmeldung"-Schlüsselbund die Rede. Oder gilt das nur für den Zertifikatsassistenten?

Ich habe das Zertifikat letztendlich exportiert und auf dem MacBook ebenfalls in "Anmeldung" importiert - das hat natürlich funktioniert. Aber meine Erwartungshaltung war eine andere...

Danke, Weia, für die ausführliche Antwort auf meine Frage. Deine Beiträge sind immer lesenswert und hilfreich.

Meine Erfahrungen mit S/MIME, bringt am Ende nichts und interessiert auch niemand. Ich habe mehrere Jahre S/MIME eingesetzt und es wieder aufgegeben.

Danke @Weia für die Anleitung – echt Wahnsinn, wieviel Arbeit Du da immer reinsteckst in so etwas. Hut ab und chapeau.

Ich persönlich nutze seit vielen Jahren sogar beides (je nachdem, was 'die andere Seite' halt lieber im Einsatz hat), also entweder S/MIME oder PGP. Aber außer IT-Kollegen hat das ehrlich gesagt niemand im Einsatz … leider.

Einen wichtigen Punkt sollte man bei S/MIME übrigens auch nicht unterschätzen: Da man nach spätestens 3 Jahren komplett neue Zertifikate benötigt, muss man sich gut überlegen, wie man die dann 'alten' (abgelaufenen) Zertifikate/Keys archiviert, damit man im Zweifel wieder Zugriff auf diese hat (denn nur dann kann man ja auch die älteren empfangenen wie auch gesendeten signierten und verschlüsselten Mails auch noch entschlüsseln und somit lesen).

Aus meiner Sicht wäre eine Option sinnvoll, auch unlimitiert gültige Zertifikate zuzulassen (so wie das ja bei PGP auch möglich ist). Ist dann natürlich die Frage, wie so etwas bezahlt wird und auch der 'revoke-Prozess' (also das zurückziehen / ungültig machen von certs) müsste dann sicher noch einmal überdacht werden.

Im 'real life' ist aber eher das Gegenteil der Fall, man wollte die 3-jährige Gültigkeit ja sogar schon auf maximal 1 Jahr verkürzen, ist dann aber doch noch mal zurück gerudert …

Das wird so also nie kommen befürchte ich …

Oooops, mein Fehler. Ich bin wie/zu selbstverständlich davon ausgegangen, dass beim Einschalten des iCloud-Schlüsselbundes alle (jedenfalls alle nutzerspezifischen) Schlüsselbünde aus der Schlüsselbundverwaltung in die iCloud übertragen würden und nicht nur ein spezieller Schlüsselbund iCloud. Getestet habe ich das nicht, weil ich das für mich persönlich nicht wollte und ich nicht wusste, ob ich das restlos rückgängig machen kann, wenn die Daten erstmal in der iCloud sind. Sofort wieder erwischt – eine Sache, die man schreibt, ohne sie getestet zu haben, und prompt falsch – sorry, mein Fehler.

Wie verhält sich denn der Schlüsselbund iCloud? Ist der ebenfalls stets automatisch offen, sobald man sich in seinem Nutzerkonto anmeldet, so wie der Schlüsselbund Anmeldung? In dem Fall einfach den Schlüsselbund Anmeldung in meiner Anleitung durch den Schlüsselbund iCloud ersetzen. Ansonsten müsste man Zertifikat inklusive privatem Schlüssel zur Synchronisation in den Schlüsselbund iCloud verschieben und danach wieder zurück; ich weiß aber nicht, ob das dann auch auf iPhone und iPad geht. Aber das klingt ohnehin nicht, als sei es Sinn des iCloud-Schlüsselbundes.
Der Zertifikatsassistent speichert bei Erstellen der Zertifikatsanforderung öffentlichen und privaten Schlüssel immer im zu diesem Zeitpunkt ausgewählten Schlüsselbund. Da ich wie selbstverständlich davon ausgegangen bin, dass das immer der Schlüsselbund Anmeldung sein sollte, habe ich das so geschrieben. Technisch entscheidend ist nur, dass derselbe Schlüsselbund verwendet wird für die Erstellung der Zertifikatsanforderung und später dann die Installation der von Certum erhaltenen .cer-Datei durch Doppelklick auf sie – wobei es sogar sein kann, dass die Schlüsselbundverwaltung von sich aus für Letzteres automatisch den Schlüsselbund wählt, der bei Erstellung der Zertifikatsanforderung durch den Zertifikatsassistent ausgewählt war bzw. in dem sich öffentlicher und privater Schlüssel befinden.

Nochmals sorry für meinen Fehler.

Ein bisschen besser ist es bei mir mittlerweile. Und die Anleitung habe ich ja nur in der boshaft-egoistischen Absicht geschrieben, dass es noch besser wird.
Archiviert? Wozu? Einfach in der Schlüsselbundverwaltung lassen. Man kann dort ja nach Ablaufdatum sortieren, so sind die verfallenen Zertifikate immer ganz unten und stören nicht.

Kann jemand, der den iCloud-Schlüsselbund nutzt, mal kurz beschreiben, wie man den verwendet? Kann man den einfach alternativ zum Schlüsselbund Anmeldung verwenden, ist er also ebenfalls immer geöffnet, wenn man auf dem Mac in seinem Nutzerkonto angemeldet ist? Wo werden dann neue Login-Passwörter etc. per Default abgespeichert – im Schlüsselbund ICloud oder im Schlüsselbund Anmeldung? Oder kann man sich das von Fall zu Fall irgendwie aussuchen?

Ich habe mir auf meinen Irrtum bezüglich des iCloud-Schlüsselbundes hin nochmal die Schlüsselbundverwaltung angesehen. Da gibt es seit geraumer Zeit (aber eben nicht von Anfang an) bei mir einen Schlüsselbund Lokale Objekte. Ich vermute angesichts von Apples Nomenklatur in anderen Programmen, dass dieser spezielle Schlüsselbund zum iCloud-Schlüsselbund mutiert, sobald man in den Systemeinstellungen → iCloud den Schlüsselbund aktiviert.

Unter dieser Maßgabe (Schlüsselbund Lokale Objekte ≙ Schlüsselbund iCloud) ist das Verhalten des iCloud-Schlüsselbundes wie folgt:

• Er ist genau wie der Schlüsselbund Anmeldung stets geöffnet, wenn der Nutzer in seinem macOS-Nutzerkonto angemeldet ist, und kann insofern dieselbe Funktion erfüllen.
• Er besitzt keine Zugriffssteuerung, d.h. man kann im Gegensatz zu Objekten aus dem Schlüsselbund Anmeldung nicht angeben, welche Programme die Berechtigung haben, dauerhaft ohne Passworteingabe auf ihn zuzugreifen; stattdessen steht unter Zugriffsberechtigung lapidar und nicht editierbar apple, com.apple.irgendwas oder appleaccount (und vielleicht noch anderes mit apple).

Sprich, welche Programme in diesen Schlüsselbund schreiben und welche aus ihm ohne Passworteingabe lesen dürfen, ist eine völlig opake, nur Apple zugängliche Sauce. Safari legt (alternativlos) alle Login-Passwörter dort ab, die andere Web-Programme auf der ansonsten selben Basis (WebKit) wie z.B. OmniWeb dann aber nicht lesen geschweige denn ändern können. Auch Mail legt die Login-Daten der Mailkonten wiederum alternativlos dort ab.

Zertifikate finden sich dort hingegen überhaupt nicht und lassen sich auch nicht dorthin verschieben. Entsprechende Versuche quittiert die Schlüsselbundverwaltung mit einer Fehlermeldung. Für Objekte anderer Art entpuppt sich der iCloud-Schlüsselbund hingegen als Schwarzes Loch: Man kann sie aus anderen Schlüsselbünden, insbesondere dem Schlüsselbund Anmeldung, zwar in ihn hineinziehen, aber man kriegt sie danach nie wieder heraus (und z.B. in den Schlüsselbund Anmeldung zurück). Hotel California …

Langer Rede kurzer Sinn: Es geht wohl schlicht nicht für Zertifikate und ich würde von irgendeiner Bearbeitung dieses Schlüsselbundes nach den gerade gemachten Erfahrungen auch grundsätzlich absehen wollen. Da hat Apple im Zuge der Umstellung auf iCloud ein zuvor wunderbar transparentes Verfahren mal wieder verschlimmbessert.

Also bleibt für das Verteilen des Email-Zertifikats inklusive privaten Schlüssels nur das schon beschriebene Verfahren ohne iCloud-Schlüsselbund:

Man muss ja auch dazu sagen, dass das Thema "Schlüsselbundverwaltung" … mmh, wie soll ich es ausdrücken … schwierig ist.

Von der Benutzung des iCloud-Schlüsselbundes (wie auch nebenbei bemerkt vom iCloud-Drive) rate ich persönlich grundsätzlich ab, denn dort gab (und gibt) es teilweise so schwerwiegende 'bugs' (Sync-Fehler mit im schlimmsten Fall Datenverlust) – das will man nicht ernsthaft benutzen – zumindest nicht, wenn man geschäftlich darauf angewiesen ist.

Zum Thema "Schlüsselbund" muss man sich im Terminal auch einfach nur mal die manpage des Befehls anschauen, seit März 2017 steht da (selbst noch unter 12.5) ganz am Ende:


Das sagt eigentlich schon alles …

PS: Denn das certtool ist ebenfalls ordentlich buggy …

Ja, wie gesagt, ich nutze den iCloud-Schlüsselbund ja auch nicht, aber in Bezug auf Zertifikate hat sich das Thema ja nun ohnehin erledigt.
Na gut, das betrifft aber die zugehörigen Kommandozeilen-Programme.

In der Schlüsselbundverwaltung kann ich lokal jetzt keine Probleme entdecken. Und wie das Erstellen der Zertifikatsanforderung mit dem Zertifikatsassistenten funktioniert, finde ich sogar ausgesprochen elegant gelöst.

Der einzige wenn man so will etwas holprige Schritt dabei ist, die erstellte Zertifikatsanforderung in TextEdit zu öffnen und den Textinhalt in das entsprechende Feld auf der Certum-Website zu kopieren. Da wäre es einen Tick eleganter, man könnte die Zertifikatsanforderung einfach als Datei auf die Certum-Website hochladen. Aber das ist etwas, was Certum optimieren müsste, nicht Apple.

Na die Schlüsselbundverwaltung (die App) greift ja letztlich auch nur auf die Kommandozeilen-Programme, also sowohl 'security' als auch 'certtool' und auch 'systemkeychain', zurück.

Ein kleines Problem hatte ich z.B. schon des öfteren mit den 'älteren' (nicht mehr gültigen) certs/keys … das war (und ist es teilweise immer noch) ein Krampf, Apple Mail 'beizubringen', dass es doch jetzt gefälligst die aktuell gültigen certs/keys benutzen möge und nicht mehr die alten/ungültigen …

Selbst 'caches löschen' und 'Neustart' half da manchmal nicht, sondern erst das entfernen der alten certs/keys nebst 'caches löschen' und 'Neustart' und erst wenn das neue griff, konnte man die alten wieder importieren, ohne dass sie fälschlicherweise für neue E-Mails benutzt wurden.

Da ich das so nicht nur auf meinen Rechnern sondern auch schon vielen anderen macOS-Geräten erlebt habe (und auch Kollegen auf ähnliche Probleme stießen), merkte ich das weiter oben an mit dem 'alte certs/keys archivieren', denn das war für manche dann die tatsächlich schnellste Lösung, um einfach normal weiter arbeiten zu können …

Du (Weia) hattest speziell damit bisher tatsächlich nie Probleme?

Weil hier gefragt wurde, wie man die certs/keys auch unter iOS nutzen kann – sowohl unter macOS als auch iOS macht sich das IMHO am besten mit sogenannten "Configuration Profiles".

Entweder hat man schon einen MDM-Server im Einsatz (mit jamf NOW kann man z.B. bis zu drei Geräte kostenfrei verwalten) oder man baut sich die Profile mit dem kostenfreien iMazing Profile Editor:

Das ist aus meiner Sicht der eleganteste Weg, dies unter macOS wie auch iOS zu verwalten.

@ Weia,

ganz, ganz herzlichen Dank für Deine Anleitung und Deine Arbeit.

Ich hatte mich mit dem Thema vor über 2 Jahren mal etwas beschäftigt, aber keine so so prägnante Anleitung gefunden wie Du sie geschrieben hast und bin damals für mich, mit meinen gefühlten vorhandenen Fachwissen, kläglich gescheitert. Dein Beitrag hat mich dazu gebracht, dass Thema nochmals aufzunehmen. Jetzt hat es mit Hilfe deiner Anleitung (Signierung vom SMTP/IMAP-Konten) auf Anhieb geklappt; als nächstes werde ich mich meinen Exchange Konten zuwenden, mal schauen wie es da klappt.

Eine kurze Frage habe ich noch. Du empfiehlst Certum als Zertifikatsstelle, mit sehr überschaubaren finanziellen Aufwand.

Ich bin zum damaligen Zeitpunkt als Zertifizierungsstelle über die DGN gestolpert (https://www.dgn.de/e-mail-zertifikat-dgncert/), die komplett kostenlose Zertifikate anbietet. Siehst Du einen Nachteil darin, diese als Zertifikatsausstellungsstelle zu verwenden, insbesondere um sich in das Thema einzuarbeiten?

Viele Grüße und einen schönen Restabend
Hulg

hulg: DGN benutze ich persönlich für meine private Mail, hat eben den Nachteil, dass man dort nur 1 Jahr Gültigkeit bekommt, dafür aber komplett kostenfrei.

Ich selbst nutze 3 Jahre gültige bisher über TRUSTZONE, werde dann aber wohl auch auf CERTUM wechseln, da sie noch einmal deutlich günstiger sind.

Ich habe das mit dem iMazing Profile Editor (Version 1.6.1) gerade auch noch mal getestet auf einem 'frischen' System (macOS 12.5) – klappte auf Anhieb.

Wichtig ist, dass man nicht nur sein cert+key (als .p12) drin hat, sondern auch das ausstellende cert (als .crt), in meinem Fall ist das dann z.B. das gsgccr3personalsign1ca2020.crt bzw. GlobalSign GCC R3 PersonalSign 1 CA 2020 - Stichwort "Zertifikatskette" bzw. "Certificate chain".

"Key is Extractable" sollte man aus naheliegenden Gründen deaktiviert lassen, auch "Allow Private Key Access to All Apps" kann man deaktiviert lassen (beides im iMazing Profile Editor bei 'Certificate').

Nach dem installieren der .mobileconfig Datei muss man dann nur noch dauerhaft der Mail.app den Zugriff auf cert/key gewähren (wird automatisch abgefragt), und dann ist alles i.O.

So sieht das bei mir z.B. aus:



PS: Zum iOS Device kann man das Profile dann auch per Airdrop 'schubsen'.

Hallo Marcel_75@work,

vielen Dank für Deinen Hinweis. Das mit dem Thema der einen Jahr Gültigkeit ist mir auch gerade aufgefallen, als ich den Beitrag schrieb; hatte parallel die Schlüsselbundverwaltung offen und es dort gesehen.
Wobei mir ehrlicherweise nicht wirklich zum jetzigen Zeitpunkt klar ist, welche Einschränkungen bzw. welche Arbeiten bei Erneuerung eines Zertifikates damit einhergehen: Daher habe ich mich auf lediglich auf die Möglichkeit der "Einarbeitung" bezogen.

Mir ist nicht wirklich klar, welcher Aufwand auf meiner Seite (Anwender) entsteht, sofern das Zertifikat - unabhängig von der Laufzeit - ausläuft; ist möglicherweise auch ein Thema für andere Anwender, welche Konsequenzen sich ergeben, wenn die Notwendigkeit der Zertifikatserneuerung ansteht.

Ich für meinen Teil kenne dieses Thema bisher nur (aktuell aber auch nicht mehr; da nicht mehr verwendet) von macOS Server, da war das Thema Verlängerung vom Zertifikaten im Ergebnis sehr entspannt.

Viele Grüße
Hulg

Das stimmt nicht. Cocoa-Programme greifen praktisch nie auf ihre Kommandozeilen-Pendants zu, sie verwenden höchstens beide dieselben Libraries.

Im konkreten Fall liefern
allesamt keinen Treffer.
Nie. Und ich nutze S/MIME-Zertifikate seit 2004.

Auch andere Probleme hatte ich mit der Schlüsselbundverwaltung nie.

Weia: Ok, kann nicht ausschließen, dass in meinem Fall (wie auch bei den Kollegen) die Verwendung von Konfigurations-Profilen ein paar extra Schwierigkeiten bereiten in dem Zusammenhang …

Aber sobald es um mehr als nur ein Gerät geht, kommt man da kaum dran vorbei, erst recht wenn es um viele Mitarbeiter/Geräte geht, will man das irgendwie zentral 'verwalten' können.

Das ist eine Interessante Idee. Ich beschäftige mich mit Configuration Profiles erst seit kurzem und bin bislang nicht so ganz warm damit geworden, weil der Fokus da ja eher auf großen Mengen uniform zu konfigurierender Geräte liegt, aber das könnte im Fall der Zertifikate eine gute Alternative sein.

Für einige wenige Geräte ist aber auch das manuelle Verteilen kein Hexenwerk.
Das spräche dann wiederum gegen Konfigurations-Profile …

Das kann ich bestätigen. Ich nutze E-Mail Verschlüsselung auch schon ein "paar Tage" und war immer beeindruckt, wie simpel und transparent man das machen kann mit Apples 'Mail'.

Jüngst gab es übrigens ein "Oho" von mir für die Berliner Sparkasse: Wenn man einem Mitarbeiter eine signierte E-Mail schickt, dann ist die Antwort auch signiert - ohne daß der Sparkassenmitarbeiter auch nur ein Bit irgendwo ändern muß. Das ist ja schon halb- bis dreiviertel-automatische E-Mail Verschlüsselung!

So geht IT!

Da das Deutsche Gesundheitsnetz Dienstleistungen für Berufsgruppen wie Ärzte und Anwälte anbietet, sollten sie technisch solide sein.

Ich persönlich habe ich mich nicht näher damit beschäftigt, da ich nichts mit Medizin zu tun habe und mich in diesem Kreis schlicht fehl am Platze und auch ein wenig schmarotzend gefühlt hätte, auch wenn Branchenfremde wohl ganz offiziell „geduldet“ werden.

Wenn ich mir jetzt den Antrag für das kostenfreie DGNcert-Zertifikat ansehe, sehe ich aber zumindest zwei kritische Punkte:

• Der private Schlüssel wird hier im Gegensatz zu Certum beim Anbieter erzeugt. Das ist wie geschildert kein wirklich wasserdichtes Verfahren, was den Datenschutz betrifft, auch wenn es den Einstieg leichter macht, wenn man kein Programm wie den Zertifikatsassistent zur Verfügung hat – aber das hast Du ja.
• Das Zertifikat enthält angeblich auch den Personennamen, nicht nur die Email-Adresse, wäre von daher also ein Personenzertifikat, von einer Überprüfung der Identität ist aber nirgendwo die Rede und das wäre kostenfrei ja auch kaum machbar. Ohne Überprüfung der Identität ist die Aufnahme eines Namens in das Zertifikat aber hochgradig unseriös. Das lässt das ganze Unternehmen in einem für mich dann doch recht zweifelhaften Licht erscheinen.

Ich weiß nicht wirklich, was es da einzuarbeiten gibt, bevor man das beträchtliche Vermögen von 27€ für 3 Jahre investiert. Ich kenne Deinen Stundensatz nicht, aber wie viel kosten 20 Minuten Nachgrübeln über die Frage DGN vs. Certum? Zumal Certum das technisch bessere Verfahren anbietet, in das Du dich beim DGN gar nicht einarbeiten kannst …

Kein Aufwand außer einer Neubestellung, die aufgrund schon angelegten Kundenkontos und gemachter Erfahrungen weniger Aufwand als bei der Erstbestellung verursachen wird.

Üblicherweise wird die Zertifizierungsstelle Dir ein paar Wochen vor Ablauf eine entsprechende Erinnerungsemail schicken. Und dann bestellst Du halt rechtzeitig ein neues Zertifikat. Das ist alles.

Bei Certum kannst Du dann ja sogar explizit als Typ der Bestellung renew statt new angeben; ich weiß aber bislang auch nicht, was das ändert.

Danke für den Test!
Alternative wäre, eine signierte Email an das neue Gerät zu schicken – das hat denselben Effekt, was die Zwischenzertifikate betrifft.
Installiert man ein identitätsvalidiertes Zertifikat, das man im Adobe Reader dann auch zum Unterschreiben von PDFs verwenden kann, wird man Allow Private Key Access to All Apps vermutlich aktivieren müssen.

Hallo Weia,

vorab sei die Bemerkung erlaubt, dass der Betrag vom 27 Euro für mich keine Thema darstellt, über das es sich ernsthaft nachzudenken lohnt, daher auch die Frage.

Jetzt zum Thema und zu meinem Background. Ich interessiere mich seit langem für Signaturen und soweit wie möglich zum Verschlüsseln von emails. Dies mag damit zusammenhängen, dass ich - die graue Vorzeit mag mich einholen - für Mandanten, und das Ganze in sehr relevanten Sitatationen die, eigentlich bedeutsam waren, sich kein Schwein - auch im Rahmen von IPO's (ist aber ein paar Tage her) für Verschlüsselungen von email auch nur nur im Ansatz sich interessierte.

Nun habe ich folgen Situation:

1. Private email: Da hat mir Deine Anleitung sehr geholfen und das Ganze funktioniert mit Signatur ohne Probleme
2. Meine Steuerberater email über MS-Exchange Server (Exchange Online (Plan 2) muss ich noch testen
3. In Bezug auf das Unternehmen, in dem ich unterweges bin, ca. 10 Mitarbeiter - verbunden mit einem externen IT-Dienstleister, wäre ich sehr verbunden, wenn mir diesbezüglich, jemand die richtige Strategie diesbezüglich nennen könnte. Zur Information: ich habe vor kurzem alle Mitarbeiter auf MacBook Air migrieid, sodass eine einheitliche Plattform vorhanden ist.

Aus meiner Sicht entscheidend für den Erfolg von Signaturen und möglicherweise Verschlüsselungen von Email ist die "Einfachheit" des Systems. Insofern verzeihe mir den Hinweis hinsichtlich zweierlei Aspekte. In Bezug auf meine Person, mag Interesse bestehen, dass Thema zu durchdringen, jedoch in Bezug auf die anderen Anwender liegt genau dieses nicht vor. Diese möchten ihre email - ich löse mich gerade mal von der Plattform - so problemlos wie möglich versenden. Wenn diesbezüglich Informationen Vorlieben, bitte ich um Hinweis. Dann würde ich den Serviceprovider bitten, dass entsprechend umzusetzen. Sorry, wenn es länger geworden ist.

Vorab mit vielen Grüßen und vielem Dank

Mmh, sollte da der Adobe Reader dann nicht auch (also wie bei Apple Mail) beim ersten Bedarf (also Zugriff auf den private key) danach fragen und man entscheidet dann, ob man das 'einmalig' oder 'immer' erlauben möchte für diese App?

Dazu kann ich mangels jeglicher Erfahrung mit MS Exchange nichts beitragen, aber eigentlich sollte das da natürlich genauso problemlos funktionieren – wenn nicht, liegt es jedenfalls definitiv nicht an den Zertifikaten, die sind standardkonform.
Die erste Frage ist da: Sollen die Mitarbeiter alle dasselbe Zertifikat für die gesicherte Kommunikation nach außen bekommen (info@unternehmen.de) oder individuelle Zertifikate für die gesicherte Kommunikation untereinander und individuell mit Kunden (hinz@unternehmen.de, kunz@unternehmen.de)?

Für erstere Variante reicht dann ein Zertifikat, das bei 10 Rechnern wohl in der Tat am besten über ein mit dem iMazing Profile Editor erstelltes Konfigurationsprofil an alle MacBooks verteilt wird.

Für die zweite Variante könntest Du möglicherweise ein „Wildcard“-Zertifikat (*@unternehmen.de) verwenden, dessen Existenz von Peter Eckel bestätigt wurde. Damit kenne ich mich aber überhaupt nicht aus und wüsste auch keine Bezugsquellen. Am Ende kann es auch sein, dass so ein Zertifikat teuerer ist als 10 einzelne. Die Administration würde das sicher sehr vereinfachen, weil man dann ja wohl das Zertifikat genauso an alle Rechner gleich verteilen könnte wie bei einer einzigen, gemeinsamen Email-Adresse. So richtig klar ist mir das allerdings nicht. Dann hätten ja alle Nutzer denselben privaten Schlüssel, was ein Widerspruch in sich ist. Wenn jeder hingegen einen eigenen privaten Schlüssel hat, dann macht es vom administrativen Aufwand her auch keinen Unterschied mehr, ihm gleich ein individuelles Zertifikat zu spendieren …

Ansonsten muss halt auf jedem Rechner das individuelle Zertifikat erstellt werden. Du könntest alle 10 Zertifikate en bloc bei Certum kaufen, da die Email-Adressen ja wie geschildert erst im Anschluss an den Kauf konfiguriert werden; nur die CSR-Erstellung und die anschließende Aktivierung der Zertifikate müsste dann einzeln auf jedem Rechner vorgenommen werden.
Das ist ja auch nicht erforderlich. Nach der einmaligen Einrichtung funktioniert für den Anwender ja alles ohne jeden zusätzlichen Aufwand. Und die übrige Einrichtung (Mailkonten, IMAP, SMTP) werden diese Anwender dann doch vermutlich genauso wenig selbst vornehmen? Die Einrichtung vom Mailkonten und Zertifikaten könnte ein Administrator ja dann in einem Aufwasch erledigen.
Wen meinst Du mit Serviceprovider, einen lokalen Administrator der MacBooks? Der Internet-Diensteanbieter für Email etc. hat mit Zertifikaten ja nichts zu tun. Das muss lokal am Rechner eingerichtet werden.

Ach so, wenn das so ist, dass die Profileinstellungen individuell überschrieben werden können, dann natürlich, klar. Ich habe da halt keine Erfahrung und dachte, andere Apps könnten bei so einer Profilkonfiguration grundsätzlich und nicht veränderbar nicht auf die Schlüssel zugreifen.

Hervorragend informativer Beitrag - danke Weiha.

Also das ist grundlegend falsch.
Das Equivalent zu HTTPS ist nicht S/MIME bzw. PGP, sondern die Verschlüsselung der SMTP-Verbindung mittels TLS. Und das ist heute eigentlich Standard. Die großen Mailprovider machen das standardmäßig, und zumindest in Deutschland schreibt es der Datenschutz für Firmen vor. Bleiben noch ein paar kleine Klitschen die sich nicht drum kümmern und privat betriebene Mailserver, die keine TLS-Verschlüsselung bei SMTP können.

Der Unterschied: bei TLS (HTTPS ist HTTP über TLS) handelt es sich um eine Transportverschlüsselung (TLS = Transport Layer Security). Nicht die Daten sind verschlüsselt, sondern die Verbindung ist verschlüsselt (Quell- und Zielhost kommunizieren verschlüsselt miteinander, auf Quell- und Zielhost liegen die Daten aber unverschlüsselt vor). Damit kann niemand die Verbindung abhören (= den Inhalt während der Übertragung mitlesen).
Bei S/MIME und PGP handelt es sich um eine Inhaltsverschlüsselung. Dabei wird der Body des Mails verschlüsselt (Header bleibt unverschlüsselt). Die Inhaltsverschlüsselung schützt davor, dass jemand der sich unberechtigt Zugang zu dem Mail verschafft (z.B. Zugang zum Mailpostfach per Phishing erbeutet), den Inhalt des Mails lesen kann. Dafür braucht man dann zwingend den privaten Schlüssel (der quasi wie ein zweiter Faktor schützt).

Kann man sich übrigens im Mailheader eines eingegangenen Mails anschauen, ob das Mail verschlüsselt übertragen wurde:

Vielen Dank für das Thema und die detaillierte Erläuterung.
Es hat sogar alles geklappt - bis auf die Nutzung von S/Mime in Mail bei iOS 15.6
Habe mir das Zertifikat selbst zugeschickt und auf dem iPhone installiert.
Aber egal was ich mache, ich kann im Mail (unter "Erweitert" im betreffenden Mailaccount) das Signieren nicht aktivieren. Es steht auch weiterhin dort, dass keine gültigen Zertifikate gefunden wurden.
Auf dem MBP mit macOS 12.5 klappte es sowohl unter Mail als auch mit eM Client auf Anhieb.
Woran könnte es nun noch liegen?

VG

Das was man per Mail verschickt, ist im Normalfall nur der öffentliche Teil des Zertifikats.
Damit du aber Mails signieren und entschlüsseln kannst, brauchst du das komplette Zertifikat inkl. privatem Schlüssel. Und das schickt man sich übrigens nicht mal selbst per Mail, weil es damit ja auch auf dem Mailserver liegt, der dir nicht gehört. Wenn man so mit seinem privaten Schlüssel umgeht, kann man das verschlüsseln und signieren auch gleich ganz bleiben lassen.

@athlonet: und nun? Hast Du einen Tip?

d2o: Habe ich doch weiter oben erwähnt, was allgemein der 'way to go' ist …

Am schnellsten geht die Verwaltung sowohl unter macOS als auch iOS per .mobileconfig Datei. Die kannst Du Dir z.B. mit dem kostenfreien iMazing Profile Editor erstellen. Da kommt die .p12 rein (das ist dein cert inkl. deines private key) und idealerweise auch gleich noch die .crt der Zertifizierungstelle (für die certificate chain).

Übrigens: Die .p12 sollte man immer mit einem Kennwort schützen, so dass man ohne dieses Kennwort nicht einfach an deinen private key kommt. D.h., wenn du dir aus aus dem Schlüsselbund dein S/MIME-Zertifikat und den dazu passenden "Privaten Schlüssel" als .p12 (Personal Information Exchange) exportierst, schützt du die zu exportierenden Objekte mit einem sicheren Kennwort.

Und wie athlonet schon richtig anmerkte bitte niemals cert+key "per E-Mail" auf das Gerät schubsen, sondern wenn schon dann per Airdrop oder halt auch direkt per Kabel und iTunes bzw. Finder.

Na man 'überschreibt' damit ja keine Profileinstellung, sondern man erlaubt halt nur nicht pauschal jeder App den Zugriff. Um Erlaubnis fragen können die Apps dann ja trotzdem und das muss man dann eben nur jedes mal (oder auch dauerhaft, damit es nicht nervt) erlauben.

Die Profileinstellung bleibt dabei ja komplett unberührt, es ist weiterhin "Allow Private Key Access to All Apps" nicht erlaubt und somit muss jede App explizit mind. 1x um die entsprechende Erlaubnis fragen.

Bleibt zu hoffen, dass Adobe und deren Reader das so auch "kann" … getestet habe ich das nicht. Aber ich gehe mal davon aus, dass das klappen sollte.

Ist es nicht. Es kommt auf das tertium comparationis an.

Das hier ist offenkundig ein an Laien gerichteter Beitrag. Aus deren Perspektive sind beides Verfahren für eine gesicherte Übermittlung vertraulicher Dokumente. Beide bauen auf einer Public-Key-Infrastructure auf, für die die erforderlichen Zertifikate bei denselben Zertifizierungsstellen ausgestellt werden. In Ermangelung der generellen Verfügbarkeit von S/MIME wird oft der Umweg benutzt, dass vertrauliche Dokumente über Email nur angekündigt werden, dann aber von einem HTTPS-Server heruntergeladen werden müssen, was man sich mit S/MIME ersparen könnte.

Funktionell betrachtet sind HTTPS und S/MIME Pendants, um ein bestimmtes Problem zu lösen. Die technischen Details, die Du hier nennst, spielen hierfür keine Rolle.
Nö, ist es nicht, wenn man unter Normalfall versteht, die Schritte dieser Anleitung abzuarbeiten. Dann verschickt man nämlich einen passwortgeschützten .p12-Container, der auch den privaten Schlüssel enthält.
Bist Du heute im Dauer-Motz-Modus?

Alle Zertifizierungsstellen, die nicht mit CSRs arbeiten, verschicken Zertifikat und privaten Schlüssel im .p12-Format oder einem vergleichbaren Format per Email an den Kunden. Das Ding ist schließlich passwortgeschützt. Was Zertifizierungsstellen recht ist, sollte d2o billig sein.

Und es ist die von Apple empfohlene Methode, um S/MIME-Zertifikate auf dem iPhone zu installieren.

WIe würdest Du das denn machen?