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 lorsque 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? Est-ce juste une grosse arnaque?
Un mot - confiance. Le certificat SSL d'un fournisseur auquel votre navigateur fait confiance signifie qu'il a au moins effectué une vérification de base pour dire que vous êtes bien ce que vous dites être.
Sinon, je pourrais créer mes propres certificats pour google.com ou yourbank.com et faire semblant d'être eux.
Les certificats payés ne fournissent aucun niveau de cryptage supplémentaire par rapport à l'auto-signature (généralement). Mais un certificat auto-signé entraînera une erreur du navigateur.
Oui, certaines parties de SSL sont une arnaque (un certificat Verisign vs un géotrust où Verisign est jusqu'à 100 fois plus cher) mais pas tout.
Si tout cela est interne, il n'est pas nécessaire d'avoir un certificat payant car vous pouvez utiliser vos propres méthodes de confiance (par exemple, ne rien faire, ou peut-être simplement vérifier les empreintes digitales).
L'intérêt d'un certificat SSL est que le navigateur ait un degré de confiance raisonnable dans la clé publique du serveur pour les transactions HTTPS.
Voyons d'abord ce qui se passerait si nous n'utilisions pas de certificats. Au lieu de cela, le serveur enverrait la clé publique en texte brut et le navigateur lancerait une communication chiffrée à l'aide de celle-ci (la première chose qu'il ferait serait de chiffrer sa propre clé publique et de l'envoyer en toute sécurité). Et si moi et l'attaquant, je me suis coincé au milieu? Je pourrais remplacer votre clé publique à la volée par la mienne, avoir une connexion chiffrée avec le navigateur, déchiffrer tout ce que je reçois, chiffrer avec votre clé publique et l'envoyer (et vice versa pour le trafic de type réponse). Aucune partie ne remarquerait la différence, car personne ne connaissait les clés publiques à l'avance.
OK, nous avons donc établi que nous avons besoin d'un moyen pour que le navigateur fasse confiance à ma clé publique. Une façon de procéder 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 a enregistré une clé publique, ce qui conduirait à des ballonnements. On pourrait également garder les clés publiques entre les mains des serveurs DNS1, mais les serveurs DNS peuvent également être usurpés et DNS n'est pas un protocole sécurisé.
La seule option qui reste est donc de "chaîner" la confiance via un mécanisme de signature. Le navigateur stocke les détails de quelques autorités de certification, et votre certificat sera envoyé avec une chaîne d'autres certificats, chacun signant le suivant et remontant à l'autorité de certification racine/approuvée/intégrée. Il appartient à 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 cela. Certains plus que d'autres.
Si vous avez créé votre propre certificat, vous obtiendrez une erreur similaire à:
Il n'y a aucune valeur pour un certificat non signé. C'est comme prendre un crayon et un livret, dessiner un passeport qui prétend que vous êtes Barack Obama. Personne ne lui fera confiance.
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.
La réponse à votre question dépend de votre public: étant donné que l'ensemble du système de certificats est basé sur la "confiance", vos utilisateurs doivent avoir la disponibilité pour vérifier eux-mêmes vos certificats ou faire confiance à une tierce partie qui a effectué ces vérifications et 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 personnellement et ont la capacité technique de prouver que votre certificat a été émis par vous-même, il n'est pas nécessaire techniquement 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 eux-mêmes. Ici, ces fournisseurs SSL arrivent sur le marché. Ils offrent le service pour effectuer ces contrôles et exprimer le résultat des contrôles en signant le certificat. Mais un fait important à garder à l'esprit est le suivant: en signant un certificat, un fournisseur SSL exprime qu'il a vérifié l'identité des émetteurs de certificats 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.
Le point principal est que, si le certificat est auto-généré, les utilisateurs ordinaires n'ont aucun moyen de vérifier sa véracité. Pour un certificat acheté, ils supposent qu'au moins vérifié ce qui est imprimé à l'intérieur du certificat est correct. Idée: si vous mettez votre téléphone et votre adresse dans le certificat, l'autorité de certification suppose de les vérifier, mais ils le font rarement.
De plus, les certificats d'achat sont traçables, ce qui signifie que l'utilisateur peut toujours retracer d'où vient le certificat, tandis qu'un certificat auto-signé n'est qu'une identité aléatoire.
Pour de nombreux systèmes, la "signature de code" était nécessaire dans le passé auprès d'une autorité de certification autorisée, qui est régie par des règles, mais comme les certificats auto-signés sont si nombreux, ils ne sont plus appliqués à 100% maintenant.
Il n'y a pas de différence technique (les vôtres ne sont pas moins sécurisées) mais 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 aucun sens d'acheter un certificat pour un réseau interne.
Récemment, LetsEncrypt a annoncé la disponibilité de leurs outils de ligne de commande pour générer des certificats valides.
Aucun e-mail de validation, aucune modification de configuration compliquée, aucun certificat expiré ne brise votre site Web. Et bien sûr, parce que Let’s Encrypt fournit des certificats gratuitement, pas besoin d’organiser le paiement.
Pour ceux qui se demandent si ces certificats sont valides dans les principaux navigateurs, la réponse est oui:
Le 19 octobre 2015, les certificats intermédiaires ont été signés par IdenTrust, ce qui a fait que tous les certificats émis par Let's Encrypt ont été approuvés par tous les principaux navigateurs. [20]
..... Le 8 mars 2016, Let's Encrypt a émis son millionième certificat après sept mois d'existence. [39]
Le 12 avril 2016, Let's Encrypt a quitté la version bêta.
Lien pour l'administrateur système et les développeurs: https://letsencrypt.org/getting-started/
À l'ère de la technologie de la blockchain et de l'élimination des systèmes de confiance tiers, il était temps que la délivrance de certificats coûteux par quelques autorités choisies commence à être remise en question.
Bien que Letsencrypt n'ait rien à voir avec la technologie de la blockchain, c'est un début dans la bonne direction. Il est à espérer que la nécessité de payer une redevance élevée chaque année à une autorité de certification coûteuse tire à sa fin.
Cela revient à faire confiance. Un fournisseur SSL "certifié" est censé être réputé (bien que cela puisse être manipulé) par rapport à un certificat auto-signé du serveur lui-même.
Si votre organisation a sa propre signature de certificat, cela est parfaitement acceptable et ne devrait pas provoquer d'avertissement pour les utilisateurs (à condition qu'ils utilisent votre trousseau de certificats comme source de confiance), mais créera toujours un avertissement si vous essayez de l'utiliser en externe.
En résumé: pour un usage interne, c'est bien, si vous le fournissez à un client payant en externe, ne pas avoir d'avertissement est une tranquillité d'esprit. Vous sentiriez-vous plus en sécurité que vos transactions financières passent par une source accréditée, ou un gars debout dans la rue que vous ne connaissez pas vraiment?
Autrement dit, un certificat SSL auto-signé ne signifie rien. Il n'a aucune valeur pour le monde extérieur. C'est comme dire "Je possède l'Espagne". Vous pourriez honnêtement penser que vous le faites, mais personne ne va reconnaître votre demande.
Une analogie similaire consisterait à inventer quelque chose et à revendiquer ensuite que vous détenez les droits sur l'invention, mais à moins que vous n'ayez déposé un brevet au bureau, il sera difficile de vous fier à votre mot, n'est-ce pas?
L'intérêt d'un certificat est qu'il est signé par une autorité à laquelle les gens font confiance. Si un site Web possède un certificat SSL valide, cela signifie que le propriétaire a pris la peine d'enregistrer son site Web, de payer pour le certificat SSL et d'obtenir la certification officielle d'une autorité de certification du monde réel, il ne s'agit donc probablement pas d'un site Web d'hameçonnage bon marché. D'autre part, si vous faites confiance aux certificats auto-signés, alors ledit site Web de phishing pourrait simplement générer son propre certificat falsifié (que vous accepterez avec plaisir) et le tour est joué.
Bien sûr, s'il s'agit d'un réseau interne sur un intranet privé, vous vous faites probablement déjà confiance, alors dans ce cas, un certificat faisant autorité n'ajoute vraiment rien, vous pouvez donc ignorer en toute sécurité les lumières rouges vives que votre navigateur vous lancera. . Idem pour les petits sites Web où vous voulez toujours que le trafic client-serveur soit chiffré mais votre modèle de menace ne garantit pas une authentification forte, auquel cas vous pouvez vous en tirer avec un certificat auto-signé et accepter le (négligeable par votre modèle de menace) risque de MITM.
Ce qui est probablement satisfaisant compte tenu du coût élevé des certificats SSL de confiance.
En d'autres termes, un certificat auto-signé revient à dire "je certifie que je suis qui je suis - croyez-moi!".
Pour faire court et simple ... et démystifier un peu ce qui a été dit ...
Ce n'est pas le problème de cryptage, avec des outils appropriés, vous pouvez générer un certificat localement avec le type de cryptage que vous souhaitez ... et obtenir un certificat valide.
Le principal avantage que vous avez lors de l'achat d'un certificat auprès d'une entité de certification est que pendant la période de validité du certificat, ils détiennent dans leurs serveurs un mécanisme pour valider tout ce que vous avez signé avec votre certification en ligne ...
Vos PC n'ont pas besoin d'être connectés pour que vos produits numériques soient vérifiés et validés avec votre certificat ... vous devez rediriger la validation vers l'entité de certification.
Désolé de participer à cette discussion si tard - j'ai pensé qu'il valait la peine de souligner qu'en utilisant openssl, il est possible de configurer une autorité de certification privée, avec son propre certificat racine, puis de créer des certificats de serveur signés par cette autorité de certification. À condition que le certificat racine de l'autorité de certification soit importé dans le navigateur et que le navigateur soit invité à l'accepter, le certificat de serveur sera accepté sans commentaire. (Évidemment, ce n'est une option viable que si la communauté d'utilisateurs est petite et que les utilisateurs se connaissent tous personnellement.)