Qu'est-ce que SSL/TLS/HTTPS, cryptage symétrique et asymétrique + certificat + CA

Qu'est-ce que SSL/TLS

aperçu

SSL (Secure Socket Layer)

SSL (Secure Socket Layer) est un ensemble de protocoles de sécurité des données Internet développé par Netscape, la version actuelle est la 3.0. Le protocole SSL se situe entre le protocole TCP/IP et divers protocoles de couche application , fournissant un support de sécurité pour la communication de données . SSL est à la cinquième couche de session dans le modèle OSI.

Le protocole SSL peut être divisé en deux couches : Protocole d'enregistrement SSL (SSL Record Protocol) : Il est basé sur un protocole de transmission fiable (tel que TCP) et prend en charge les fonctions de base telles que l'encapsulation, la compression et le cryptage des données à haute protocoles de niveau. SSL Handshake Protocol (SSL Handshake Protocol): Il est basé sur le protocole d'enregistrement SSL et est utilisé pour l'authentification de l'identité , la négociation des algorithmes de cryptage et l'échange de clés de cryptage avant le début de la transmission des données .

TLS (sécurité de la couche transport)

TLS (Transport Layer Security) est un protocole de couche de transport sécurisé, son prédécesseur est SSL. Lorsque Netscape a lancé la première version du navigateur Web , Netscape Navigator , en 1994 , il a lancé le protocole HTTPS , crypté avec SSL, qui est à l'origine de SSL. L'IETF normalise SSL et a publié la première version du document standard TLS en 1999. Cela a été suivi par RFC 5246 (août 2008) et RFC 6176 (mars 2011). Ce protocole est largement pris en charge dans des applications telles que les navigateurs , les boîtes aux lettres , la messagerie instantanée , la VoIP et la télécopie Internet . Les principaux sites Web, tels que Google , Facebook , etc. utilisent également ce protocole pour créer des connexions sécurisées et envoyer des données. Il est devenu la norme de l'industrie pour les communications sécurisées sur Internet .

L'une des étapes les plus importantes pour certaines entreprises en ligne (telles que le paiement en ligne) consiste à créer un environnement de transaction fiable qui permet aux clients d'effectuer des transactions en toute tranquillité d'esprit. SSL/TLS le garantit. SSL/TLS est appelé certificat X.509 A document numérique qui lie les informations du site Web et de l'entité de l'entreprise aux clés cryptographiques pour effectuer le travail. Chaque paire de clés (les paires de clés) possède une clé privée (clé privée) et une clé publique (clé publique). La clé privée est unique et se trouve généralement sur le serveur. Elle sert à décrypter les données cryptées par la clé publique. informations ; la clé publique est publique, et toute personne qui interagit avec le serveur peut détenir la clé publique, et les informations chiffrées avec la clé publique ne peuvent être déchiffrées que par la clé privée.

X.509

X.509 est le format standard des certificats de clé publique, un document qui associe en toute sécurité les clés cryptographiques à (individus ou organisations). Les principales applications de X.509 sont les suivantes

• SSL/TLS et HTTPS pour une navigation Web authentifiée et cryptée
• E-mail signé et crypté via le protocole S/MIME
• Signature de code : il s'agit du processus de signature d'applications logicielles à l'aide de certificats numériques pour une distribution et une installation sécurisées.

En signant numériquement un logiciel avec un certificat délivré par une autorité de certification publique bien connue telle que SSL.com, les développeurs peuvent garantir aux utilisateurs finaux que le logiciel qu'ils souhaitent installer a été publié par un développeur connu et de confiance ; et qu'après la signature n'a pas été altéré ou endommagé

Explication détaillée de TLS

TLS est utilisé pour assurer la confidentialité et l'intégrité des données entre deux applications communicantes. TLS est composé de plusieurs sous-protocoles tels que le protocole d'enregistrement, le protocole de prise de contact, le protocole d'avertissement, le protocole de spécification de changement de mot de passe et le protocole d'extension. Il utilise de nombreuses technologies de cryptographie de pointe telles que le cryptage symétrique, le cryptage asymétrique et l'authentification d'identité.

