Mailpartner schicken mir *.cer statt *.asc -- was nun?

Hi David,

Zitat von "David.P"

Leider habe ich keine Ahnung, ...

Genau dafür habe ich mir die Mühe gemacht, und eine umfangreiche Abhandlung zu diesem Thema in den FAQ veröffentlicht. Schon gelesen?

Zitat von "David.P"

...ob dieses Zertifikat nun

• den öffentlichen Schlüssel des betreffenden Mitarbeiters enthält, und falls ja,
• was ich mit dem Zertifikat anfange, insbesondere wie ich es in Enigmail importiere, so dass ich dem betreffenden Mitarbeiter eine verschlüsselte Mail schicken kann.

zu 1.) Ja, es ist der öffentliche Schlüssel darin eingebettet.
zu 2.) Es handelt sich um ein X.509-Zertifikat und der Absender verwendet S/MIME, so wie im Screenshot erkennbar.

Zitat von "David.P"

... ob und wie ich solche Zertifikate in Thunderbird/Enigmail verwenden kann.

Auch wenn es in letzer Zeit Entwicklungen gegeben hat, mit PGP-MIME einen Kompromiss zwischen den beiden Entwicklungszweigen der Mailverschlüsselung zu finden, so wird es wohl noch eine Weile bei der Zweigleisigkeit bleiben.
- Firmen, Behörden und "Profis" nutzen S/MIME
- hauptsächlich Privatpersonen nutzen GnuPG
- beides mit fließenden Übergängen, es gibt also auch GnuPG nutzende Firmen, genau so wie die Zahl der S/MIME nutzenden Privatpersonen zunimmt. Thunderbird beherrscht S/MIME "von Hause aus".

MfG Peter, der sich wieder etwas mehr Zeit gelassen hat

Hi David,

mit Genuss habe ich deinen langen Beitrag gelesen :-).
Und bis auf eine ganz kleine Nebensächlichkeit stimme ich dir auch speziell in deinem einleitendem Sermon auch vollständig zu. Die kleine, aber bedeutungsvolle Nebensächlichkeit: .asc = GnuPG und .cer, .der. pfx und p12 sowie pem sind Zertifikate bzw. Schlüsseldateien für S/MIME (X.509). Aber das sei dir verziehen.

Zitat von "David.P"

Zunächst mal vorneweg, eigentlich halte ich (und meine Umwelt) mich für einen extremen Power User bezüglich PC und digitale Kommunikation... Seit vielen Jahren sind für mich Sachen wie papierloses Büro, Spracherkennung, Multitouch-Input, virtuelle Teams und Web-Kooperation usw. tägliche Selbstverständlichkeiten.

Hut ab! Ehrlich!

Zitat von "David.P"

Zudem verwende ich bereits seit Jahren mit bestimmten Kommunikationspartnern E-Mail-Verschlüsselung (GPG). Trotzdem muss ich sagen, dass ich nach wie vor geschätzte ca. 80 % der Anleitungen bezüglich Mailverschlüsselung nicht verstehe. Bezüglich des Themas S/MIME und Zertifikate liegt der Prozentsatz wahrscheinlich eher bei 95 %.

Keine Sorge, da stehst du nicht allein.
Ich selbst bin hier kein Maßstab, verdiene ich doch seit vielen Jahren mit dieser Problematik meine Brötchen. Aber die gesamte Problematik der sicheren Kommunikation stößt bei einem großen Teil unserer Bevölkerung auf taube Ohren. Leider trifft das auch immer noch auf viele Firmen zu. Und auch viele Nutzer, die ihre Mails verschlüsseln, wollen gar nicht wissen, was im Hintergrund passiert.
Letzteres versuche ich zu beeinflussen, indem ich auf fast jeden Beitrag zu diesem Thema "anspringe".
Ich selbst zitiere auch gern einen bekannten Berliner Politiker (weil ich seinen Spruch einfach mag, auch wenn ich diesen völlig aus dem Zusammenhang gerissen verwende!). Aber niemals in die Richtung, dass "wir Insider" dieses Wissen gepachtet haben und nur für uns verwenden wollen. Nein, ich möchte dieses Wissen breittragen.

Zitat von "David.P"

... zum Ausdruck zu bringen, dass das Thema "Mailverschlüsselung" für fast jeden PC-Nutzer ein derzeit nahezu unüberwindliches Hindernis darstellt. Ganz zu schweigen vom problemlosen täglichen Einsatz von Mailverschlüsselung, von der wir nach wie vor noch Lichtjahre entfernt sind.

