61 votes

Pourquoi dois-je acheter un certificat SSL alors que je peux en générer un localement ?

J'ai du mal à comprendre pourquoi nous devons acheter des certificats SSL alors que nous pouvons les générer localement en utilisant openSSL. Quelle est la différence entre le certificat que j'achète et un certificat de test que je génère localement ? S'agit-il simplement d'une grosse arnaque ?

17 votes

En ce qui concerne le Triade de la CIA pour la sécurité des informations, les certificats auto-signés fournissent confidentialité y intégrité (c'est-à-dire qu'elles permettent l'envoi de messages cryptés entre deux parties), mais seules les certitudes signées par une source de confiance fournissent des garanties de sécurité. authenticité (c'est-à-dire que l'autre partie de votre conversation cryptée est bien celle que vous pensez qu'elle est).

10 votes

Il faut espérer que, lorsque les DNSSEC entreront en jeu, les gens pourront créer leur propre certificat et le stocker dans un enregistrement DNS. La chaîne de confiance DNSSEC serait alors suffisante pour prouver que le certificat appartient au propriétaire du domaine. (Je ne pense pas qu'il s'agisse d'une spécification formalisée (pour l'instant), mais ce serait bien).

2 votes

Pour un usage interne, vous pouvez déployer le certificat en tant que certificat de confiance en utilisant la stratégie de groupe (sous Windows).

73voto

Shlomi Fish Points 1951

Un seul mot : la confiance. T

Sinon, je pourrais créer mes propres certificats pour google.com ou yourbank.com et me faire passer pour eux.

Les certificats payants ne fournissent pas de niveau de cryptage supplémentaire par rapport aux certificats auto-signés (généralement). Mais un certificat auto-signé provoquera une erreur dans le navigateur.

