Hallo,

ich habe ein Zertifikat (.cert) für s/mime in E-Mails erworben, heruntergeladen und per Doppelklick in den Schlüsselbund übernommen.
Nun liegt das Zertifikat dort, aber z.B. Mail erkennt es nicht. Ich habe auch in Mail keine Chance irgendwie darauf zuzugreifen.
Gibt es noch irgendwelche Schritte, die durchzuführen sind, bevor das Zertifikat genutzt werden kann?

VG

Nein, nur die Angabe "E-Mail-Adresse" von dem Account, von dem aus gerade gesendet wird, muss exakt mit dem Namen übereinstimmen, auf den das Zertifikat ausgestellt wurde.

Wenn von diesem Account aus eine neue Nachricht erstellt wird, müssen in der Betreffzeile rechts die Symbole für verschlüsselt / signiert eingeblendet werden. Anklicken schaltet die jeweilige Funktion ein.

Weia hat hier mal einen umfassenden Post über S/MIME verfasst:

Ok danke für die Info.
Ich habe allerdings die Schritte in der Schlüsselverwaltung nicht so durchgeführt und anstelle von CSR habe ich die „key generation“ gewählt.

Durch den Doppelklick auf die .cer Datei wurde das Zertifikat zwar in die Schlüsselverwaltung importiert, aber Mail interessiert sich nicht dafür.
Die Funktionen beim Erstellen einer neuen Mail, mit der zugehörigen Mail-Adresse erscheinen nicht.

Nachtrag:
Ich habe es geschafft das Zertifikat in eM Client zu importieren.
Nutze ich das Zertifikat um eine Mail zu signieren erhalte ich folgende Fehlermeldung:

"Es gibt kein gültiges S/Mime-Zertifikat (oder PGP-Schlüssel) zum Signieren. Ein privater Schlüssel fehlt."

Mir liegt das Zertifikat als "Binary" .cer Datei vor und wurde so in eM Client erfolgreich importiert, ebenso liegt es auch in der Schlüsselbundverwaltung.
Inwiefern fehlt denn nun ein privater Schlüssel? Lässt der sich aus der .cer bzw. aus dem Zertifikat extrahieren? Oder bekomme ich den privaten Schlüssel her?

Ist das Zertifikat evtl. nicht brauchbar oder Schrott, weil ich bei der Zertifikatsanforderung in der Schlüsselverwaltung nicht das CSR ausgewählt habe?

Egal was ich mache, Mail erkennt oder sieht mein Zertifikat auch nicht. Es wird's nichts zur Signierung oder Verschlüsselung einer E-Mail angeboten.
E-Mail Adresse stimmt mit der im Zertifikat überein - kein Schreibfehler enthalten.

Stehe hier irgendwie komplett auf dem Schlauch...

Bist du nach dieser Anleitung von Apple vorgegangen?

Du sitzt einem grundlegenden Missverständnis auf. Ein Zertifikat allein nützt Dir gar nichts, das bekäme in Zukunft ja jeder von Dir, dem Du eine mit S/MIME signierte Email senden würdest. Das Zertifikat ist der öffentliche Teil des Schlüsselpaares; was Du brauchst, ist der dazu passende private Schlüssel, den nur Du hast – oder eben nicht, wenn Du ihn gar nicht bekommen hast. Logisch, dass dann nichts geht.

Am saubersten und einfachsten geht das über ein CSR, aber das hat Du ja nun nicht gemacht. In diesem Falle musst Du den privaten Schlüssel von dem Anbieter bekommen, bei dem Du das Schlüsselpaar gekauft hast (und ihm vertrauen, dass er keine Kopie des privaten Schlüssels behält).

Üblicherweise geschieht das in einem Archiv im .p12-Format, das Dir der Anbieter zukommen lässt. Wenn Du das in die Schlüsselbundverwaltung importierst (Doppelklick reicht hierfür), extrahiert die daraus Zertifikat und privaten Schlüssel. Nur so geht es. Das Zertifikat allein nützt Dir überhaupt nichts, wie Du ja schon leidvoll gemerkt hast. Übrigens speichert die Schlüsselbundverwaltung von allen S/MIME-signierten Emails, die Du jemals bekommst, die Absender-Zertifikate ab; das ist der Sinn der Sache. Könnte man aus dem Zertifikat den privaten Schlüssel dafür extrahieren, wäre das Ganze völlig für die Katz.

