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

Noch ein kleiner Tipp für diejenigen, bei denen bei neu zu schreibenden E-Mails statt S/MIME immer OpenPGP in Apple Mail vorausgewählt ist (war bei mir auf einem Rechner so):


Dann ist S/MIME wieder dauerhaft vorausgewählt.

Hast Du die Email, mit der Du dir das Zertifikat selbst zugeschickt hast, auch gemäß Anleitung mit diesem Zertifikat signiert?

Sonst funktioniert das nämlich nicht, da das Zwischenzertifikat noch fehlt, das durch den Empfang einer signierten Email aber nachgeladen würde.

Im Zweifelsfall einfach noch mal eine signierte Email (ohne den .p12-Anhang) schicken.

Marcel_75@work hat darauf schon die perfekte Antwort geliefert. Z.B. per Airdrop.

Aber ich mache es gar nicht. Weil S/MIME im Privatbereich overkill ist.
Erstens wird heute eh kaum noch ein Mail unverschlüsselt übertragen, weil SMTP über TLS bereits fast Standard ist (bei uns in der Firma kommen 97% aller Mails über TLS verschlüsselte SMTP Verbindungen an, und nur noch 3% im Klartext) - bei den großen Mailprovidern sowieso. Und vertrauliche Daten kann man privat als passwortgeschützte ZIP-Datei versenden. Ist immer noch einfacher als S/MIME. Machen übrigens immer mehr Firmen und Banken so, wenn sie etwas Vertrauliches per Mail an Privatleute schicken (z.B. verschickt Vodafone Einzelverbindungsnachweise als passwortgeschützten Anhang).

Naja, Konfigurationsprofile sind sicher nicht der way to go für ein einzelnes Zertifikat. Wenn man bis dahin noch nie mit Konfigurationsprofilen gearbeitet hat, ist das mit Kanonen auf Spatzen geschossen. Der offizielle Weg, den Apple nennt, ist, eine Email mit dem .p12-Container ans iPhone zu schicken.
Natürlich. Steht ja so da:Witzig: Ich habe mir beim Verfassen der Anleitung lange überlegt, ob ich .p12-Export und Installation auf anderen Macs und iOS/iPadOS-Geräten mit aufnehmen soll, und mich am Ende dagegen entschieden, da meine Beiträge immer zu lang werden, weil sie alle Eventualitäten mitberücksichtigen wollen. Und prompt wird das zum Thema. 🙄
Nochmals: Das ist der offizielle Weg. Natürlich im passwortgesicherten .p12-Container. Ich wüsste aber auch gar nicht, wie man „cert+key“ anders aus dem Schlüsselbund exportieren könnte. Oder was meintest Du?Wie genau sollte das funktionieren? Was kopierst Du wie in iTunes wohin?

Weia: Naja, ich persönlich sehe das mit den Profilen schon als großen Vorteil. Warum?

Wenn Du die .p12 als Datei an iOS übergibst, hast Du das cert inkl. des dazugehörigen private key im Schlüsselbunf von iOS – wieder raus bekommst Du es da da aber nicht mehr ohne weiteres. Und vor allem hast Du keine Möglichkeit zu kontrollieren, ob und wenn ja was für welche da noch drin sind (also weitere certs/keys etc.).

Es fehlt halt eine Schlüsselbundverwaltung für iOS/iPadOS …

MIt einem Profil verhält es sich da anders … entferne ich das Profil, wird auch dessen Inhalt (also cert inkl. des dazugehörigen private key) wieder aus dem Schlüsselbund von iOS sauber entfernt.

Ich sehe das eben aus datenhygienischer Sicht …

Du hast recht, sorry … ich nahm an über "Dateien" könne man das da auch hochschubsen per Kabel, aber das macht man nur so für die config der OpenVPN.app beispielsweise … habe ich mich wohl geirrt.

Aber dann bleibe ich trotzdem dabei lieber per Airdrop als per Mail.

Vielen Dank für die super Anleitung!
Das Frauenhofer SIT hat eine Plattform für kostenlose Zertifikate geschaffen:

Leider sehr Windows orientiert und aktuell bekommt man das Zertifikat nur, wenn man es per digitalem Personalausweis identifiziert, aber einmal einen Blick wert!
Volksverschlüsselung

Deren root CA (Wurzelzertifikat) ist nicht Bestandteil von macOS … dazu kommt, dass es am 10. Mai 2023 abläuft:



Also ich weiß nicht … klingt für mich nicht sonderlich überzeugend.

Und was genau würdest Du per AirDrop kopieren? Einen .p12-Container oder etwas anderes?
Abgesehen davon, dass man da unterschiedlicher Auffassung sein kann, ist in den meisten relevanten Fällen aber mindestens eine der beiden beteiligten Parteien eben nicht privat, ob Behörden, Ärzte oder Anwälte. Und die weigern sich oft (bzw. dürfen es gar nicht), per Email bestimmte Unterlagen zu versenden oder Auskünfte zu geben, wenn die Emails nicht via S/MIME geschützt sind. Es geht ja nicht nur um den Inhalt, sondern auch um die Bestätigung der Absender-Adresse.
Aber um den Transportweg geht es hier überhaupt nicht. Du kannst die übelste Trojaner-Email problemlos TLS-transportgeschützt übertragen.
Das fasse ich jetzt nicht – Du schlägst allen Ernstes vor, Nutzer sollten habitualisieren, in unsignierten Emails übersandte ZIP-Dateien zu öffnen?
Herrje, was soll denn an S/MIME nur so schwierig sein? Irgendwie behaupten das immer die, die es gar nicht nutzen …

Was soll denn daran einfacher sein, jedes Mal ein mutmaßlich getrennt versandtes Passwort eingeben zu müssen?

In jedem Fall ist Dein Vorschlag um einige Million mal gefährlicher als S/MIME.
Mit einem Unternehmen, das eine derartige IT- und Datenschutz-Kompetenz an den Tag legt, würde ich sofort jede Geschäftsbeziehung beenden.

Richtig ist, dass zunehmend Behörden, Ärzte und Anwälte S/MIME einsetzen. Nicht ohne Grund existiert mit dem DGN sogar eine speziell an den Medizinsektor gerichtete Zertifizierungsstelle.

Signiert auch...
Der Unterschied ist nur, dass ich dann weiß, bei wem ich mich für den Trojaner "bedanken" muss.

Das tun sie bereits seit Jahrzehnten...
Und ja, natürlich ist es nicht richtig. Aber du bist ein Träumer wenn du glaubst du könntest das ändern
Da sind wir dann bei dem Thema, dass es sehr wohl besser wäre, per Mail nur eine Info raus zu schicken, und die Datei dann per HTTPS aus einem per Zwei-Faktor-Authentifizierung geschützten Bereich herunterzuladen.

Richtig. Für die Kommunikation untereinander (z.B. Anwälte mit dem Gericht).
Aber für die Kommunikation mit Privatpersonen wirst du das nie durchsetzen können. Selbst De-Mail ist gescheitert.
Und selbst mit einer einfacheren Signatur-Lösung auf Basis des ePerso wirst du niemals alle Privatpersonen dazu bringen das zu nutzen.

Und wenn du das Mail nicht nur signierst, sondern auch per S/MIME verschlüsselst, nimmst du dem Mailserver die Möglichkeit, den Trojaner überhaupt zu erkennen.

Ich persönlich sehe da gar nicht so sehr das Problem, dass die Leute nicht bereit wären, sich S/MIME einzurichten (bzw. einrichten zu lassen).

Denn Weia hatte ja schon richtig angemerkt: Einmal eingerichtet läuft das eigentlich unauffäliig und geschmeidig (zumindest für 1-3 Jahre … dann muss man wieder ran).

Das Hauptproblem sind aus meiner Sicht (so traurig das ist) einfach die Kosten!

Für viele ist es ja schon zu viel verlangt, sich Threema zu kaufen. Im Idealfall kann man die Leute dann wenigstens noch vom Einsatz von Signal überzeugen, da es das tatsächlich kostenfrei gibt.