Jusqu'à présent, il existait trois versions de TLS : 1.1, 1.2 et 1.3. À l'heure actuelle, la version 1.2 est la plus largement utilisée. La discussion suivante est donc basée sur la version de TLS 1.2.

Notes de version et exigences de sécurité

Maintenant SSL 2.0et SSL 3.0ont été éliminés. Parmi eux TLS 1.0, TLS 1.1, TLS 1.2se trouve le courant dominant, relativement sûr.

Cela dépend principalement de l'algorithme de chiffrement. TLS 1.3Il s'agit actuellement de la dernière version du protocole, et c'est aussi relativement la version la plus sécurisée.

Exigences de l'entreprise : les protocoles SSL2.0 et SSL3.0 sont interdits, le protocole TLS1.0 ne peut être utilisé qu'en tant qu'héritage, les versions TLS1.1 et TLS1.2 sont recommandées

Convention de nommage TLS

Prenons un exemple de TLS pour voir la structure de TLSECDHE-ECDSA-AES256-GCM-SHA384

Qu'est-ce que cela signifie? J'étais un peu confus quand je l'ai lu pour la première fois, mais il existe en fait des routines, car les suites de chiffrement de TLS sont relativement standardisées et le format de base est un algorithme d'échange de clés-algorithme de signature-algorithme de chiffrement symétrique-algorithme de synthèse. mode regroupement,

Voyons d'abord ce que cela signifie.
Utilisez ECDHE pour l'échange de clés , utilisez ECDSA pour la signature et l'authentification , puis utilisez AES comme algorithme de chiffrement symétrique , la longueur de la clé est de 256 bits, utilisez GCM comme mode de regroupement et enfin utilisez SHA384 comme algorithme de résumé .

TLS utilise fondamentalement les deux formes de chiffrement symétrique et asymétrique.

Algorithme de chiffrement - confidentialité de la transmission des informations

Avant de comprendre le chiffrement symétrique, commençons par comprendre la cryptographie. En cryptographie, il existe plusieurs concepts : texte en clair, texte chiffré, chiffrement et déchiffrement.

• Le texte en clair est généralement considéré comme un caractère significatif ou un ensemble de bits, ou un message qui peut être obtenu via un certain codage public. Le texte en clair est généralement noté m ou p
• Ciphertext (Ciphertext), après un certain cryptage du texte en clair, il devient un texte chiffré
• Chiffrement (Encrypt), le processus de transformation des informations consistant à convertir les informations d'origine (texte en clair) en texte chiffré
• Décryptage (Decrypt), le processus de restauration des informations cryptées en texte clair.

Cryptage symétrique

Le chiffrement symétrique, comme son nom l'indique, signifie que la même clé est utilisée pour le chiffrement et le déchiffrement. Tant que la sécurité de la clé est garantie, l'ensemble du processus de communication est confidentiel.

Il existe de nombreux algorithmes de chiffrement disponibles dans TLS, tels que DES, 3DES, AES, ChaCha20, TDEA, Blowfish, RC2, RC4, RC5, IDEA, SKIPJACK, etc. Actuellement, les plus couramment utilisés sont AES-128, AES-192, AES-256 et ChaCha20.