Du scheinst grundsätzliche konzeptionelle Verständnisschwierigkeiten mit dem System asymmetrischer Schlüsselpaare zu haben. Lies doch bitte mal den Abschnitt Zum theoretischen Hintergrund in dem verlinkten Beitrag von mir, da habe ich versucht, das allgemeinverständlich zu erklären. Sonst rennst Du immer wieder gegen diese Verständniswand.

Na, das erklärt ja, weshalb das Zertifikat beim Senden keine Wirkung hat. Wenn Du nur den öffentlichen Teil des Zertifikats hast, kannst Du es nur "passiv" verwenden, also testen, ob damit versendete Nachrichten echt sind, bzw. diese entschlüsseln.

Zum Senden brauchst Du aber den nicht öffentlichen Teil, den privaten Schlüssel. Auch der muss im Anmeldeschlüsselbund abgespeichert sein.

Es gibt sehr viele verschiedene Dateiformate für den Austausch von Zertifikatsdaten. Wird ein neues Zertifikat ausgestellt, liegen üblicherweise drei Teile vor:

a) der öffentliche Teil des Zertifikats
b) die Kette von Ausstellungs-Zertifikaten, die die Beglaubigung dieses Zertifikats bis hin zum Stammzertifikat des Anbieters nachweist
c) der private Schlüssel für dieses Zertifikat

Diese Teile können in 1, 2 oder 3 Dateien in verschiedenen Formaten verschickt werden. Das Konvertieren und Anzeigen dieser Dateien ist mit dem Programm "openssl" möglich, das in jeder Version von macOS enthalten ist. Manches (nicht alles) kann der Schlüsselbund aber auch direkt lesen. Der private Schlüssel ist das eigentliche Geheimnis des Zertifikats und sollte eigentlich noch nicht einmal dem Aussteller bekannt sein. Wie der Schlüssel übertragen wird, ist je nach Anbieter verschieden. Es könnte z.B. sein, dass Du den Schlüssel getrennt, mit Deinem Kundenkennwort zusätzlich verschlüsselt, irgendwo vom Anbieter herunterladen musst. Das müsste in der Anleitung des Anbieters stehen.

Ein CSR ist nur ein weltweit genormter Weg, an ein Zertifikat zu kommen. Ein Anbieter kann auch andere Techniken verwenden, z.B. die Eingabe der Daten in ein Web-Formular.

Danke für die Erklärungen und Infos.

Da ich das Zertifikat bei certum.pl erworben habe, kein CSR verwendet habe, sondern die Key Generation von denen verwendet habe, muss ich nun von denen den privaten Schlüssel bekommen.

Habe noch mal im Account unter Zertifikate nachgesehen, aber ich kann nur mein Zertifikat in Binary oder Plain runterladen. Gleiches gilt für die Zertifikats-Kette.

Dann begebe ich mich mal auf die Suche nach dem privaten Schlüssel...

Statt zu suchen, schreib denen doch einfach eine Support-Email, dass Du die Daten im .p12-Format bräuchtest. Bei mir war der Support immer sehr gut und zuvorkommend.

Ja, habe ich unmittelbar nach dem Post auch gemacht. 👍🏻

Mag ja ein blöde Frage sein aber wenn eine Website solch eine Zertifikatserstellung anbietet und dann nicht auch gleich den privaten Schlüssel für das erstellte Zertifikat liefert in einem geeigneten Format, wozu ist das dann gut (außer man macht noch was anderes auf deren Website was ein Zertifikat braucht)?

