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

Ich habe noch Schwierigkeiten, die Qualität von Zertifikaten einzuschätzen. Mit Qualität meine ich hier, ob das Zertifikat nur für S/MIME geeignet ist oder auch zur Signierung von Dokumenten mit Adobe.
Wenn ich nun die Beschreibung des Certum-Zertifikats von PSW heranziehe, dann steht dort , dass das Root-Zertifikat "Certum CA SHA-2" heißt.
In Adobe Reader findet sich das Root-Zertifikat in den vertrauenswürdigen Zertifikaten. Öffne ich das und schaue unter Vertrauenswürdigkeit steht dort:

Dort steht das Zauberwort "AATL". Das heißt doch, dass das Zertifikat auch zur Signierung von Dokumenten geeignet ist.
Das wiederum kann eigentlich nicht sein, da das Zertifkat dann nicht nur E-Mail-validiert, sondern auch identitätsvalidiert sein müsste.
Wie kann ich das auseinanderhalten?

Nein, Du bist da nicht zu ungeduldig sondern das kann so auch nicht funktionieren! In der .p12 muss ja Dein 'cert' + Dein dazugehöriger 'private key' enthalten sein … und dies beides brauchst Du natürlich auch auf dem iPhone, wenn Du vom iPhone aus signiert (und gegebenenfalls sogar verschlüsselt) per E-Mail kommunizieren willst.

Von Certum hast Du Deinen 'private key' nämlich nicht erhalten, sondern der wurde lokal auf Deinem Rechner generiert, als Du die Zertifikatsanforderung (CSR) für Certum 'gebastelt' hast.

Die beiden heruntergeladen Zertifikatsdateien von Certum (die Du per Airdrop auf Dein iPhone geschubst hast) sind ziemlich sicher nur Dein cert selbst und noch mal zusätzlich deren Austeller-cert. Da fehlt Dein 'private key'.

Weia hat das so schön und ausführlich beschrieben eigentlich …

Das ist schon mal ein Fehler. Die Angaben von PSW sind nichts, worauf man sich verlassen könnte – die behaupten ja auch, dass das D-Trust-Zertifikat D-TRUST Advanced Personal ID nur ein Email-Zertifikat ist. Die autoritative Auskunft bekommt man (abgesehen von der AATL-Kompatibilität) in der macOS-Schlüsselbundverwaltung – Problem ist freilich, dass man dazu schon ein entsprechendes Zertifikat besitzen und installiert haben muss.

Ist das überhaupt dasselbe Zertifikat? Das ist da ja doppelt so teuer. Ein Zertifikat dieses Namens gibt es nicht einmal, aber das steht doch auch nicht da. Laut PSW ist das Root-Zertifikat Certum CA. Das gibt es zwar, aber das ist auch falsch, insofern es nicht das Root-Zertifikat für Certum E-mail ID Individual-Zertifikate ist.

Die Zertifikatskette lautet Certum E-mail ID Individual → Certum Digital Identification CA SHA2 → Certum Trusted Network CA.
Seltsamerweise das Root-Zertifikat nicht, wohl aber das Zwischenzertifikat. Offenbar will Adobe den Kreis der Zertifikate einschränken, die AATL-kompatibel sein können.
Indem Du beim korrekten Zertifikat nachschaust? Root- und Zwischenzertifikat beglaubigen mehrere Zertifikatsprodukte von Certum, u.a. offenbar auch solche, die AATL-kompatibel sind – deswegen müssen Root- oder Zwischenzertifikat auch in der AATL sein. Aber deswegen muss doch nicht jedes Zertifikat, das von dieser Zertifikatskette beglaubigt wird, auch AATL-fähig sein. Dass ein Zertifikat der Zertifikatskette in der AATL ist, ist eine notwendige, aber keine hinreichende Bedingung für AATL-Kompatibilität des auf den Nutzer ausgestellten und mit der Zertifikatskette beglaubigten Zertifikats. Dafür muss dieses Zertifikat selbst AATL-fähig sein.

Das Certum E-mail ID Individual-Zertifikat ist das aber nicht. Schaust Du dir das Zertifikat im Adobe Reader an, so steht da: Das gewählte Zertifikat ist fehlerhaft: Ungültige Richtlinieneinschränkung Und in einem trotzdem damit unterschriebenen Dokument: Zertifikat des Unterzeichners ist ungültig bzw. Die Identität des Unterzeichners ist ungültig.