• Le nom complet de DES est Data Encryption Standard (Data Encryption Standard), qui est un algorithme à clé symétrique pour le cryptage des données numériques. Bien que sa courte longueur de clé de 56 bits la rende trop peu sûre pour les applications modernes, elle a été très influente dans le développement de la technologie de chiffrement.
• 3DES est un algorithme de chiffrement dérivé du Data Encryption Standard (DES) d'origine.Il est devenu très important après les années 1990, mais plus tard, en raison de l'émergence d'algorithmes plus avancés, 3DES est devenu moins important.
• AES-128, AES-192 et AES-256 appartiennent tous à AES. Le nom complet d'AES est Advanced Encryption Standard (Advanced Encryption Standard) Algorithmes de chiffrement symétriques étendus.
• ChaCha20 est un autre algorithme de cryptage conçu par Google. La longueur de la clé est fixée à 256 bits. Les performances des logiciels purs sont meilleures qu'AES. Il était autrefois populaire sur les clients mobiles, mais après ARMv8 a également ajouté l'optimisation matérielle AES, il n'est donc pas long A des avantages évidents, mais compte toujours comme un bon algorithme.

paquet crypté

L'algorithme de chiffrement symétrique a également le concept d'un mode de groupe. Pour le mode de groupe GCM, il ne peut être utilisé qu'avec AES, CAMELLIA et ARIA, et AES est évidemment le choix le plus populaire et le plus largement déployé. Il permet à l'algorithme d'utiliser un clé de longueur fixe Crypte le texte en clair de n'importe quelle longueur.
Il y avait plusieurs modes de regroupement tels que ECB, CBC, CFB et OFB au plus tôt, mais ils se sont tous avérés présenter des vulnérabilités de sécurité les unes après les autres, ils ne sont donc pratiquement pas beaucoup utilisés maintenant. Le dernier mode de regroupement s'appelle AEAD (Authenticated Encryption with Associated Data), qui ajoute la fonction d'authentification lors du chiffrement. Les plus couramment utilisés sont GCM, CCM et Poly1305.

Par exemple, ECDHE_ECDSA_AES128_GCM_SHA256 signifie qu'il a une clé de 128 bits, et AES256 signifiera une clé de 256 bits. GCM signifie mode de fonctionnement AEAD (Modern Authenticated Associated Data Encryption) avec un chiffrement par blocs de 128 bits.

Nous avons parlé de chiffrement symétrique ci-dessus. La partie de chiffrement et la partie de déchiffrement du chiffrement symétrique utilisent la même clé, c'est-à-dire que la partie de chiffrement doit chiffrer les données d'origine, puis remettre la clé à la partie de déchiffrement pour le déchiffrement avant il peut être déchiffré. données, quels problèmes cela pose-t-il ? Le chiffrement symétrique ne peut garantir la sécurité de la transmission de la clé elle-même.

Il existe plusieurs solutions au problème de distribution de clé comme suit :

1. Clé Pré-Partagée
2. centre de distribution de clés
3. Échange de clés Diffie-Hellman
4. cryptage asymétrique

Cryptage asymétrique

Le cryptage asymétrique est également appelé cryptage à clé publique.Par rapport au cryptage symétrique, le cryptage asymétrique est une méthode de cryptage nouvelle et améliorée. La clé est échangée par transmission réseau, ce qui peut garantir que la clé est interceptée à temps et que les informations de données ne seront pas exposées. Il existe deux clés dans le chiffrement asymétrique, l'une est la clé publique et l'autre est la clé privée. La clé publique est publique, mais la clé privée doit être conservée par elle-même.

La clé publique et la clé privée forment une paire de clés. Si vous chiffrez des données avec une clé, vous devez utiliser l'autre clé pour les déchiffrer. Non, puisque la clé publique est publique).

Sous chiffrement asymétrique, deux parties doivent disposer de quatre clés pour communiquer.

Pour en revenir à l'exemple de tout à l'heure, Xiaoming et Xiahong ont découvert grâce à des recherches que le cryptage asymétrique peut résoudre le problème de sécurité de leur communication, ils ont donc fait ce qui suit :

1. Xiao Ming a déterminé sa clé privée mPrivateKey et sa clé publique mPublicKey. Gardez la clé privée pour vous et envoyez la clé publique mPublicKey à Xiaohong

2. Xiaohong a déterminé sa clé privée hPrivateKey et sa clé publique hPublicKey. Gardez la clé privée pour vous et envoyez la clé publique hPublicKey à Xiaoming