Auch hier Zustimmung.
Den Durchbruch können wir nur durch kryptografische Anwendungen erreichen, welche fast unbemerkt vom Nutzer arbeiten. Hier zwei Beispiele:
1. Ich nenne hier gern das nette kleine Programm "Locknote" von Steganos. Das ist ein kleiner einfacher Texteditor, welcher ohne Installation funktioniert. Du kannst damit beliebige Texte (=> deine Passwortdatei!) eintippen. Und beim Beenden wirst du nach einem Passwort gefragt. Ein Doppelklick auf das Programm, und du wirst nach dem PW gefragt. Das Programm ist so klein, dass man es auch problemlos (samt Inhalt ...) per Mail hin- und her schicken kann.
2. Hier muss meine "ehemalige Verlobte" herhalten. Sämtliche Mails, welche sie mir, den Kindern und einigen Freunden verschickt bzw. von ihnen empfängt - sind verschlüsselt! Dabei ist sie die reinste (Linux-)"Nutzerin". Sie bemerkt es nicht einmal, dass ihre Mails verschlüsselt sind! Thunderbird mit dem Add-on "Virtual Identity" und ein paar importierten Zertifikaten (die .cer der Empfänger) und einer (=> ihrer) Schlüsseldatei machen es möglich. Klar, ein "Wissender" muss das einmal eingerichtet haben.

Zitat von "David.P"

Ich verstehe nun, dass die besagte Firma offensichtlich S/MIME verwendet, und dass es sich bei den mir zugesandten *.asc-Dateien offenbar um X.509-Zertifikate handelt. Nach wie vor ist mir aber gänzlich unklar, ob und wie ich diese erhaltene Zertifikate nun einsetzen kann.

Nur mit der bereits im TB eingebauten S/MIME-Funktionalität.

Zitat von "David.P"

Mache ich einen Doppelklick auf eine solche *.asc-Datei, dann öffnet sich das Zertifikat mit einem Button "Zertifikat installieren". Drücke ich da drauf, dann öffnet sich (in Windows XP) ein Zertifikats-Import-Assistent, der nach mehrmaligen Drücken von "Weiter" die eigentlich erfreuliche Meldung abgibt "Der Importvorgang war erfolgreich".

Stimmt ja auch. Allerdings hast du damit mit Windows-Bordmitteln die Zertifikatsdatei "nur" in den Zertifikatsspeicher des Betriebssystems importiert. Mozilla-Produkte benutzen aber einen eigenen Zertifikatsspeicher, welcher völlig unabhängig von dem des Betriebssystems ist.
Dieser Zertifikatsspeicher wird mit dem gleichen Passwort geschützt, welches auch für die Datei mit dem Mailpasswörtern angewendet wird => "Masterpasswort".

Zuerst musst du dir von einem Trustcenter eine "Schlüsseldatei" beschaffen. Das ist dein eigenes Zertifikat, welches auch deinen eigenen "geheimen" Schlüssel beinhaltet. (Hast du schon eines? Reicht meine Anleitung in den FAQ?)
Ich betone auch hier noch einmal: deinen geheimen Schlüssel produziert dein eigener Browser, er wird NICHT zum Trustcenter gesandt! Dorthin gehen nur dein öffentlicher Schlüssel und deine Nutzerdaten, die ja im Zertifikat stehen müssen.
Mit diesem geheimen Schlüssel wirst du später deine Mails signieren und die mit deinem öffentl. Schlüssel verschlüsselten Mails entschlüsseln. (=> genau wie bei GnuPG!)
Die Schlüsseldatei mit deinen eigenen Schlüsseln wird logischerweise nach "Ihre Zertifikate" importiert. Bei diesem Import benötigst du einmalig das Passwort, welches bei der Erstellung des geheimen Schlüssels selbst eingetippt hast.

Die von deinen Mailpartnern erhaltenen Zertifikate (.cer, .der) importierst du nach "Zertifikate anderer Personen"

Und jetzt kommt der große Unterschied zu GnuPG: Die zentrale Bereitstellung der Zertifikate. Wir nennen es auch "Vertrauenskette". Du vertraust dem Herausgeber, dass er die Person auf deren Namen das Zertifikat ausgestellt wurde, sicher identifiziert hat. Damit vertraust du automatisch, dass die Person, die eine Mail mit ihrem Zertifikat unterschrieben hat, auch wirklich identisch ist. Du vertraust also dem Zertifikat.