MikeMuc
Deswegen verwendet man üblicherweise einen CSR (Certificate Signing Request). Da wird das Schlüsselpaar auf deinem Rechner erzeugt und der Public Key wird zur Signierung an den Anbieter geschickt. Der macht daraus ein Zertifikat mit dem Public Key, welches in seiner Trust Chain beglaubigt ist und schickt dieses zurück. Die Response wird dann in der Schlüsselbundverwaltung gemeinsam mit dem Private Key als gültiges Zertifikat aufgenommen.
Das war ein wenig verwirrend am Anfang (man musste es auch zum Signieren von Apps so machen, aber mittlerweile sind diese Schritte in Xcode zusammengefasst), aber man muss es eben einfach so machen - selbst wenn man es nicht versteht (das Verständnis wuchs bei mir auch erst mit der Zeit).

Das ist dazu gut, dass die Zertifizierungsstelle unter Einsatz der Glaubwürdigkeit ihres Root-Zertifikates bezeugt, dass derjenige, der den privaten Schlüssel für eine Email-Adresse besitzt, auch tatsächlich diese Email-Adresse besitzt bzw. bei Personen-validierten Zertifikaten, dass der Besitzer des privaten Schlüssels für eine bestimmte Person auch tatsächlich diese Person (ausweislich Personalausweis etc.) ist.

Das ist die einzige Aufgabe einer Zertifizierungsstelle. Sie ist eben eine Zertifizierungs- und keine Schlüsselerstellungsstelle. Dass manche Zertifizierungsstellen die Schlüsselerstellung selbst auch für ihre Kunden anbieten, ist ein Service, der zwar gut gemeint ist, um Kunden den technischen Aufwand der Schlüsselerstellung (der de facto keiner ist, nur eine Frage des technischen Verständnisses) abzunehmen, der aber der Sache vollkommen zuwiderläuft, denn der private Schlüssel darf eben eigentlich niemals, auch nicht vorübergehend, in der Hand eines anderen sein, um garantiert nicht kompromittiert zu werden.

Das ist wirklich lediglich eine Frage des technischen Verständnisses. Denn der faktische Aufwand, ein Schlüsselpaar mit privatem und öffentlichen Schlüssel zu erzeugen, ist nahe Null. Du gibst im Zertifikatsassistenten Deine Email-Adresse ein, klickst auf Erstellen, und schon hast Du Dein Schlüsselpaar. Dafür soll jemand 20€, 30€ bezahlen? Sicher nicht.

Das Problem ist: Das Zertifikat (der öffentliche Schlüssel) ist in diesem Falle selbst-signiert, d.h., Du behauptest einfach, dass Du derjenige bist, der diese Email-Adresse hat oder der diese Person ist. Niemand hindert Dich technisch daran, ein Zertifikat für tim.cook@apple.com oder für die Person Tim Cook auszustellen. Dass diese Angaben stimmen, unter Einsatz ihrer Glaubwürdigkeit zu bezeugen, ist die Dienstleistung der Zertifizierungsstelle, für die sie bezahlt wird, nicht die Erstellung eines Schlüsselpaares, die sie streng genommen gar nicht anbieten dürfte. Und diese Aufgabenstellung erfüllt sie, indem sie eine Verifikationsemail an tim.cook@apple.com sendet, die nur der tatsächliche Inhaber dieser Adresse beantworten kann, beziehungsweise sich den Personalausweis von Tim Cook vorlegen lässt, und daraufhin das Zertifikat ausstellt.

Deswegen ist das CSR-Verfahren das einzig wirklich adäquate: Du selbst erstellst das Schlüsselpaar (ein marginaler Aufwand), behältst den privaten Schlüssel für Dich und sendest (per CSR) nur den öffentlichen Schlüssel an die Zertifizierungsstelle mit der Bitte, aus dem öffentlichen Schlüssel ein beglaubigtes (Email- oder Personen-validiertes) Zertifikat zu machen. Für diese Dienstleistung bezahlst Du.

@MikeMuc: Ich war ja so ein Kandidat der gar nicht über CSR nachgedacht, sondern einfach gemacht hat.
Deswegen renne ich jetzt dem priv. Key hinterher. Der Support kümmert sich schon drum, aber lästig ist es trotzdem.
Aber aus solchen Situationen lernt man ja, und beim nächsten mal läuft es dann anders.