Ja, ich hatte das Synium auch vorgeschlagen, aber die wollten nicht.
Wenn Du das kannst, dann müssen die notwendigen Zertifikate auch bereits im Schlüsselbund Anmeldung sein, sonst würde das gar nicht funktionieren. Suche doch in der Schlüsselbundverwaltung mal nach Certum und lass Dir mal die Kategorie Meine Zertifikate anzeigen.
Dann hast Du in der Schlüsselbundverwaltung den Schlüsselbund System-Roots ausgewählt, in dem alle Root-Zertifikate von macOS liegen und der natürlich nicht verändert werden darf. Du musst wie beschrieben den Schlüsselbund Anmeldung auswählen, bevor Du im Finder doppelklickst. Ab wie schon gesagt, da müssten Dein Zertifikat und das Zwischenzertifikat längst sein, sonst könntest Du in Mail keine signierten Emails verschicken.
Warum System? Du musst den Schlüsselbund Anmeldung benutzen. Das steht auch so in der Anleitung, ich weiß nicht, wie Du auf System kommst.
Wie gesagt, da ist es vermutlich längst, halt im Schlüsselbund Anmeldung.
↔︎Finde den Fehler.

Das ist Unsinn; Certum ist einer der Pioniere in dem Bereich, die gibt es seit 2 Jahrzehnten.

Wenn Du noch keine Email bekommen hast, dann hast Du ja noch nicht einmal ein Nutzerkonto bei Certum angelegt, dann kann natürlich nichts funktionieren.
Ist da denn überhaupt was abgebucht worden? Denn wenn es das ist, hast Du definitiv ein Email-Problem; Du hättest dann nämlich auch eine Zahlungsbestätigung des von Certum völlig unabhängigen Zahlungsproviders Dotpay online payments bekommen müssen.
Wer sagt Dir, dass sie nicht längst geantwortet haben? Das Problem scheint doch gerade zu sein, dass die Emails von Certum nicht zu Dir durchdringen.
Da steht In Progress, bis Du Dein gekauftes Zertifikat aktiviert hast, wovon Du offenkundig weit entfernt bist, weil Du dazu auf mehrere Emails antworten musst. Du hast ja wohl noch nicht einmal den CSR eingeben können.

Allerdings steht da auch, das Produkt sei bezahlt. Da gibt es definitiv ein Email-Problem auf Deiner Seite, denn Du hättest wie gesagt auch eine Zahlungsbestätigungs-Email bekommen müssen.
Das bestätigt meinen Verdacht, dass nicht einmal das Anlegen des Kundenkontos geklappt hat – dann kann natürlich auch nichts funktionieren, was darauf aufbaut.

Da ist irgendwo gewaltig der Wurm drin. Ich hatte Null Probleme, und ich habe (wegen der Anleitung, für die Screenshots) sogar mehrere Kundenkonten angelegt – absolut reibungslos. Einen Capcha habe ich nie zu sehen bekommen. Bist Du auf einer Blacklist gelandet?
Auch das war bei mir nie der Fall. Kann es sein, dass Du in Deinem Webbrowser irgendwelche Ad-Blocker oder Cookie-Blocker aktiviert hast? Eine interaktive Website kann natürlich nicht funktionieren, wenn keine Cookies zugelassen werden. Welchen Browser verwendest Du?

Danke für deine Erläuterungen. So lässt sich leider erst nach dem Kauf des Zertifikats hinreichend feststellen, ob das Zertifikat auch AATL-fähig ist.
Erstmal bleibe ich ohnehin beim D-Trust-Zertifikat, dass ich diesen Monat erneuern muss. Habe schon Erinnerungen von PSW und einer Sparkasse erhalten.

Nö, durch Lektüre von Anleitungen aus dem MacTechNews-Forum kann man das auch vorher.    (Im Ernst: Das war ja nun schließlich der ursprüngliche Anlass für die Anleitung, dass diese Information nirgendwo verfügbar war und mich 2 Jahre Recherche gekostet hatte.)

Oder halt, wie überall sonst auch, durch die Produktbeschreibung, idealerweise vom Hersteller selbst. Das ist in dem speziellen Falle des D-TRUST Advanced Personal ID-Zertifikates zugegeben nur leider wenig hilfreich, weil D-Trust selbst eine denkbar undurchschaubare, offenbar noch vom Behördengeist geprägte Website hat (auf der man Produkte nicht bestellt, sondern beantragt ) und PSW es aus irgendeinem Grund scheut wie der Teufel das Weihwasser, die AATL-Kompatibilität dieses Zertifikats zuzugeben. Das liegt ziemlich offenkundig daran, dass dieses Zertifikat solch ein Preisbrecher ist; nur wovor PSW Angst hat, wurde mir in den Telefonaten nicht ganz klar. Adobes Groll? Konkurrenz im eigenen Haus, weil dann niemand mehr die teureren Zertifikate kauft? Von weiteren Distributoren weiß ich im Moment nichts.

