10
SMIME und XCA
Hallo Leute,
ich habe mich ein wenig bzgl. SMIME im Netz ungesehen und ich denke die Theorie ist soweit halbwegs begriffen. Jetzt möchte ich zur Tat schreiten und versuchen, meinen Emailverkehr mit meinem Firmenaccount zu verschlüsseln. Mit XCA habe ich schon häufig Zertifikate ausgestellt, allerdings lediglich für OpenVPN. Nun ist mir hier noch nicht so ganz klar, wer welche Dateien bekommt und welche nicht.
Also ich erstelle eine ROOT-CA. Dann erstelle ich ein Client Zertifikat, welches von der CA signiert wird. Habe ich das jetzt richtig verstanden, dass ich einfach das Client-Zertifikat in mein Outlook importiere, dem Gegner (Firmen Account) dann eine signierte Email schicke und schon hat er meinen öffentlichen Schlüssel zum verschlüsselten Versenden an mich? Was ist dann mit dem Root CA, brauch das auch noch der gegner zum Ablgeich der Gültigkeit des Client-Zertifikats? Oder kann ich eine PKCS#12 Datei mit Zertifikatskette ausstellen und das RootCA ist mit dabei?
Danke für einen kurzen Schubs in die richtige Richtung!
Gruß
ich habe mich ein wenig bzgl. SMIME im Netz ungesehen und ich denke die Theorie ist soweit halbwegs begriffen. Jetzt möchte ich zur Tat schreiten und versuchen, meinen Emailverkehr mit meinem Firmenaccount zu verschlüsseln. Mit XCA habe ich schon häufig Zertifikate ausgestellt, allerdings lediglich für OpenVPN. Nun ist mir hier noch nicht so ganz klar, wer welche Dateien bekommt und welche nicht.
Also ich erstelle eine ROOT-CA. Dann erstelle ich ein Client Zertifikat, welches von der CA signiert wird. Habe ich das jetzt richtig verstanden, dass ich einfach das Client-Zertifikat in mein Outlook importiere, dem Gegner (Firmen Account) dann eine signierte Email schicke und schon hat er meinen öffentlichen Schlüssel zum verschlüsselten Versenden an mich? Was ist dann mit dem Root CA, brauch das auch noch der gegner zum Ablgeich der Gültigkeit des Client-Zertifikats? Oder kann ich eine PKCS#12 Datei mit Zertifikatskette ausstellen und das RootCA ist mit dabei?
Danke für einen kurzen Schubs in die richtige Richtung!
Gruß
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 378548
Url: https://administrator.de/contentid/378548
Printed on: April 23, 2024 at 16:04 o'clock
10 Comments
Latest comment
Servus.
Wenn du stattdessen ein Zertifikat einer öffentlich annerkannten CA verwendest entfällt dieser Schritt natürlich weil dieser ja bereits vertraut wird.
Grüße Uwe
Zitat von @CyborgWeasel:
Habe ich das jetzt richtig verstanden, dass ich einfach das Client-Zertifikat in mein Outlook importiere, dem Gegner (Firmen Account) dann eine signierte Email schicke und schon hat er meinen öffentlichen Schlüssel zum verschlüsselten Versenden an mich?
Ja.Habe ich das jetzt richtig verstanden, dass ich einfach das Client-Zertifikat in mein Outlook importiere, dem Gegner (Firmen Account) dann eine signierte Email schicke und schon hat er meinen öffentlichen Schlüssel zum verschlüsselten Versenden an mich?
Was ist dann mit dem Root CA, brauch das auch noch der gegner zum Ablgeich der Gültigkeit des Client-Zertifikats?
Ja, wenn du das Zertifikat mit deiner eigenen CA signierst muss das Gegenüber der CA natürlich erst mal vertrauen, dazu muss er das CA Zertifikat in den vertrauenswürdigen Speicher für Stammzertifizierungsstellen importieren damit Outlook dem Zertifikat vertraut und es als gültig ansieht und auch so markiert!Oder kann ich eine PKCS#12 Datei mit Zertifikatskette ausstellen und das RootCA ist mit dabei?
Das reicht nicht, wie oben geschrieben muss er dieses dann erst noch am Rechner als vertrauenswürdige CA deklarieren indem er es in den CA Speicher importiert.Wenn du stattdessen ein Zertifikat einer öffentlich annerkannten CA verwendest entfällt dieser Schritt natürlich weil dieser ja bereits vertraut wird.
Danke für einen kurzen Schubs in die richtige Richtung!
Immer gerne.Grüße Uwe
Dazu sollte man das hier auch nochmal lesen:
https://www.heise.de/security/meldung/PGP-E-Mail-Verschluesselung-akut-a ...
Besonders S/MIME gilt jetzt als unrettbar kaputt. Warum also noch der Aufwand für ein schon totes Pferd...?
https://www.heise.de/security/meldung/PGP-E-Mail-Verschluesselung-akut-a ...
Besonders S/MIME gilt jetzt als unrettbar kaputt. Warum also noch der Aufwand für ein schon totes Pferd...?
Irgendwer muss ja der NSA noch was an Klartext liefern 
.
.
Zitat von @aqui:
Dazu sollte man das hier auch nochmal lesen:
https://www.heise.de/security/meldung/PGP-E-Mail-Verschluesselung-akut-a ...
Besonders S/MIME gilt jetzt als unrettbar kaputt. Warum also noch der Aufwand für ein schon totes Pferd...?
Dazu sollte man das hier auch nochmal lesen:
https://www.heise.de/security/meldung/PGP-E-Mail-Verschluesselung-akut-a ...
Besonders S/MIME gilt jetzt als unrettbar kaputt. Warum also noch der Aufwand für ein schon totes Pferd...?
Ich bin da nicht ganz bei Dir.
Die Meldung wurde nach meinem Kenntnisstand dahingehend relativiert, dass das Problem EFail nicht im Verschlüsselungsalgorithmus zu suchen sei, sondern nur in den Programmen.
Es gibt Anfälligkeiten bei bestimmten Clients und einer bestimmten Art, wie E-Mails aufgebaut sein müssen, so dass eine temporär entschlüsselte E-Mail abgreifbar wird. Das kompromittiert aber nicht den Algorithmus.
Ich setze bei uns auf OpenPGP und fahre damit gut.
Wenn XMSS in ersten Implementierungen vorliegen wird, werde ich das ausgiebig testen.
@colinardo: Super, danke es hat wunderbar geklappt. Aber noch eine Frage, bei PKCS#13 Export, ist da der Private-Key nicht auch mit dabei? Den sollte man doch nicht aus der Hand geben, oder?
Zitat von @aqui:
Dazu sollte man das hier auch nochmal lesen:
https://www.heise.de/security/meldung/PGP-E-Mail-Verschluesselung-akut-a ...
Besonders S/MIME gilt jetzt als unrettbar kaputt. Warum also noch der Aufwand für ein schon totes Pferd...?
Dazu sollte man das hier auch nochmal lesen:
https://www.heise.de/security/meldung/PGP-E-Mail-Verschluesselung-akut-a ...
Besonders S/MIME gilt jetzt als unrettbar kaputt. Warum also noch der Aufwand für ein schon totes Pferd...?
Der Artikel ist mir tatsälich bekannt. Aber es ist zumindest besser als gar nicht verschlüsselt, ich denke damit sollte wengistens dem Datenschutz genüge getan sein (f. Steuerberater o.ä.).
Vermutlich nicht, denn weil nun die ganze Welt ja weiss wie man insbesondere S/MIME schnell und einfach knacken kann, kann ja logischerweise von "Datenschutz" keinerlei Rede mehr sein.
Das wird wohl auch ein seriöser Datenschützer so sehen.... Aber egal, wenn du damit gut schlafen kannst ist das was anderes. Sicher ist es jetzt nicht mehr...
Das wird wohl auch ein seriöser Datenschützer so sehen.... Aber egal, wenn du damit gut schlafen kannst ist das was anderes. Sicher ist es jetzt nicht mehr...
OK, was wäre dein Alternativvorschlag?
EDIT: Wenn die Email zusätzlich noch signiert wird, sollte doch eine Manipulation erkennbar und damit das Problem behoben sein, oder habe ich was übersehen?
EDIT: Wenn die Email zusätzlich noch signiert wird, sollte doch eine Manipulation erkennbar und damit das Problem behoben sein, oder habe ich was übersehen?
Zitat von @CyborgWeasel:
@colinardo: Super, danke es hat wunderbar geklappt. Aber noch eine Frage, bei PKCS#13 Export,
Du meinst PKCS12.@colinardo: Super, danke es hat wunderbar geklappt. Aber noch eine Frage, bei PKCS#13 Export,
ist da der Private-Key nicht auch mit dabei?
PKCS12 ist ein Container-Format und wenn du beim Export wählst das der private Schlüssel mit exportiert werden soll landet dieser ebenfalls zusammen mit dem öffentlichen Teil im Container. Der Container wird seinerseits mit einer Passphrase versehen.Den sollte man doch nicht aus der Hand geben, oder?
Absolut richtig, der private Key gehört niemals nicht weitergegeben!! Gibst du ihn weiter ist dein Schlüssel nicht mehr geheim und jeder kann damit Mails in deinem Namen signieren.Weitergegeben wird immer nur der öffentliche Teil deines Zertifikates, ob als crt, der, pem or whatever, die Formate kannst du leicht bei Bedarf per XCA oder OpenSsl umwandeln.
Du meinst PKCS12.
Ja, sorry, Tippfehler
Weitergegeben wird immer nur der öffentliche Teil deines Zertifikates, ob als crt, der, pem or whatever, die Formate kannst du leicht bei Bedarf per XCA oder OpenSsl umwandeln.
Ja, XCA kenne ich. Ich tu mir nur noch etwas schwer mit den Zertifikatformaten. Ich werde einfach für die Weitergabe nur CRT verwenden, dann bin ich sicher dass der private Schlüssel nicht dran hängt. Bzw. habe ich eben gemerkt, dass hier XCA auch nicht nach einer Passphrase fragt. Schlussfolgerung: Frägt XCA nach einem Passwort, dann vorsicht mit der Weitergabe (je nach Zweck natürlich).
Danke nochmals!!
Gruß