Dass das irgendwie miteinander zusammenhängt, steht überhaupt nicht fest. Wie gesagt hängt es vom Anbieter, bzw. von dem jeweiligen Vertragsangebot ab, wie das mit dem privaten Schlüssel läuft. Ohne weitere Informationen über Deinen Vertrag kann hier eigentlich niemand etwas dazu sagen.

Für Laien sind CSRs oft viel zu kompliziert. Nicht jeder besitzt einen Mac mit Schlüsselbundprogramm, der ein CSR mit ein paar Mausklicks erstellen kann. Deshalb gibt es stark vereinfachte Verfahren, darunter tatsächlich auch unsichere, bei denen der Anbieter den privaten Schlüssel "sieht" und ihn zwischenspeichert, bis der Kunde ihn abgeholt hat.

Das oben erwähnte "certum.pl" bietet zum Beispiel je nach Zielgruppe eine Java-App zum Herunterladen an, mit der man ein Schlüsselpaar sicher auf seinem eigenen Rechner erzeugen kann und dann eine Zertifikatsbestellung ausgelöst wird. Da muss der Kunde auch kein CSR erstellen, jedenfalls nicht für ihn erkennbar.

Genau so lief das ja auch hier ab. Aber mit der Folge, dass ich nun die Keys anfordern muss, weil die nicht im Kundencenter, neben dem Zertifikat zur Verfügung gestellt werden.
Hätte ich CSR genutzt, dann lägen die Schlüssel bei mir vor und alles wäre gut - nur der öffentliche Schlüssel wäre an certum gegangen. Auch für certum besser, weil sie eben dann nur das beglaubigte Zertifikat zur Verfügung stellen müssten.
Man kann den Nutzen der Schlüsselerstellung in der Schlüsselbundapp schon nachvollziehen und verstehen.
Nächstes mal denke ich auch daran

Das ist alles nicht so klar. In dem Fall müsste die Certum-App den privaten Schlüssel "irgendwo" auf Deinem Computer gespeichert haben, so dass Du ihn bereits hast. Bei professionellen Verträgen darf der Anbieter Deinen Schlüssel ja niemals sehen, und kann ihn Dir deshalb überhaupt nicht zur Verfügung stellen.

Laut offizieller Anleitung kannst Du mit der cer-Datei und der Schlüsseldatei eine pfx-Datei mit einem Befehl nach dem untenstehenden Muster erstellen und diese in den Schlüsselbund importieren. Danach enthält der Schlüsselbund das Zertifikat mit dem zugehörigen privaten Schlüssel. Die Dateinamen in diesem Beispiel müssen natürlich angepasst werden:

Natürlich hängt das damit zusammen. Wenn Du einen CSR sendest, hast Du den privaten Schlüssel prinzipbedingt ja bereits.
Naja, nachdem ich den Bestellprozess bei Centum in meinem Artikel minutiös beschrieben habe, kann ich das sehr wohl. Aber das ist doch nicht der Punkt. Klar können sich Anbieter irgendwas ausdenken, wie das mit dem privaten Schlüssel genau gehandhabt wird, aber bei einem CSR taucht die Frage prinzipbedingt erst gar nicht auf.
Dafür erfolgt die Integration in den Schlüsselbund nicht automatisch. Das Verfahren über den macOS-Zertifikatsassistenten ist an Komfort und Narrensicherheit schwer zu überbieten. Apple könnte noch dafür sorgen, dass das Suffix .certSigningRequest per Default in TextEdit geöffnet würde, das wäre de facto sinnvoller. Oder beim Sichern gleich noch automatisch dort geöffnet wird.

Noch komfortabler ist die andere Lösung im Zertifikatsassistenten, wo eine Email mit dem CSR an die Zertifizierungsinstanz geschickt wird; da bekommt der Nutzer von den technischen Interna überhaupt nichts mit. Aber das scheitert daran, dass die Zertifizierungsanbieter die entsprechende Schnittstelle nicht einrichten, weil unklar ist, wie dann die Zahlung abgewickelt werden soll. Denkbar wäre, dass der Kunde nach Zahlung eine individuell kodierte Email-Adresse bekommt, die er in den Zertifikatsassistenten als Email-Adresse der Zertifizierungsinstanz einträgt. Könnte ich Certum & Co. ja mal vorschlagen.