Also musst du auch das so genannte Herausgeberzertifikat in den Zertifikatsspeicher importieren. Dieses findest du auf der Webseite des jeweiligen Trustcenters. Mit diesem Zertifikat prüft das Programm die Gültigkeit der Benutzerzertifikate.
Diesem Zertifikat musst du unbedingt mit "Bearbeiten" dein Vertrauen aussprechen.
ACHTUNG: bei den beliebten "Kostnix-Zertifikaten" ist das mit der Identifizierung der Personen natürlich nur theoretisch.
Für Mailverschlüsselung sind diese Zertifikate selbstverständlich voll geeignet. Es gibt nur Abstriche bei der Gültigkeit der Signatur. Deshalb musst du auch derartige Herausgeberzertifikate manuell importieren und ihnen bewusst (!) das Vertrauen aussprechen.

Damit hast du die Punkte 1-4 in der Anleitung abgearbeitet.

Zitat von "David.P"

ad 1) Zunächst mal verstehe ich nicht, warum der Absender sein Zertifikat "in Thunderbird" installiert haben muss. In meinem Fall verwendet der Absender irgendeinen firmeninternes Mailsystem, keinesfalls jedoch Thunderbird. Insofern ist dieser Teil von Voraussetzung Nr. 1 wahrscheinlich hinfällig?

Wie oben schon beantwortet: Mit deinem eigenen geheimen Schl. entschlüsselst du erhaltene Mails und signierst die eigenen.
Alles, was ich beschrieben habe trifft selbstverständlich nicht nur auf TB zu. Das mache ich mit Lotus Notes genau so wie mein Mailpartner mit Ausgugg. Es spielt auch keine Rolle, woher die Zertifikate kommen. Wichtig ist nur, dass du immer auch die Herausgeberzertifikate mit importierst. Viele Mailpartner => viele Herausgeber => viele Herausgeberzertifikate.

Zitat von "David.P"

ad 2) "Für die Empfänger müssen gültige Zertifikate installiert sein"
Hier ist mir folgendes unklar:
a) Wer sind "die Empfänger", bin das ich in diesem Fall?
b) wo müssen die Zertifikate für die Empfänger installiert sein, beim Absender oder beim Empfänger, also bei mir -- oder bei beiden?

Die Empfänger sind deine Mailpartner. Von ihnen benötigst du die Zertifikate mit den öffentlichen Schlüsseln. Mit denen verschlüsselst du die zu sendenden Mails.

Zitat von "David.P"

ad 3) dito:
a) Wo müssen die Zertifikate der Zertifizierungsstellen installiert sein, beim Absender, beim Empfänger oder bei beiden?
b) Und warum sind "die Zertifizierungsstellen" hier im Plural -- weil auch "die Empfänger" im Plural ist, oder weil Absender und Empfänger unterschiedliche Zertifizierungsstellen verwenden könnten?

Jeder muss - an die richtige Stelle - sein eigenes Zertifikat+geh. Schlüssel (Schlüsseldatei .p12 oder .pfx) und die Zertifikate (.cer, .der) aller Mailpartner installieren. Und natürlich die Herausgeberzertifikate aller Herausgeber.
Aber letztere sind hier bei uns in der Regel nur 3-4.

Zitat von "David.P"

ad 4)
a) wer spricht den Zertifikaten von Empfänger und Herausgeber das Vertrauen aus, der Absender, oder ich als Empfänger, oder beide, oder noch wer anders und
b) wie geht das?

beide (wie beschrieben)

Zitat von "David.P"

Bitte all dies wie gesagt nicht als Kritik verstehen, sondern nur als Ausdruck der für mich nach wie vor riesigen Hürden auf dem Weg zum täglichen Einsatz von Mailverschlüsselung.

Dann würde ich mich nicht eine Stunde hinsetzen und das hier tippen

Zitat von "David.P"

Langer Rede kurzer Sinn, was müsste ich tun, damit ich dieses *.asc-Zertifikat meines Mailpartners im Thunderbird verwenden und diesem verschlüsselte Mails schicken kann?

Also, wenn die Frage jetzt immer noch steht ...
... zuerst einmal diesen Beitrag und meine FAQ ein zweites mal und vielleicht auch noch ein paar Beiträge anderer Verfasser (=> google) durchlesen.
... dich mit weiteren konkreten Fragen hier melden.

MfG Peter

Hi David,

im Prinzip hast du alles richtig gemacht ... .
Leider kann ich es nicht kontrollieren, denn du hast ja aus guten Grund einige Angaben anonymisiert.

Ich gehe also mal davon aus, dass du jetzt im Zertifikatsmanager unter "Ihre Zertifikate" einen Eintrag in folgender Form hast:

