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

Es beginnt mit:

-----BEGIN CERTIFICATE-----
Q0EgU0hBMjAeFw0yMzA4MTExMDQwMDdaFw0yNTA3MzExMzAxMzRaMDQxFTATBgNV
BAMMDHNyQHB1bHN1bS5kZTEbMBkGCSqGSIb3DQEJARYMc3JAcHVsc3VtLmRlMIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEApPOk0Oi1pgRIYq4G09zHSlRlv1yUpeYZsXHPw7CU4CfF5Jet
...
...
und endet nach noch mehr Zeilen von vorstehenden Inhalt mit:

-----END CERTIFICATE-----

Mehr steht da nicht drin.

Danke Dir. Damit ist klar, dass tatsächlich nur das Zertifikat in der Datei steht.

Ich habe es seinerzeit per CSR direkt bei D-Trust gemacht. Ging problemlos und hat auch nicht soo lange gedauert wie von Weia angekündigt. Leider hat sich D-Trust vom Endkundenvertrieb zurückgezogen. Aber das macht die Sache zumindest preiswerter.

Das stimmt aber nicht wirklich. In einer .cer-Datei ist, Überraschung, ein Zertifikat im PEM-(Privacy Enhanced Mail)-Format (Base64-ASCII-kodiert) zwischen den Zeilen
Es gibt x Websites, die die PEM-Kodierung in eine menschenlesbare Form wandeln können, z.B. https://ssltools.godaddy.com/views/certDecoder.

Rein technisch gesehen könnte man in die Datei natürlich auch noch den privaten Schlüssel zwischen den Zeilen
im selben PEM-Format anhängen. Nur wäre das hochgradig sinnlos, denn diese Datei ist ja nicht verschlüsselt und passwortgeschützt, der private Schlüssel wäre also kompromittiert, sobald sie übers Internet wandert.

Eine Datei, die auch den privaten Schlüssel enthält, muss, soll das Ganze Sinn ergeben, im passwortgeschützten .p12-Format vorliegen (.pfx auf diesem seltsamen anderen Betriebssystem).

Zu guter Letzt: Wäre da irgendwo der private Schlüssel, würde die Schlüsselbundverwaltung ihn automatisch erkennen, extrahieren und importieren.
Wenn man im Bestellprozess Key pair generation statt CSR wählt, wird eine .jnlp-Datei heruntergeladen (Java Network Launch Protocol). Das eigentliche Java-Programm wird also übers Netzwerk gestartet und das geht vermutlich nur während des Bestellprozesses – das Programm muss ja mit Certum interagieren zum Senden des öffentlichen Schlüssels (was schon wieder das Problem beinhaltet, dass niemand sagt, dass es nicht auch den privaten sendet …).
Ich weiß gar nicht, warum hier so viel herumgerätselt wird: Natürlich muss das Programm den privaten Schlüssel lokal speichern und wäre sonst unbrauchbar. Es können also prinzipiell nur 2 Dinge passiert sein:

• Das Programm ist buggy.
• d2o hat einen Bedienungsfehler gemacht (übersehen, einen Speicherort anzugeben oder was auch immer).

Natürlich dafür (Genauer gesagt: zur Erzeugung des Schlüsselpaares aus privatem und öffentlichem Schlüssel. Der öffentliche Schlüssel wird dann zur Zertifizierung an Certum gesandt.)
Vermutlich gibt es nichts in Ordnung zu bringen. Das Java-Programm ergibt ja nur Sinn, wenn der private Schlüssel erst gar nicht an Certum gesandt wird; also können sie ihn auch nicht zurücksenden. Könnten sie das, also: hätten sie ihn, dann wäre der ganze Aufwand mit dem Java-Programm sinnlos.

Der Schlüssel kann nur lokal bei d2o auffindbar sein. Ist er das nicht, ist wie gesagt entweder das Java-Programm buggy oder d2o hat einen Bedienungsfehler gemacht
Da ist definitiv etwas passiert, was nicht so sein sollte.
Es ist jetzt schon exakt so einfach, wenn man mit dem Zertifikatsassistenten einen CSR erzeugt – das müsstest Du für Let’s Encrypt ganz genauso. Und 10€ im Jahr sind wahrlich nicht un-günstig.

Das Problem ist nicht die Infrastruktur oder der Prozess. Das Problem ist ausschließlich die mangelhafte Dokumentation. Welcher Mac-Nutzer weiß schon, dass es den Zertifikatsassistenten überhaupt gibt, geschweige denn, wie das alles zusammenhängt? Daher ja mein damaliger Beitrag.

Prinzipiell wäre das möglich, aber soweit ich mich erinnere, musste ich nur den Downloadordner vorgeben bzw. bestätigen und das wars. Der Generator selbst ist nur ein kleines Fenster mit einer Oberfläche, die den Hersteller/Urheber beschreibt und eine Version anzeigt.
Nach einem Speicherort für Schlüssel - also während die App lief - wurde ich nicht gefragt.

Ich wollte Dir keinesfalls was unterstellen. Ich meine einfach, dass es rein logisch eine von diesen beiden Sachen sein muss. Denn die beiden einzig logisch noch möglichen Alternativen wären, dass das Java-Programm absichtlich keinen privaten Schlüssel speichert oder aber ihn an Certum überträgt und beides ergäbe überhaupt gar keinen Sinn bzw. würde das Java-Programm ad absurdum führen.

Warum dem Help-Desk das nicht klar ist, ist freilich auch noch eine gute Frage. Die müssten doch wissen, dass sie den privaten Schlüssel gar nicht haben können.

d20
Was mir gerade noch einfällt: Arbeitest Du in einem Nutzerkonto mit Standard- oder Adminrechten? Vielleicht will das Java-Programm irgendwo hinschreiben, wo es keine Zugriffsrechte hat, und scheitert dann ohne jede Fehlermeldung?

Unvernünftigerweise immer mit Adminrechten.

Hm, dann kann es das jedenfalls nicht sein.

Über die PSW gibts das noch preiswert: https://www.psw-group.de/smime/advanced-personal-a010015/.