it-swarm.com.de

Bester Speicherort für SSL-Zertifikate und private Schlüssel unter Ubuntu

Unter Ubuntu scheint der beste Ort für einen privaten Schlüssel zum Signieren eines Zertifikats (zur Verwendung durch Nginx) in /etc/ssl/private/ Zu sein.

Diese Antwort fügt hinzu, dass das Zertifikat in /etc/ssl/certs/ Abgelegt werden sollte, aber das scheint ein unsicherer Ort zu sein. Müssen .crt - Dateien sicher aufbewahrt werden oder gelten sie als öffentlich?

63
Adam Nelson

Die CRT-Datei wird an alle Verbindungen gesendet. es ist öffentlich. (chown root:root und chmod 644)

Hinzufügen zum Speicherort des privaten Schlüssels; Stellen Sie sicher, dass Sie es ordnungsgemäß sichern und dort haben. (chown root:ssl-cert und chmod 640)

49
Shane Madden

Es spielt wirklich keine Rolle, wo Sie sie ablegen, solange Sie Ihre privaten Schlüsseldateien ordnungsgemäß schützen. Das öffentliche Zertifikat ist öffentlich; Kein Schutz erforderlich - Serverrechte oder anderweitig.

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

Für Apache SSL behalte ich meine in /etc/Apache2/ssl/private Oder einem ähnlichen "Stammbereich" in /etc/.

Beispiel-Setup

Dieser Beitrag richtet sich an Ubuntu (Debian) + Apache, sollte aber auf den meisten Systemen funktionieren -
Wenden Sie einfach die Berechtigungen an und aktualisieren Sie den Speicherort/Pfad in der angegebenen Konfiguration (Apache/nginx/etc).
Wenn die SSL-Schlüsseldateien korrekt geschützt sind (Verzeichnis und Dateien), ist alles in Ordnung. Beachten Sie die Notizen !

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 die Gruppe ssl-cert Unter Ubuntu.
(Siehe Kommentare)
Das Setzen der Berechtigung auf 700 Für /etc/Apache2/ssl/private Funktioniert ebenfalls einwandfrei.

Platzieren Sie SSL-Dateien:

Setzen Sie public www ssl-Zertifikat (e) zusammen mit Zwischenzertifikat (en) in /etc/Apache2/ssl
Setzen Sie privat SSL-Schlüssel in /etc/Apache2/ssl/private

Set Besitzer:

Sudo chown -R root:root /etc/Apache2/ssl/
Sudo chown -R root:ssl-cert /etc/Apache2/ssl/private/

Hinweis:
Wenn Sie keine ssl-cert Gruppe haben, verwenden Sie einfach 'root: root' in der obigen Zeile oder überspringen Sie die 2. Zeile.

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 in Ordnung.

Aktivieren Sie das Apache SSL-Modul

Sudo a2enmod ssl

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

(siehe letzter 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 Standard-Apache-SSL-Site-Konfigurationsdatei (Sudo cp /etc/Apache2/sites-available/default-ssl.conf /etc/Apache2/sites-available/mysiteexample-ssl.conf) Als guten Ausgangspunkt/Beispiel für Standardanweisungen/-verzeichnisse kopieren, die normalerweise unter einem einfachen (Ubuntu/Debian) Apache verwendet werden/SSL 'conf' Datei. Normalerweise verweist es auf ein selbstsigniertes SSL-Zertifikat + Schlüssel (Snakeoil), CA-Bundles sowie allgemeine Direktiven , die für eine bestimmte SSL-Site verwendet werden.

Bearbeiten Sie nach dem Kopieren einfach die neue .conf-Datei und fügen Sie sie nach Bedarf hinzu/entfernen/aktualisieren Sie sie mit den oben genannten neuen Informationen/Pfaden. Führen Sie dann Sudo a2ensite mysiteexample-ssl Aus, um sie zu aktivieren.

36
bshea

Alle Antworten hier scheinen in Ordnung zu sein, aber ich möchte eines erwähnen, das ich als Problem empfunden habe ... Wenn Sie Ihr Zertifikat mit Zwischenprodukten oder Roots verketten müssen, um eine Kettendatei zu erstellen, nicht = Geben Sie dies in /etc/ssl/certs ein, da beim Ausführen von c_rehash aufgrund der darin enthaltenen Wurzeln oder Zwischenprodukte möglicherweise Hash-Symlinks zu Ihren Zertifikaten erstellt werden.

Wenn Ihre Zertifikate später abgelaufen sind und Sie sie entfernen und nicht wissen, dass Sie c_rehash Erneut ausführen sollen, haben Sie möglicherweise Hash-Symlinks in Ihrem /etc/ssl/certs - Verzeichnis und seltsame Dinge beschädigt Dies geschieht, wenn Ihr lokaler Computer versucht, über SSL eine Verbindung zu sich selbst herzustellen, und er keine Wurzeln findet, anhand derer er validieren kann. Zum Beispiel bekam ich mit Curl plötzlich:

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

Kurz nach dem Bereinigen einiger alter .crt- und verketteter .pem-Dateien hatte ich in /etc/ssl/certs.

Wenn Sie mindestens Ihre Ketten an einem anderen Ort aufbewahren, wird dieses Problem vermieden. Am Ende habe ich einen /etc/ssl/local_certs Für meine Zertifikate und Ketten erstellt, damit sie nicht im Durcheinander der CA-Zertifikate verloren gehen, die Sie in /etc/ssl/certs Finden.

10
barryp

Es gibt keinen wirklich unsicheren Ort, wenn die Berechtigung für die einzelnen Dateien/Verzeichnisse auf chown root :0 private.key Und chmod 600 private.key Festgelegt ist, sodass nur root sie lesen kann. CSRs und Zertifikatdateien sind weniger sensibel, wie Sie sagen.

Mit diesen Berechtigungen sollten die von Ihnen genannten Pfade und/usr/local/ssl in Ordnung sein.

2
Jonathan Ross

Standorte sind korrekt:

  • /etc/ssl/certs/ Für die Datei .crt
  • /etc/ssl/private Für die Datei .key

Eigentümer muss für beide root:root Sein (bei Bedarf Sudo chmod root:root <file> Zum Ändern verwenden).

Berechtigungen:

  • 644 Für die Datei .crt
  • 600 Für die Datei .key

Dies funktioniert für nginx.

1