2 votes

Risques des certificats auto-signés

Je suis actuellement en train d'utiliser un certificat auto-signé pour des besoins de développement interne et je veux m'assurer que je suis conscient de tout risque de sécurité réel.

Voici comment j'ai configuré les choses.

Certificat Racine

  1. Créé un CA racine .pvk et .cert
  2. Installé le certificat CA racine sur ma machine locale sous "Autorités de certification racines de confiance"
  3. Installé le certificat CA racine sur mon serveur d'hébergement de développement sous "Autorités de certification racines de confiance"

Certificat pour Mon Site

  1. Généré un autre certificat à partir du certificat racine .cert et .pvk
  2. Importé le nouveau certificat en tant que fichier .pfx sur le serveur d'hébergement
  3. Configuré le serveur d'hébergement pour utiliser le nouveau certificat pour mon site dans IIS

À part la clé privée du certificat racine, y a-t-il d'autres éléments de données qui présentent un risque de sécurité si quelqu'un venait à les obtenir?

7voto

Ethabelle Points 2022

Un certificat auto-signé interne n'est pas un risque tant que les gens sont conscients qu'il s'agit d'un certificat auto-signé. Le plus grand risque qu'ils posent est pour les clients.

Par exemple, lors de la distribution à un client et de la connexion initiale, vous voudrez vous assurer qu'ils vérifient que c'est valide, mais à part cela, le seul avantage d'utiliser un fournisseur tiers est que vous n'avez pas à vous soucier d'un attaquant se faisant passer pour votre serveur, mais cela signifie que vous auriez été piraté dès le départ et auriez eu beaucoup d'autres problèmes également.

Par conséquent, le plus grand risque de sécurité est de ne pas informer les gens qu'il s'agit d'un certificat auto-signé et de vérifier son emplacement. Du moins, à mon avis. De plus, ils ne sont pas gérés par une AC, donc vous ne pouvez pas émettre de révocations de certificats et vous devriez réellement refaire la clé si les choses étaient compromises - mais pour un système interne, je ne m'inquiéterais pas vraiment de cela.

2voto

Bruno Points 4069

Votre certificat de site (+ clé privée) doit être traité comme tout certificat de site. Si quelqu'un parvenait à obtenir la clé privée, il pourrait se faire passer pour votre site web. Il y a peu de différence dans la manière dont vous devriez faire confiance au service d'hébergement pour un certificat émis par une AC commerciale.

Les risques sont atténués par le fait que, puisque vous avez créé votre propre AC, peu de personnes feront confiance à cette AC par défaut. Il s'agit d'un risque effectivement limité à ceux qui ont choisi de faire confiance à votre AC.

Il en va de même pour la clé privée de l'AC. Quelqu'un qui mettrait la main sur sa clé privée pourrait émettre n'importe quel certificat.

Les plus gros problèmes viennent du fait que les interfaces utilisateur ont tendance à traiter toutes les AC de confiance de manière équitable (sauf les certificats EV), ou très similaire si l'utilisateur ne fait pas attention. Par conséquent, si un attaquant (a) avait la clé privée de votre AC et (b) connaissait un utilisateur qui fait confiance à ce certificat AC ciblé, il pourrait créer un certificat valide pour n'importe quel site web.

Votre évaluation des risques devrait tenir compte de ceux qui accepteront de faire confiance à cette AC interne. Les AC commerciales ont tendance à avoir des politiques strictes concernant la protection de leurs clés privées (généralement, stockage non-extractible sur des cartes à puce ou similaire) : c'est souvent une exigence pour être approuvé pour inclusion dans la plupart des navigateurs.

Plus spécifiquement à propos des "autres informations". Il peut être important, lors de la conception d'une AC, d'avoir une politique concernant quels attributs et comment les DN du sujet sont structurés par exemple. J'ai connu certaines AC qui faisaient en sorte de ne jamais divulguer explicitement l'identité de l'utilisateur dans le certificat (qui est généralement public et souvent visible pendant le handshaking par un espion), donc le DN du sujet était juste un identifiant interne, connu de l'AC (et éventuellement lié à un nom réel entre le service et l'AC par un canal de rétrorelation chiffré ou un mécanisme similaire).

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X