3. Xiao Ming envoie un message « Rendez-vous en bas au Soho T1 à 10 h samedi », et le crypte avec la clé publique hPublicKey de Xiaohong.

4. Xiaohong utilise sa clé privée hPrivateKey pour déchiffrer le message après l'avoir reçu. Répondez ensuite "Je l'ai, ne soyez pas en retard" et cryptez-le avec la clé publique mPublicKey de Xiaoming.

5. Xiao Ming utilise sa clé privée mPrivateKey pour déchiffrer le message après l'avoir reçu. Après avoir lu le message, je me suis dit : Tu me rappelles toujours de ne pas être en retard ? Tu es toujours en retard, n'est-ce pas ?

Le processus ci-dessus est une demande et une réponse complètes. A travers cet exemple, nous décomposons le processus de chiffrement et de déchiffrement asymétrique d'une transmission d'informations :

1. Le destinataire du message prépare la clé publique et la clé privée

2. Le destinataire conserve la clé privée et publie la clé publique à l'expéditeur du message

3. L' expéditeur du message crypte le message avec la clé publique du destinataire

4. Le destinataire du message déchiffre le message avec sa propre clé privée

La clé publique ne peut être utilisée que pour le chiffrement des données. Les données chiffrées avec une clé publique ne peuvent être déchiffrées qu'avec la clé privée correspondante. C'est le concept de base du cryptage asymétrique .

La conception des algorithmes de chiffrement asymétriques est beaucoup plus difficile que celle des algorithmes symétriques (nous ne discuterons pas des méthodes de chiffrement spécifiques), les plus courantes telles que DH, DSA, RSA, ECC, etc.
Parmi eux, l'algorithme de chiffrement RSA est le plus important et le plus connu. Par exemple DHE_RSA_CAMELLIA128_GCM_SHA256. Sa sécurité est basée sur la décomposition d'entiers, utilisant le produit de deux super grands nombres premiers comme matériau de génération de clé, il est très difficile de déduire la clé privée de la clé publique.
ECC (Elliptic Curve Cryptography) est également une sorte d'algorithme de chiffrement asymétrique. Il est basé sur le problème mathématique du logarithme discret de la courbe elliptique. Il utilise des équations de courbe spécifiques et des points de base pour générer des clés publiques et privées. ECDHE est utilisé pour l'échange de clés et ECDSA est utilisé pour la signature numérique.

chiffrement hybride

TLS utilise une méthode de chiffrement hybride de chiffrement symétrique et de chiffrement asymétrique pour assurer la confidentialité.

Par rapport au chiffrement symétrique, le chiffrement asymétrique présente les caractéristiques suivantes :

1. Le chiffrement asymétrique résout le problème de la distribution des mots de passe

2. La vitesse de traitement du chiffrement asymétrique n'est que de quelques centièmes de celle du chiffrement symétrique. Ne convient pas au chiffrement de messages très longs.

3. Le RSA 1024 bits ne doit pas être utilisé par les nouvelles applications. Au moins 2048 bits RSA.

RSA résout le problème de distribution des mots de passe, mais est moins efficace. Ainsi parfois, selon les besoins, les chiffrements symétriques et asymétriques peuvent être utilisés ensemble pour former un cryptosystème hybride, chacun prenant ses propres avantages.

La vitesse de fonctionnement de RSA est très lente, tandis que la vitesse de cryptage d'AES est relativement rapide, et TLS utilise cette méthode de cryptage hybride. Au début de la communication, utilisez des algorithmes asymétriques, tels que RSA et ECDHE, pour résoudre d'abord le problème de l'échange de clés. Utilisez ensuite le nombre aléatoire pour générer la clé de session (clé de session) utilisée par l'algorithme symétrique, puis chiffrez-la avec la clé publique. L'autre partie déchiffre le texte chiffré avec la clé privée et extrait la clé de session. De cette manière, les deux parties réalisent l'échange sécurisé de clés symétriques.