Oui, certaines parties du SSL sont une escroquerie (un certificat verisign contre un geotrust où verisign est jusqu'à 100x plus cher) mais pas tout.

S'il ne s'agit que d'éléments internes, il n'est pas nécessaire d'utiliser un certificat payant, car vous pouvez employer vos propres méthodes de confiance (par exemple, ne rien faire, ou simplement vérifier les empreintes digitales).

8 votes

S'il ne s'agit que d'affaires internes, vous pouvez déployer votre certificat comme étant de confiance en utilisant la politique de groupe.

2 votes

D'autre part, la signature du conducteur est un peu une arnaque. Pour ce que c'est, oui c'est une énorme arnaque, mais nous n'avons pas le choix. successfulsoftware.net/2008/02/27/

2 votes

@Matt - J'ai déjà lu cet article ; lorsque nous envisagions de faire de la signature de code au travail. Nous avons décidé de nous contenter de l'auto-signature et de conseiller aux gens de vérifier les signatures. Heureusement, nous avons des utilisateurs qui utilisent des technologies de pointe (pour la plupart).

23voto

Anonimous Points 23

L'objectif d'un certificat SSL est de permettre au navigateur d'avoir un degré raisonnable de confiance dans la clé publique du serveur pour les transactions HTTPS.

Tout d'abord, voyons ce qui se passerait si nous n'utilisions pas de certificats. Au lieu de cela, le serveur enverrait la clé publique en clair et le navigateur initierait une communication cryptée en l'utilisant (la première chose qu'il ferait serait de crypter sa propre clé publique et de l'envoyer en toute sécurité). Et si moi, un attaquant, je me plaçais au milieu ? Je pourrais remplacer votre clé publique à la volée par la mienne, établir une connexion cryptée avec le navigateur, décrypter toutes les données que je reçois, les crypter avec votre clé publique et les envoyer (et vice versa pour le trafic de type réponse). Aucune partie ne remarquerait la différence, puisque personne ne connaît les clés publiques au préalable.

OK, donc nous avons établi que nous avons besoin d'un moyen pour le navigateur de faire confiance à ma clé publique. Une façon de le faire serait de stocker toutes les clés publiques enregistrées dans le navigateur. Bien sûr, cela nécessiterait une mise à jour à chaque fois que quelqu'un enregistre une clé publique, ce qui entraînerait une surcharge de travail. On pourrait également conserver les clés publiques dans les mains des serveurs DNS. 1 mais les serveurs DNS peuvent également être usurpés et le DNS n'est pas un protocole sécurisé.

La seule option qui reste est donc de "chaîner" la confiance par un mécanisme de signature. Le navigateur stocke les coordonnées de quelques autorités de certification, et votre certificat sera envoyé avec une chaîne d'autres certificats, chacun signant le suivant et remontant jusqu'à l'autorité de certification racine/de confiance/en construction. C'est le rôle de l'autorité de certification de s'assurer que le domaine vous appartient avant de signer un certificat pour vous.

Étant donné qu'être CA est une entreprise, ils facturent pour cela. Certains plus que d'autres.


Si vous avez créé votre propre certificat, vous obtiendrez une erreur similaire à celle-ci :

enter link description here

Un certificat non signé n'a aucune valeur. C'est comme prendre un crayon et un livret, et dessiner un passeport qui prétend que vous êtes Barack Obama. Personne ne le croira.

1. Après tout, votre entrée DNS est créée lorsque vous enregistrez un domaine. L'utilisation d'un protocole plus robuste qui vous permet d'enregistrer simultanément des clés publiques serait un concept intéressant.

0 votes

Vous pouvez également utiliser l'agrafage DNSSEC pour votre certificat SSL, afin que le certificat provienne (en dernier ressort) de l'ICANN en tant que CA, plutôt que d'une autre autorité de certification. Aucun des navigateurs actuels ne prend en charge cette fonctionnalité, même si Chrome le faisait auparavant.

0 votes

Et aujourd'hui, vous avez DANE et ses enregistrements DNS TLSA qui vous permettent de limiter certains services à des clés spécifiques ou à des AC spécifiques.

5voto

Shashank Agrawal Points 119

Il n'y a pas de différence technique (vos propres certificats ne sont pas moins sûrs), mais seulement une différence organisationnelle : Le certificat de votre autorité de certification ne fait pas partie de l'installation standard des navigateurs. Cela rend inconfortable pour la plupart des gens de se connecter à votre certificat. Mais cela n'aurait pas de sens d'acheter un certificat pour un réseau interne.

5voto

Ibungo Points 250

La réponse à votre question dépend de votre public : Puisque tout le système des certificats est basé sur la "confiance", vos utilisateurs doivent avoir la possibilité de prouver vos certificats eux-mêmes ou de faire confiance à une tierce partie qui a fait ces vérifications et qui montre le succès en signant votre certificat. Le terme "pour prouver vos certificats" que j'ai utilisé est un peu inexact : la version longue devrait être : "pour prouver que vous êtes le propriétaire du certificat et que vous êtes autorisé à l'utiliser".

Si tous vos utilisateurs vous connaissent en personne et ont la capacité technique de prouver que votre certificat a été émis par vous-même, il n'y a pas de nécessité technique d'utiliser un certificat d'un fournisseur "certifié". Dans ce cas, le certificat auto-signé peut même être meilleur que celui d'un de ces fournisseurs.

Mais dans la plupart des cas, les utilisateurs n'ont pas la possibilité d'effectuer ce processus par eux-mêmes. C'est là que les fournisseurs SSL entrent en scène. Ils offrent le service de faire ces vérifications et expriment le résultat des vérifications en signant le certificat. Mais il faut garder à l'esprit un fait important : en signant un certificat, un fournisseur SSL indique qu'il a vérifié l'identité de l'émetteur du certificat conformément à sa propre politique de signature. L'utilisateur doit donc décider si cette politique est suffisamment précise et s'il peut faire confiance au fournisseur.

4voto

L'essentiel est que, si le certificat est autogénéré, les utilisateurs ordinaires n'ont aucun moyen de vérifier sa véracité. Pour un certificat acheté, ils sont censés au moins vérifier que ce qui est imprimé à l'intérieur du certificat est correct. Idée : si vous indiquez votre téléphone et votre adresse dans le certificat, l'autorité de certification est censée les vérifier, mais elle le fait rarement.

En outre, les certificats d'achat sont traçables, ce qui signifie que l'utilisateur peut toujours savoir d'où vient le certificat, alors qu'un certificat auto-signé n'est qu'une identité aléatoire.

Pour de nombreux systèmes, la "signature de code" était requise par le passé auprès d'une autorité de certification autorisée, ce qui est conforme à la politique, mais comme les certificats auto-signés sont si nombreux, cette exigence n'est plus appliquée à 100%.

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