Quel est le meilleur endroit pour conserver les certificats SSL et les clés privées sur les serveurs Ubuntu ?

L'endroit où vous les mettez n'a pas d'importance tant que vous protégez correctement votre clé privée fichier(s). Le site certificat public est publique ; aucune protection n'est nécessaire - privilèges de serveur ou autre.

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 tous les miens dans un endroit séparé pour des raisons de sauvegarde et autres.

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

Exemple de configuration

Ce billet est destiné à Ubuntu (Debian) + Apache, mais il devrait fonctionner sur la plupart des systèmes.
Il suffit d'appliquer les permissions et de mettre à jour l'emplacement/le chemin dans la configuration donnée (apache/nginx/etc).

Cette réponse suppose également que vous n'utilisez PAS LetsEncrypt/Certbot, ou un service SSL automatisé. Vous avez acheté ou créé un certificat SSL et vous avez obtenu le paquet de fichiers.

Si le SSL fichier(s) clé(s) sont protégés correctement (répertoire et fichiers), tout ira 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

Note :
chmod 710 soutient ssl-cert sous Ubuntu. (Voir les commentaires)
Définir la permission de 700 en /etc/apache2/ssl/private fonctionnera également très bien.

Placez les fichiers SSL :

Mettez le public certificat(s) SSL ET certificat(s) intermédiaire(s) en :
/etc/apache2/ssl (Ce sont *.crt fichiers, normalement)

Mettez les privé Clé(s) SSL dans :
/etc/apache2/ssl/private (Ce sont *.key ou sans extension, normalement)

Note : LetsEncrypt/Certbot utilise l'extension ".pem" pour tous les fichiers SSL (public, chaînes intermédiaires et privé). Mais, vous n'avez pas besoin de déplacer (ou de protéger) ces fichiers. Ils sont déjà en place et protégés. Il suffit de les appeler directement dans votre '.conf' Apache.

Propriétaire du plateau :

Remarque - Si vous ne disposez pas d'un ssl-cert groupe, il suffit de sauter la 2ème ligne :

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

Définir les autorisations :

Certificat(s) public(s)

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

Clé(s) privée(s)

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

Note :
L'autorisation de groupe pour les clés privées est définie sur READ (640) en raison du groupe ssl-cert d'Ubuntu. L'utilisation de '600' (contrôle par le propriétaire uniquement) est la permission normale pour les clés privées et fonctionnera également.

Activez le module SSL d'Apache

sudo a2enmod ssl

Modifiez 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émarrer le service Apache2

sudo service apache2 restart

o

sudo systemctl restart apache2.service

Fait. Testez votre nouveau site SSL.

* Encore une fois, cela va au-delà de la question, mais vous pouvez copier le fichier de configuration du 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 dans un simple fichier 'conf' (Ubuntu/Debian) Apache/SSL. Il pointe normalement vers un certificat SSL auto-signé et une clé (snakeoil), des paquets d'autorité de certification, ainsi que vers les fichiers communs suivants directives utilisé pour un site SSL donné.

Après la copie, éditez simplement le nouveau fichier .conf et ajoutez/supprimez/mettez à jour si nécessaire avec les nouvelles informations/chemins ci-dessus puis exécutez sudo a2ensite mysiteexample-ssl pour l'activer. Recharger/redémarrer apache2. Test.

Toutes les réponses données ici semblent correctes, mais je tiens à mentionner une chose qui, selon moi, pose problème... Si vous devez concaténer votre cert avec des intermédiaires ou des racines pour obtenir un fichier de chaîne, Ne le fais pas. mettez ça dans /etc/ssl/certs car lorsque c_rehash est exécuté, il peut créer des liens symboliques de hachage vers vos certificats en raison des racines ou des intermédiaires qu'ils contiennent.

Puis, plus tard, si vos certificats ont expiré et que vous les supprimez, et que vous ne savez pas comment relancer l'opération c_rehash vous avez peut-être cassé des liens symétriques de hachage dans votre fichier /etc/ssl/certs et des choses bizarres commencent à se produire lorsque votre machine locale essaie de se connecter à elle-même via SSL, et qu'elle ne trouve pas les racines à valider. 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é de vieux fichiers .crt et .pem concaténés que j'avais dans mon ordinateur. /etc/ssl/certs .

En stockant au moins vos chaînes ailleurs, vous évitez ce problème. J'ai fini par faire un /etc/ssl/local_certs pour contenir mes certs et mes chaînes, afin qu'ils ne soient pas perdus dans le fouillis de certs CA que vous trouverez dans /etc/ssl/certs

Sites sont correctes :

• /etc/ssl/certs/ para .crt fichier
• /etc/ssl/private para .key fichier

Propriétaire doit être root:root pour les deux (utiliser sudo chown root:root <file> à modifier si nécessaire).

Permissions :

• 644 para .crt fichier
• 600 para .key fichier

Cela fonctionnera pour nginx .

Il n'y a pas vraiment d'endroit dangereux si la permission pour les fichiers/répertoires individuels est fixée à quelque chose comme chown root :0 private.key y chmod 600 private.key afin que seul l'utilisateur root puisse le lire. Les CSRs et les fichiers de certificats sont moins sensibles comme vous le dites.

Avec ces permissions, les chemins que vous mentionnez et /usr/local/ssl devraient convenir.