TC TrustCenter GmbH
Vorname Name.........Mailadresse...............Software Sicherheitsmodul..........lange HexZahl...................Gültig bis

Und auch dass sowohl der angezeigte Name und die Mailadresse mit den Daten in deinem Mailkonto übereinstimmen.
In dem unter Konto > S/MIME-Sicherheit eingetragenen Zertifikat ist auch wieder dein Name und deine Mailadresse zu sehen.
OK?

Und jetzt kommt es darauf an, dass du unter "Zertifizierungsstellen" auch wirklich die richtigen Herausgeberzertifikate importiert und diesem auch das Vertrauen ausgesprochen hast. Du kannst das ganz einfach feststellen, indem du bei deinem Zertifikat auf Ansehen > Details gehst. Es müssen dort insgesamt drei Zertifikate stehen, wovon bei den beiden Herausgeberzertifikaten jeweils mindestens der Haken bei "Mail" (besser alle drei) gesetzt ist.
Da das TC recht viele Herausgeberzertifikate besitzt (und das ist auch gut so!), musst du beim Import dieser genau aufpassen. Mein Tipp: hole dir alle, die auf der Webseite stehen. Dann kannst du nichts falsch machen - und schaden kann es keinesfalls.

Ich habe mir auch ein Zertifikat von der Konkurrenz "geleistet", da sieht es so aus:

TC TrustCenter Class 1 CA - TC Trustcenter for Security ... GmbH...................drei Haken
... TC TrustCenter Class 1 L1 CA VI...............................................................drei Haken
........Mein Name

Die Vertrauenskette von oben nach unten muss "stimmig" sein! Das ist es aber automatisch, wenn du alle Herausgeberzertifikate importiert hast. Bei dir muss natürlich dann beim zweiten "TC TrustCenter Class 1 L1 CA IX" stehen, genau wie in deinem Zertifikat.

Dann müsste eigentlich alles funktionieren.

Zitat von "David.P"

Außerdem hätte ich noch ein paar grundsätzliche Fragen zum Einsatz von S/MIME-Verschlüsselung....
*.p7c
*.der
*.crt

Die bisher erhaltenen Zertifikate meiner Mailpartner haben jedoch keine dieser Endungen, sondern lauten grundsätzlich auf
*.cer

Nein, das spielt keine Rolle.
Die genannten Endungen stehen nur für die unterschiedlichen Speicherformate des gleichen Zertifikatsinhalts. Wenn der Anwender das Zertifikat importieren kann spielt die Endung für die Datei keine Rolle. Selbst der Empfänger könnte noch nachträglich durch Import in den Zertifikatsspeicher des Betriebssystems und anschließendem Export in sein geignetes Format dieses jederzeit ändern. Er kann sich ja auch jederzeit das Zertifikat (= die "öffentlichen Bestandteile") vom jeweiligen Trustcenter herunterladen. Was viel wichtiger ist, du solltest ihm netterweise auch gleich die beiden Herausgeberzeritifikate mitschicken, damit er nicht erst suchen muss.
Und ganz wichtig: Niemals die Schlüsseldateien .pfx oder .p12 bzw. .pem aus der Hand geben ... .
NB: Ein einfaches Umbenennen .crt in .der wird meistens auch anstandslos geschluckt.

Zitat von "David.P"

C) Und wenn ich schlussendlich mein Zertifikat an meine Mailpartner versende, können die dieses dann problemlos importieren und zur Verschlüsselung verwenden? Spricht, ist das Stammzertifikat von der Trustcenter GmbH (das ja zusätzlich benötigt wird, um mein Zertifikat verwenden zu können) entsprechend weitverbreitet bzw. leicht zugänglich?

Ich schreib ja schon: besser gleich mitschicken ... .
Die Herausgeberzertifikate aller gängigen Trustcenter sind immer leicht öffentlich zugänglich. Das ist Grundlage bei den X.509-Zertifikaten.
Das Problem ist aber nur, das richtige Z. zu erwischen ... (s. oben).

Zitat von "David.P"

Ich habe zum Beispiel kürzlich mit meinem Trustcenter-Zertifikat eine digital signierte PDF-Datei erzeugt. Beim Öffnen dieser Datei erscheinen jedoch unerfreuliche Meldungen, offenbar weil Adobe Acrobat dem Stammzertifikat von Trustcenter GmbH nicht traut:

Und das ist auch gut und richtig so! (Oh, wie oft habe ich das hier schon geschrieben ... .?)
Ein Trustcenter garantiert dir, dass die Identität der in einem nach SigG produzierten Zertifikat bei der persönlichen Registrierung durch Vorlage eines gültigen Personalausweises/Reisepasses genau überprüft wurde. (==> Personal, Zeitaufwand, Kosten!)
Deshalb kannst du dich als Empfänger eines signierten Dokumentes darauf verlassen, dass:
- der in der Signatur stehende Name auch wirklich der des Absenders ist (Authentizität),
- und die Nachricht nach dem Absenden nicht verändert/manipuliert wurde (Integrität).

Ein Kostnix-Zertifikat gewährleistet selbstverständlich die Überprüfung der Identität des Dokumentes. Aber niemals die Authentizität des Absenders! Und nur deswegen dürfte eigentlich kein Herausgeberzertifikat derartiger ohne Personenidentifizierung hergestellter Zertifikate gleich "von Hause aus" in die Anwendungen eingebaut werden. Und wenn ein Anwender bewusst derartige Herausgeber als vertrauenswürdig einstuft, dann weiß er, was er getan hat. Sachlich steht da überhaupt nichts dagegen, der Anwender muss es nur bewusst getan haben - und sich dessen auch immer bewusst sein.
Der Acroreader ist hier genau so ein Programm, welches die Zertifikate auswertet, wie der Thunderbird. Wenn er die richtigen Herausgeberzertifikate vorfindet, und denen auch das Vertrauen ausgesprochen wurde, meckert er auch nicht mehr.

Wenn du gesetzlich verpflichtet bist, elektronisch versandte Rechnungen usw. mit einer el. Signatur zu versehen, dann wird dir dein Kostnix-Zertifikat garantiert nichts nutzen. Im Gegenteil, du stiftest nur Verwirrung ... .

Zitat von "David.P"

D) Und, erstmal letzte Frage: Kann ich mit S/MIME dann problemlos alle Arten von E-Mails ver- und entschlüsseln (Text, HTML, Mixed, Inline, mit Anhang usw.) -- ist das ganze also nicht so furchtbar problematisch wie bei PGP und den ganzen Inkompatibilitäten zwischen den verschiedenen Mailclients?

Hier die gute Nachricht:
ALLES, was sich im Mailbody befindet, wird bei der S/MIME-Verschlüsselung in einen einzigen .p7m-Container gepackt und beim Empfänger wieder entschlüsselt. Bitgenau, denn sonst würde die Signaturprüfung ja eine Fehlermeldung bringen. Es spielt also keine Rolle, ob Text oder Klickibunti, mit oder ohne Anhänge.
Und jeder Mailclient, bei dem S/MIME sachgerecht implementiert ist, kann diese Mails auch entschlüsseln und die Signatur prüfen.

MfG Peter

edit: Jetzt habe ich mir viel Zeit gelassen mit der Antwort, ich schicke es ab, wie es ist ... .

So, obwohl ich weiß, dass man seine Beiträge auch editieren kann und sollte, ergänze ich mit einem weiteren Beitrag

zu A)
manchmal ist es gut, solche "Kleinigkeiten" (mehrere Identitäten) gleich bei der Frage mit zu bringen ... .

zu B/C)
Meine Empfehlung für die Herstellung eigener Zertifikate ist das Programm "XCA"!
Dieses Linuxprogramm wurde mittlerweile auch für die WinDOSe portiert und ist für mich das private CA-Programm!
Du kannst dir sowohl Vorlagen (Templates) für jede Art von Zertifikaten (diverse Server, Clients, S/MIME, CA usw.) anlegen, als auch die Zertifikate und Schlüsseldateien in den verschiedensten Formaten und auch Bestandteilen exportieren. Es beinhaltet auch eine komplette Benutzerverwaltung, die Herausgabe von Sperrlisten usw.
Ich erstelle auf diesem Programm (bei unter für private Maßstäbe extremen Sicherheitsanforderungen!) jedes Jahr mehrere Hundert Schlüsseldateien für Familie, Freunde, Usern aus mehreren Foren usw. Ich staune manchmal selbst, welche Kreise das zieht ... .

Und: Ich exportiere meine Schlüssel und Zertifikate so, dass sich immer in der Datei auch gleich meine beiden Herausgeberzertifikate befinden (PCA und Jahres-CA). Das bedeutet, wenn ein User ein Zertifikat von mir erhält, hat er nach dessen Import auch gleich die Herausgeberzertifikate mit importiert. Vertrauen aussprechen und fertig.

