Une autorité de certification personnalisée est requise si vous souhaitez utiliser https sur votre intranet d'entreprise. Les autorités de certification tierces ne peuvent vous fournir des certificats que pour les domaines publics. Ils ne vous donneront pas de certificats pour intranet.local ou pour tout autre nom d'hôte qui n'est acheminé que dans votre propre réseau. Ainsi, lorsque vous souhaitez avoir un certificat pour votre intranet ou pour l'interface Web de vos propres serveurs, vous devez ajouter une autorité de certification personnalisée et la signer vous-même.

Vous pourriez vous demander "Pourquoi utiliser https sur mon propre réseau "? Il existe actuellement une tendance à tout mettre en œuvre en tant qu'application basée sur un navigateur. Cela signifie que de plus en plus de processus sont gérés via des interfaces Web internes, y compris les plus sensibles. Par exemple, notre société met actuellement en œuvre une application intranet basée sur le Web pour afficher nos propres fiches de paie (et, espérons-le, uniquement les nôtres). Mais dans les grandes organisations, le réseau interne peut devenir si vaste et complexe que vous ne pouvez plus vraiment parler de LAN privé. L'écoute des attaquants internes devient une possibilité qui ne peut pas être supprimée à la main, donc le chiffrement interne devient une précaution raisonnable.

Les certificats sont une question de confiance.

Les autorités de certification sont censées être de confiance dans le monde entier afin que nous puissions nous y fier même si nous ne nous connaissons pas.

Dans les cas où vous communiquez uniquement avec des personnes que vous connaissez ou ... vous-même, comme lorsque vous êtes responsable d'un réseau de machines différentes, vous pouvez choisir de vous fier davantage à vous-même qu'à une CA que vous ne connaissez pas en fait .

Un exemple pourrait être lorsque vous souhaitez créer des tunnels via openVPN entre les ordinateurs que vous gérez.

Vous «espionnez» intentionnellement à des fins de débogage, en utilisant des outils proxy tels que Fiddler ou Charles pour capturer le trafic https.

Ces outils sont souvent utilisés par les développeurs d'applications mobiles, entre autres, pour déboguer les communications client-serveur. Une autorité de certification racine peut être générée et installée sur un appareil mobile, un ordinateur défini comme proxy http de cet appareil, et tout le trafic Web, y compris les détails des en-têtes, des cookies, etc. sera affiché pour le développeur.

Ceci est utile pour comprendre les performances des requêtes réseau, décider s'il faut blâmer le client ou le serveur pour un bogue, ou procéder à l'ingénierie inverse des API existantes.

Une autre réponse (supplémentaire) est que l'autorité de certification privée a un domaine de sécurité différent de celui des autorités de certification publiques.

Une autorité de certification publique certifiera les informations publiques: le fait que le propriétaire de la clé privée correspondant a un droit public particulier au moment de la demande. ils ne se soucient pas vraiment de la ségrégation interne et ne sécuriseront certainement pas les ressources internes (par exemple, l'exemple fourni par @Philipp sur les noms d'hôtes n'appartenant pas au DNS public).

Une autorité de certification privée est une question sécuriser vos ressources internes: il est conçu pour avoir un domaine d'application plus limité: il ne fonctionnera que dans le cadre de votre réseau. Par conséquent, il peut être utilisé pour sécuriser la communication interne et fournir une authentification interne qui n'a que peu ou pas de sens en dehors du réseau.

De plus, leur utilisation est un peu plus sûre: vous pouvez déléguer l'accès plus facilement avec eux. Par exemple, l'administrateur d'une succursale locale pourrait avoir le droit nécessaire d'émettre des certificats pour les systèmes et les personnes sous son contrôle sans avoir à lui déléguer l'identité d'entreprise complète.

Une autre raison pour laquelle une organisation peut souhaiter installer un certificat racine est le filtrage de contenu. Mon lycée avait un filtre de contenu juste avant le pare-feu, destiné à empêcher les étudiants d'accéder à divers types de contenu. Cependant, il n'a pas fait un très bon travail de filtrage des connexions HTTPS - parfois il bloquait en fonction de l'adresse IP, mais il avait tendance à être très lourd sur certains sites (bloquant toute l'adresse IP) et à ne pas filtrer du tout sur d'autres (donnant un accès complet et non filtré). Par exemple, les élèves ont rapidement compris qu'ils pouvaient accéder à Facebook s'ils tapaient https: // facebook.com . (Je pense que le filtre de contenu était suffisamment ancien pour ne pas non plus prendre en charge l'indication du nom du serveur.)

Peu de temps avant mon diplôme, ils ont installé un nouveau filtre de contenu qui fournissait un filtrage complet du trafic HTTPS. Ils ont installé une autorité de certification racine sur tous les ordinateurs et le pare-feu créait des certificats à la volée pour les sites Web HTTPS. Cela permettait le blocage basé sur les URL (plutôt que le blocage beaucoup plus grossier basé sur le nom d'hôte qu'ils auraient dû utiliser s'ils n'avaient pas usurpé les certificats), de sorte que, par exemple, ils pouvaient désormais permettre aux étudiants de regarder des vidéos YouTube tout en bloquant d'autres.

Fait intéressant, le pare-feu avait une option pour détecter le trafic vers les sites bancaires, avec un gros avertissement pour laisser l'option désactivée pour la sécurité. (Il y avait probablement une liste blanche de domaines financiers.)

Si j'exécutais un réseau d'entreprise et que je voulais garder un œil sur ce que faisaient mes employés, je créerais un serveur de certificats et configurerais tous les ordinateurs clients pour qu'ils ne fassent confiance qu'aux certificats de ce serveur. Je demanderais alors à ce serveur d'émettre ses propres certificats pour tous les sites que mes employés pourraient avoir besoin d'utiliser.Mes employés utiliseraient alors volontiers leur gmail, Facebook, etc. , mais par mon propre serveur CA réseau interne. Leur trafic réseau non chiffré complet peut ensuite être enregistré et surveillé par le serveur proxy du réseau.

J'ai une opinion à ce sujet (et ce n'est qu'une opinion).

"La seule raison à laquelle je pense est de forcer les ordinateurs du réseau à faire confiance à vos propres certificats auto-signés au lieu de les obtenir signé numériquement par une autorité de certification tierce. "

Si vous n'ajoutez qu'une seule autorité de certification racine, il est peu probable que le certificat auto-signé au sens traditionnel du terme soit affiché, il s'agit d'un certificat signé par une autorité de certification interne (bien que ce certificat de l'autorité de certification sera auto-signé). À moins que vous ne frappiez le même certificat sur chaque boîte, ce serait une idée très stupide. Il vous suffit de signer le certificat correct avec celui-ci, puis de verrouiller à nouveau cette autorité de certification, ne lui donnant jamais accès au réseau et les demandes de signature sneakernet en cas de besoin.

De plus, il est préféré (par moi) à un certificat générique en tant que compromis de un hôte ne peut conduire à l'interception que de cet hôte (ce qu'il ferait probablement de toute façon) plutôt que de tout ce qui se trouve dans ce domaine.

Enfin, une autorité de certification tierce est pour moi une ligne de confiance inutile sur un réseau interne . Vous pouvez contrôler vos propres politiques internes mais pas les leurs - bien sûr, si elles sont corrompues / compromises, elles peuvent toujours vous foutre en l'air à moins que vous ne fassiez confiance UNIQUEMENT à votre propre autorité de certification.J'ai donc des sentiments mitigés sur ce point.

Si vous protégez suffisamment ce certificat CA, il n’est pas moins sécurisé qu’un tiers et, à mon avis, plus sûr qu’un certificat générique.