Frage Der beste Speicherort für SSL-Zertifikate und private Schlüssel unter Ubuntu


Unter Ubuntu scheint es, als wäre der beste Ort für einen privaten Schlüssel, der zum Signieren eines Zertifikats (für nginx) verwendet wird /etc/ssl/private/

Diese Antworten fügt hinzu, dass das Zertifikat gehen sollte /etc/ssl/certs/ aber das scheint ein unsicherer Ort zu sein. Tun .crt Dateien müssen sicher aufbewahrt werden oder gelten sie als öffentlich?


53
2018-04-13 15:56


Ursprung


Sie können Ihre .crt auf einer Times Square Billboard, wenn Sie möchten. - ceejayoz


Antworten:


Die .crt-Datei wird an alles gesendet, was verbindet; Es ist öffentlich. (chown root:root und chmod 644)

Hinzufügen zum Speicherort des privaten Schlüssels stellen Sie sicher, dass Sie es richtig sichern und es auch dort haben. (chown root:ssl-cert und chmod 640)


44
2018-04-13 16:06



Ich frage mich, warum dieses Verzeichnis nicht standardmäßig g + s ist. - Collin Anderson
Es muss nicht sein; Das Verzeichnis ist 0750. Daher können Benutzer, die nicht in der Gruppe sind, nicht in das Verzeichnis wechseln, um die Dateien zu lesen. - womble♦
Für die meisten Anwendungen, die ich verwende, sehe ich das Verhalten wie in der verknüpften Antwort beschrieben: Sie verwenden den Benutzer root um das Zertifikat zu laden. Aber die Berechtigungen hier sind gut erklärt. - SimonSimCity
Sieht aus, als wäre ssl-cert ein ungültiger Gruppenname auf ubuntu. Vielleicht sollte es chown root sein: root stattdessen - Atifm


Es spielt wirklich keine Rolle, wo Sie sie hinstellen, solange Sie Ihren Schutz richtig schützen Privat Schlüssel Datei (en). Das öffentliches Zertifikat ist öffentlich; Kein Schutz benötigt - Serverprivilegien oder sonst.

Um die Antwort zu erweitern, verwende ich nicht den Standardspeicherort /etc/ssl.
 Es ist einfacher für mich, alle meine in einem separaten Bereich aufgrund von Backups und anderen Gründen zu halten.

Für Apache SSL halte ich meinen /etc/apache2/ssl/private oder ähnlicher "root area" in /etc/.

Beispieleinrichtung

Dieser Post ist auf Ubuntu (Debian) + Apache ausgerichtet, sollte aber auf den meisten Systemen funktionieren -
 Übernehmen Sie einfach die Berechtigungen und aktualisieren Sie den Pfad / Pfad in der angegebenen Konfiguration (apache / nginx / etc).
  Wenn die SSL-Schlüsseldateien korrekt geschützt sind (Verzeichnis & Dateien), ist alles in Ordnung. Beachten Sie die Hinweise!

Verzeichnisse erstellen:

sudo mkdir /etc/apache2/ssl
sudo mkdir /etc/apache2/ssl/private
sudo chmod 755 /etc/apache2/ssl
sudo chmod 710 /etc/apache2/ssl/private

Hinweis:
chmod 710 unterstützt ssl-cert Gruppe unter Ubuntu.
 (Zeige Kommentare)
Berechtigung festlegen für 700 auf /etc/apache2/ssl/private wird auch gut funktionieren. 

Besitzer festlegen:

sudo chown -R root:root /etc/apache2/ssl/
sudo chown -R root:ssl-cert /etc/apache2/ssl/private/

Hinweis:
Wenn du nicht hast SSL-Zertifikat Gruppe, verwenden Sie einfach "root: root" in der Zeile über oder überspringen Sie die zweite Zeile.

SSL-Dateien platzieren:

Stellen Öffentlichkeit www ssl Zertifikat (e) zusammen mit Zwischenzertifikat (en) in     /etc/apache2/ssl
  Stellen Privatgelände ssl Schlüssel in /etc/apache2/ssl/private

Berechtigungen festlegen:

Öffentliche Bescheinigung (en)