Für die verschlüsselte Mailkommunikation sind diese Zertifikate und Schlüssel völlig ausreichend. (Ich benutze sogar 4K-Schlüssel, was ggw. extrem übertrieben ist ... .) Du wirst ja wohl niemals mit einer völlig unbekannten Person eine verschlüsselte Mailkommunikation beginnen. Also kannst du dem zukünftigen Empfänger eine signierte Mail schicken, und schon hat er deinen öffentlichen Schlüssel (dein Zertifikat). Dann kannst du ihm persönlich oder auf anderem geeigneten sicheren Weg (meinetwegen auf CD per Post) seine Schlüsseldatei zukommen lassen. Das Export-Passwort Tage später telefonisch ausgetauscht, wenn es stimmt, ist auch gleich gesichert, dass alles "echt" ist. Das spart sogar den Austausch des Fingerprints. (Wir sind ja hier nicht "auf Arbeit" ... .)

Und noch ein Tipp:
Mit dem Add-on "Virtual Identity" ist ein alter Wunsch von mir in Erfollung gegangen!
Du kannst hier zu jeder Empfängeradresse (neben vielen anderen Optionen!) festlegen, ob die Mails verschlüsselt und/oder signiert werden. Einmal eingestellt (abgefragt beim Senden) bleibt das "ewig" so, und du kannst diese Einstellungen nie wieder vergessen. Auf diese Weise verschlüsselt z. Bsp. meine Frau, eine reine Userin, alle Mails an mich und viele andere Personen, ohne dass ihr das überhaupt bewusst ist. Das ist echt komfortabel!

So, nun reichts für heute

MfG Peter

Hi David,

du willst es noch einfacher haben?
IMHO ist S/MIME bereits einfacher zu handhaben und auch komfortabler als GnuPG. Aber ich will ja den uralten "Streit" der Vertreter der beiden Richtungen nicht wieder aktivieren. Wir wollen und müssen ja zusammenarbeiten, wenn wir unsere Privatsphäre noch eine Weile erhalten wollen. Noch dürfen wir in Deutschland unsere privaten Mails verschlüsseln. Keiner weiß, wie lange noch ... .

Ich halte mich natürlich (privat: freiwillig) weitestgehend an die Vorgaben, die für uns beruflich Gesetz sind:
- Gültigkeit eines Softwaretoken mit den Eigenschaften zur Signatur: ein Jahr. (Nur Chipkarten 3- max. 5 Jahre)
- Einschränkung der Zertifikate auf die zu nutzenden Funktionen (SSL-, S/MIME- oder sonstiges Zertifikat, Verschlüsselung und/oder Signatur usw.)
- Klare Anmerkungen im Zertifikat, die Verwendung und die Einschränkungen betreffend
- eine PCA mit längerer Gültigkeit (15 Jahre), jährlich eine Jahres-CA (2 Jahre)

Die Gültigkeit kannst du frei einstellen. Niemand hindert dich daran, die Userzertifikate länger gültig zu lassen. (Die GnuPG-Fraktion begrenzt ja die Gültigkeit ihrer Schlüssel auch so gut wie nie ... .)

Wichtig ist, dass du zumindest im "Netscape-Zertifikat-Kommentar" eine Anmerkung in folgender Art einträgst:
"XCA generatet Certificate. Nur für private Anwendungen und einfache Signaturen". Dient zur eigenen Absicherung.
Und du solltest dir auch der Verantwortung bewusst sein, dass du mit deiner Zertifizierung bestätigst, dass dort wo "Meier" drauf steht, auch "Meier" drin sein sollte. Du solltest dir also schon sicher sein, dass die im Zertifikat eingetragenen cn der Realität entsprechen - auch, wenn du dich mit dem o.g. Eintrag von jeder Verantwortung freisprichst.

Du kannst mir gern in einer PN deine Mailadresse zukommen lassen. Ich schicke dir dann per Mail meine Templates, die du dann nur noch etwas umkonfigurieren musst. Zumindest können sie dir als Anhalt dienen.

MfG Peter

Hi David,

zuerst einmal hoffe ich für dich, dass die in den Bildern eingetragenen Daten ausschließlich Dummies sind, denn sonst bekommst du bestimmt bald unerwünschte Post ... .

Das System "Julia Mail Office" kenne ich zwar nicht, aber gemäß deren Webseite sollte es damit problemlos funktionieren (wobei ich eine End-to-End-Verschlüsselung eindeutig einer Serverbasierten Lösung vorziehe).

Was du falsch gemacht hast?
Wenn ich das richtig sehe, dann hast du lediglich ein einziges selbst signiertes Zertifikat erzeugt und dieses exportiert. Dieses ist für die Anwendung immer nicht vertrauenswürdig!

