11
votes

Certificats SSL signés pour une utilisation interne

J'ai une application distribuée composée de nombreux composants qui communiquent sur TCP (pour examiner JMS) et http. Tous les composants fonctionnent sur du matériel interne, avec des adresses IP internes et ne sont pas accessibles au public.

Je tiens à sécuriser la communication en utilisant SSL. Est-il logique d'acheter des certificats signés d'une autorité de certification bien connue? Ou devrais-je simplement utiliser des certs auto-signés?

Ma compréhension de l'avantage des certificats de confiance est que l'autorité est une entité qui peut être confiée par le grand public - mais ce n'est qu'un problème lorsque le grand public doit être sûr que l'entité d'un domaine particulier est de savoir qui Ils disent qu'ils sont.

Par conséquent, dans mon cas, où la même organisation est responsable des composants aux deux extrémités de la communication et que tout se situe entre les deux, une autorité de confiance publiquement serait inutile. En d'autres termes, si je génère et signer un certificat pour mon propre serveur, je sais que c'est digne de confiance. Et personne de l'extérieur de l'organisation ne sera jamais demandé de faire confiance à ce certificat. C'est mon raisonnement - suis-je correct, ou y a-t-il un avantage potentiel d'utiliser des certs d'une autorité connue?


1 commentaires

vous avez raison. Il n'y a rien d'autre à dire.


3 Réponses :


0
votes

Je dirais que c'est raisonnablement sûr, sauf si vous pensez qu'un infiltrator Ninja va échanger votre serveur sur vous.

La tierce partie est là pour rendre plus difficile la «up & générer» un nouveau cert. Quelqu'un pourrait recréer un certificat auto-signé sur une nouvelle machine avec les mêmes détails, ce ne serait pas le même cert, vous devez y ajouter une exception aussi, mais vos utilisateurs ne connaissaient probablement pas la différence .


3 commentaires

Ce n'était pas ma compréhension des autorités de confiance. Mais je suis un débutant à ce sujet! Je pensais que l'idée était que l'idée d'avoir un certificat d'une autorité de confiance vous permet de persuader le grand public que vous pouvez faire confiance. Le point clé (aucun jeu de mots prévu) serait que un certificat payé n'est pas plus difficile à générer qu'un auto-signé - c'est simplement qu'il vient de quelqu'un qui fait confiance à tout le monde. Donc, c'est comme la différence entre faire une carte d'identité vous-même et en obtenir un du gouvernement. Vous pouvez faire un unique, inoubliable vous-même, mais vous ne pouvez pas vous attendre à ce que quelqu'un d'autre l'accepte?


Pour élaborer plus loin, cette réponse couvre le rôle de la CA: Stackoverflow.com/questions/188266/... "Votre navigateur Web est installé avec les clés publiques de toutes les principales autorités de certificats. Il utilise cette clé publique pour vérifier que le certificat du serveur Web a été signé par le certificat de confiance. autorité." En d'autres termes, l'utilisation d'une CA de confiance ne signifie pas que le certificat n'a pas été volé, forgé ou spoofed - seulement qu'il a été publié à l'origine par l'entité selon laquelle le serveur affirme qu'il a été émis par.


-1. Exécuter votre propre ca (éventuellement hors ligne) le rend tout aussi difficile à "générer un nouveau cert" comme avec n'importe quel ca. La différence est l'inclusion par défaut dans les navigateurs.



5
votes

Il n'est pas nécessaire que vous utilisiez un CA externe pour un projet communautaire fermé. Dans de nombreuses grandes organisations, elles exploitent une PKI interne pour émettre des certificats pour des projets internes comme celui-ci. Un avantage de l'utilisation d'un PKI est que vous pouvez configurer une relation de fiducie entre les différents composants basés sur un seul certificat de racine de racine et une ancrage de confiance en toute sécurité.

Toutefois, si le projet permettait aux utilisateurs internes de se connecter de manière sécurisée à un service interne via leur navigateur Web, vous pouvez envisager d'envisager d'utiliser un certificat publié par CA émis. L'alternative consiste à vous assurer que chaque navigateur devait être connecté à votre service de confiance de votre certificat racine; Ceci est pour empêcher les messages d'avertissement du navigateur.


4 commentaires

Il est facile d'inclure votre propre CA dans les navigateurs de vos utilisateurs avec une gestion centralisée. Les avertissements de navigateurs ne sont pas une raison valable de gaspiller de l'argent sur une Ca.


@Hop Pas toujours dans une grande organisation avec une base d'utilisateurs complexe et un contrôle de changement lourd. Dans ces environnements, si vous devez fournir un service sécurisé aux utilisateurs du navigateur, il peut être moins cher et moins problématique de simplement obtenir un certificat CA Public.


Cela ressemble à un type d'organisation dysfonctionnelle qui éliminerait toutes les CAS commerciales de la paranoïa en premier lieu. N'essayez pas de constituer des arguments idiotes qui - même s'ils étaient valables - n'auraient qu'une influence de petite fraction des utilisateurs. Merci.


@HOP, vous devez obtenir une expérience mondiale plus réelle; En tant que consultant, j'ai visité de nombreuses organisations qui utilisent des certificats publics en interne pour cette raison même - y compris plusieurs banques.



0
votes

Tant que votre système fonctionne à l'intérieur de votre groupe et qu'il n'y a pas de prévoir de l'agrandir (et les plans changent, alors gardez cela à l'esprit), il convient tout à fait de configurer votre propre infrastructure PKI.

Si vous finissez par développer au-delà de votre organisation, tout ce que vous avez à faire est de distribuer votre certificat racine aux parties que vous communiquerez. Cela donne en fait un bon contrôle grainé à vos partenaires Combien de confiance qu'ils souhaitent mettre en vous vs l'infrastructure de l'autorité de certification publique.


0 commentaires