Grundsätzlich kannst Du mit recht großer Wahrscheinlichkeit folgende Formel zugrunde legen:

Identitätsvalidiertes Zertifikat + eIDAS-kompatibel + ein Zertifikat der Zertifikatskette in der AATL = AATL-kompatibles Zertifikat

Und zu guter Letzt würde PSW ja ein Rückgaberecht bieten.
Da wird Dir auch nicht viel anderes übrig bleiben. Dieses Zertifikat ist bis auf weiteres vollkommen konkurrenzlos.

Das ist doch mal eine gute Daumenregel 👍

Ok, jetzt habe ich die Kommunikation mit der Firma da hinbekommen. Und in Mail habe ich auch die Signature drin. Passt. Danke euch allen.


Nun aber eine neue Frage. Es scheint mit meinem Schlüsselbund auch etwas nicht zu passen.
Cloud ist aktiviert aber beim hinzufügen zur Cloud kommt ein Fehler. Ich kann die Zertifikate nur zum System hinzufügen (in Mail ist es dann sichtbar). Da ich aber das gern dann auch auf dem Handy haben wollte wäre ja wie oben beschrieben, das über die Cloud.

Da kommt aber



wenn ich das wie Weia beschrieben hat Export als p12 machen will kommt :



Das ist ausgegraut. Was passt bei meinem Mac nicht ?

Danke.

Tom Macintosh

Ich vermute, Du versuchst das falsche Zertifikat zu exportieren.
Du musst in der Schlüsselbundverwaltung am Mac das Zertifikat suchen, das den Namen der zu signierenden Mailadresse trägt und dann über Ablage Objekte exportieren. Dann ist auch p12 als Format wählbar.

Hallo H.Naumer,

Danke, aber hier sind die beiden die ich heute importiert habe :



und bei beiden ist das P12 ausgegraut... Ich würde ja auch die Cloud Variante nehmen, aber das geht nicht, da kommt der Fehler oben.

Tom Macintosh
Bei mir liegen beide von Certum geladenen Zertifikate im Schlüsselbund Anmeldung! (Durch Doppelklick installiert)
Räumlich davon getrennt (Schlüsselbund nach Namen sortiert) liegt ein dritter Eintrag mit der Bezeichnung der zu signierenden Mailadresse und der ist exportierbar als p12 (Ablage - Objekte exportieren)

Und was war nun das Problem gewesen?
Was heißt das genau? Dass die beiden zusätzlichen Knöpfe (Schloss und Zertifikat) sichtbar sind und Zertifikat auch aktiv ist (nicht ausgegraut)?
Das sind nur die Zertifikate, aber ohne Kombination mit dem privaten Schlüssel. Deshalb kannst auch nicht im .p12-Format exportieren – ein entscheidender Bestandteil fehlt.

Du brauchst ein Objekt in der Schlüsselbundverwaltung, das links so ein kleines graues Aufklappdreieck hat, also entweder

• das Zertifikat mit (aufgeklappt) dem Schlüssel drin    oder
• den Schlüssel mit (aufgeklappt) dem Zertifikat drin

Am einfachsten solltest Du das finden, wenn Du dir nur (in der linken Seitenleiste spezifiziert) die Kategorie Meine Zertifikate anzeigen lässt.

PS. In den Schlüsselbund System solltest Du auf gar keinen Fall etwas importieren, zumal es sich um dasselbe Zertifikat wie im Schlüsselbund Anmeldung zu handeln scheint, also nur eine unsinnige Dopplung ist.Logisch, es fehlen ja die entscheidenden Daten. Das .p12-Format beinhaltet stets Zertifikat und privaten Schlüssel; genau deshalb ist es ja zum Übertragen auf einen anderen Rechner geeignet.
Was meinst Du denn mit „Cloud Variante”? Den iCloud-Schlüsselbund? Der ist ausdrücklich nicht für Zertifikate geeignet. Oder iCloud Drive? Der hat damit gar nichts zu tun.

Hallo Weia,

tja, die PL Emails wurden auf meinem Server als Spam sofort aussortiert. Habe das dann in die Whiteliste gepackt. Die Kommunikation war aber auch so nicht einfach. Aber nunja, es hat geklappt.