Lösung:
Zuerst ein Root-Zertifikat für eine CA herstellen
Diese Root-CA zertifiziert entweder gleich die Nutzerzertifikate, oder - wie im professionellen Bereich üblich - nur die einzelnen Jahres-CA.
Dann die Jahres-CA erzeugen und diese von der root-CA zertifizieren lassen.
Und jetzt erstellst du die einzelnen Nutzer-Zertifikate und zertifizierst diese mit der jeweils gültigen Jahres-CA.

Zum Schluss exportierst du die Zertifikate.
- das Zertifikat der root-CA (nur den öffentlichen Teil, cer oder der, ohne Passwort!)
- wenn vorhanden das Zertifikat der Jahres-CA - " -
- die Zertifikate der Nutzer, wie oben, zur Übergabe an die "anderen"
- die Schlüsseldatei, ausschließlich zur eigenen Verwendung für den Inhaber, als .pfd oder .p12, weil mit secret-key mit Passwort

Die Schlüsseldatei kannst du so exportieren, dass die beiden Herausgeberzertifikate gleich mit in den Container übernommen werden. Das bedeutet, dass nach Import der pfx-Datei gleich die Herausgeberzertifikate mit importiert werden.
Importiert heißt aber keinesfalls, dass damit das Aussprechen des Vertrauens entfallen kann! Du spartst dir lediglich den vorherigen Import dieser Zertifikate.

MfG Peter

Hi David,

Zitat von "David.P"

Was bedeutet zum Beispiel CA -- ist das eine Abkürzung für "Certificate" oder für "Certificate Authority"?

Certificate Authority
Also die Stelle, welche Zertifizierungen vornehmen darf.
Zertifizierung bedeuteet hier, die elektronische Signatur der Userangaben, dessen öffentl. Schlüssels usw.

Zitat von "David.P"

Falls es Letzteres ist, was ist in diesem Fall die von Dir genannte "Root-CA"? Ich hätte eigentlich gedacht, das ist ein "Wurzelzertifikat", in diesem Fall wäre es aber eine "Wurzel-Zertifikatsbehörde", und was würde das dann bedeuten...?

Im realen Leben ist das wirklich oftmals eine Behörde (z. Bsp. für die Bundesverwaltung das BSI).
"Root-CA" und "Wurzelzertifikat" ist im Prinzip das gleiche. Es ist die CA, die mit ihren "Wurzelzertifikat", die Signatur aller darunter stehenden Zertifikate vornimmt. In einem richtigen Trustcenter ist diese oftmals körperlich getrennt und besonders gesichert. Denn, wenn das "Wurzelzertifikat" kompromittiert wurde, kann das Trustcenter dicht machen. Dann wird wohl nie wieder jemand von denen ein Zertifikat kaufen wollen ... .
Bei dir (und mir privat) läuft das natürlich alles auf einer Kiste bzw. in einem Programm.

Zitat von "David.P"

Wie stelle ich also "ein Root-Zertifikat für eine CA" her. Ich habe es mit der Vorlage "[default] CA" versucht, die ganzen persönlichen Daten eingetragen, ansonsten nichts verändert und das Zertifikat als *.crt exportiert. Schau ich mir dieses an, dann steht dort schon wieder "Unterzeichner unbekannt, nicht vertrauenswürdig". Dasselbe in einem Nutzerzertifikat, welches mit diesem von mir erstellten Root-Zertifikat unterschrieben ist: "Unterzeichner unbekannt, nicht vertrauenswürdig". Habe ich hier wieder was falsch gemacht, oder ist das normal, weil niemand den Zertifikaten Vertrauen ausgesprochen hat....?

Das Root- oder Wurzelzertifikat ist immer selbst signiert (selbst beim BSI).
Es hat eine längere Gültigkeit (10-15 Jahre), und es stehen auch keine persönlichen Daten drin, sondern eben die "der Firma".
Dieses Zertifikat dient ausschließlich der Signatur (wenn vorhanden bzw. gewollt) weiterer Unter-CAs (Jahres-CA), der Nutzer-Zertifikate und evtl. der Sperrlisten.
Das Vertrauen in dieses Wurzelzertifikat muss der Nutzer bewusst einstellen! => Bearbeiten, Haken setzen. Das ist der so genannte "Vertrauensanker". Erst wenn dieses einmalige Einstellen des Vertrauens erfolgt ist, werden auch alle darunter liegenden Zertifikate als vertrauenswürdig anerkannt.
Bei den etablierten Trustcentern übernimmt das Einstellen des Vertrauens der Hersteller des Browsers oder Mailclients. Deshalb stehen da schon so viele drin.

