Mastershrimp: Verständnisfrage bzgl. Einrichtung von SSL-Zertifikat (Apache)

Hallo,

ich bin noch recht neu was die Einrichtung eines SSL-Zertifikats unter Apache (2.2) betrifft. Geliefert wurde mir ein Zertifikat mit der Endung ".p12" - vermutlich ist das dann PKCS12?

Bisher hatte ich ein selbst generiertes (Dummy-)Zertifikat, welches als ".crt" vorlag. Also bin ich zunächst hingegangen und habe das p12 in crt umgewandelt:

  1. openssl pkcs12 -in zertifikat.p12 -out zertifikat.crt
    Dabei musste ich das PW des Zertifikats eingeben und eine PEM-PassPhrase festlegen.

  2. Da bei mir der Apache unter Windows läuft und dieser "SSLPassPhraseDialog builtin" nicht unterstützt wird, muss ich die PassPhrase per .key-Datei übergeben. Also habe ich mir (gemäß einiger Tutorials) eine .key-Datei gebaut:
    openssl rsa -in C:\zertifikat.crt -out C:\zertifikat.key
    Hier musste ich die zuvor festgelegte PassPhrase eingeben.

  3. Anschließend den Apache so konfigurieren, dass der Parameter SSLCertificateFile auf die zertifikat.crt-Datei und der Parameter SSLCertificateKeyFile auf die zertifikat.key zeigt. Außerdem muss der Parameter SSLPassPhraseDialog builtin auskommentiert werden.

Damit funktioniert's. Aber ich kann nicht behaupten, dass ich alle Entscheidungen bewusst gefällt habe :D
Naja, und da das ja möglicherweise schon sicherheitskritische Punkte sind, wollte ich mich bei euch erkundigen, ob der o.g. Vorgehen Sinn macht und ein sicheres Ergebnis liefert.

Die PassPhrase habe ich recht groß und komplex gewählt. Aber ist "rsa" gut? Wenn ich das richtig verstanden habe, ist das die Verschlüsselung des öffentlichen Schlüssels. Ist RSA empfehlenswert?