Algorithme Digest - Signature numérique - Intégrité de l'échange de données

Maintenant que nous utilisons le cryptage hybride pour garantir la confidentialité, pouvons-nous transmettre des données en toute sécurité ? Il ne suffit pas, sur la base de la confidentialité, il faut ajouter les caractéristiques d'intégrité et d'authentification d'identité pour atteindre une réelle sécurité. Le principal moyen d'atteindre l'intégrité est l'algorithme de synthèse (Digest Algorithm)

Envoyez les données d'origine et la signature numérique au destinataire. Une fois la signature numérique reçue, le destinataire utilise le même algorithme de hachage pour calculer la valeur de résumé du message, puis déchiffre le message avec la clé publique de l'expéditeur. La valeur récapitulative de la le texte est comparé. S'ils sont égaux, cela signifie que le message provient bien de l'expéditeur revendiqué et qu'il n'a pas été falsifié.

MD5 (Algorithme de résumé de message 5)

Si vous ne connaissez pas l'algorithme de résumé, vous devriez connaître MD5. C'est une sorte d'algorithme de hachage cryptographique. MD5 peut être utilisé pour créer une valeur de chaîne de 128 bits à partir d'une chaîne de n'importe quelle longueur.

Bien que MD5 ne soit pas sécurisé, il est encore utilisé aujourd'hui. MD5 est le plus souvent utilisé pour vérifier l'intégrité des fichiers. Cependant, il est également utilisé dans d'autres protocoles et applications de sécurité tels que SSH, SSL et IPSec. Certaines applications améliorent l'algorithme MD5 en salant le texte en clair ou en appliquant la fonction de hachage plusieurs fois.
Qu'est-ce que le Sel ? En cryptographie, un sel est un élément de données aléatoires utilisé comme entrée supplémentaire dans une fonction à sens unique pour hacher des données, des mots de passe ou des mots de passe. Salt est utilisé pour protéger les mots de passe stockés.

Qu'est-ce qu'un sens unique ? C'est-à-dire que cet algorithme n'a pas de clé à déchiffrer et ne peut effectuer qu'un chiffrement à sens unique. Les données chiffrées ne peuvent pas être déchiffrées et le texte d'origine ne peut pas être inversé.

Revenons à la discussion sur l'algorithme de résumé. En fait, vous pouvez comprendre l'algorithme de résumé comme un algorithme de compression spécial, qui peut compresser des données de n'importe quelle longueur dans une chaîne de longueur fixe, ce qui revient à ajouter un verrou.

SHA1 (algorithme de hachage sécurisé 1)

En plus de l'algorithme de chiffrement MD5 couramment utilisé, SHA-1 est également un algorithme de chiffrement couramment utilisé, mais SHA-1 est également un algorithme de chiffrement non sécurisé, qui est interdit dans TLS. La recommandation TLS actuelle est le successeur de SHA-1 : SHA-2.

SHA2 (algorithme de hachage sécurisé 2)

Introduit en 2001, SHA-2 a apporté des modifications importantes sur la base de SHA-1. La série SHA-2 contient six fonctions de hachage dont les résumés (valeurs de hachage) sont 224, 256, 384 ou 512. Bits : SHA-224, SHA-256, SHA-384, SHA-512. Capable de générer respectivement des résumés de 28 octets, 32 octets, 48 ​​octets et 64 octets.

Avec la protection de SHA-2, l'intégrité des données peut être atteinte. Même si vous modifiez un signe de ponctuation ou ajoutez un espace dans le fichier, le résumé du fichier généré sera complètement différent, mais SHA-2 est une méthode de chiffrement basée sur en clair. Toujours pas assez sûr, alors que dois-je utiliser ?