In Mail habe ich die beiden Bubbles rechts drin so wie du geschrieben hast. Das passt und auf dem iPhone habe ich das jetzt auch. Dank deiner Beschreibung. Sorry, war bin nicht so fit mit dem Schlüsselbund. Da muss man erst einmal verstehen was einer meint Jetzt habe ich es

Danke noch einmal für die gute Beschreibung und das ich jetzt signierte Emails versenden kann Das passt sehr gut bei mir. Lob, Lob, Lob von mir. Danke.

Na, dann ist ja alles gut.

großartige Anleitung.
Vielen Dank dafür.
Hat keine 5 Minuten gedauert.

Als Ergänzung hierzu:

Kostenfreie Zertifikate gibt es noch bei dem italienischen Anbieter Actalis . Unglücklicherweise wird leider der private key auch beim Anbieter erzeugt, so daß es theoritisch möglich wäre, daß Dieser eine Kopie bei sich speichert. - Aber wie sage ich da immer: Selbst eine schwache, knackbare Verschlüsselung ist besser als gar Keine (Fryofg rvar fpujnpur, xanpxoner Irefpuyüffryhat vfg orffre nyf tne Xrvar).

Ich habe auf meiner Webseite auch schon eine entspr. Anleitung veröffentlicht (aktuell leider wegen techn. Probleme nicht erreichbar). Die Reaktionen, die ich darauf bekam waren erschreckend. Es ist wirklich erstaunlich, wieviele Menschen es gibt, die "nichts zu verbergen" haben und Anleitungen zur Verschlüsselung lediglich als "Förderung illegaler und terroristischer Aktivitäten" ansehen - Da ist wirklich zum Teil Hopfen und Malz verloren.
Anderen ("mein Mailanbieter verschlüsselt doch") muss man zum Glück lediglich den Unterschied zwischen Transportweg- und E-Mail-Verschlüsselung erklären, so daß da wenigstens noch Hoffnung besteht

Wenn man das für eine eigene PKI haben möchte, dann kosten allein die hierfür notwendigen Audits schon einen erheblichen Betrag.Eher "Es MUSS etwas kosten". Allein die notwendige Hardware liegt mindestens schon in einem 6-stelligen Betrag mit 4-stelligen jährlichen Wartungskosten (für eine "kleine" Inhouse PKI für 15k Mitarbeiter).Aber frühestens dann, wenn es möglich ist, in den Betriebssystemen (allen!) unterschiedliche Truststores für die Root- und Intermediatezertifikate einzurichten (Getrennt nach S/MIME und sonstigen), ansonsten würde ich mir niemals Zertfikate von Anbietern hinter denen eine Behörde steht, installieren, ansonsten eröffnet man BND, NSA und dgl. jede Möglichkeit der MITM-Attacke. Außerdem sind in meinen Augen "eine vernünftige IT Security" und "Bezahlung nach BAT" nicht miteinander vereinbar.

picsnmore.de: Spannend, Du scheinst da also auch etwas im Thema drin zu stecken?

Verstehe ich das richtig, dass man diverse Audits bestehen muss (welche denn genau und was kosten die im Detail?), wenn man das root-cert seiner eigenen PKI in den 'System-Roots' keychains dieser Welt haben möchte?

Wenn man diese/alle Audits bestanden hat, dann ist man da 'automatisch mit drin'? Oder gibt es da noch zusätzliche Hürden/Absprachen?

Und sehr wahrscheinlich müssen dann auch weitere regelmäßige Audits gemacht werden, also z.B. jährlich oder sogar quartalsweise?

Finde das wirklich spannend, wäre interessant da mehr Details zu erfahren zu den Hintergründen.

PS: Und etwas erstaunt bin ich über die nötige Hardware – also nach Deinen Aussagen zwischen 100.000,- € und einer Million € allein für die Hardware + Wartungskosten von ca. 10.000,- € pro Jahr für eine 'kleine Inhouse PKI bei knapp 15k Mitarbeitern'?

Und die professionelle Einrichtung und Betreuung so einer PKI, da benötigt man dann wahrscheinlich auch ein Team von 10-20 Mann, die dann jeder für sich genommen Jahresgehälter von 80k bis xxx? aufrufen würden?