Zitat von "David.P"

Weiter im Text schreibst Du "Diese Root-CA zertifiziert entweder gleich die Nutzerzertifikate [...]. was heißt "zertifiziert", für mich bei der Erstellung des Nutzerzertifikats?

Zertifizieren heißt, dass du durch das ausgewählte Herausgeber- oder Wurzelzertifikat die weiteren Zertifikate unterschreibst.
Bei XCA ganz einfach gelöst: Du wählst das auf der erste Seite bei einem neuen Zertifikat einfach aus. Mehr ist das nicht. Wenn du dann zum Schluss auf OK drückst, wird das neue Zertifikat durch das ausgewählte Zertifikat signiert (=zertifiziert).
Hast es ja selbst erkannt:

Zitat von "David.P"

Bedeutet das, dass ich bei der Zertifikatserstellung mit XCA, im Tab "Herkunft" im Feld "Verwende dieses Zertifikat zum Unterschreiben" dann mein vorher erstelltes Root-Zertifikat auswähle --

Zitat von "David.P"

Wie exportiere ich also ordnungsgemäß die Schlüsseldatei?

So, wie du beschrieben hast:
Nur im Tab "Zertifikate" kann ich überhaupt den Export als .pfd oder .p12 auswählen. Aber dann wird ja nicht gemäß Deiner Anleitung die Schlüsseldatei, sondern das ganze Zertifikat exportiert.
Schlüsseldatei = Zertifikat + privater Schlüssel., Format .pfx oder .p12
Dort einstellen "mit CertificateChain", dann ist das Wurzelzertifikat mit drin.

Die reinen Zertifikate (also ohne privaten Schlüssel), exportiert im cer oder der-Format benötigst du, um sie deinen Mailpartnern zur Verfügung zu stellen. Also sowohl dein eigenes, als auch das Wurzelzertifikat.

Ein intelligentes Mailprogramm importiert beim Empfang einer signierten Mail diese Zertifikate automatisch. Trotzdem muss der Nutzer das Vertrauen in das Wurzelzertifikat immer bewusst einstellen, so lange es keines der etablierten Trustcenter ist. Erst nach dem Einstellen des Vertrauens funktionieren die Zertifikate, bzw. werden sie als vertrauenswürdig anerkannt. Trotzdem schadet es keinesfalls, wenn du dem Mailpartner auch die o.g. Zertifikate per Mail mitschickst. Nicht alle Mailclients sind intelligend genug. Hier muss der Empfänger eben die Zertifikate manuell installieren. Bei Produkten von M$ werden Zertifikatsdateien sogar als gefährliche Dateianhänge eingestuft und automatisdch gelöscht. Aber vor dem Versenden die Endung umbenennen hilft schon ... .

Letzter Hinweis:
Mozilla-Produkte bringen im Gegensatz zu M$-Produkten einen eigenen Speicher für Zertifikate und Schlüssel mit. Wenn du im Thunderbird so wie beschrieben, das Root-Zertifikat importiert und das Vertrauen ausgesprochen hast, dann dürften alle Zertifikate dieser CA als vertrauenswürdig gelten. Öffnest du allerdings ein Nutzerzertifikat direkt auf der WinDOSe, dann gilt das nicht! Hier musst du die Zertifikate zuerst über den Internet-Explorer importieren. Das Wurzelzertifikat natürlich zu den Vertrauenswürdigen. Dann klappt das auch mit der WinDOSe.

HTH

MfG Peter

Na, denk mal scharf nach ...

... wer oder was muss wissen, ob ich einem bestimmten Herausgeber von Zertifikaten vertrauen darf?

o
o
o
o
o

Richtig! Der Client, welcher das Zertifikat auswertet bzw. nutzt.

Bei einem WinDOSen-Nutzer mit Ausgugg ==> Zertifikatsspeicher des Betriebssystems (via I-Ex)
Bei einem Thunderbird-Nutzer (alle Betriebssysteme) ==> Zertifikatsspeicher des TB
Bei einem Firefox-Nutzer (Zertifikate für Webseiten) ==> ebenso
Bei einem ... usw.
Und wenn du selbst einen Webserver mit SSL betreibst, oder einen VPN-Server, dann auch die Server.

Und wenn du im Zertifikatsmanager des TB unter "Herausgeber" ein Zertifikat markierst, dann siehst du unten den Button "Bearbeiten". Mal gaaaaaaaanz vorsichtig draufklicken ... .