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