Ich bin der Verantwortliche für unsere Inhopuse-PKI, daher habe ich mich in der Tat schon ein wenig mit der Materie beschäftigt Ja. Hier gibt es nähere Infos dazu:
Bzgl. der Kosten muß man sich ein entspr. Angebot von einem der zertifizierten Auditoren machen lassen.Wenn man anerkannt ist, sollte es mit den Herstellern eigentlich keine großen Probleme mehr geben, daß das eigene Root mit verteilt wird.Hier haben wir nicht weiter nachgefragt, aber man kann davon ausgehen, daß man regelmäßig nachweisen muß, daß die eigene Umgebung noch allen Richtlinien entspricht. Entsprechende weitere Zertifizierungen (ISO27001 u.ä.) können nötig oder zumindest hilfreich sind.
Wir sind gerade beim Ablösen unserer HSM-Module (auf Diesen werden die privaten Schlüssel der Zertifikate abgelegt), Stückpreis ca. 23.000,- plus Steuer, mind. 2 Stück benötigt wegen Redundanz, dazu entspr. Backup-Module um die Schlüssel "secure" zu sichern, ... Dazu kommt dann die "normale" Serverhardware nebst Infrastrukturkomponenten für Root- und Issuing-CAs, Softwarelizenzen etc.

Die Wartungskosten werden meist prozentual dem Anschaffungspreis berechnet und liegen bei 10-25%, je nach Umfang der Wartung.Die Einrichtung ist hierbei das Umfangreichste, was zu tun ist (resp. die vernünftige Planung der Infrastruktur, die ja VOR der Installation kommt), der eigentlich Betrieb beschränkt sich auf den normalen Betrieb/Monitoring der Geräte, Patching, Prüfen von Anträgen und freigeben und dokumentieren. Die Infrastruktur läuft eigentlich ganz entspannt "im Hintergrund", das meiste passiert automatisiert. Was heißen soll, je nach Auslastung und für wieviele Zertifikatsvorlagen Bestätigungen nötig sind (und welche automatisch bestätigt werden) kann der Betrieb von 3-4 Admins nebenbei gestemmt werden... evtl. noch mit einem guten Dienstleister im Hintergrund. Jedenfalls ist bei unserer PKI nicht viel mehr Aufwand nötig.

Die Planung hingegen sind 2-3 Wochen Vollzeit (incl. entspr. Dokumentation, Pflichtenheft etc.), die Umsetzung sollte nicht viel länger als eine Woche (incl. Dokumentation) dauern. Dies ist einmalig notwendig, aber sollte alle paar Jahre natürlich noch auf Aktualität und möglicherweise geänderte "Best Practises" überprüft werden und ggf. Restrukturiert werden.

Wie gesagt, die genannten Aufwände sind für unserer Inhouse-PKI gültig. Es kann da natürlich erhebliche Abweichungen im Aufwand geben, wenn eine Public CA als Dienstleistung für "jedermann" plant. Hier sind die Supportaufwände mit Sicherheit erheblich höher.

picsnmore.de: Vielen Dank für diese (für mich zumindest) wirklich sehr interessanten Erläuterungen.

Noch eine kurze Frage dazu: Wäre es denn Deiner Erfahrung nach denkbar, dass man so eine komplette eigene Inhouse-PKI auch komplett 'Microsoft-frei' betreiben kann, also tatsächlich ausschließlich auf Linux- und/oder BSD-Basis?

Oder führt grundsätzlich kein Weg vorbei an Windows Server Enterprise (oder was auch immer aus dem Hause Microsoft diesbezüglich verfügbar ist)?

Hintergrund wäre folgender: Wenn die zu versorgenden Endgeräte zu 100% ausschließlich aus macOS- und iOS/iPadOS-Geräten bestehen (knapp unter 5k), könnte man eventuell tatsächlich auf M$ verzichten, weil man dann ja auch nichts mit Windows testen müsste?

PS: Denn ich finde ja, dass ist dann immer der Witz – sobald es um Audits geht (TISAX, ISO 27001 etc.), sind die Prüfer immer ganz verdutzt, wenn keine einzige Windows-Kiste im Haus vorhanden ist (und somit auch weder AD noch Exchange etc.).

Kostenfreiheit bedeutet aber umgekehrt letztlich auch immer: kein Anspruch auf irgendwas. Warum ist das denn so wichtig, auch noch 9€ pro Jahr zu sparen? Ich hätte da ein mulmiges Gefühl.
Ich weiß ja nicht, welchen Adressatenkreis Deine Website hat, aber das ist schon sehr merkwürdig. Behörden, Anwälte und Ärzte (die zunehmend auf gesicherte Kommunikation pochen) als Förderer illegaler und terroristischer Aktivitäten? Solche Reaktionen gab es hier ja gottseidank überhaupt nicht; ich weiß jetzt nicht, was repräsentativer ist.
Mag sein, aber um eine eigene PKI geht es hier ja nicht. Warum sollte irgendjemand (außer Zertifizierungsstellen) so etwas wollen?
Du selbst hat doch gerade das kostenfreie Angebot von Actalis verlinkt?
Was genau meinst Du damit und inwiefern würde das die Zugriffsmöglichkeiten von BND & Co. schmälern?