Beides sehr sichere E2EE Messenger, immerhin einer der beiden 'kostenfrei'.

Bei S/MIME fehlt einfach eine Lösung, die ebenfalls komplett kostenfrei ist (und das auch bleibt).

Die DGN certs sind zwar kostenfrei erhältlich, aber nur mit maximal einem Jahr Gültigkeit und der private key wird bei denen erzeugt, eine Anfrage per CSR ist beim DGN leider nicht möglich soweit ich weiß.

Was es bräuchte:

1) Kostenfrei erhältliche S/MIME Zertifikate, die man per CSR anfordern kann und die dann auch gleich 3 Jahre Gültigkeit haben.

2) Dazu kommt, dass mind. das Wurzelzertifikat dieser Zertifikats-ausstellenden Institution auch zu den vertrauenswürdigen root-Zertifikaten der gängigen Systeme gehören sollte.

So eine PKI sicher und zuverlässig zu betreiben (inklusive Revocation-Möglichkeiten, Verlängerungs-Möglichkeiten etc.) ist ein großer Aufwand. Wer soll das betreiben, wenn niemand dafür bezahlen möchte?

Eigentlich sähe ich hier am ehesten das BMBF (Bundesministerium für Bildung und Forschung) in der Pflicht, so etwas auf die Beine zu stellen. Oder gleich eine EU-Institution.

Gleichzeitig hätte man so sehr wahrscheinlich den BND etc. 'mit im Boot', die würden dann z.B. durchdrücken, dass es doch keine per CSR anforderbaren S/MIME certs gibt, sondern es würde so laufen wie jetzt beim DGN (und BND & Co. würde sich die ganzen 'private keys' dann fein säuberlich in eine Datenbank packen).

Um das nochmals deutlicher zu machen:

1. Ein (im Idealfall identitätsvalidiertes) TLS-Zertifikat für eine Website bestätigt, wer der Betreiber einer Website ist und bei wem entsprechend meine Eingaben in einem Formular auf dieser Website landen, also z.B. meine Bank. Das ist, was ich an dieser Stelle wissen will.

2. Ein (im Idealfall identitätsvalidiertes) S/MIME-Zertifikat für den Email-Absender bestätigt, wer der Absender der Email ist und bei wem entsprechend meine Antwort auf die Email landet, also z.B. meine Bank. Das ist, was ich an dieser Stelle wissen will.

3. Ein TLS-Zertifikat, das für die verschlüsselte Übertragung einer Email zu und von dem Email-Provider genutzt wird, bestätigt die Identität des Email-Providers. Der interessiert mich als Empfänger einer Email aber normalerweise überhaupt nicht.

In diesem funktionalen Sinne sind ganz klar Punkt 1 und 2 die Pendants und nicht Punkt 1 und 3, auch wenn Punkt 1 und 3 technisch gesehen enger verwandt sind.

Aber um die technischen Details ging es in der Einleitung nicht, sondern um die gesellschaftlichen Funktionen von HTTPS und S/MIME. Du schaust zu sehr auf die technischen Details und auf den Aspekt der Verschlüsselung, statt den der Identität.

Weia: Übrigens, was mir gerade noch einfällt: Mit dem 'renew' der certs ist das wohl so (zumindest bei TRUSTZONE, wo ich bisher meine S/MIME certs kaufte), dass man da dann einfach die Option bekommt, schon vor Ablauf der alten certs sich neue ausstellen zu lassen und diese "Überschneidung" der Zeiträume (von maximal 2 oder 3 Wochen glaube ich) wird einem dann nicht 'doppelt berechnet' sozusagen.

Keine Ahnung ob das bei CERTUM auch so ist, aber da kann man ja mal anfragen beim Support, wie die sich das vorstellen bzw. wie genau bei denen dieser 'renew'-Prozess läuft.

Mir geht es bei der Nutzung des S/MIME-Zertifikats nur darum, dass das Zertifikat bestätigt, dass die Mail von mir kommt (Identität). Die Verschlüsselung von S/MIME habe ich bislang noch nicht gebraucht bzw. gebrauchen können.

