SSL / TLS - Distinction entre le certificat auto-signé et l'AC auto-signé, et d'autres questions?
J'ai un petit site Web personnel que je souhaite servir en toute sécurité via HTTPS. Pour le moment, je ne souhaite pas utiliser une autorité de certification tierce pour signer mes certificats. Je lisais ce document sur génération d'un certificat auto-signé .
J'ai trois questions.
Le document présente deux façons: (1A) Génération de votre propre certificat auto-signé. et (1B) Génération de votre propre certificat/autorité de certification, puis utilisation de l'autorité de certification pour signer votre certificat.
Je ne comprends pas quelle est la différence entre les deux. Quel est l'intérêt de générer votre propre autorité de certification si aucun des navigateurs ne lui fait confiance (contrairement aux certificats signés par Verisign)? Est-ce que (1B) est utilisé pour empêcher les attaques MITM? Si oui, dois-je utiliser (1B) sur (1A)?
Outre la gestion/révocation de plusieurs certificats (si je les utilise), une autorité de certification auto-signée semble inutile?
J'ai remarqué que le doc utilise le chiffrement des3. Serait-il possible d'utiliser le chiffrement aes-256 à la place à moins qu'il n'y ait une bonne raison d'utiliser des3? (Aussi comment dois-je faire cela?)
Ce fil a fait une distinction entre l'utilisation de clés de 2048 bits et de clés de 256 bits. Je comprends ce que la réponse dit dans une certaine mesure (que les clés publiques (2048 bits) sont utilisées pour chiffrer les clés symétriques (256 bits) afin d'échanger des clés entre le serveur et le client). Mais je ne comprends pas comment cela est appliqué dans le contexte du document. Dans le doc, je vois cette ligne:
openssl genrsa -des3 -out server.key 4096
Est-ce que cette ligne signifie qu'elle génère une clé symétrique (des3), puis génère une clé publique (RSA 4096 bits)?
A certificat CA est un certificat qui appartient à une autorité de certification et marqué comme pouvant être utilisé comme autorité de certification; à savoir, qu'il contient un Basic Constraints extension avec l'indicateur "cA" défini sur TRUE.
Un certificat auto-signé est un certificat qui est signé avec la clé privée correspondant à la clé publique qui se trouve dans le certificat lui-même. Cela signifie que le certificat a été délivré par le propriétaire du certificat lui-même, et non par quelqu'un d'autre.
Un certificat CA peut être auto-émis; c'est le cas normal pour une racine CA. Une autorité de certification racine est une autorité de certification qui existe par elle-même et est censée être approuvée a priori (incluse manuellement dans un navigateur Web ou un magasin de certificats de système d'exploitation) et pas en raison d'être émis par une autre autorité de certification de confiance.
La création d'une autorité de certification auto-signée et son utilisation pour signer le certificat de serveur réel (option 1B) est utile si vous envisagez d'émettre plusieurs certificats (éventuellement plusieurs) pour de nombreux serveurs. Avec votre propre autorité de certification racine (c'est ce que signifie l'option 1B), il vous suffit d'insérer un certificat manuellement dans tous les clients (votre racine auto-signée CALIFORNIE). Si vous n'avez qu'un seul certificat de serveur à produire et que vous prévoyez que les choses resteront ainsi, l'option 1A est aussi bonne que 1B, sans doute meilleure car elle est plus simple.
L'option - des sert au chiffrement symétrique de la clé CA. C'est pas mal. Il n'y a pas assez de puissance de calcul (ou, d'ailleurs, de puissance brute) sur Terre pour briser le cryptage 3DES correctement effectué. Passer à AES-256 serait inutile, et cela pourrait s'avérer difficile car l'outil de ligne de commande OpenSSL ne le prend pas en charge (OpenSSL, la bibliothèque, inclut une implémentation AES-256, mais la ligne de commande les outils ne lui donnent pas un accès facile en ce qui concerne le chiffrement symétrique de la clé privée).
Les signatures numériques (celles qui sont appliquées sur les certificats) utilisent, par définition, clés asymétriques. Les clés asymétriques nécessitent beaucoup de structure mathématique interne, et cette structure peut être utilisée pour les affaiblir, elles doivent donc être beaucoup plus grandes que les clés symétriques afin d'atteindre un niveau de sécurité décent. C'est pourquoi une bonne clé RSA devra aller à 2048 bits environ, tandis qu'une clé symétrique à 128 bits est déjà solide. La ligne:
openssl genrsa -des3 -out server.key 4096
génère une nouvelle paire de clés RSA asymétrique de taille 4096 bits et la stocke dans le fichier server.key. Ce stockage est en outre protégé (crypté) avec 3DES, en utilisant une clé symétrique dérivée du mot de passe que vous tapez à ce moment-là.
La clé privée comprend une copie de la clé publique. La clé publique (mais, bien sûr, pas la clé privée) fera également partie du certificat : elle est d'abord copiée dans un demande de certificat (le fichier ".csr") puis dans le certificat lui-même.
CA vs certificat auto-signé
Dans toute installation PKI, le certificat auto-signé (CA ou entité finale - par exemple un serveur) doit être distribué à toutes les parties de confiance. Pour votre utilisateur moyen, les systèmes d'autorités publiques bien connus et hautement fiables sont déployés automatiquement. Pour les petites infrastructures - telles que les environnements d'entreprise internes - un certificat CA interne peut être automatiquement intégré dans les navigateurs, les serveurs et d'autres distributions. Dans tous les cas, si le certificat est auto-signé, il doit être explicitement approuvé.
Les grandes différences sont:
certificat d'entité finale auto-signé - si vous créez plusieurs certificats, CHAQUE certificat que vous créez doit être explicitement approuvé à chaque point de terminaison. Si un certificat est compromis, l'approbation doit être supprimée de chaque point de terminaison. Cela peut être fait avec des scripts automatisés, mais c'est beaucoup de travail.
cA auto-signée -> entité finale signée - vous devez explicitement faire confiance à l'autorité de certification, puis chaque entité finale sera automatiquement approuvée. Si vous prévoyez de créer plusieurs certificats de serveur sur une période donnée, cela réduira la charge de travail. L'astuce est que vous avez besoin d'un moyen de vérifier la révocation s'il y a une chance de compromis sur le certificat du serveur (ce qui est toujours le cas). C'est là que la complexité entre en jeu - les CRL ou OCSP sont les moyens standard de communiquer sur un compromis, mais cela signifie faire plus de travail, pas moins, pour organiser et distribuer les CRL et (éventuellement) organiser et exécuter un serveur OCSP. De plus, les navigateurs doivent être configurés pour vérifier cela - ce qui n'est pas un paramètre par défaut.
Cela a beaucoup à voir avec les risques dans votre système et ce que vous pensez du cycle de vie de l'émission et de la révocation de votre certificat.
DES3 contre AES-256
Depuis documentation openSSL , vos options avec la commande que vous avez citée sont:
- DES
- DES3
- IDEA
Je recommanderais IDEA comme nouvel algorithme et meilleure pratique, mais pas si l'un de vos systèmes n'est pas compatible. Cela peut être très difficile - essayer de diagnostiquer pourquoi vous ne pouvez pas utiliser un un certificat et une clé privée donnés peuvent être extrêmement frustrants et les réponses fournies par la plupart des systèmes ne sont pas claires et difficiles à comprendre.
Selon cette documentation:
Ces options chiffrent la clé privée avec le DES, le triple DES ou les chiffrements IDEA respectivement avant la sortie. Si aucune de ces options n'est spécifiée, aucun chiffrement n'est utilisé. Si le chiffrement est utilisé, une phrase de passe est demandé s'il n'est pas fourni via l'argument -passout.
C'est ainsi que la clé privée est stockée et protégée dans le fichier server.key. Cela n'a rien à voir avec la façon dont le certificat permet à votre serveur de communiquer avec d'autres systèmes.
Dans un système CA normal (OpenSSL peut être un peu primitif), il existe un moyen de spécifier comment la clé peut être utilisée pour le chiffrement - qui peut inclure des paramètres SSL valides, comme autoriser ou appliquer une clé de session 256 bits.
Ce n'est pas un facteur de la clé du certificat (dans votre exemple, c'est une clé assymétrique RSA 4096 bits) - c'est un facteur de ce que la paire de clés représentée est autorisée à faire selon l'autorité de certification et sa politique de sécurité associée. Cela contrôle généralement la configuration d'une session SSL.
Pour être clair aucune clé de session SSL n'est faite lors de la création d'un certificat . Les clés de session sont créées et négociées au moment où un client communique avec un serveur - longtemps après la création, la signature et l'installation du certificat.
- Si une entreprise souhaite générer son propre CA, elle peut l'inclure dans les ordinateurs de son personnel, par exemple pour faire confiance aux sites Web internes ou aux mandataires (en cas d'inspection des connexions SSL).
- 3 DES n'est pas cassé, mais AES-Fournit une plus grande sécurité que DES et est plus efficace sur le plan informatique que 3DES. AES offre trois forces différentes: 128-, Clés de 192 et 256 bits. 3DES est essentiellement DES crypté 3 fois.
- RSA est un algorithme coûteux et n'est pas vraiment adapté pour crypter chaque connexion avec. donc ce qui se passe, c'est qu'au lieu de tout transmettre crypté avec RSA, le serveur crée une clé aléatoire composée de 256 bits (vous pouvez voir cette clé comme un mot de passe, juste un tas de caractères aléatoires, 256 bits de longueur) et la crypte avec la clé RSA et l'envoie à l'autre extrémité. À partir de là, ils utilisent tous deux un algorithme de chiffrement symétrique comme AES (qui est beaucoup plus rapide que RSA pour chiffrer et déchiffrer les données) pour transmettre les données en toute sécurité.
En ordre:
Le document présente deux façons: (1A) Génération de votre propre certificat auto-signé. et (1B) Génération de votre propre certificat/autorité de certification, puis utilisation de l'autorité de certification pour signer votre certificat.
Je ne comprends pas quelle est la différence entre les deux. Quel est l'intérêt de générer votre propre autorité de certification si aucun des navigateurs ne lui fait confiance (contrairement aux certificats signés par Verisign)?
Même si votre certificat n'est pas signé par une autorité de certification approuvée par un navigateur, il peut être utilisé pour chiffrer le trafic entre le client et le serveur. Cela signifie que vous obtiendrez le secret que vous souhaitez grâce au cryptage. Ce que vous n'obtiendrez pas, c'est ce petit cadenas vert dans le navigateur de vos visiteurs qui leur indique que la propriété de votre domaine a été vérifiée par une autorité de certification. Ils ne pourront donc pas vérifier l'authenticité de votre site (possible MITM) mais la communication sera cryptée.
Un certificat auto-signé est la racine de la confiance dans toutes les hiérarchies de certificats. Verisign a un certificat auto-signé qui est la racine de confiance pour tous les certificats qu'ils signent (et c'est probablement dans un bunker quelque part). Si vous souhaitez pouvoir jouer à l'autorité de certification (c'est-à-dire créer plusieurs certificats et les faire tous partie de la même chaîne de confiance), vous devez créer un certificat auto-signé et l'utiliser pour signer les autres certificats (voir openssl req et openssl x509).
Est-ce que (1B) est utilisé pour empêcher les attaques MITM?
Non. Votre (1B) est destiné à permettre la création de plusieurs certificats qui sont tous liés à la même autorité de certification, tout comme l'indique l'auteur dans le premier paragraphe. Fondamentalement, il s'agit d'un exercice qui vous montre efficacement ce qu'est une hiérarchie de certificats.
Si oui, dois-je utiliser (1B) sur (1A)?
Pour un seul site Web, vous pouvez très bien vous en sortir avec 1A, bien que faire 1B soit un bon exercice.
J'ai remarqué que le doc utilise le chiffrement des3. Serait-il possible d'utiliser le chiffrement aes-256 à la place à moins qu'il n'y ait une bonne raison d'utiliser des3? (Aussi comment dois-je faire cela?)
Il manque une partie de la documentation openssl dans les distributions Linux, mais vous pouvez remplacer -aes256 au lieu de -des3 pour utiliser l'AES 256 bits à la place. De même, les variantes 192 et 128 bits sont également disponibles. Vérifiez la sortie de openssl genrsa --help pour la liste des algorithmes pris en charge. Quant à la bonne sélection d'algorithme: tant que l'algorithme n'est pas connu pour être cassé, il y a peu de différence. AES256 et tripple-DES (des3) sont tous deux très solides. Je préfère généralement AES car il est plus efficace.
openssl genrsa -des3 -out server.key 4096Cette ligne signifie-t-elle qu'elle génère une clé symétrique (des3), puis génère une clé publique (RSA 4096 bits)?
Non. Cette commande oblige openssl à créer une clé privée RSA de 4096 bits qui est chiffrée à l'aide de tripple-DES. Vous serez invité à saisir une phrase secrète et avant de pouvoir utiliser cette clé à quelque fin que ce soit, vous devrez la déchiffrer en utilisant la même phrase secrète. Ceci est destiné à empêcher l'utilisation de la clé en cas de perte/vol.
Comme il semble que vous recherchiez des informations générales ici, je vais garder ma réponse courte mais n'hésitez pas à lire la documentation openssl
Une autorité de certification (CA) est utilisée pour signer d'autres certificats afin de créer un réseau de confiance. Par exemple: si vous deviez obtenir un certificat tiers, vous recevrez un certificat signé par quelqu'un d'autre (thwat, verisign, koomodo, etc.). Ce sont des `` autorités de certification de confiance '' que le magasin de clés du navigateur d'un utilisateur pourra vérifier. Le navigateur examine votre certificat pour YYY.com et s'il est signé par un agent de confiance et n'est pas révoqué, il l'accepte comme bon (verrou vert). S'il n'y a pas d'autorité de certification approuvée dans la chaîne de signature, il n'y a aucun moyen de savoir si le certificat peut être approuvé.
Tu devrais être capable de. essayez
openssl genrsa -aes256 -out server.key 4096Vous devrez creuser un peu plus profondément pour vraiment comprendre ce sujet, mais à un niveau très élevé, la clé privée est utilisée pour générer votre paire de clés asymétriques. Dans l'article que vous référencez, la section `` GÉNÉRER UNE CLÉ DSA '' montre la création de votre clé privée et `` CRÉER UN CERTIFICAT AUTO-SIGNÉ À PARTIR D'UNE DEMANDE DE SIGNATURE DE CERTIFICAT '' montre comment utiliser cette clé pour signer un csr afin que le certificat résultant soit approuvé par votre autorité de certification.
Ceci est un examen VRAIMENT rapide et sale des concepts SSL (je m'attends à être flambé :) donc je vous recommande fortement de creuser plus profondément si vous voulez vraiment vous familiariser avec SSL. Il y a un joli petit aperçu de SSL sur gavaghan.org qui devrait aider à vous donner une compréhension plus complète de la technologie. Un rapide google de "SSL tutorial" ou similaire devrait également donner de bons résultats.