Vielen Dank schonmal und viele Grüße!

  1. Tach!

    Ich bin auch kein Guru auf dem Gebiet, also sieh meine Antwort als Anregung für weitere Nachforschungen/Überlegungen und nicht unbedingt als Wahrheit an.

    ich bin noch recht neu was die Einrichtung eines SSL-Zertifikats unter Apache (2.2) betrifft. Geliefert wurde mir ein Zertifikat mit der Endung ".p12" - vermutlich ist das dann PKCS12?

    Allem Anschein nach. Was ich zu PKCS #12 gelesen habe, ist das ein Paket-Format für Zertifikate und Schlüssel. Das eigentliche Zertifikat ist also darin enthalten.

    Bisher hatte ich ein selbst generiertes (Dummy-)Zertifikat, welches als ".crt" vorlag.

    Wofür genau hast du das Zertifikat verwendet (oder willst es noch tun)? Also zum einen was für einen Anwendungsfall hast du und hast du dir schon Gedanken darüber gemacht, warum da ein Zertifikat benötigt wird und was es für Eigenschaften/Vorteile/Nachteile hat (auch im Vergleich zwischen selbst signiert und "offiziell")?

    Also bin ich zunächst hingegangen und habe das p12 in crt umgewandelt:

    Das ist keine sinnvolle Kausalität. Ein Grund für das Umwandeln ist wohl eher, dass der Apache nichts mit dem Containerformat anfangen kann und die Zertifikatsdateien ausgepackt benötigt.

    1. openssl pkcs12 -in zertifikat.p12 -out zertifikat.crt
      Dabei musste ich das PW des Zertifikats eingeben und eine PEM-PassPhrase festlegen.

    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. Siehe http://httpd.apache.org/docs/2.2/ssl/ssl_faq.html#startup ff.

    [...] "SSLPassPhraseDialog builtin" [...]

    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.

    1. Anschließend den Apache so konfigurieren, dass der Parameter SSLCertificateFile auf die zertifikat.crt-Datei und der Parameter SSLCertificateKeyFile auf die zertifikat.key zeigt. Außerdem muss der Parameter SSLPassPhraseDialog builtin auskommentiert werden.

    Ein Auskommentieren sollte keine Änderung bringen, denn builtin ist der Default-Wert von SSLPassPhraseDialog.

    Naja, und da das ja möglicherweise schon sicherheitskritische Punkte sind, wollte ich mich bei euch erkundigen, ob der o.g. Vorgehen Sinn macht und ein sicheres Ergebnis liefert.

    "Sicher" ist kein allgemein definierter Zustand. Ich weiß also nicht, was "sicher" bei dir heißt, was du also abzusichern gedenkst und kann dann auch nicht einschätzen, wie nahe du diesem Ziel gekommen bist.

    Die PassPhrase habe ich recht groß und komplex gewählt. Aber ist "rsa" gut? Wenn ich das richtig verstanden habe, ist das die Verschlüsselung des öffentlichen Schlüssels. Ist RSA empfehlenswert?

    Die Alternative zu RSA ist wohl nur DSA und da DSA von einer US-Regierungsorganisation entwickelt wurde, darf man DSA gegenüber ruhig auch skeptisch sein. Ob dann für dich nur RSA übrig bleibt, musst du selbst entscheiden. Wenn ich das recht sehe, gibt es keine Alternative zu den beiden Verfahren.

    dedlfix.

    1. Hallo dedflix!

      Danke für deine ausführliche Antwort!

      Konkret geht es mir darum, eine nach allgemeinem Ermessen vernünftige Konfiguration aufgesetzt zu haben. Anders formuliert: Dass ich nicht in Anfänger-Fallen gestolpert bin und grundlegende Sachen übersehen habe.

      Ich möchte mit dem Zertifikat übrigens die Verbindung zu einer Webanwendung verschlüsseln.

      Ich schließe aus deiner Antwort, dass mein Vorgehen im Großen und Ganzen OK ist. Zumindest nichts, wo der fortgeschrittene Admin laut aufschreien würde :)

      Noch kurz ein paar Anmerkungen:

      Allem Anschein nach. Was ich zu PKCS #12 gelesen habe, ist das ein Paket-Format für Zertifikate und Schlüssel. Das eigentliche Zertifikat ist also darin enthalten.

      Ja, das macht Sinn. Mir sagte das Format vorher auch nicht wirklich etwas.

      Also bin ich zunächst hingegangen und habe das p12 in crt umgewandelt:

      Das ist keine sinnvolle Kausalität. Ein Grund für das Umwandeln ist wohl eher, dass der Apache nichts mit dem Containerformat anfangen kann und die Zertifikatsdateien ausgepackt benötigt.

      Ja, das meinte ich damit ;)

      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.

      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?

      Ein Auskommentieren sollte keine Änderung bringen, denn builtin ist der Default-Wert von SSLPassPhraseDialog.

      Das ist gut möglich. Da hatte ich mich an ein Tutorial gehalten, das diesen Schritt empfahl.

      Die Alternative zu RSA ist wohl nur DSA und da DSA von einer US-Regierungsorganisation entwickelt wurde, darf man DSA gegenüber ruhig auch skeptisch sein. Ob dann für dich nur RSA übrig bleibt, musst du selbst entscheiden. Wenn ich das recht sehe, gibt es keine Alternative zu den beiden Verfahren.

      Ok, vielen Dank! Ich laufe halt ungern mit Default-Werten los, ohne sie zu hinterfragen. Aber dann ist RSA wohl ausreichend für meine Zwecke.

      1. Vielleicht noch ein kleiner Nachtrag:

        Wie generiere ich denn am besten den Key?
        Das eine Tutorial schrieb:

        openssl rsa -in C:\zertifikat.crt -out C:\zertifikat.key

        Im Apache Manual geht das auch ohne die .crt-Datei als Input:
        openssl genrsa -des3 -out zertifikat.key 1024

        Was wäre da deine Empfehlung? Macht ersteres überhaupt Sinn? Warum will er das Zertifikat als Input nehmen?

        Viele Grüße

        1. Ok, wie's scheint funktioniert das mit dem genrsa-Befehl nicht. Dann kommt wieder der PassPhraseDialog-not-supported-Fehler.

          Gut, dann bleibe ich wohl beim ursprünglichen Befehl zur Generierung des Keys.

      2. 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.

        1. Hallo dedlfix!

          Vielen Dank nochmal für die ausführliche Antwort! Echt interessant!
          Einen groben Plan von SSL und asymmetrischer Verschlüsselung hatte ich bereits - dennoch danke für den Link :)

          Ich sehe halt nur bei den diversen Konfigurationsmöglichkeiten die Gefahr, dass ich zwar einen funktionierenden Weg wähle, der aber in seinem Design nicht unbedingt sicher ist. Deshalb wollte ich das noch einmal absegnen lassen, wie schon gesagt.

          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.

          Ja, ich brauchte beides. Ich musste bei der Umwandlung von .p12 in .crt zuerst das Passwort des Containers angeben (1x). Danach wurde ich nach dieser PEM-PassPhrase gefragt, die ich erstellen (und somit 2x eingeben) musste.
          Ich denke mittlerweile, dass ersteres zum Aufschließen des Containers gedacht ist, und zweiteres für die Verschlüsselung der .crt-Datei. Ich konnte diese PEM-PassPhrase auch nicht leer lassen. Sie muss mindestens 4 Zeichen lang sein, glaube ich.

          Zur Verwendung der verschlüsselten .crt-Datei braucht der Server den Key, vermutlich. Daher muss ich im zweiten Schritt den .key für das zuvor generierte .crt-Zertifikat generieren. Und um im Zuge dessen auf das Zertifikat zugreifen zu können, musste ich erneut die PassPhrase angeben. Damit konnte OpenSSL dann das Zertifikat entschlüsseln und den Key generieren.

          Der Apache bekommt nun beides: .key und .crt. Mit dem .key entschlüsselt er (wann immer er es braucht) das .crt. Und daher ist auch keine Eingabe der PassPhrase mehr nötig, weil die aus der Datei kommt.

          Soweit mein Verständnis. Aber das basiert nur auf Beobachtungen und ist letztendlich komplett geraten :D

          Macht das denn grob Sinn?

          1. Tach!

            [...]
            Soweit mein Verständnis. Aber das basiert nur auf Beobachtungen und ist letztendlich komplett geraten :D
            Macht das denn grob Sinn?

            An der Stelle muss ich dich allein lassen, denn meine Zertifikatsselbsterzeugungen hatten bisher nicht auf eine Passphrase bestanden.

            dedlfix.

            1. An der Stelle muss ich dich allein lassen, denn meine Zertifikatsselbsterzeugungen hatten bisher nicht auf eine Passphrase bestanden.

              Ok, trotzdem danke für deine Tipps und Erklärungen :)

              Viele Grüße!

  2. Ist eine "Verständnisfrage" etwas besseres, anspruchsvolleres als eine normale Frage? Soll diese Formulierung etwas suggerieren?
    Cheers, Frank