X.509-Zertifikate, Erzeugung und Anwendung

  • Hallo Freunde,


    im Beitrag #197 wurde ich gebeten, einmal etwas zu diesem Thema zu schreiben, und dieser Bitte komme ich gern nach.
    Eine übliche "Schritt für Schritt -Anleitung" ist es nicht, aber ich denke, dass ich doch trotzdem einiges an evtl. noch nicht vorhandenem Hintergrundwissen zu diesem Thema rüberbringen kann. Ich beschränke mich auch ganz bewusst auf dieses Hintergrundwissen und versuche auch, dieses für Laien verständlich zu erklären. Wer mehr wissen will, kann gern fragen oder die Suchmaschine seines Vertrauen nutzen.


    Grundsätzliches zu TLS/SSL und X.509:
    Für die Sicherung der diversen Verbindungen zu (Web-, ftp-, Mail- usw.- )Servern verwenden wir üblicherweise Transport Layer Security (Früher "SSL" genannt) Und dabei werden X . 509-Zertifikate eingesetzt.


    Diese Zertifikate dienen im Zusammenspiel mit TLS/SSL zwei Aufgaben:
    1.) Der Verschlüsselung der Verbindung zum jeweiligen Server, indem damit die eigentlichen Session-Keys für die symmetrische Verschlüsselung gesichert übertragen oder ausgetauscht werden.
    2.) Der sicheren Authentisierung des mit dem Client verbundenen Servers.


    Eine Bedingung, dass dies funktioniert, ist der aufzubauende so genannte "Vertrauensbaum". Dazu muss das oberste Herausgeberzertifikat (root-Zertifikat) des Herausgebers der eigentlichen Server- oder auch Nutzer-Zertifikate im jeweiligen Betriebssystem des Clients bzw. bei Clients, welche den Zertifikatsstore des Betriebssystems nicht nutzen und einen eigenen Zertifikatsstore mitbringen wie zum Bsp. der Firefox oder der Thunderbird, in diesem unter "vertrauenswürdige Herausgeber" installiert sein.


    Wird bei der Initiiierung einer TLS-gesicherten Verbindung dem Client vom Server dessen öffentliches Serverzertifikat angeboten, dann prüft der Client, ob die Signatur dieses Serverzertifikates mit genau dem richtigen lokal gespeicherten Herausgeberzertifikat erfolgreich bestätigt werden kann. Wenn alles stimmt, wird die verschlüsselte Verbindung aufgebaut, ein "https" im Browser angezeigt und üblicherweise auch alle anderen Merkmale, mit denen die Browser dem User eine gesicherte Verbindung demonstrieren.
    Geht diese Prüfung schief, weil entweder das Server- oder gar das Herausgeberzertifikat abgelaufen sind, letzteres nicht vorhanden ist, falsche Daten im Serverzertifikat stehen oder gar ein "Man in the Middle" sich in die Verbindung eingeklinkt hat, dann wird das dem User sehr deutlich angezeigt.
    Und genau das ist damit gewollt!



    Das Problem mit dem "unbekannten Herausgeber":
    Seriöse TrustCenter sind Firmen, welche in einer nach sehr hohen Sicherheitsstandards gebauten und betriebenen Infrastruktur die o.g. X.509-Zertifikate erzeugen. Dabei werden von diesen TC Identitätsprüfungen der antragstellenden Personen (bei Personen-Zertifikaten, Identitätskarten usw., siehe dt. Signaturgesetzt § 5) mit der Pflicht zum persönlichen Erscheinen in einer Registrierungsstelle (aber auch mit Postident - Deutsche Post) und Vorlage eines amtlichen Lichtbildausweises durchgeführt. Das TC garantiert also, dass die im Zertifikat genannte Person mit dem Antragsteller identisch ist!
    Gleiches erfolgt bei so genannten Zertifikaten für "Technische Einrichtungen" wie eben die öffentlichen Server. Hier muss bei der Antragstellung eine dazu befugte Person der Registrierungsstelle einen notariell bestätigten Auszug aus dem Handelsregister vorlegen, aus welchem hervorgeht, dass seine Firma eben den Server *****.tld betreibt. Somit ist dem Nutzer auch bei jedem Zugriff bestätigt, dass er wirklich mit dem Server seiner Bank usw. verbunden ist.
    (Zumindest sollte dies so sein, aber das ist hier nicht das Thema.)


    Jetzt müsste sich eigentlich ein Nutzer darauf verlassen können, dass nur die Herausgeberzertifikate von diesen o.g. seriösen TC in seinem Betriebssystem, in seinem Browser oder seinem Mailclient von deren Herstellern vorinstalliert werden. Leider ist das nicht immer der Fall! Es gibt auch Herausgeber, die in den Betriebssystemen gelistet sind, obwohl man von denen ohne jegliche richtige Identifikation (oder nur mit einer E-Mailadresse!) ein Server- oder Personenzertifikat bekommen kann. Eigentlich dürfte das nicht sein, denn damit wird die gewollte Sicherheit ausgehebelt. (Wer schaut schon auf die Klassifizierung der Zertifikate?) Derartige Herausgeber müsste der Anwender eigentlich bewusst (mit dem Bewusstsein, dass sie eben Zertifikate ohne Authentisierung herstellen!) manuell importieren.
    Ob hier Bequemlichkeit/Akzeptanzgründe oder gar Geld eine Rolle spielt, weiß ich nicht ... . Auf jeden Fall sollte der Anwender wissen, das es dieses gibt!


    Wenn man sich von einem seriösen TC ein "offizielles" Server- oder Personenzertifikat herstellen lässt, dann muss man dafür entsprechend zahlen. Ich habe versucht, den personellen (Identifizierung, Rollen- und Rechteverteilung, 4-Augenprinzip, usw. im TC ...) und materiellen (Gebäude, IT-Sicherheit) Aufwand anzudeuten. Ich kann nur versichern, dass die Kosten gerechtfertigt sind.
    Wenn ich einen "offiziellen" öffentlich ereichbaren Web- usw.- Server ins Netz stellen will, dann muss ich mir ein Zertifikat kaufen. Eine Firmen-Webseite mit einem selbstgebastelten (selbstsignierten) Zertifikat ist einfach nur unprofessionell und blamabel.



    Die Lösungen für "nicht offizielle", öffentlich erreichbare oder gar für nur einen begrenzten Personenkreis bestimmte Server:
    Selbstverständlich muss man nicht ein (teueres) offizielles Zertifikat kaufen, wenn man seinen privaten Server vor unbefugtem Mitlesen schützen will. Das ist keinesfalls erforderlich - die gewünschten Funktionen erfüllen auch selbst signierte Zertifikate.
    Und wie wir oben gelesen haben, müssen (!) die Browser der Empfänger bei der ersten Verbindungsaufnahme eine Sicherheitswarnung anzeigen!


    Es gibt mehrere Möglichkeiten der Produktion eigener Zertifikate und Schlüssel, man sollte überlegen, was man erreichen will:

    • Das per openssl-script direkt auf der Maschine erzeugte selbstsignierte Zertifikat.
      Dabei wird mit einer Zeile Code ein Zertifikat und ein private-Key erzeugt und gleich an der richtigen Stelle lt. Konfigurationsdatei eingefügt. Funktionell, super schnell erzeugt, schlicht und einfach ... .
      Das ist die einfachste Lösung, wenn man der einzige Nutzer ist oder nur eine Handvoll persönlich bekannter Nutzer auf den Server zugreifen sollen. Denen kann man persönlich mitteilen, dass sie ohne Bedenken einfach eine so genannte "Ausnahmegenehmigung" hinzufügen müssen. Weil wir ja kein Herausgeberzertifikat haben, hebeln wir (bewusst!) mit dieser Ausnahmegenehmigung weitere Prüfungen aus.
    • Mit den in openSSL beschriebenen und bereit gestellten Scripten eine eigene CA und darauf weitere Zertifikate und Schlüssel erzeugen.
      Das ist die Lösung für die Konsolen-Freaks unter uns. Wir erzeugen eine eigene CA ("<users>-Privat-CA") mit einer Gültigkeit von 10-15 Jahren und dann mit dieser CA die benötigten Server- oder auch Personen-Zertifikate für die Mailverschlüsselung mit S/MIME. Die Zertifikate kann man per Mail seinen Nutzern übersenden, man kann diese aber auch auf seiner eigenen Webseite sauber anbieten. (Näheres siehe 3.) Die Vorteile dieser Methode sind, dass man zum einen viele Zertifikate unter einer (eigenen) root herstellen kann, und dass man hier ein eigenes Herstellerzertifikat hat, welches man 1x in den Zertifikatsstore seines Betriebssystems, Browsers und Mailclients importieren und als vertrauenswürdig einstufen kann. Das machen wir bewusst (!) und dann läuft alles weiter, so wie bei den "eingebauten" Herausgeberzertifikaten.
    • Die Nutzung guter grafischer Tools wie zum Beispiel "Tiny-CA" oder noch besser: "XCA" (Natürlich auf dem PC zu installieren :D)
      Irgendwann habe ich festgestellt, dass die stürmisch gewachsenen Anforderungen an meine kleine "Konsolen-CA" den Bedarf nicht mehr decken konnten. (=> S/MIME mit eigenem Zertifikat • Thema anzeigen ...) Da habe ich dann das Programm "XCA" gefunden. Dieses gibt es nicht nur für mein Betriebssystem Linux, sondern auch für die WinDOSe.
      Das Schöne an diesem Programm ist (im Gegensatz zu den vorhandenen weiteren Programmen), dass ich mit XCA eine Reihe von so genannten Templates (Vorlagen) anlegen kann. Also je eins für meine jeweilige "Jahres-CA", eins für S/MIME-Nutzer, für openVPN, SSL-Server, SSL-Clients usw., je nach dem, was ich eben herstellen will. Ich kann ein Template auswählen, und das Ergebnis ist dann das gewünschte. Fast wie im TrustCenter ... .
      DAS ist die Lösung für "Massenproduktion" oder auch für Leute, denen die Konsole nicht zum Freund geworden ist.
      Auf meiner Webseite habe ich (ja, in einem nicht verlinkten "unsichtbaren" Bereich) das Zertifikat meiner root-CA und aller meiner Jahres-CA incl. der jeweiligen Hashwerte, aber auch meine regelmäßig erzeugten Sperrlisten (crl) veröffentlicht. Ebenso ist dort eine bebilderte Anleitung für den Import der Zertifikate in den Thunderbird zu finden.
      (Jahres-CA, Sperrlisten usw. müssen aber nicht unbedingt sein. root- und Server-Zertifikat reichen auch aus!)


    Produktion von Zertifikaten mit XCA:
    Hier wollte ich eigentlich mit einer bebilderten Anleitung für ONU kommen. Zum Glück habe ich vorher die Suchmaschine meines Vertrauens bemüht und - erwartungsgemäß - ein paar gute Anleitungen gefunden. Die im folgenden gepostete Anleitung entspricht in etwa dem, was ich sonst "produziert" hätte. Ein paar wenige Anmerkungen folgen dazu später.
    Da ich die genannte Anleitung einfach mal so "guttenborge", poste ich hier den Link, so wie ich ihn als ersten bei "gg" mit Suchwort "xca anleitung"gefunden habe:
    xca -openvpn - Optik Berndt Auch die weiteren Ergebnisse der Suche sind zielführend.


    Folgende Einstellungen mache ich anders oder folgende Ergänzungen empfehle ich:
    - CA: 10-15 Jahre Gültigkeit
    - Endnutzer: 1 (i.W. ein!) Jahr Gültigkeit (Das ist die vom BSI vorgegebene Gültigkeitsdauer für Softwareschlüssel. Für uns natürlich nicht bindend, aber sinnvoll!)
    - Als Signaturalgorithmus SHA-256 oder höher (Evtl. testen, was die Nutzprogramme können! Nicht alle können SHA-512, SHA-256 reicht aber allemal.)
    - Als Schlüssellänge 4096 bit. (Begründung muss ich keinem geben, der die letzten Monate das pol. Geschehen verfolgt hat.)
    - Und dann empfehle ich noch folgende Bemerkung (Comment im Reiter "Netscape"):
    "XCA generated Certificate. Nur fuer private Nutzung und "einfache Signaturen"!
    Dieser Kommentar dient der eigenen Absicherung, wenn man so wie ich jedes Jahr ein paar Hundert Zertifikate für andere Personen erzeugt.


    Jetzt müssen die erzeugten Zertifikate und Schlüssel nur noch in die entsprechenden Programme "hineingebracht" werden. Hier als Beispiel in einen owncloud-Server mit enginx:

    • Informieren, welches Format die Programme erwarten und wohin diese Zert./Keys zu kopieren sind. (Ist doch immer in der jeweiligen Anleitung beschrieben ... .)
      Es gibt mehrere Speicherformate für Zertifikate, dabei ist der eigentliche "wirksame Inhalt" immer gleich. Es unterscheiden sich aber die Dateiendungen und der sichtbare Inhalt. In unserem Fall sind es beides Dateien im PEM-Format (BASE-64 encodet, also mit einem Editor zu betrachten) mit den Endungen ".pem" für das Zertifikat und ".key" für den private Key.
    • Danach zuerst das Zertifikat (= nur der öffentliche Teil) als "PEM with Certifikate chain", Endung: .crt und danach den (private-)Key als PEM exportieren.
      Nun musst du nur noch die Dateien umbenennen (oder gleich beim Export machen) in "cert.pem" bzw. "cert.key" und in den vorgegebenen Ordner kopieren sowie dort die Besitzverhältnisse und Rechte anpassen.


    Kleiner Tipp für die, die es das erste mal machen: Neben dem Lesen der Anleitung einfach mal ein Zertifikat mit dem in fast allen Anleitungen zu findenden Script erzeugen. Dann kannst du in den Zielordner gehen, und findest die erzeugten Dateien aber auch deren Besitzer und Rechte. Diese löschen und durch die deiner CA ersetzen.


    Jetzt musst du nur noch das eigene Herausgeber-Zertifikat (also im Beispiel "<users>-Privat-CA.crt", auch .pem, oder .der sind fast immer möglich) in die Zertifikatsstores der Betriebssysteme (bei Nutzung von Internet-Explorer) bzw. der Browser (Firefox u.a.) importieren. Es handelt sich um ein öffentliches Zertifikat, du kannst (musst) diese frei verteilen, wenn deine Nutzer diese importieren sollen und ohne Ausnahmegenehmigung und Fehlermeldung deinen Server nutzen wollen.


    Das wars dann schon.
    Wie immer: Fragen, Hinweise und Kritiken sind erwünscht.



    MfG Peter

  • Hallo Peter,


    danke für die ausführliche Aufklärung, die wird man so kompakt wohl kaum woanders finden!


    Meine Fragen:


    1. Es ist nicht möglich, selbst ein root Zertifikat zu erstellen, daß allgemein von den üblichen Browsern OHNE zusätzliche Bestätigung anerkannt wird?


    2. Falls ja, wo bekommt man zu einem angemessenen Preis die Zertifizierung nicht nur für den privaten Gebrauch? Soweit ich bisher gesehen habe, ist das für die anerkannten Zertifizierer ein recht einträgliches Geschäft ohne viel Aufwand. :(


    Danke und Gruß, mmi

  • Hallo mmi,


    zu 1.)
    Ja, das ist so, und das ist auch gut so! WOWEREIT!
    Nur ein "Zertifikatsdiensteanbieter" ("ZDA" oder "Trustcenter"), welcher nach bestimmten und sehr hohen Kriterien arbeitet, darf (oder dürfte) von den Herstellern der Betriebssysteme und Browser/Mailclients vorinstalliert werden. Es sollte so sein, dass ein Nutzer sich voll darauf verlassen kann ("können sollte" ...), dass die Identität einer antragstellenden Person bzw. eines Serverbetreibers zuverlässig geprüft wird. Nur so macht das ganze einen Sinn.
    Wie ich schon angedeutet habe, ist dies leider nicht immer so. So manchen gelisteten Herausgeber würde ich nicht dazu zählen. Und dass jeder private Herausgeber (so wie meine eigene "Privat-CA" [Blocked Image: http://1.1.1.5/bmi/www.forum-raspberrypi.de/images/smilies_green/icon_biggrin2.gif]) aufgenommen wird, ist ein absolutes No-Go. Zum Glück gibt es da eine nicht geringe finanzielle Schranke, welche erst mal übersprungen werden muss. Die Hersteller der o.g. BS und Programme lassen sich das gut bezahlen.
    Auch wenn das so manche Firmen locker können - siehe oben ... . Ich würde dort viel härtere Kriterien anwenden!


    BTW: Ich habe in den 10 Jahren, in denen ich "für Freunde und Bekannte", selbstverständlich kostenfrei, Zertifikate und Schlüssel produziere festgestellt, dass man sich Vertrauen auch erarbeiten kann.


    zu 2.)
    Zuerst einmal möchte ich deutlich zurückweisen, dass es "für die anerkannten Zertifizierer ein recht einträgliches Geschäft ohne viel Aufwand" ist!
    Das trifft nämlich überhautpt nicht zu!
    Ein seriöser, nach dem dt. Signaturgesetz arbeitenden ZDA, muss einen enormen materiellen, finanziellen und personellen Aufwand treiben, um Zertifikate erstellen zu dürfen, welche für die qualifizierte el. Signatur zugelassen werden. Nicht umsonst sind einige Anbieter schon wieder vom Markt verschwunden (Bsp.: der IMHO erste dt. Anbieter, das TrustCenter Hamburg ist so gut wie weg. Sehr schade ...) Ich kenne die wichtigsten dt. Trustcenter durch persönliche Besuche und weiß, wovon ich schreibe.
    Um deine eigentliche Frage zu beantworten, müsste ich Werbung betreiben. Das darf und will ich keinesfalls!
    Die Suchmaschine deines Vertrauens ist dein Freund ... .


    Du musst genau überlegen, was du bezweckst.
    Wenn du privat einen öffentlichen Server mit einem Zertifikat für TLS ausstatten willst, dann reicht doch wohl ein Kostnix-Zertifikat von einem der gelisteten "Billigheimer". Du musst doch niemandem beweisen, dass dein privater Server wirklich identisch ist. Bist doch keine Bank ... .
    Auch ein Zertifikat von einem seriösen Anbieter nach einfacher Identifizierung bekommst du schon für ein paar Euronen.
    Und für die meisten privaten Anwendungen reicht immer noch ein selbstsigniertes Zertifikat und die Veröffentlichung der Dateien/Hashwerte auf der eigenen Webseite.
    Und solltest du eine Bank gründen wollen [Blocked Image: http://1.1.1.1/bmi/www.forum-raspberrypi.de/images/smilies_green/icon_lol.gif] ... .



    MfG Peter

  • Hallo Peter,


    danke für die Aufklärung - wirklich intensiv habe ich mich damit noch nicht beschäftigt.


    Klar, für den Privatbereich habe ich auch selbst erstellte, was auch völlig genügt.
    Ich dachte aber oben schon an ein gewerblich nutzbares - in erster Linie für https Verbindungen auf einem Webserver. Falls Du dafür eine Empfehlung hast, kannst Du sie mir gerne auch per PN schicken - Schleichwerbung muß ja nicht sein. ;)


    Gruß, mmi

  • halohalo,
    danke für die Anleitung, bzw. Erklärung.


    Um das nochmal auf den Punkt zu bringen:
    - Um seinen eigenen Webserver mit https zu erreichen und KEINE Vertrauensmeldung zu erhalten gibt es keine kostenlose Lösung.



    Ist das so korrekt? Weil auch nach 2 mal lesen ist mir das nicht ganz klar.
    Verstehen tue ich es ... aber ob es nicht doch eine Lösung gibt Frage ich mich.


    Da mein Owncloud nur eine private ist, werde ich es selbstsignieren und in meien browsern geräten installieren ... aber schick finde ich das nicht.

    Lasst uns die Welt besser machen!

  • Hallo raspiServerBastler,


    doch, es gibt auf dem "freien Markt" einige wenige TrustCenter, ich nenne sie gern "Billigheimer", welche - mit welchem Trick auch immer - in manchen Betriebssystemen, Browsern und Mailclients gelistet sind. Diese stellen dann für jedermann ohne Identitätsprüfung (als Werbegeschenk?) Zertifikate aus, welche keine Fehlermeldung verursachen. Das Herausgeberzertifikat steht ja im Zertifikatsstore des BS/Browsers/MUA.


    ==> die Suchmaschine deines Vertrauens ist dein Freund, "X.509 kostenlos" könnte das Suchwort sein.


    Welches Vertrauen du einem solchen, ohne saubere Identifizierung produzierten Zertifikat entgegenbringen willst, musst du selber entscheiden.
    Das gleiche gilt auch für so manches TrustCenter selbst, wenn ich mir deren Policy (das veröffentlichte Regelwerk, nach dem sie arbeiten, wenn sie denn überhaupt eine haben und veröffentlichen) und auch den Standort desselben ansehe.



    MfG Peter

  • /dev/null


    Erst einmal ein fettes "Dankeschön" für deinen Artikel!
    :danke_ATDE:


    Leider muss ich auch immer wieder in meinem Bekanntenkreis auf die Antwort stoßen:


    "Warum denn verschlüsseln, ich hab doch nichts zu verbergen, kann doch jeder lesen ... "


    Aber Briefe verschicken sie trotzdem noch anstatt einer Postkarte ...


    "Liken und Co." können sie, sind aber zu "simpel" ihre e-Mails zu konfigurieren :(


    Ob nun S/Mime oder GnuPG (Enigmail oder PEP), sie interessieren sich einfach nicht dafür :(


    Heute habe ich "per Zufall" gesehen, dass sich auch TinyCA per apt-get installieren lässt.


    Code
    sudo apt-get install tinyca


    Wie kann man nun seinen Bekanntenkreis motivieren Zertifikate oder GnuPG für die Verschlüsselung ihrer e-Mails zu nutzen?


    Ich bin echt ratlos :(

  • Hallo


    Was meinst du mit:

    Code
    ... dass sich auch TinyCA per apt-get installieren lässt.

    ?


    Selbstverständlich ist TinyCA in so ziemlich jedem Linux-Repo drin. Und es ist auch einsdreifix installiert. Selbst auf dem RasPi.
    Aber ich hoffe doch mal, dass du niemals auf die Idee kommst, eine CA auf einem dauerhaft frei im Netz hängenden und auch nicht besonders gut gesicherten Serverchen zu betreiben. Dort wird eine CA nicht benötigt, und rein aus Gründen der Sicherheit ist das auch das absolut schlechteste, was man machen kann. (Es sei denn, du willst einen RasPi nur als reine CA betreiben, und ihn im Jahr vlt. zwei oder drei mal einschalten und für den Rest des Jahres sicher in einer Geldkassette verwahren... .)
    Ich schrieb ja weiter oben schon, dass die Betreiber eines TrustCenters einen immensen und kaum nachvollziehbaren Aufwand zum Schutz ihrer Infrastruktur betreiben (müssen). Das kann niemals ein Privatnutzer und auch kein KMU leisten. Ist ja auch nicht notwendig. Aber gewisse Schutzmaßnahmen musst du schon treffen, wenn du ernsthaft Zertifikate und Schlüssel herstellen willst.


    Und jetzt weichen wir von eigentlichen Thema ab und werden [OT].
    Es stimmt leider, die "Masse" der Menschen bildet sich ein, nichts zu verbergen zu haben. Die "Generation Facebook" hat ja wohl schon vollkommen auf ihre Privatsphäre und vor allem den Schutz der selbigen verzichtet. Die Menschen haben einfach (noch) nicht gelernt -oder schon wieder vergessen - dass Privatsphäre ein schützenswertes Gut ist. Und sie lassen sich auch nicht vom Gegenteil überzeugen. Leider.
    Ich habe große Hoffnungen gehabt, dass die Enthüllungen eines gewissen Herrn Snowden da etwas bewirken. Falsch gedacht! Frag mal deine Bekannten, ob sie einen Menschen dieses Namens kennen ... .


    Das Motivieren dieser Menschen ist ein Vorgang, der sehr viel Kraft, Überzeugungsfähigkeit und Zeit kostet. Ich bin diesen Weg gegangen. Dafür "muss" ich jetzt natürlich in Kauf nehmen, dass ich mit meiner "Privat-CA" jedes Jahr ein paar Hundert (!) Zertifikate oder Schlüsselpaare erzeuge. Ich betrachte es als meinen kleinen persönlichen Beitrag, um die Privatsphäre in dieser von Beschnüffelung geprägten Welt zumindest teilweise zu erhalten.


    Code
    Ob nun S/Mime oder GnuPG ...


    ... ist völlig egal, Hauptsache, du machst überhaupt etwas in dieser Richtung.
    [/OT]



    MfG Peter

  • Aber ich hoffe doch mal, dass du niemals auf die Idee kommst, eine CA auf einem dauerhaft frei im Netz hängenden und auch nicht besonders gut gesicherten Serverchen zu betreiben.


    Hatte ich nicht vor. Es geht mir darum, meinen Bekannten, eine einfache Möglichkeit zum Verschlüsseln ihrer E-Mails anzubieten.


    Unter z.B. Thunderbird gibt es ja Enigmail (GnuPG und S/Mime) welches ich persönlich ziemlich einfach finde, was das Erzeugen von Schlüsselpaaren und das Versenden des public Keys angeht.


    Bei den Zertifikaten fängt das Problem schon an.


    Woher nehmen/kaufen?


    Darum die Idee, die Zertifikate selber zu erstellen.


    Hatte ein bisschen gedauert bis ich verstanden hatte, das man trotz

    Code
    sudo dpkg-reconfigure ca-certificates


    dem Mail-Client, im eigenen System, die CA noch einmal manuell hinzufügen muss.


    Deinen Bericht hatte ich erst im Nachhinein gefunden :)


    Wenn ich jetzt für eine Bekannte ein Zertifikat erstellt habe, dann braucht sie doch nur ihr eigenes mit dem Schlüssel und das des Servers, richtig?

  • Hallo duno,


    Wenn du dich mehr für dieses Thema interessierst, dann kannst du dich gern im dt. Thunderbird-Forum (http://www.thunderbird-mail.de) informieren. Ich denke mal, dass ich dort als der sich für IT-Sicherheit und Kryptologie verantwortlich fühlende Moderator so ziemlich alle Fragen beantwortet habe. Zumindest, was S/MIME betrifft. (Mit PGP/GnuPG befasse ich mich nicht mehr.)


    Auch, warum niemals "Home-CAs" und eigentlich auch keine sonstigen "Billigheimer" in den Betriebssystemen sowie Browsern und MUA mit eigenem Zertifikatsstore (eben die Mozillen) vorinstalliert sein dürften, dürfte jetzt klar sein. Der Empfänger eines fremden Zertifikates (einer von einer fremden Person signierten E-Mail oder beim Betreten einer tls-gesicherten Webseite) möchte sich sicher sein, dass die signierende Person oder der Betreiber der Webseite authentisch sind. Deshalb verlangt das dt. Signaturgesetz in seinem §5 die "sichere Identifizierung der antragstellenden Person" durch Vorlage seines "amtlichen Lichtbildausweises" und Unterschriftsleistung nach dem 4-Augenprinzip und bei Serverzertifikaten zusätzlich durch Vorlage eines notariell beglaubigten Auszuges aus dem Handelsregister, aus dem zweifelsfrei hervorgehen muss, dass diese Firma eben jenen Server betreibt.
    Leider wird auf diesem Gebiet mitunter recht schlampig gearbeitet. (Auch wenn ich mir das in Deutschland aufgrund der bestehenden Gesetzeslage nicht so recht vorstellen kann.) Auf jeden Fall tauchen in den vorinstallierten Herausgebern so manche TrustCenter auf, welche eigentlich dort nicht stehen dürften. Auch gibt es dort einen beliebten Herausgeber von Kostnix-Zertifikaten, welcher unter Insidern als der Ableger eines bekannten ausländischen Geheimdienstes zählt ... .


    Wenn du für Familie/Freunde/Bekannte Schlüssel und Zertifikate herstellst, spielt das aber alles keine Rolle. Du weißt ganz genau, wer diese Menschen sind und diese kennen dich genau so. => Beidseitiges Vertrauensverhältnis! Damit können alle Beteiligten dein eigenes Herausgeberzertifikat und die persönlichen Zertifikate der anderen mit ruhigem Gewissen in ihre Betriebssysteme/Browser/MUA importieren und denen das Vertrauen aussprechen.
    Auch wenn du auf deinem Raspberry Pi (um endlich mal wieder auf dieses Forum zurück zu kommen, bevor mir hier ein Mod wegen dauerhaftem [OT] einen Platzverweis erteilt ;-)) bestimmte Angebote/Dienste für einen kleinen bekannten Nutzerkreis mit einer TLS-gesicherten Verbindung beteitstellst, kannst du das problemlos mit einem selbstsignierten Zertifikat machen. Du kannst den gewollten Nutzern ja auf geeignete Weise per E-Mail oder auf deiner sonstigen Webseite dein Herausgeberzertifikat, dein eigenes S/MIME-Zertifikat und auch deren Hashwerte zur Kontrolle (oder gar noch Sperrlisten) bereitstellen.
    Bei einem für die breite Öffentlichkeit oder gar von einer Firma bereitgestellten Webangebot würde ich mir das mit dem selbstsignierten Zertifikat allerdings sehr überlegen. Dort sieht es zumindest unprofessionell oder gar wenig vertrauenserweckend aus.


    Noch ein paar Worte zur Erzeugung der Schlüssel und Zertifikate.
    Begonnen habe ich vor ca. 15 Jahren mit openssl auf der Konsole. Dann habe ich die Yast-CA von openSUSE, TinyCA und weitere frei verfügbare "Home-CAs" ausprobiert und eine Zeitlang genutzt. Mit steigendem Aufkommen von Zertifikatswünschen bin ich etwa vor 5 Jahren auf "XCA" umgestiegen. Mit diesem für Linux und auch für die WinDOSe verfügbaren Programm ist eine echte Massenproduktion, welche einem kommerziellen TrustCenter recht nahe kommt, möglich. Nicht nur, weil dieses Programm gleich eine Speicherfunktion für die erzeugten Zertifikate mitbringt, sondern vor allem, weil du mit diesem Programm für jeden Anwendungsfall (CA, S/MIME-Nutzer, TLS-Server, TLS-Clients, diverse VPN uvam.) Templates anlegen kannst. So kannst du bei jedem zu erzeugenden Zertifikat per "Knopfdruck" gleich die richtigen Einsellungen vornehmen. So dass du z.Bsp. einem Nutzerzertifikat niemals die Möglichkeiten mitgibst, daraus selbst eine CA zu erstellen. Es sei denn, du willst eben eine von dir signierte Sub-CA aufbauen (lassen). Auch die komfortablen Export- und Importfunktionen sind erwähnenswert. Und wenn du die XCA beendest, verschwinden sämtliche Daten und Einstellungen in einer einzigen passwortgeschützten Containerdatei (die bei Berufsparanoiden wie mir dann auch noch in einem TrueCrypt-Container steckt).
    Bevor ich es vergesse: Nutzer, welche ihren private Key selbst erzeugen wollen (es sind sehr wenige!) verwenden natürlich auch XCA zum Erzeugen des Requests. Diesen schicken sie mir dann per Mail und ich signiere diesen dann lediglich mit meiner CA und schicke das erzeugte Zertifikat ebenfalls per Mail zurück. Dieser Transport kann in beiden Richtungen unverschlüsselt erfolgen, was gerade bei dem "ersten Zertifikat" sehr sinnvoll ist. In der eigenen XCA (also ohne eigene CA) können sie dann die Schlüsseldatei (.p12) zusammenfügen und auch sicher speichern.
    Ja, und warum machen sie diesen Umweg über mich? 3x darfst du raten ... .


    Fast übersehen (auch wenn man das eigentlich aus dem obigen langen Text und den Einstellungen des Thunderbird herauslesen kann ...):

    Quote

    Wenn ich jetzt für eine Bekannte ein Zertifikat erstellt habe, dann braucht sie doch nur ihr eigenes mit dem Schlüssel und das des Servers, richtig?


    Du must deinen Mailpartnern übergeben:
    - das Herausgeberzertifikat deiner CA => im TB importieren nach "Zertifizierungsstellen" und dort das Vertrauen aussprechen, zumindest bei "E-Mail".
    - die eigene "Schlüsseldatei", .p12, welche das eigene Zertifikat und den private Key des Mailpartners enthält. => Importieren nach "Ihre Zertifikate" Nur an diese Person übergeben!!!
    - die Zertifikate der anderen gewollten Nutzer dieses Nutzerkreises, zumindest aber dein eigenes. Zertifikat = nur der öffentliche Schlüssel. => Importieren nach "Personen".
    Bei diesen Zertifikaten NICHT noch einmal das Vertrauen aussprechen! Dieses wird von deinem Herausgeberzertifikat automatisch übernommen!
    Und dann nicht vergessen, dass jeder in den Konten-Einstellungen > S/MIME noch einmal sein eigenes Zertifikat bewusst zum Entschlüsseln und zum Signieren deklarieren muss.


    MfG Peter