Bei einem Kunden wird mein Zertifikat aber offenbar als Sicherheitsrisiko betrachtet. Meine Mail kommt als Anhang zu einer Mail mit Sicherheitshinweis an: "[EXTERNAL E-MAIL] DO NOT CLICK links or attachments unless you recognize the sender and know the content is safe." Absurd, denn meine Identität soll das Zertifikat ja gerade bestätigen.

Wunderbar! So isses!

Ja, ich sehe Deine Punkte ja und folge ihnen auch zumindest bis zu einem gewissen Grad. (Meine Bauchschmerzen wären, dass zusätzliche Komplexität auch immer zusätzliches Fehlerpotential bedeutet.)

Mein Punkt ist ein anderer: Meine Anleitung richtet sich gerade auch an völlige Computerlaien und versucht, ihnen den Einstieg in S/MIME-Emails so einfach wie möglich zu machen.

Vermutlich praktisch niemand aus diesem Adressatenkreis hat schon von Konfigurationsprofilen gehört geschweige denn den iMazing Profile Editor bereits installiert und sich mit ihm vertraut gemacht. Für diese Nutzer würde das faktisch oder zumindest psychisch eine enorme zusätzliche Einstiegshürde darstellen. Wenn schon das Installieren eines S/MIME-Zertifikats auf einem einzelnen Mac als zu kompliziert gilt, dann brauchen wir von Konfigurationsprofilen doch gar nicht erst anfangen zu reden.

Je erfahrener der Nutzer ist und je mehr Geräte es sind, auf denen die Zertifikate installiert werden sollen, desto mehr gebe ich Dir recht.

Und wie funktioniert das dann? Profile kannst Du so übertragen, ja. Aber Schlüssel? In welchem Format? .p12?

Ist halt noch in einem frühen Stadium. Aber grundsätzlich finde ich solche Initiativen sehr begrüßenswert. Du selbst schreibst doch später, es müsste kostenfreie Zertifizierungsstellen geben.
Das muss sich natürlich ändern, bevor die Initiative praxisrelevant wird. Aber dafür hat ein Fraunhofer-Institut vielleicht bessere Karten als andere Institutionen.
Ääähh, am 25. Mai 2036:

Ich hätte mir nur gewünscht, dass es nicht ausgerechnet Volks… im Namen trägt. Der Name ist politisch einfach verbrannt.

Mmh, davon wäre ich eigentlich ausgegangen, ja. Aber eventuell geht das dann wirklich nur mit .mobileconfig aber nicht mit .p12?

Ich hätte da eigentlich vermutet, dass man das .p12 per Airdrop zum iOS/iPadOS-Gerät schubst und das fragt dann, ob man das öffnen und letztlich installieren will?

An der Stelle möchte ich nochmal nachfragen. Wenn ich jetzt dieses Zertifikat von Fraunhofer nutzen wollen würde, wäre das fehlende Wurzelzertifikat ein Problem bei der Feststellung der Gültigkeit des Zertifikats beim Empfänger?

Nur?

Ich finde, es ist ein erheblicher Sicherheitsgewinn, wenn ich weiß, dass die Email von meiner Bank auch tatsächlich von meiner Bank kommt.

Wenn die mir dann Trojaner schickt, kündige ich.
Aber das muss man doch nicht noch fördern, statt dem was entgegenzusetzen.
Dann bin ich halt einer. Das höre ich immer wieder. Aber ich bin einfach nicht bereit, ein Leben unter der Prämisse zu führen, dass ich ohnehin nichts beeinflussen kann. Dann hätte ich diese Anleitung erst gar nicht verfassen müssen.
Nicht nur. Mein Anwältin mit mir auch.
Werden wir ja sehen.
Selbst ist gut. Das war ja nun das Allerletzte.
Niemand sagt, dass das alle nutzen müssen.
Das würde ich auch nicht wollen; das mache ich schon selbst. Den Mailserver gehen meine Emails absolut nichts an; auf bevormundende Technik kann ich mehr als verzichten.

