nicht angemeldet
Tach!
Ich möchte mit dem Zertifikat übrigens die Verbindung zu einer Webanwendung verschlüsseln.
Da sehe ich doch ein Verständnisproblem. Nicht das Zertifikat selbst macht die Verschlüsslung. Das Zertifikat soll lediglich bezeugen, dass der Client mit dem richtigen Server anzubandeln versucht. Dazu müsste eigentlich der Anwender überprüfen, ob alles mit rechten Dingen zugeht. Aber wie macht er das, ohne bereits im Vorfeld sich von der Richtigkeit überzeugt zu haben? Nun, der Serverbetreiber lässt sich von einer der offiziellen Zertifizierungsstellen beglaubigen, dass er wirklich der ist, der er vorzugeben versucht. Und diesen (ziemlich vielen) Zertifizierungsstellen glauben die Bowser von Haus aus. Die Anwender kümmern sich üblicherweise nicht um diesen Aspekt und denken, das alles gut ist, solange der Browser grün zeigt. Von einer dieser Zertifizierungsstellen ist jedoch in der Vergangenheit bekannt geworden, dass sie gehackt wurde. Diese ist auch mittlerweile nicht mehr in den (aktuellen) Browsern vertreten.
Das Zertifikatswesen ist also eigentlich alles nur ein wenig Beruhigungspille für Anwender - und Geldquelle für die Zertifizierungsstellen.
Für die Verschlüsslung ist in dem Zertifikat der öffentliche Schlüssel des Servers enthalten, mit dem der Client seine Nachricht verschlüsselt. Den privaten Key braucht der Server, um diese Nachricht zu entschlüseln. (Die Verschlüsslung in Richtung Client ist für die Zertifikatsbetrachtung nicht weiter wichtig, aber siehe zum Beispiel: http://www.tldp.org/HOWTO/SSL-Certificates-HOWTO/x64.html.
Wenn du dir schon Gedanken um die Zertifikatsinstallation machst, solltest du zumindest auch wissen, wie das da beim Verbindungsaufbau vor sich geht und was wozu benötigt wird. Meine Empfehlung ist also, dass du mal eine generelle Einführung zu SSL zu Gemüte führst.
Die Apache-Doku ist auch nicht unbedingt ein Fan der Passphrase. Das erschwere wohl einen automatischen Start des Servers, weil die Passphrase einzugeben ist. Da ist quasi trotz erhöhtem Risiko die Empfehlung, auf eine Passphrase im Schlüssel zu verzichten.
[...]
Das würde ich als Admin abseits von hochsicherheitsrelevanten Systemen nicht wollen, weil damit immer eine händische Aktion beim Starten verbunden ist. In dem Fall, meine ich, sollte man auch einen 24-Stunden-Service haben, der das System überwacht und gegebenenfalls eingreifen kann. Selbst die beiden anderen Optionen neben "builtin" bringen keine zusätzliche Sicherheit - im Gegenteil. Die angefragten Programme müssen die Passphrase einfach so auf eine simple Anfrage rausrücken.Ich bin mir nicht sicher, ob ich das verstanden habe. So wie ich das sehe, braucht der Apache die PassPhrase um das Zertifikat entschlüsseln und somit verwenden kann. Die PassPhrase kann er entweder manuell durch eine Eingabe des Admins bekommen (das wäre dieser PassPhraseDialog). Oder er bezieht sie automatisch aus dem .key-File.
Bei meiner obigen Ausführung geht es um die Passphrase für den private Key. Man kann den Key mit und ohne Passphrase erstellen. Wenn der Key "verpassphraset" ist, musst du diese beim Starten des Servers angeben. Soweit nach meinem Verständnis.
Nun kommt auch noch die PKCS#12-Geschichte mit ins Spiel, für die ich jedoch keine Erfahrungswerte habe. Ich denke, dass du, um dieses Paket aufzuschließen, eine Passphrase/-wort/wasimmer brauchst. Du solltest aber keine neue für den private Key eingeben.
Ich hatte mich für die .key-Lösung entschieden, weil der Dialog von der Windows-Version des Apaches nicht unterstützt wird (da bekam ich in den Logs einen entsprechenden Fehler). Deshalb habe ich den Parameter auch auskommentiert (wurde so auch in einem Tutorial empfohlen).
Gäbe es auch einen Weg, der völlig ohne PassPhrase auskommt? Das wäre dann aber unsicherer, oder?
Hätte ich eine .key-Datei auch aus dem Container PKCS12 bekommen können?
Die .key-Datei enthält den privaten Schlüssel, den du benötigst, um die mit dem im Zertifikat enthaltenen öffentlichen Schlüssel vom Client verschlüsselten Daten zu dekodieren. Ohne .key-Datei kommst du also generell nicht weit. Wenn du den Apachen starten kannst, ohne dass er eine Eingabe verlangt, dann hast du eine .key-Datei ohne zusätzliche Passphrase.
Hier muss ich aber passen, weil ich einerseits nicht weiß, wofür konkret deine Passphrase-Eingaben notwendig waren, noch die Notwendigkeit hatte, mich mit PKCS#12 auseinanderzusetzen, also nicht weiß, wann man da konkret was eingeben muss. Ich hab nur selbst signierte Zertifikate erstellt und dabei darauf geachtet, die optionale Passphrase nicht mit einzugeben.
dedlfix.