Welche „Certum-App“?
Du kannst doch einem normalen Nutzer nicht mit der Kommandozeile kommen. Die „offizielle Anleitung“ ist auch nicht für Mac-User.

Sorry, Du machst die Dinge unnötig kompliziert. Es ist doch ganz einfach:

• Du generierst im Zertifikatsassistenten einen CSR und speicherst ihn auf der Festplatte mit dem Suffix .certSigningRequest. Der private Schlüssel wird dabei automatisch mitgeneriert und bereits in der Schlüsselbundverwaltung gespeichert, ohne dass der Nutzer das mitbekommt.
• Du öffnest den .certSigningRequest in TextEdit und kopierst den Inhalt in das CSR-Feld bei Deiner Certum-Bestellung.
• Nach Bezahlung und Identitätsvalidierung erhältst Du von Certum einen Download-Link für die Zertifikatsdatei.
• Nach dem Herunterladen machst Du auf die Zertifikatsdatei einen Doppelklick und das wars.

Die Vorstellung, der Nutzer müsse Terminal und openssl bemühen, ist doch absurd. So wird das in der Tat nie was mit der Verbreitung von S/MIME.

Das ist gut möglich - als ich mir das erste Entwicklerzertifikat für den AppStore manuell geholt habe, habe ich einfach die Schritt-für-Schritt-Anleitung von Apple abgearbeitet und fand es am Ende viel einfacher als es zuerst schien.
Die alternativen Lösungen wie Java-Apps oder ähnliches sind eher für die Menschen gedacht, denen man auch "RTFM" zurufen könnte. (Das meine ich dem TE gegenüber nicht abwertend - gäbe es solche Alternativen nicht, würden es alle via CSR angehen und sich über eine entsprechende Anleitung freuen)Hmm, mir ist eigentlich kein halbwegs aktueller Mac bekannt, auf dem die Schlüsselbundverwaltung nicht installiert ist. Der Zertifikatsassistent ist Teil der Schlüsselbundverwaltung.

Ich glaube eher, Marcel Bresink meinte, nicht jeder besitzt einen Mac (der ja eine Schlüsselbundverwaltung hat).

Hier aber eigentlich schon …

Nur müssen die Zertifizierungsstellen sich halt auch mit dem Rest der Menschheit herumschlagen …

Weia etc.
Ihr habt mich mißverstanden. Warum man ein Zertifikat braucht und wie das mit einer Zertifikatsanfrage funktioniert ist mir schon bekannt. Ich wollte wissen, warum bei Erstelller des Threads der private Schlüssel ggf erst auf Nachfrage rausgerückt wird. Ohne den privaten Teil nutzen einem die zur bis jetzt geladenen Daten eben im. Nur der Ersteller des Zertifikats könnte das jetzt nutzen.

Naja, Hellseher ist hier keiner. Wo bei der Kommunikation was schiefgelaufen ist, kann aus der Ferne doch niemand sagen. Böse Absicht von Certum war es sicher nicht.

Das einfachste könnte sein, er fragt bei Certum nach, ob er den Vorgang einfach noch mal wiederholen könne. Wen er sagt (ohne es ihm unterstellen zu wollen) er habe da einen Fehler gemacht und er wisse jetztm, wie man es richtig macht, dann drücken sie vielleicht ein Auge zu und lassen ihn den Vorgang kostenfrei wiederholen.

Andererseits gehts um €39,-. Auf der Gegenseite hat der TS dann ein Wissen, das in Beruf, Privatleben und Freundeskreis wertvoll ist. Ich würde das als "günstiges Fachbuch" abhaken und einfach nochmal von Vorne starten. Vielleicht gleich mit "Folge" eine Anleitung dazu verfassen.

Letzteres habe ich nicht gemacht. Also glaube ich, dass ich Ende 24 relativ blöd dastehe und verzweifelt nach Weis Anleitung krame....

