Bester Ort für SSL-Zertifikat und private Schlüssel auf Ubuntu

Auf Ubuntu sieht es so aus, als ob sich der beste Ort für einen privaten Schlüssel, der zum Signieren eines Zertifikats (zur Verwendung durch nginx) verwendet wird, in befindet /etc/ssl/private/

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

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

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

Es ist wirklich egal, wo Sie sie ablegen, solange Sie Ihre privaten Schlüsseldateien ordnungsgemäß schützen . Das öffentliche Zertifikat ist öffentlich; Kein Schutz erforderlich - Serverberechtigungen oder sonstiges.

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

Für Apache SSL behalte ich meinen /etc/apache2/ssl/privateoder einen ähnlichen "Root-Bereich" bei /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 & 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 710Unterstützt ssl-certGruppen unter Ubuntu. (Siehe Kommentare) Das
Setzen der Berechtigung 700auf /etc/apache2/ssl/private"Ein" funktioniert auch einwandfrei.

Legen Sie SSL-Dateien ab:

Setzen Sie die öffentliche www ssl - Zertifikat (e) zusammen mit Zwischenzertifikat (e) in /etc/apache2/ssl
Put privaten ssl Taste (n) in/etc/apache2/ssl/private

Eigentümer festlegen:

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

Hinweis:
Wenn Sie keine SSL-Zertifikatsgruppe haben , verwenden Sie einfach 'root: root' in der oberen Zeile oder überspringen Sie die zweite Zeile.

Berechtigungen festlegen:

Öffentliches Zertifikat

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

Privater Schlüssel

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

Hinweis:
Die Gruppenberechtigung ist 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

(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

Getan. Testen Sie Ihre neue SSL-Site.

* Auch dies geht über die Frage hinaus, aber Sie können die standardmäßige 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 standardmäßige Direktiven / Verzeichnisse kopieren, die normalerweise unter einer einfachen (Ubuntu / Debian) Apache / SSL-Conf-Datei verwendet werden . Normalerweise verweist es auf ein selbstsigniertes SSL-Zertifikat + Schlüssel (snakeoil), CA-Bundles sowie auf allgemeine Anweisungen, 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 mit neuen Informationen / Pfaden hinzu / entfernen / aktualisieren Sie sie und führen Sie sie aus sudo a2ensite mysiteexample-ssl, um sie zu aktivieren.

Alle Antworten hier scheinen in Ordnung zu sein, aber ich möchte eines erwähnen, bei dem ich ein Problem festgestellt habe ... Wenn Sie Ihr Zertifikat mit Intermediates oder Roots verknüpfen müssen, um eine Chain-Datei zu erstellen, geben Sie das nicht ein /etc/ssl/certs, denn wann ? c_rehashwird es ausgeführt, kann es aufgrund der darin enthaltenen Wurzeln oder Zwischenstufen zu Hash-Symlinks zu Ihren Zertifikaten kommen.

Später, wenn Ihre Zertifikate abgelaufen sind und Sie sie entfernen und nicht wissen, ob Sie sie erneut ausführen sollen c_rehash, haben Sie möglicherweise Hash-Symlinks in Ihrem /etc/ssl/certsVerzeichnis unterbrochen , und seltsame Dinge beginnen, wenn Ihr lokaler Computer versucht, sich über zu verbinden SSL, und es können keine zu überprüfenden Roots gefunden werden. Zum Beispiel bekam ich plötzlich mit Locken:

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

Kurz nach dem Aufräumen einiger alter .crt- und verketteter .pem-Dateien, die ich in hatte /etc/ssl/certs.

Wenn Sie zumindest Ihre Ketten an einem anderen Ort aufbewahren, wird dieses Problem vermieden. /etc/ssl/local_certsAm Ende habe ich ein gemacht , um meine Zertifikate und Ketten zu halten, damit sie nicht im Chaos der CA-Zertifikate verloren gehen, in denen Sie zu finden sind/etc/ssl/certs

Es gibt keinen wirklich unsicheren Ort, wenn die Berechtigung für die einzelnen Dateien / Verzeichnisse auf so etwas wie gesetzt ist chown root :0 private.keyund chmod 600 private.keynur root darauf zugreifen kann. CSRs und Zertifikatsdateien sind, wie Sie sagen, weniger sensibel.

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

Standorte sind korrekt:

• /etc/ssl/certs/für die .crtDatei
• /etc/ssl/privatefür die .keyDatei

Eigentümer muss root:rootfür beide sein ( sudo chmod root:root <file>ggf. ändern).

Berechtigungen :

• 644für die .crtDatei
• 600für die .keyDatei

Dies wird funktionieren für nginx.