Das könnte gut sein und wäre natürlich eine höchst erfreuliche Funktionalität. Bislang habe ich immer eine gewisse Überlappungs-Zeitspanne verschenkt, weil ich nicht riskieren wollte, erst im letzten Moment neu zu ordern und dann klappt irgendwas nicht. (Ich bin erst seit Anfang des Jahres Kunde bei Certum.)

In dem Fall reicht es dir doch aber normalerweise, wenn es sich um ein validiertes Zertifikat der Bank, der Anwaltskanzlei, der Arztpraxis, des Finanzamtes,... handelt (ist ja bei HTTPS auch nicht anders).
Dafür gäbe es was einfacheres als S/MIME. Nämlich DKIM. Da mangelt es nur leider auch noch an der Verbreitung.
Bei DKIM wird jedes Mail mit einem DomainKey signiert.

Ja, das ist natürlich wirklich absurd. 🙄

Einen so ähnlichen Fall kenne ich auch: Ausgerechnet bei der IHK in meiner Stadt stürzt das Mailprogramm ab, sobald es eine signierte Email bekommt. Da gibt es noch viel zu tun …

Da bin ich mir aber ziemlich sicher, dass das nicht wegen, sondern trotz des Zertifikates passiert.
Ich kenne auch Firmen, die machen genau das (das ursprüngliche Mail als Anhang in ein neues Mail packen und mit tausenden Warnhinweisen versehen) mit jedem Mail das von einer Domain kommt, die kein SPF / DKIM / DMARC hat.
Die Signatur ist nämlich genau der Grund, warum sie die Warnhinweise ("Mail von extern" blablabla...) nicht einfach in das ursprüngliche Mail rein schreiben. Dadurch würde nämlich die Signatur ungültig werden. Deshalb generieren sie ein neues Mail mit den Warnhinweisen, und hängen das ursprüngliche Mail (mit dann noch gültiger Signatur) an.

spf und DKIM habe ich für meine Mails definiert. Wenn ich diesem Kunden mit einer anderen Mail schreibe ohne S/MIME-Zertifikat, dann kommt dieser Hinweis nicht.
Aber ich könnte das Zertifikat für diesen Empfänger auch deaktivieren, daran habe ich noch gar nicht gedacht 🤦

Zu recht. Das funktioniert genau so wie Du dachtest, gerade getestet. Das ist also eine echte Alternative für die Installation auf iPhone und iPad.

Allerdings muss man dann auch noch das Zwischenzertifikat (im exportierten Format .cer) auf dieselbe Weise kopieren und installieren, damit das eigene Zertifikate als gültig erkannt wird. Schickt man das eigene Zertifikat mit signierter Email, muss man das nicht. Und meiner Erinnerung nach geht die Installation auch über weniger Passworteingaben und Umwege, da bin ich mir aber nicht sicher.

Ich finde mein Verfahren immer noch eleganter. Allerdings, so fällt mir gerade ein, nutze ich auch nur POP zum Emailempfang, d.h. die Email mit dem Zertifikat ist nach kürzester Zeit wieder vom Server verschwunden.

Ja. Dein Zertifikat würde als ungültig markiert, bis Dein Gegenüber manuell das Root-Zertifikat installiert hat. Kannst Du vergessen.

Für die Identifikation ja. Die Verschlüsselung ist mir dennoch wichtig, denn auf dem Mailserver des Providers liegt die Email sonst ja dennoch ungeschützt.
Das ist lustig, dass Du das sagst. Ich finde DKIM deutlich komplizierter und fehleranfälliger als S/MIME. Ich hatte damit schon viel Ärger, als Sender und Empfänger. Und es bietet halt weniger als S/MIME.

Woher Deine Aversion gegen S/MIME kommt, kann ich einfach nicht nachvollziehen.

Ich weiß nicht. Wem 9€ im Jahr zuviel sind, der will einfach nicht. Und würde das vermutlich nicht mal machen, wenn er 9€ im Jahr dafür bekäme.