Was schief gelaufen ist, ist halt die Tatsache, dass ich mir nicht selbst die Keys erzeugt habe und bei der Aktivierung nicht über CSR gegangen bin. Daher liegt in meinem Account bei Certum u.a. nur mein Zertifikat vor.
Das ich nun nach dem privaten Schlüssel fragen muss, weil er nicht zur Verfügung gestellt wird, wusste ich vorher auch nicht.
Aber andersherum geht die Rechnung auch nicht auf, denn was nützt das Zertifikat, wenn man ohne den priv. Key keine Signierung und Verschlüsselung durchführen kann. Demnach könnte der private Schlüssel auch von Certum direkt verfügbar gemacht werden.
Von daher sage ich ja, das nächste mal passiert mir sowas nicht mehr. Man lernt.
Es geht mir auch nicht um die paar Kröten, aber so ist es etwas nervig.

Das muss man auch nicht. Du hast aber bisher nicht verraten, welchen der vielen angebotenen anderen Wege Du stattdessen benutzt hast. Hast Du die Java-App (Certum CryptoAgent) verwendet, wie oben angedeutet? Dann müsstest Du den Schlüssel bereits in einer Datei auf der Festplatte haben, da er in der App gespeichert wurde. Er ist halt nur noch nicht im Schlüsselbund.

Auch das ist nicht klar. Wie gesagt darf Certum bei den höherwertigen Produkten diesen Schlüssel eigentlich überhaupt nicht haben.

Naja, die alternative Key pair generation-Methonde, die Certum auch anbietet und die Du gewählt hast, muss ja auch funktionieren – sonst dürfte sie nicht angeboten werden.

Meine Vermutung ist, dass Du bei dieser Methode aufgefordert wirst, den bei Certum generierten privaten Schlüssel sofort herunterzuladen (noch vor Beendigung des Aktivierungsvorgangs) und Du das irgendwie übersehen hast (oder es auf Polnisch dastand oder …). Das wird bei Zertifizierungsstellen, die aus Komfortgründen anbieten, die Schlüssel zu generieren, oft so gehandhabt, eben, damit die Verweildauer der Daten bei ihnen so kurz wie möglich ist. Bei PSW (einer anderen Zertifizierungsstelle) z.B. wird das Schlüsselpaar via JavaScript erzeugt und nirgendwo gespeichert, d.h. man muss sich den privaten Schlüssel nach der Generierung sofort als Text von der Webseite kopieren, sonst ist er unwiederbringlich fort.

Andernfalls hätte Certum Dir eine .p12-Datei zum Herunterladen anbieten müssen.

Doch, das hat er:Das bezieht sich auf folgenden Website-Dialog:

Das hat d2o nirgendwo angedeutet; Du bist der einzige, der diese Java-App ins Spiel gebracht hat.
Es geht aber um die Certum E-mail ID Individual (S/MIME), die ist das billigste Angebot von Certum.

Die Eingabe von „Weia Certum“ in die MacTechNews-Suche hilft.

Doch, die Java-App habe ich verwendet, weil es der nächste Schritt und er Key Pair Generation war.

Derzeit versuche ich mit Certum an die p12 Datei zu gelangen. Man hatte mir zwar einen Weg gezeigt, wie ich an die .p12 Datei kommen soll, aber die Optionen werden mir in dem Dialog nicht angeboten. Es endet letztlich immer darin, dass ich nur die .cer Datei herunterladen kann.

Ah, sorry, dann hatte ich das falsch verstanden.

Verstehe ich das jetzt richtig, dass Du auf der Seite warst, die ich im Screenshot gezeigt habe, dort statt auf CSR auf Key pair generation geklickt hast und als Konsequenz dann die Java App geöffnet wurde? Oder musstest Du die zuvor herunterladen? Oder kamst Du von ganz woanders?

Genau so war es. Es wurde die Java App geöffnet und anschließend ging es in die Aktivierung.
Musste nur noch die JRE updaten, weil ich einen älteren Versionsstand hatte. Anschliessend lief die App.
Ich hatte Certum auch direkt aufgerufen, bin also von nirgendwo anders gekommen.

Um das Thema - von meiner Seite - abzuschließen, hier noch der letzte Stand.