HMAC (code d'authentification de message basé sur le hachage)

Une méthode de cryptage plus sécurisée consiste à utiliser HMAC.Avant de comprendre ce qu'est HMAC, vous devez savoir ce qu'est MAC.

Le nom complet de MAC est Message Authentication Code, qui est généré à partir du message et de la clé via l'algorithme MAC. La valeur MAC permet au vérificateur (qui possède également la clé secrète) de détecter toute modification du contenu du message, ce qui protéger l'intégrité des données du message.

HMAC est une autre extension de MAC. Il utilise la combinaison de la valeur MAC + valeur de hachage. Toute fonction de hachage cryptée peut être utilisée dans le calcul de HMAC, comme SHA-256.

Authentification - Man-in-the-Middle Attack - Certitude de l'identité du commerçant

vérification de la signature

Maintenant que nous avons résolu le problème de l'intégrité, il ne reste plus qu'un seul problème, celui de l'authentification, comment se fait l'authentification ?

Dans le processus d'envoi de données au serveur, les pirates (attaquants) peuvent se faire passer pour n'importe quelle partie pour voler des informations. Il peut se faire passer pour vous pour envoyer des informations au serveur, ou il peut se faire passer pour un serveur pour accepter les informations que vous envoyez. Alors comment résoudre ce problème ?

Comment l'authentification détermine-t-elle votre propre unicité ? Nous avons vu le concept de chiffrement à clé publique et de déchiffrement à clé privée dans le processus de description ci-dessus. La clé privée mentionnée n'appartient qu'à vous, et vous pouvez distinguer l'unicité, de sorte que nous pouvons inverser l'ordre pour être chiffré avec la clé privée et déchiffré avec la clé publique. À l'aide d'une clé privée et d'un algorithme de résumé, des signatures numériques peuvent être mises en œuvre pour réaliser l'authentification. ——Signature de clé privée, vérification de clé publique.

La vérification de signature peut vérifier l'identité de l'expéditeur, empêcher les attaques de l'homme du milieu et les attaques de falsification d'identité inter-domaines CSRF.

Jusqu'à présent, nous avons implémenté le cryptage, l'authentification des données et l'authentification en utilisant de manière exhaustive le cryptage symétrique, le cryptage asymétrique et les algorithmes de résumé, est-ce donc sûr ? Non, il y a aussi un problème d'authentification de signature numérique. Parce que la clé privée vous appartient et que n'importe qui peut publier la clé publique, vous devez donc publier la clé publique certifiée pour résoudre le problème de confiance de la clé publique .

Problèmes avec la distribution de la clé publique

Le « serveur » veut libérer la clé publique au monde extérieur, alors comment le « serveur » envoie-t-il la clé publique au « client » ? Notre première réaction peut être les deux méthodes suivantes :

• a) Placez la clé publique dans une adresse de téléchargement quelque part sur Internet et donnez-la au "client" pour qu'il la télécharge à l'avance.

• b) Chaque fois que la communication avec le "client" est lancée, le "serveur" envoie la clé publique au "client".

Mais ces deux méthodes présentent certains problèmes. Pour la méthode a), le "client" ne peut pas déterminer si l'adresse de téléchargement est émise par le "serveur". Pourquoi pensez-vous que le téléchargement à partir de cette adresse est émis par le "serveur" au lieu de Qu'en est-il des faux d'autres personnes, et si un faux est téléchargé ? De plus, il est irréaliste d'exiger que tous les "clients" téléchargent la clé publique avant la communication.

Pour la méthode b), il y a aussi des problèmes, car n'importe qui peut générer lui-même une paire de clé publique et de clé privée, et il peut se faire passer pour un "serveur" tant qu'il envoie sa propre clé privée au "client". L'indication est la suivante :

"Client" -> "Hacker": Bonjour //Hacker intercepte le message envoyé de "Client" à "Serveur"

"Hacker" -> "Client" : Bonjour, je suis le serveur, ceci est ma clé publique // Le pirate génère lui-même une paire de clé publique et de clé privée, envoie la clé publique au "client", et conserve le clé privée pour lui-même

"Client" -> "Hacker" : Prouvez-moi que vous êtes le serveur