Dann halt nicht. Es muss ja nicht jeder mitmachen.
Klar, das ist unabdingbar.
Falsche Frage. Es darf was kosten.
Eben. Daher scheidet das aus. Darf ich an das De-Mail-Desaster erinnern?

Und die, die das machen, verwalten auch deine Zertifikate?

Hallo Weia,

wie lange hast du nach dem Kauf warten müssen ? Ich habe das vor 2 Tagen gekauft und habe noch immer keine Email zur Bestätigung bekommen. Es steht immer noch in Progess da ..

Ich habe gestern für meine private Posteo-Mail mein DGN cert durch ein 3 Jahre gültiges CERTUM cert ersetzt, das lief tatsächlich alles innerhalb von Sekunden.

Bezahlt hatte ich direkt per PayPal, eventuell hast Du ja eine andere Zahlungsmethode benutzt und deshalb dauert das einfach?

Nachtrag:
Ich habe es tatsächlich so gemacht, wie Apple es vorgeschlagen hat.
Aber ich hatte das nicht den privaten Teil exportiert. Habe es noch mal versucht und das Zertifikat und den privaten Schlüssel in einen p12-container exportiert, per Mail zugeschickt und tadaaaa... klappt.
Ich wollte mir nicht extra noch Konfigurationstools besorgen etc.

VG

Bei Certum? Gar nicht. Der Prozess läuft automatisiert quasi in Echtzeit ab. Am längsten dauert die Maillaufzeit und die menschliche Reaktionszeit zum Klicken auf den Verifikationslink für die Email-Adresse.
Wo steht in Progress?

Was hast Du den bislang überhaupt für Emails von Certum bekommen? Es müssten – in dieser Reihenfolge – sein:

• Confirmation of creating new account in Certum Shop
• Newsletter subscription confirmation (noch nicht abonniert, geschieht auch nicht, wenn Du nicht auf den Link klickst)
• Order confirmation
• Activate the certificate (kommt manchmal vor Order confirmation)
• Dotpay payment information (von Dotpay online payments)

Prima.

Wenn wir schon bei Thema iPhone gelandet sind, hier noch ein Hinweis zum Senden verschlüsselter Emails vom iPhone aus:

Ich weiß nicht, ob das bei iOS 15 auch noch so ist, aber bis iOS 14 gibt es folgendes Problem nach erfolgreicher Installation des Zertifikats via .p12-Container wie beschrieben:

Empfangen signierter und verschlüsselter Emails funktioniert, das Senden signierter Emails ebenfalls, aber das Senden einer verschlüsselter Email an einen Dritten funktioniert nicht.

Natürlich muss von diesem Dritten, wie beim Mac auch, zuvor mindestens eine signierte Email auf dem iPhone empfangen worden sein, sonst funktioniert das Senden verschlüsselter Emails an denjenigen prinzipiell nicht.

Aber auf dem Mac funktioniert das automatisch, sobald solch eine signierte Email empfangen wurde. Auf dem iPhone jedoch nicht. Warum?

Um eine verschlüsselte Email senden zu können, muss Mail wie oben beschrieben das Zertifikat des Empfängers bekannt sein. Dieses Zertifikat ist in der signierten Email der betreffenden Person enthalten. Auf dem Mac wird es beim Empfang dieser Email sofort automatisch im Schlüsselbund Anmeldung abgespeichert und steht somit ab da zur Verfügung, wenn Mail eine verschlüsselte Nachricht an diese Person senden will.

Auf dem iPhone passiert das Speichern des Zertifikats im Schlüsselbund aber seltsamerweise nicht automatisch. Ob das ein Bug ist oder ein Feature (möglichst geringer Ressourcenverbrauch auf dem zumindest anfänglich sehr begrenzten iPhone), weiß ich nicht. Jedenfalls muss man das bei allen Personen, denen man verschlüsselt antworten will, einmalig bei einer von der jeweiligen Person digital signierten Email manuell selbst machen:

• Die digital signierte Email der Person aufrufen
• Auf den Absender und dann rechts neben Von: nochmals auf den Absender touchen
• In dem Textblock Signiert auf Zertifikat anzeigen touchen
• In der Zertifikat-Anzeige unten auf Installieren touchen