sudo chmod 644 /etc/apache2/ssl/*.crt

Private Schlüssel

sudo chmod 640 /etc/apache2/ssl/private/*.key

Hinweis:
Die Gruppenberechtigung wird aufgrund der Ubuntu ssl-cert-Gruppe auf READ (640) gesetzt. '600' ist auch gut.

Aktivieren Sie das Apache SSL-Modul

sudo a2enmod ssl

Bearbeiten Sie alle Apache-Site-Dateien und aktivieren Sie sie

(siehe letzten Absatz) *

sudo nano /etc/apache/sites-available/mysiteexample-ssl.conf
sudo a2ensite mysiteexample-ssl
#             ^^^^^^^^^^^^^^^^^ <-Substitute your ".conf" filename(s)

Starten Sie den Apache2-Dienst neu

sudo service apache2 restart

oder

sudo systemctl restart apache2.service

Erledigt. Testen Sie Ihre neue SSL-Site.

* Auch dies geht über die Frage hinaus, aber Sie können die standardmäßige Apache SSL Site-Konfigurationsdatei kopieren (sudo cp /etc/apache2/sites-available/default-ssl.conf /etc/apache2/sites-available/mysiteexample-ssl.conf) als guter Ausgangspunkt / Beispiel für Standard-Direktiven / Verzeichnisse, die normalerweise unter einer einfachen (Ubuntu / Debian) Apache / SSL 'conf' Datei verwendet werden. Es zeigt normalerweise auf ein selbstsigniertes SSL-Zertifikat + Schlüssel (Snakeoil), CA-Bundles, sowie allgemein Richtlinien verwendet für eine bestimmte SSL-Site.

Kopieren Sie nach dem Kopieren einfach die neue .conf-Datei und fügen Sie sie bei Bedarf hinzu, entfernen Sie sie / aktualisieren Sie sie mit neuen Informationen / Pfaden, und führen Sie sie anschließend aus sudo a2ensite mysiteexample-ssl um es zu ermöglichen.


32
2017-10-21 17:17



nicht sicher, warum Sie 710 für Berechtigungen für / etc / apache2 / ssl / private festlegen sollten. Das Ausführen des Ausführungsbits für das Verzeichnis (für die Gruppe) ohne Setzen des Lesebits für das Verzeichnis (für die Gruppe) ist für mich nicht sehr sinnvoll. Hast du vor, es als 750 zu setzen? - chriv
@chriv Ich setze einfach Berechtigungen, basierend auf wie ich es unter Ubuntu Standard-SSL-Bereich eingerichtet sehe. Siehe / etc / ssl / certs & / etc / ssl / private & ssl-certs Gruppe verwenden. Sehen stackoverflow.com/a/23408897/503621 - bshea
Eine sehr schöne und detaillierte Erklärung zu einer generischen Frage mit vielen möglichen Antworten. Vielen Dank. Um nur ein paar Dinge hinzuzufügen, deine <VirtualHost *:443> Abschnitt in Ihrem sites-available/mysite.conf sollte die Zertifikate wie folgt einschließen: SSLEngine on  SSLCertificateFile /etc/apache2/ssl/mysite.crt  SSLCertificateKeyFile /etc/apache2/ssl/private/mysite.key - George Dimitriadis
BTW - Es ist auch möglich, einfach Ihre: 80 und: 443 Configs in einer Apache ".conf" Datei zu kombinieren.Ich leite alles um, was auf Port trifft: 80 at: 443 / SSL auf jeden Fall. Es ist auch möglich, grundlegende SSL-Einstellungen in der .conf-Datei zu speichern und eine zusätzliche "detaillierte" SSL-Einstellungsdatei zu erstellen (um z. B. Verschlüsselungen festzulegen, die / etc verwendet werden) und nur umfassen es in allen Ihren .conf-Dateien außerhalb virtueller Bereiche. Ich verwende diese Einstellungen, um SSL ein wenig zu "härten" und ich schließe es in jede virtuelle Site .conf ein. Ich kann A + bekommen SSL-Labors auf diese Weise . - bshea


Alle Antworten hier scheinen in Ordnung zu sein, aber ich möchte eine Sache erwähnen, die ich gefunden habe, ist ein Problem ... Wenn Sie Ihr Zertifikat mit Zwischenprodukten oder Wurzeln verketten müssen, um mit einer Ketten-Datei zu kommen, nicht leg das rein /etc/ssl/certs, weil wenn c_rehash ausgeführt wird, kann es Hash-Symlinks zu Ihren Zertifikaten aufgrund der Wurzeln oder Zwischenprodukte in ihnen erstellen.

Dann später die Straße hinunter, wenn Ihre Zertifikate abgelaufen sind und Sie sie entfernen, und nicht wissen, um wieder zu laufen c_rehashMöglicherweise haben Sie Hash - Symlinks in Ihrem /etc/ssl/certs Verzeichnis, und seltsame Dinge beginnen, wenn Ihr lokaler Computer versucht, sich über SSL mit sich selbst zu verbinden, und er kann die zu validierenden Roots nicht finden. Zum Beispiel, mit curl habe ich plötzlich angefangen zu bekommen:

curl: (60) SSL certificate problem: unable to get issuer certificate

Kurz nachdem ich einige alte .crt- und verkettete .pem-Dateien aufgeräumt hatte /etc/ssl/certs.

Wenn Sie Ihre Ketten irgendwo anders lagern, vermeiden Sie dieses Problem. Ich landete ein /etc/ssl/local_certs Meine Zeugnisse und Ketten zu halten, damit sie nicht in dem Durcheinander von CA-Akten verloren gehen, in denen Sie finden werden /etc/ssl/certs


8
2018-03-23 14:58





Es ist nicht wirklich ein unsicherer Ort, wenn die Berechtigung für die einzelnen Dateien / Verzeichnis auf etwas wie eingestellt ist chown root :0 private.key und chmod 600 private.key so dass nur die root es lesen kann. CSRs und Zertifikatsdateien sind weniger empfindlich als Sie sagen.

Mit diesen Berechtigungen sollten die angegebenen Pfade und / usr / local / ssl in Ordnung sein.


2
2018-04-13 16:08



Häufig werden Anwendungen, die auf private Schlüssel zugreifen, als Nicht-Root-Benutzer ausgeführt. Ich würde empfehlen, den Zugriff für die ssl-cert-Gruppe beizubehalten. - Shane Madden♦
Verstanden, aber Web-Server wie Apache spawnen einen Root-Parent-Prozess und nehmen auch nginx an. - Jonathan Ross