Dois-je rejeter une CSR lorsque l'hôte m'a envoyé la clé privée pour la demande de certificat SSL?
Je viens de demander une CSR à mon hébergeur mutualisé, pour générer un certificat que je leur renverrai pour l'installer. (Le certificat lui-même doit être généré correctement par une organisation pour laquelle je travaille qui peut fournir des certificats pour notre usage officiel.) L'hébergeur m'a rapidement envoyé la CSR mais aussi la clé privée! Ils ont même CC quelqu'un d'autre, et c'est dans Gmail, donc Google l'a probablement déjà ingéré à des fins publicitaires.
À mon humble avis, cela semble être une chose terrible à faire. Je suis sur le point de leur écrire en rejetant celui-ci, et en demandant de renouveler le CSR et cette fois de garder la clé privée - privée.
Avant de me ridiculiser, je voudrais confirmer que la clé privée d'un certificat "SSL" (TLS) ne doit jamais quitter le serveur?
Je travaille dans des secteurs liés à la sécurité depuis de nombreuses années et j'étais un programmeur de crypto, donc je sens que je connais un peu le sujet - mais je sais que les choses changent avec le temps.
J'ai lu cette question connexe: Quels problèmes découlent du partage de la clé privée d'un certificat SSL?
Meta Update: J'ai réalisé que j'avais écrit un format de question de mauvaise qualité pour Stack Exchange - car il est maintenant difficile d'accepter une réponse spécifique. Toutes mes excuses - toutes les réponses couvraient des aspects différents et tout aussi intéressants. Je me suis d'abord demandé comment le rédiger à cet effet, mais j'ai dessiné un blanc.
Mise à jour: j'ai suivi cela avec l'hôte et ils se sont excusés pour tout inconvénient, ont promis de garder les futures clés privées "en sécurité" et m'ont émis une nouvelle CSR différente. Que ce soit généré à partir de la même clé privée exposée, je ne suis actuellement pas sûr de. Je me demande maintenant également, car c'est un hôte partagé, s'ils m'ont envoyé la clé pour l'ensemble du serveur ou si chaque client/domaine/hôte virtuel obtient une paire de clés.
C'est une leçon intéressante sur la façon dont toute la force de la crypto dans le monde peut être rendue nulle et non avenue par une simple erreur humaine. Kevin Mitnik hochait la tête.
Mise à jour 2: En réponse à une réponse de l'utilisateur @Beau, j'ai utilisé les commandes suivantes pour vérifier que le deuxième CSR a été généré à partir d'une autre clé privée secrète.
openssl rsa -noout -modulus -in pk1.txt | openssl md5
openssl req -noout -modulus -in csr1.txt | openssl md5
openssl req -noout -modulus -in csr2.txt | openssl md5
Les deux premiers hachages sont identiques, le troisième est différent. C'est donc une bonne nouvelle.
Si j'étais à votre place, je refuserais d'accepter ce certificat SSL. La raison en est que si quelqu'un s'introduisait dans l'un des e-mails qui ont reçu la clé privée, il serait en mesure de la télécharger, puis d'usurper l'identité du serveur dans différentes attaques contre des clients, comme l'homme au milieu ou similaire. Dans le cas également où l'une des adresses e-mail de réception a été écrite de manière incorrecte, quelqu'un peut déjà avoir la clé privée. Il existe également probablement de nombreux autres scénarios dans lesquels cette clé privée pourrait être téléchargée et utilisée par un attaquant.
Il doit également être important d'avertir la société du fait de ne pas partager la clé privée, pour vous assurer qu'elle ne vous enverra pas la clé privée ailleurs - la clé privée vous a été envoyée, ainsi que d'autres CC dans ce courrier électronique, mais vous ne pouvez pas savoir si l'entreprise n'a pas envoyé un e-mail séparé avec la clé privée ailleurs.
Il y a une raison pour laquelle la clé privée est appelée une clé privée
Veuillez noter qu'il s'agit principalement de mon opinion personnelle et que je ne suis pas un expert en SSL.
Oui, vous devez absolument rejeter la RSE. De plus, vous devez changer votre hébergeur car il semble qu'ils ne savent pas ce qu'ils font.
Il est déjà assez mauvais qu'ils vous aient envoyé la clé privée par e-mail, c'est-à-dire via un support non sécurisé. Cependant, ils l'ont également remis à quelqu'un d'autre, ce qui constitue une violation totale de la confidentialité.
De plus, je me demande pourquoi ils vous ont envoyé la clé privée - elle est censée être installée sur le serveur, ce qu'ils peuvent faire par eux-mêmes.
Oui, vous devez définitivement rejeter la RSE.
Quant à savoir si vous devez reconsidérer le fournisseur d'hébergement, cela dépend.
Ils ont même CC'd quelqu'un d'autre,
Y a-t-il des raisons pour lesquelles la société d'hébergement devrait connaître la structure interne de votre entreprise? La personne qui fait cela est-elle un gestionnaire de compte désigné qui a été spécifiquement affecté à votre entreprise et qui est responsable de savoir qui est qui dans votre entreprise? Votre entreprise a-t-elle suffisamment informé le responsable de compte de la façon dont votre entreprise est structurée et qui est autorisé à faire quoi? Si ce n'est pas le cas, c'est peut-être en partie la faute de (votre entreprise) de ne pas leur avoir expliqué clairement comment ils devraient vous envoyer la clé.
Dans la plupart des comptes d'hébergement, si vous n'avez pas de gestionnaire de compte désigné qui connaît votre secteur d'activité, vous devriez avoir expliqué très clairement à leur support technique comment vous envoyer les clés, qui devrait les recevoir et si vous souhaitez ou non recevoir la clé en premier lieu. Ne présumez pas qu'un personnel de support technique connaît la situation de votre entreprise et ne supposez jamais qu'un personnel de support technique qui n'est pas votre responsable de compte désigné se souviendra de qui vous êtes lors d'une précédente interaction.
et c'est dans Gmail
Vous vous rendez compte que l'envoi d'un CSR par e-mail n'est pas non plus très sûr, n'est-ce pas? Il est tout à fait possible pour quelqu'un (un initié travaillant dans Gmail ou un APT), d'intercepter l'e-mail contenant la CSR, de remplacer la CSR que l'hôte vous envoie par sa propre CSR et de signer la CSR de la société d'hébergement à la société d'hébergement elle-même. Cela leur permettrait d'utiliser plus tard les certificats falsifiés pour MITM entre vous et vos utilisateurs et la société d'hébergement.
Une CSR doit être délivrée via un canal authentifié (par exemple, ils soumettent le certificat à un site HTTPS que vous contrôlez ou ils doivent signer la CSR avec une clé GPG qu'ils publient sur leur site), ou au moins vous devez faire une vérification des empreintes digitales et les deux vous et votre hôte devez avoir un moyen d'identifier et d'authentifier l'autre partie. La mise en place d'un canal authentifié peut être un processus assez compliqué, et n'est pas quelque chose qui sera disponible chez un fournisseur d'hébergement à moindre coût ou ceux qui ne sont pas spécialisés dans l'hébergement professionnel haute sécurité.
Si vous ne spécifiez pas comment votre entreprise exige que la RSE soit livrée, et surtout si vous n'êtes pas géré par un gestionnaire de compte qui devrait savoir quel type d'entreprise vous faites, alors la plupart des hébergeurs supposeront raisonnablement que vous êtes un minimum société de sécurité. La plupart des personnes travaillant dans une entreprise à sécurité minimale considéreraient qu'une copie de la clé privée a une valeur supérieure à la sécurité de ne pas contrôler la clé, il n'est pas déraisonnable pour eux de le supposer.
Avant de me ridiculiser, je voudrais confirmer que la clé privée d'un certificat "SSL" (TLS) ne doit jamais quitter le serveur?
Cela dépend, il peut y avoir de bonnes raisons de quitter le serveur. Par exemple, vous souhaiterez peut-être utiliser le même certificat sur plusieurs serveurs ou vous voudrez peut-être une clé de sauvegarde pour le verrouillage des clés.
Mais il absolument doit être traité comme un secret précieux, uniquement stocké sur des machines en qui vous avez confiance et s'il doit se déplacer entre les systèmes, il doit le faire de manière sécurisée.
Mon conseil serait de s'éloigner de ces clowns immédiatement.
Ils voulaient probablement que vous ayez la paire clé/certificat complète au cas où vous voudriez l'utiliser ailleurs.
Avoir la clé privée flottante est un problème de sécurité légitime, en particulier si vous n'allez pas l'utiliser. Expliquez que ce certificat est uniquement destiné au fournisseur d'hébergement et demandez-lui de réémettre la CSR et de l'envoyer sans clé privée. Vérifiez que l'empreinte numérique de la RSE change.
On dirait qu'ils traitent le certificat comme un moyen de faire apparaître un verrou vert plus que comme un dispositif de sécurité, ce qui est probablement un signe d'avertissement. Envisagez un hébergement différent si cela est possible et/ou si votre site traite des informations très sensibles.
Ils sont totalement incompétents en matière de sécurité. Une clé privée est, euh, privée, par définition. Il sert à identifier légalement son propriétaire. Ils ont rendu possible la falsification et l'usurpation d'identité.
Vous devrait envoyer eux le CSR, après l'avoir généré vous-même à partir de votre paire de clés privée/publique, et they devrait vous envoyer le certificat signé et sa chaîne d'authentification. Rien d'autre.
S'ils vous envoient des clés privées et des CSR, leur modèle entier est cassé.
Changez de fournisseur et récupérez votre argent. Au moins. Ils ont compromis votre sécurité, une action en dommages et intérêts peut donc être engagée. Au moins, vous pouvez les menacer avec cela pour faciliter le processus de remboursement.