Sobald das geschehen ist, kann man der Person auch verschlüsselte Emails schicken.

Weia: Ja, kann ich bestätigen – unter iOS/iPadOS verhält sich das bei Version 15.6 leider genau so.

Habe das gerade mal mit meinem geschäftlichen und privaten Mail-Account getestet (direkt auf dem iPhone). Ich musste das sogar bei beiden eigenen Accounts so machen wie von Dir beschrieben.

Mir ist ehrlich gesagt nicht ganz klar, wieso das sogar bei den eigenen Accounts nötig ist? Immerhin sollten deren certs doch bereits vorhanden sein auf dem Gerät? Scheinbar werden die certs auf diesem (von Dir wie immer sehr gut beschriebenen) Wege dann doch noch mal an einem extra Ort abgespeichert? Da man das nicht wirklich prüfen kann (keine Schlüsselbundverwaltung unter iOS/iPadOS), bleibt das wohl vorerst 'ein Geheimnis' bei Apple.

Fühlt sich aber irgendwie nach 'security by obscurity' an finde ich …

Wie auch immer – sobald geschehen, konnte man auch in beide Richtungen signiert und verschlüsselt kommunizieren.

Ja, hatte ich gemacht.

Richtig. Und genau deswegen nutze ich das. Es ist die unterste Form , um Trust herzustellen. Wer nicht mal das schafft...
Und der "Schutz" ist höher, als es den Anschein macht. Es braucht schon größere kriminelle Energie, um das auszunutzen.

Ich habe die S/MIME Zertifikate damals - auf Weias Initiative - angeschafft, um meinen E-Mail-Partnern zu zeigen: mir ist das wichtig. Ich kümmere mich um "Trust", eure Daten sind bei mir sicher, etc.

Weia, danke einmal mehr für deine Mühe. Eigentlich sollte dieses Thema nicht "so nebenher" im Forum abgehandelt werden (ebenso der Bericht zum Signieren von PDFs), sondern prägnanter im redaktionellen Bereich erscheinen und dort länger sichtbar sein. Aber sei's drum.

Ich habe deine Anleitung nachvollziehen können und habe nun auch ein Zertifikat, das die Mail.app akzeptiert hat und mit dem ich signierte Mails verschicken kann.

Was ich nicht kann: Ich kann das Zertifikat nicht in die Schlüsselbundverwaltung einfügen. Egal, ob ich es im Finder doppelklicke, oder mir die Übersicht der Zertifikatsdatei anzeigen lasse, um dann mit "Öffnen mit Schlüsselbundverwaltung" das Ding dort einzupflanzen -- ich bekomme stets die Fehlermeldung "Der Schlüsselbund "System-Roots" kann nicht geändert werden."



Die Fehlermeldung hilft mir nun überhaupt nicht weiter -- ich würde das Zertifikat ja gerne in der Schlüsselbundverwaltung öffnen und dort "entsprechende" Einstellungen (welche das auch immer sein sollen) ändern. Aber ich komme ja gar nicht dazu, das Zertifikat dort zu öffnen. Was ich machen kann: Ich wähle das Schlüsselbund "System" an, entsperre es, und kann dann über "Importieren" das Zertifikat einlesen -- es erscheint dann aber nirgendwo.

Seltsamerweise kann Mail ja mit dem Zertifikat arbeiten. Ich benötige das Zertifikat allerdings in der Schlüsselbundverwaltung, um es von dort aus exportieren zu können für die weitere Verwendung unter iOS -- wenn ich das richtig verstanden habe.

Wo ist der Knoten, bzw. wo kann ich hier ansetzen? Dieser Mac hier läuft unter 10.14.6 Mojave, falls das für dieses Vorgehen von Belang ist.

Habe noch gar keine Mail bekommen... Der Provider scheint wohl nicht so seriös zu sein.
Naja, ziehe das Geld zurück von der Kreditkarte. Die Firma antwortet mir auch nicht.
Auf der Webseite sehe noch immer :