Erst mal größtes Lob an Weia für die super Anleitung. Damit hat es auf dem Mac reibungslos funktioniert.

Wo ich nun scheitere ist am iPhone/ iOS.

1. Ich habe aus der Schlüsselbundverwaltung in macOS "mein Zertifitkat" als p12 exportiert und an das iPhone versandt wie im Beitrag von Weia 01.08.22 12:03 beschrieben

2. und das Zertifikat in iOS noch mal installiert aus einer signierten Email von macOS, wie im Beitrag Weia vom 03.08.22 06:22 beschrieben.

Bei VPN und Geräteverwaltung ist das Zertifikat für die Mailadresse auch drin, allerdings als "nicht überprüft"

Ich kann von der Mailadresse keine signierten und verschlüsselten Mails unter iOS versenden

Einstellungen > Mail > Accounts ist bei dem Mailaccount auch unter Erweitert der Schalter zum signieren und verschlüsseln deaktiviert und lässt sich nicht aktivieren.

Wo liegt bitte der Fehler? Danke.

Wo kommt denn bei Deinem iPhone VPN ins Spiel? Und was ist diese Geräteverwaltung?

Ich habe leider mit VPN null Erfahrung, weil ich das selbst nie genutzt habe, würde aber für möglich halten, dass da die Komplikation auftaucht.

Was sagt denn Einstellungen → Allgemein → Profile? Da müssten sich mindestens 2 Profile befinden, nämlich ein Profil, das nach Deiner Email-Adresse benannt ist, und eines namens Certum Digital Identification CA SHA2. Bei beiden müsste, wenn Du sie antoucht, Überprüft ✔︎ stehen.

Die Konfigurationsprofile bei iOS 15 sind nun statt am vorher bekannten Ort Einstellungen Allgemein Profile an neuer Stelle Einstellungen Allgemein VPN und Geräteverwaltung zu finden — das hat mit VPN per se nichts zu tun.

Ich habe übeigens das selbe Problem wie shotekitehi. Es gelingt mir nicht, vom iPhone aus signierte Mails zu versenden.
Der detaillierte und reich bebilderte Bericht, den ich dazu schon verfasst hatte, ist leider vor dem Absenden im digitalen Nirvana verschwunden und ich hatte leider noch keine Zeit gehabt, den neu zu erstellen.

das Profil mit der Email-Adresse ist da (nicht überprüft) und das Certum Digital Identification CA SHA2 fehlt mir da.

Wie kriege ich das bitte noch da rein und überprüft?

--
Nachtrag, dass habe ich jetzt geschafft in dem ich den die Mail von Certum "Certificate has been created..." und den Link klickte und die Binaries auf dem iPhone installierte, wie im Bild und Anleitung von Weia...

Aber signiert und verschlüsselt kann ich deswegen trotzdem nicht versenden...

Ah, OK, sorry. Ich habe halt noch nicht auf iOS 15 aktualisiert, gerade heute hat ich mein iPhone wieder daran erinnert, das endlich mal zu machen.

2. Nachtrag...ich habe es nun hinbekommen.

Problem war, dass von meinem Mailanbieter auch ein Profil (QR-Code von dessen Website zur Kontoeinrichtung) installiert war und den Mailaccount konnte ich daher offenbar nicht bearbeiten.

Lösung: Dieses Profil habe ich gelöscht und den Mailaccount manuell angelegt und jetzt kann ich auswählen, dass die Mails verschlüsselt und signiert werden...

Gerade getestet und es klappt.

Aha! Gerade wollte ich als nächstes vorschlagen, mal zu probieren, auch noch das Root-Zertifikat zu installieren. Das war ein vager Verdacht, dass iOS vielleicht nicht alle Root-Zertifikate mit vorinstalliert (vermutlich aus Platzgründen).

Also, Kurzanleitung ohne Screenshot: Am schnellsten müsste es folgendermaßen gehen:

In der Schlüsselbundverwaltung als Kategorie Zertifikate auswählen und im Suchfeld oben rechts Certum eingeben. Dann werden nur noch ein paar Zertifikate angezeigt, unter denen sich Zwischenzertifikat und Root-Zertifikat für das Email-Zertifikat befinden:

• Certum Digital Identification CA SHA2
• Certum Trusted Network CA