Auch mit dem Help Desk von certum war es nicht möglich den Key zu bekommen.
Nach zwei "Reissue" Versuchen, landete ich stets immer nur bei der .cer Datei, auch wenn ich das CSR genutzt habe, denn das Zertifikat sollte eigentlich mit CSR neu aktiviert werden - ging aber nicht, da dieser Auswahlpunkt gar nicht erst auftauchte.
Also für mich stellt sich nun heraus: Macht man es initial falsch, hat man später keine Chance mehr, um das zu korrigieren - selbst mit Hilfe des Service Desks nicht, die sich Mühe gegeben haben, aber der im Browser ablaufende Prozess weicht von deren Anleitung und auch von dem was Weia sehr umfangreich dokumentiert hat, ab.
Ich verbuche den Betrag einfach als Lehrgeld und überlege, ob ich nun wieder ohne Zertifikat weitermache.

Naja, im Rahmen derselben Order vielleicht nicht, das weiß ich nicht, aber wenn Du das als „Lehrgeld“ abgeschrieben hast, kannst Du ja jederzeit eine neue Order starten, in der Du dich an meine Anleitung hältst.
Ich verstehe nicht ganz, was Du damit meinst, aber ich habe zufällig just gestern Abend ein neues Zertifikat bei Certum gekauft und der Bestellprozess funktioniert bis ins letzte Detail genau so, wie ich ihn beschrieben habe.

Dann funktioniert es tatsächlich nur bei einem neuen Zertifikat so wie Du es beschrieben hast.
Im Reissue Prozess, mit den daraus folgenden Möglichkeiten, passt es nicht mehr. Aber da passt es auch nicht nach der Anleitung des Help Desk.

Das kann ich leider gerade nicht testen, da ich zur Zeit nix zu Reissueen habe. Aber es zwingt Dich doch keiner, das als Reissue zu deklarieren?

Ich nicht, aber Certum. Die haben offenbar nur diesen Weg vorgesehen.

Weil Du schon einen Bestellversuch gemacht hast oder warum? Du kannst doch ein völlig neues Zertifikat bestellen, auch wenn Du zuvor schon eines für diese Email-Adresse hattest?

Noch eine Idee: In der Überschrift steht ".cert", später heißt es "binary .cer". Was stimmt denn jetzt?

Hast Du schon mal mit TextEdit in die Datei geschaut? Diese cert-Endungen sind nicht wirklich genormt. Der Inhalt könnte in Wirklichkeit eine DER-Datei, aber auch eine PEM-Datei sein.

Sind dort möglicherweise mehrere Abschnitte mit den Markierungen


zu finden?

Why not? Ernstgemeinte Frage. Was nützt ein Standard, den nur "nerds" nutzen, obendrein kostet für jede einzelne Mailadresse, sich in dieser Form niemals in der Breite durchsetzen kann?

Das stimmt ja nicht, in den letzten Jahren wurde das endlich deutlich besser. Ob Behörden, Anwälte, Ärzte oder Versicherungen – mit (fast) allen kann ich mittlerweile vertrauliche PDFs einfach über S/MIME-Emails austauschen. Endlich praktisch kein Papier mehr.
Briefe wären teurer, wenn man nicht nur 3 im Jahr verschickt …

Ich habe natürlich zunächst versucht mit Certum das Problem zu beheben. Aber für die gibts immer nur den Weg, den sie jetzt beschritten sind. Für mich endet der immer gleich: Ich kann nur die .cer Datei runterladen.

Die nächste Möglichkeit wäre jetzt tatsächlich ein neues Zertifikat zu kaufen.
Und dann sofort von Anfang mit CSR.

d2o
hast du denn inzwischen mal mit einen Texteditor deine .cert Datei geöffnet und reingeschaut? Marcel hat ja schon geschrieben, das es da verschiedene Inhalte drin geben kann.

Davon ab, kann man diese Javaapp nur während einer Bestellung laden und ausführen? Sonst könnte man ja mal schauen, was die so treibt und ob die wirklich den Privatekey nicht lokal speichert. Falls nicht, ist die doch unbrauchbar?