Tom Macintosh: Also ich habe heute Certum angeschrieben um zu fragen, ob und wann ich denn eigentlich eine Rechnung bekomme?

09:32 Uhr habe ich angefragt, 11:53 Uhr hatte ich die Antwort (wenn auch erst mal nur mit einem vertröstenden "Hello, as soon as the final invoice is issued it will automatically be sent to your email address. Please wait for the message.")

Finde ich zwar auch etwas komisch, aber nun ja, immerhin kam zumindest schon mal eine Antwort.

Angeschrieben hatte ich den Certum Shop unter infolinia [at] certum.pl – vllt. hilft Dir das ja.

Hi Weia,

danke für die tolle Anleitung. Perfekt gemacht. Das der Polnische Provider das nicht hinbekommt ist ja nicht dein Fehler. Selbst Kündigen klappt nicht, da man, wenn man den Capcha eingegeben hat die Login Daten nicht bekannt sind. Das scheint wirklich nicht die beste Werbung für eine Firma sein. Zumal in den Untermenüs ständig auf die Polnische Sprache geswitcht wird.

Schade... Doch nicht so einfach. Muss ich mir mal ansehen. Ich besitze ja sogar ein SSL Zertifikat

Gruss Tom

Tom Macintosh

Hast Du mal im Spamordner nachgeschaut ? Bei mir sind die Mails dort gelandet! Nach dem Klick auf Activate waren sie dann in polnisch! aber die detaillierte Anleitung von Weia hat mich ‚gerettet‘

Huba: So etwas gehört ja auch nicht in den 'System-Roots' Schlüsselbund (wie kommst Du eigentlich darauf?), sondern wie Weia in seiner Anleitung auch ausgeführt hat in den 'Anmeldung' Schlüsselbund (login keychain) Deines angemeldeten Benutzers (wahrscheinlich ist dort Dein cert nebst dazugehörigen private key sogar längst drin, denn Du sagst ja selbst, dass Du schon signierte Mails sendest per Apple Mail).

Den 'Anmeldung' Schlüsselbund (login keychain) musst Du also in der Schlüsselbundverwaltung auswählen.

ja klar, aber es ist keine Mail angekommen. Ich habe eine ganz normale Email Adresse und da kommen ganz viele Mails am Tag an ohne das es Spam ist.

Tom Macintosh: Ob etwas als Spam eingestuft wird oder nicht entscheidet ja zum einen ein Spam-Filter direkt auf Deinem Mail-Server (bzw. beim Mail-Provider) und dann auch noch mal zusätzlich (falls aktiviert) der Spam-Filter von Apple Mail.

Zwei der diversen Mails von Certum lagen bei mir z.B. auch im Spam-Ordner, die Frage von h.naumer ist also durchaus berechtigt.

Davon abgesehen – an welche Adresse hattest Du denn geschrieben bei Certum (von denen Du ja wohl auch keine Antwort bekommen hast)? Auch an die, die ich weiter oben erwähnt habe vor wenigen Minuten?

Ja, logisch erschien mir das auch nicht. Deshalb habe ich alle Schlüsselbunde der Reihe nach ausprobiert, um dort das Zertifikat zu importieren -- nachdem ich es im Schlüsselbund "Anmeldung" nicht gefunden habe.
Aber irgendwie wundert es mich gerade überhaupt nicht sehr, dass das Zertifikat mittlerweile im Schlüsselbund aufgetaucht ist -- vielleicht war ich zu ungeduldig, oder habe mich von den Fehlermeldungen kirre machen lassen.

Es hat übrigens ausgereicht, beide von Certum heruntergeladen Zertifikatsdateien mittels Airdrop auf das iPhone zu kopieren. Dort kann es dann in den "Einstellungen" zu installieren. Der Umweg über den Export als .pt12-Datei war nicht nötig.

Jetzt zeigt immerhin die Mail.app auf dem iPhone an, dass hereinkommende Mails signiert sind, andersherum funktioniert es leider noch nicht: Auf dem Mac ankommend wird die Mail nicht als signiert interpretiert. Wahrscheinlich bin ich wieder zu ungeduldig...