Diese beiden auswählen (wenn Ihr das Zwischenzertifikat schon auf dem iPhone installiert habt, braucht Ihr das natürlich nicht nochmals), in der Schlüsselbundverwaltung wieder Ablage → Objekte exportieren … auswählen, als Format .cer wählen, die gesicherte Datei via Email oder AirDrop aufs iPhone verfrachten und dort installieren. Das müsste es dann gewesen sein.

Prima. Danke für die Info, was in Deinem Fall der „Klemmgrund“ war. Es gibt in der IT bekanntlich nichts, was es nicht gibt.

Das Root-Zertifikat musstest Du aber dann wohl doch gar nicht installieren (sodass mein gerade geäußerter Verdacht mit dem fehlenden Root-Zertifikat als allgemeiner Problemursache doch falsch wäre)?

Ein Root-Zertifikat musste ich nicht installieren. Nur die Binaries aus Deiner Anleitung

Bei mir (D-Trust) konnte ich das Problem mit "nicht überprüft" mit Installation des Root-Zertifikats beheben. Mails mit nicht überprüftem Zertifikat kamen beim Empfänger dennoch ordentlich signiert an - was aber auch zu erwarten ist, wenn das Root-Zertifikat beim Empfänger installiert ist.

Nachdem shotekitehi das Problem anders behoben hat, dachte ich mir, dass die Installation vom Root-Zertifikat im Laufe des Threads wohl schon geschildert wurde und habe daher meinen Beitrag gelöscht. Möglicherweise ist das Root-Zertifikat von Certum vorhanden und von D-Trust nicht?

Allgemeiner Nachtrag:

Bloße Zertifikate (ohne dazugehörigen privaten Schlüssel, also alle außer den eigenen) kann man, auch mehrere auf einmal, aus der Schlüsselbundverwaltung im Dateiformat .cer exportieren, um sie zu transferieren.

Zur Kontrolle kann man sich zunächst in der Schlüsselbundverwaltung davon überzeugen, dass alle gültig sind. Sind sie es dann an anderer Stelle (zu der sie transferiert wurden) plötzlich nicht mehr, so liegt das praktisch immer daran, dass irgendein Zertifikat der Zertifikatskette fehlt.

Die Zertifikatskette könnt Ihr Euch (anhand des hier besprochenen Email-Zertifikats von Certum) wie folgt selbst erschließen:

In Eurem Email-Zertifikat steht, wenn Ihr die Detailinformationen per Doppelklick auf den Eintrag in der Schlüsselbundverwaltung öffnet, unterhalb der Sektion Name des Inhabers (= der Email-Adresse)
Name des Ausstellers
     Land oder Region     PL
                         Firma     Unizeto Technologies S.A.
Organisationseinheit     Certum Certification Authority
    Allgemeiner Name     Certum Digital Identification CA SHA2

Das heißt, der Aussteller Eures Email-Zertifikats ist (technisch betrachtet) das Zwischenzertifikat (Certum Digital Identification CA SHA2).

Und für das Zwischenzertifikat gilt dann sinngemäß dasselbe:
Name des Ausstellers
     Land oder Region     PL
                         Firma     Unizeto Technologies S.A.
Organisationseinheit     Certum Certification Authority
    Allgemeiner Name     Certum Trusted Network CA

Da diese Zertifikatskette nur 1 Zwischenzertifikat enthält, ist hier der Aussteller bereits das Root-Zertifikat.

Keine Ahnung, das kann ich im Nachhinen jetzt auch nicht mehr rekonstruieren. Ich ging (und gehe nach den Erfahrungen von shotekitehi nach wie vor) davon aus, dass die Root-Zertifikate auch in iOS alle vorhanden sind (weshalb das in der Anleitung auch nicht geschildert wurde), wobei sich dann wieder die Frage stellt, warum das bei Dir nicht der Fall war.

Wie auch immer, es sollte ja jetzt klar sein, wie man die Zertifikate der Zertifikatskette ggf. noch nachinstalliert.

Trotz der Tatsache, dass auf dem iPhone mein Zertifikat den Status Überprüft hatte, hat es auf Teufel komm raus keine signierten Mails versendet.
Ich habe den Fehler nun gefunden: Ich hatte in meinem Mail-Account auf dem iPhone mehrere email-Adressen angelegt -- mail@ und info@. Erstere ist signiert und als Standardadresse ausgewählt. Mail.app hat sich offenbar daran gestört, dass die andere Alternative nicht signiert war und hat so das signierte Versenden insgesamt unterbunden.
Ich habe nun die Mailadresse, zu der ich keine Signatur habe, gelöscht. Jetzt klappt es -- da muss man auch erstmal drauf kommen…