Nun, ich wußte gar nicht, daß der Gesetzgeber zu irgendwelchen "Nerd-Techniken" verpflichtet anstatt "vernünftige Techniken" vorzuschreiben... im Enterprise-Umfeld ist Mailverschlüsselung nämlich inzwischen für bestimmte Inhalte gesetzlich vorgeschrieben.

Mir ist auch gerade mal ein einziges Mailprogramm bekannt, das kein S/MIME beherrscht (von den Nerd-OSes Linux und Android mal abgesehen).

JEDER, der auf seine Privatsphäre wert legt sollte ALLES dafür tun, daß seine Informationen privat bleiben... und Mailverschlüsselung ist hier ein recht großes Zahnrad in der gesamten Kette.

Ja, ich habe mit dem Texteditor reingeschaut.
Es steht ein bisschen was in Klartext und der Rest sind nicht wirklich lesbare Zeichen.
Die Java-App wird im Rahmen der Bestellung runtergeladen und ausgeführt. Nach der Key Generation geht es wieder zurück auf die Bestellseite, und der Prozess geht weiter, bis man das Zertifikat aktivieren und runterladen kann.
Offensichtlich passiert in der JavaApp nichts. Ob was gespeichert wird, und wo - erkennt man nicht.
Wenn es so wäre, dann wäre es für Certum aber auch einfach gewesen, mir mitzuteilen, dass der private key von der App auf meinem System gespeichert wird, und ich mir den dort holen kann.
Dann wären die letzten zwei Wochen mit dem Help Desk nicht nötig gewesen.

Ich kenne es auf Ebene der Bundesbehörden, der dort wird das Ganze zentralisiert und via Gateways umgesetzt, damit nicht jeder einzelne Beschäftigte die Zertifikate anfordern muss.
Allerdings sehen diese Zertifikate auch eine Identitätsprüfung voraus, nicht nur die Existenz der Mail-Adresse.
Dafür müsste sich aber das Bewusstsein der Nutzer ändern. Hier findet man das Scheunentor "ich habe nichts zu verbergen", durch die offenbar sehr viele Nutzer gehen.
Evtl. müsste es auch einen Mindeststandard geben, der eben nicht nur die Existenz der Mailadresse zertifiziert, sondern auch die Person, die sich namentlich damit ausgibt. Kann man zwar auch jetzt schon, aber dann ist das Zertifikat auch gleich deutlich teurer. Das ist dann die nächste "Hürde".
Allerdings ist das nicht der Mindeststandard, sondern die nächst höhere Stufe.

Um genau dieses "bisschen was in Klartext" geht es. Könntest Du diese Zeilen nicht hier posten?

Wie Marcel weiter oben ja bereits beschrieben hat, sind die Anfangs- und Endzeilen jeweils in Klartext und beschreiben, was sich dazwischen befindet:

Hm. Aber wozu ist das Java-Programm denn sonst da, wenn nicht zur Erzeugung des privaten Schlüssels?

Ist der gesamte Bestellprozess wirklich so schlecht, dass man das als Anwender dermaßen vergeigen kann, dass der Helpdesk nicht in der Lage ist, das in Ordnung zu bringen?

Ich fand damals das Prozedere bei Sectigo schon eine Zumutung, aber hier scheint das ja noch eine Nummer härter zu sein.

Es wird Zeit für einen S/MIME Zertifikatsdienst von Let‘s Encrypt.. dann wird es plötzlich einfach und günstig..

Hält man sich an die Anleitung von Weia, und nutzt CSR, dann klappt es auch problemlos.

Achtet man nicht darauf, dann sieht es anders aus.
Der Helpdesk schaltet immer nur die Neuausstellung des Zertifikats frei. Da ist ein Button, den man drücken kann.
Dann durchläuft es den Prozess, an deren Ende immer nur das Zertifikat als binary oder plain heruntergeladen werden kann.
Der Helpdesk geht die ganze davon aus, dass man auch die pfx herunterladen kann. Was dort offenbar nicht verstanden wird, dass - selbst nach penibler Einhaltung deren per E-Mail verschickten Step by step Anleitung - dies nicht angeboten wird. Es endet immer im genannten Download.
Offenbar stellt sich der Prozess für Certum anders dar als für mich.