"Hacker" -> "Client": Bonjour, je suis le serveur {Bonjour, je suis le serveur} [clé privée du hacker|RSA] //Après avoir reçu les informations chiffrées par le "hacker" avec la clé privée, le client peut Il est déchiffré avec la clé publique envoyée par le "hacker", de sorte que le "hacker" est confondu avec le "serveur"

Par conséquent, le "pirate" n'a qu'à générer lui-même une paire de clé publique et de clé privée, puis envoyer la clé publique au "client", et garder la clé privée par lui-même, afin que le "client" puisse utiliser le clé publique du pirate pour déchiffrer le contenu chiffré par la clé privée du pirate, le "client" croira que le "pirate" est le "serveur", causant ainsi des problèmes de sécurité. La racine du problème ici est que tout le monde peut générer une paire de clés publiques et de clés privées, mais il est impossible de confirmer qui est la paire de clés publiques. Si vous pouvez déterminer qui est la clé publique, vous n'aurez pas ce problème. Par exemple, si vous recevez une clé publique envoyée par un "hacker" se faisant passer pour un "serveur", après une sorte d'inspection, ce serait formidable si vous pouviez découvrir que la clé publique n'appartient pas au "serveur".

Afin de résoudre ce problème, des certificats numériques sont apparus, ce qui peut résoudre nos problèmes ci-dessus. Voyons d'abord ce qu'est un certificat numérique. Un certificat contient le contenu spécifique suivant :

• autorité de délivrance des certificats
• La durée de validité du certificat
• Clé publique
• Propriétaire du certificat (Objet)
• l'algorithme utilisé pour la signature
• Empreintes digitales et algorithmes d'empreintes digitales

L'explication détaillée du contenu du certificat sera expliquée en détail plus tard, ici nous n'avons qu'à préciser que le certificat **numérique peut garantir que la clé publique dans le certificat * numérique* est bien le propriétaire du certificat ( Objet), ou le certificat peut être utilisé pour confirmer l'identité de l'autre partie . En d'autres termes, nous obtenons un certificat numérique et nous pouvons déterminer de qui il s'agit.

Quant à la manière de juger, elle sera expliquée en détail plus tard lors de la discussion détaillée des certificats numériques.

Autorité de certification CA (autorité de certification)

Par conséquent, CA est introduit. Le nom complet de CA est Autorité de certification, une autorité de certification de certificat. Vous devez laisser CA émettre une clé publique certifiée pour résoudre le problème de confiance de la clé publique.

Il n'y a que quelques CA certifiés dans le monde, et ils ont délivré respectivement trois types : DV, OV et EV, la différence réside dans le degré de crédibilité. DV est le plus bas, il n'est digne de confiance qu'au niveau du nom de domaine, EV est le plus élevé, il a subi des contrôles juridiques et d'audit stricts et peut prouver l'identité du propriétaire du site Web (le nom de l'entreprise sera affiché dans le navigateur barre d'adresse, comme Apple, site Web GitHub). Les institutions de différents niveaux de confiance forment une relation hiérarchique entre elles.

En règle générale, un demandeur de certificat numérique génère une paire de clés composée d'une clé privée et publique et d'une demande de signature de certificat (CSR). Un CSR est un fichier texte codé qui contient la clé publique et d'autres informations qui seront incluses dans le certificat (telles que le nom de domaine, l'organisation, l'adresse e-mail, etc.). La génération de paires de clés et de CSR est généralement effectuée sur le serveur sur lequel le certificat sera installé, et le type d'informations contenues dans le CSR dépend du niveau de vérification du certificat. Contrairement à la clé publique, la clé privée du demandeur est sûre et ne doit jamais être montrée à l'AC (ou à quiconque).

Une fois le CSR généré, le demandeur l'envoie à l'autorité de certification, qui vérifie que les informations qu'il contient sont correctes, signe numériquement le certificat avec la clé privée émise et l'envoie au demandeur.