Wie Du schon geschrieben hast: In der IT ist alles möglich -- und der Fehlerteufel ist ein Eichhörnchen, was hin und herflitzt und einfach nicht zu fassen ist. An deiner Anleitung lag es jedenfalls nicht -- die ist super und kann natürlich solche Winz-Details im Vorfeld gar nicht erfassen.

Da kann ich jetzt nur drauf antworten mit Das sollte aber nicht so sein. 😳
Wie gesagt, sollte nicht so sein. Folglich kann man da eigentlich gar nicht drauf kommen. Glückwunsch, dass Du es trotzdem geschafft hast. Auf dem Mac geht es auch bei Dir hingegen mit beiden Emailadressen?
Ja, seufz.

Ich habe gerade wagemutig wieder diese andere Mailadresse erneut zu meinem Account hinzugefügt. Was soll ich sagen -- es funktioniert dann wieder nicht! Einerseits ist es ganz tröstlich, dass dieser Fehler reproduzierbar ist -- anderseits macht dieses Verhalten für mich aber überhaupt keinen Sinn. Wie gesagt: Es handelt sich um zwei e-Mail-Adressen mit derselben Domain, die in einem Account liegen.
Hat noch jemand so eine Situation und kann das bitte mal ausprobieren?
Auf dem Mac habe ich dieses Problem glücklicherweise nicht (Mail v12.4 von macOS 10.14.6)

Hast Du mal nachgedacht, diesen Artikel bzw. die ganzen zusammengetragenen Infos einer Fachzeitschrift (z.B. Mac&i) anzubieten? Dort würden Sie einem grösseren Publikum zugänglich, der Redaktion wäre in ihrem Sommerloch geholfen, Du bekämst ein kleines Taschengeld für deine Mühe und wie Du schon sagtest: Wenn das mit der Digitalisierung mal klappen soll, muss man selbst aktiv werden.
Ich habe zwei meiner Bekannten überzeugen können, sich ebenfalls S/MIME-Signierungen anzuschaffen -- dabei habe ich gerade erst angefangen

Hallo Weia,
erstmal danke für den Einsatz und die Anleitung.
Hatte bislang keinen praktischen Nutzen in der E-Mail-Verschlüsselung gesehen, aber mit diesem Satz hattest Du mich gekriegt :
Also habe ich jetzt auch Certums Umsatz phänomenal gesteigert und ein Zertifikat erworben.
Den gesamten, von dir beschriebenen Prozeß bis zum E-Mail-Versenden mit Signatur habe ich unter Mac OS X 10.6.8 durchlaufen. Funktioniert ganz genauso, sieht nur ein bißchen anders aus. Einziger Unterschied: bei der E-Mail brauchte ich nicht auf den Zertifikatsknopf drücken, der war schon aktiv. Ein Kennwort für den Zugriff war auch nicht erforderlich.
Also Erkenntnis: Snow Leopard spielt auch noch mit.

Das Ver- und Entschlüsseln von Nachrichten kann ich jetzt leider nicht testen, da ich niemanden mit E-Mail-Verschlüsselung kenne. Da wird sich ja jetzt hoffentlich ändern !

Ich fiese Ratte, ich.

Den macht es auch nicht. Das ist ein heftiger Bug. Welche iOS-Version ist das denn?
Ich habe früher des öfteren für Fachzeitschriften geschrieben, aber meiner Erfahrung nach macht das für diese Art von Artikeln heute keinen Sinn mehr. Die Anleitung würde deutlich über 10 Druckseiten ergeben; kein Verlag opfert heute noch einem einzelnen, speziellen Thema so viel Raum. Dazu kommt dann noch, dass ich kein Problem damit habe, ein einzelnes Unternehmen (so wie Centum) für die Anleitung „herauszupicken“, das für eine Publikation wie Mac&i aber problematischer sein mag. Und neue Erkenntnisse kann man dann auch nicht einarbeiten. (Ich hier auch nicht, aber das ist ja kein allgemeines Internet-Problem.)

Nein nein, das Internet ist schon der richtige Rahmen dafür, eine prominentere Stelle wäre halt sinnvoll.

Ich habe auch seit Urzeiten eine eigene Webseite für solcherart Dinge geplant, aber bin nie damit zu Potte gekommen. Und die Website müsste dann ja ihrerseits erstmal bekannt werden. (Wobei man vermutlich so eine Anleitung Google-gerecht konfigurieren könnte, so dass sie für dieses Thema weit oben in der Trefferliste erscheint.)
Prima. Sobald man zu mehreren ist, trägt das Ganze natürlich sofort Früchte.