Meilleur emplacement pour le certificat SSL et les clés privées sur Ubuntu

Sur Ubuntu, il semble que le meilleur endroit pour une clé privée utilisée pour signer un certificat (utilisé par nginx) se trouve dans /etc/ssl/private/

Cette réponse ajoute que le certificat devrait être dans /etc/ssl/certs/ mais cela semble être un endroit dangereux. Les fichiers .crt doivent-ils être gardés en sécurité ou sont-ils considérés comme publics?

Le fichier .crt est envoyé à tout ce qui se connecte; C'est public. ( chown root:root et chmod 644 )

Pour ajouter à l'emplacement de la clé privée; Assurez-vous de bien le sécuriser ainsi que de l'avoir là-bas. ( chown root:ssl-cert et chmod 640 )

Ce n'est vraiment pas grave où vous les mettez aussi longtemps que vous protégez correctement votre (vos) fichier (s) de clé privée . Le certificat public est public; Aucune protection nécessaire – privilèges du serveur ou autrement.

Pour développer la réponse, je n'utilise pas l'emplacement par défaut /etc/ssl .
Il est plus facile pour moi de garder tout le mien dans une zone distincte en raison de sauvegardes + d'autres raisons.

Pour Apache SSL, je garde le mien dans /etc/apache2/ssl/private ou similaire "zone racine" dans /etc/ .

Exemple d'installation

Cette publication est orientée vers Ubuntu (Debian) + Apache, mais devrait fonctionner sur la plupart des systèmes –
Il suffit d'appliquer les autorisations et la mise à jour d'emplacement / chemin dans config donné (apache / nginx / etc).
Si les fichiers clés SSL sont protégés correctement (répertoire et fichiers), vous allez bien. Notez les notes!

Créer des répertoires:

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

Remarque:
chmod 710 prend en charge le groupe ssl-cert sous Ubuntu. (Voir les commentaires)
L'autorisation de 700 sur /etc/apache2/ssl/private fonctionnera également bien.

Propriétaire de l'établissement:

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

Remarque:
Si vous n'avez pas le groupe ssl-cert , utilisez simplement 'root: root' en ligne ci-dessus ou sautez 2ème ligne.

Placez les fichiers SSL:

Mettez le ou les certificats publics de www ssl avec un (des) certificat (s) intermédiaire (s) dans /etc/apache2/ssl
Mettre la (les) clé (s) privée (s) dans /etc/apache2/ssl/private

Définir les autorisations:

Certificat public (s)

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

Clé privée (s)

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

Remarque:
L'autorisation de groupe est définie sur READ (640) en raison du groupe Ubuntu ssl-cert. «600» est également bien.

Activer le module SSL Apache

 sudo a2enmod ssl 

Modifiez tous les fichiers du site Apache et activez

(Voir dernier paragraphe) *

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

Redémarrez le service Apache2

 sudo service apache2 restart 

ou

 sudo systemctl restart apache2.service 

Terminé. Testez votre nouveau site SSL.

* Encore une fois, cela va au-delà de la question, mais vous pouvez copier le fichier de configuration de site SSL Apache par défaut ( sudo cp /etc/apache2/sites-available/default-ssl.conf /etc/apache2/sites-available/mysiteexample-ssl.conf ) Comme un bon point de départ / exemple de directives / répertoires par défaut normalement utilisés sous un simple fichier (Ubuntu / Debian) Apache / SSL 'conf'. Il indique normalement un certificat SSL signé par auto-signature (snakeoil), des bundles CA, ainsi que des directives communes utilisées pour un site SSL donné.

Après la copie, il suffit d'éditer le nouveau fichier .conf et de l'ajouter / le supprimer / le mettre à jour selon les besoins avec les nouvelles informations / chemins ci-dessus, puis exécuter sudo a2ensite mysiteexample-ssl pour l'activer.

Toutes les réponses ici semblent correct, mais je veux mentionner qu'une chose que j'ai trouvée est un problème … Si vous devez concaténer votre cert avec des intermédiaires ou des racines pour trouver un fichier en chaîne, ne pas mettre cela dans /etc/ssl/certs , car lorsque c_rehash est exécuté, il peut créer des liens symboliques de hash à vos certs en raison des racines ou des intermédiaires en eux.

Ensuite, plus tard sur la route, si vos certs ont expiré et que vous les supprimez et ne savez pas re-exécuter c_rehash , vous avez peut-être des liens symboliques hash brisés dans votre répertoire /etc/ssl/certs , et des choses étranges commencent à se produire lorsque votre local Machine essaie de se connecter via SSL, et il ne peut pas trouver les racines à valider contre. Par exemple, avec curl, j'ai soudainement commencé à obtenir:

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

Peu de temps après avoir nettoyé un ancien .crt et des fichiers .pem concaténés, j'avais dans /etc/ssl/certs .

Le fait de stocker au moins vos chaînes ailleurs évite ce problème. J'ai fini par faire un /etc/ssl/local_certs pour tenir mes certs et chaînes, donc ils n'étaient pas perdus dans le désordre de CER Certifié que vous trouverez dans /etc/ssl/certs

Il n'y a pas vraiment un endroit dangereux si l'autorisation pour les fichiers / répertoire individuels est configurée comme quelque chose comme chown root :0 private.key et chmod 600 private.key afin que seule la racine puisse la lire. Les CSR et les fichiers de certificats sont moins sensibles que vous le dites.

Avec ces autorisations, les chemins que vous mentionnez et / usr / local / ssl devraient être bien.