Différence entre une CA auto-signée et un certificat auto-signé
Je ne vois pas bien la différence entre une clé de L'AC et un certificat. Une clé de L'AC n'est-elle pas simplement un certificat? Laissez-moi essayer de clarifier avec un exemple.
j'ai un client et un serveur. J'essaie seulement de valider ma connexion à mon serveur et de ne pas essayer d'établir la confiance des autres donc je ne me soucie pas de signer avec une vraie CA.
Option 1: générer un CA auto-signé ( ssCA ) et utiliser celui de signer un certificat ( c ). J'installe ensuite ssCA dans le keystore racine de mon client et configure mon serveur pour utiliser le certificat c .
Option 2: générer un certificat auto-signé ( SSC ). Installer SSC dans le keystore root de mon client. Configurer mon serveur pour utiliser le certificat SSC .
La deuxième option semble être un processus beaucoup plus simple. Si cela fonctionne?
4 réponses
les deux options sont valables, l'option 2 est plus simple.
L'Option 1 (configurer votre propre CA) est préférable lorsque vous avez besoin de plusieurs certificats. Dans une entreprise, vous pouvez configurer votre propre CA et installer le certificat de CA dans le keystore racine de tous les clients. Ces clients accepteront alors tous les certificats signés par votre AC.
L'Option 2 (auto-signature d'un certificat sans AC) est plus facile. Si vous avez juste besoin d'un seul certificat, puis c'est suffisant. Installez - le dans les keystores de vos clients et vous avez terminé. Mais quand vous avez besoin d'un deuxième certificat, vous devez l'installer à nouveau sur tous les clients.
voici un lien avec de plus amples informations: créer des Autorités de certification et des certificats SSL auto-signés
tout d'abord, en ce qui concerne la distinction entre clé et certificat (en ce qui concerne la "clé de L'AC"), il y a trois pièces utilisées lorsqu'on parle de certificats à clé publique (généralement X. 509): la clé publique, la clé privée et le certificat. La clé publique et la clé privée former une paire. Vous pouvez signer et déchiffrer avec la clé privée, vous pouvez vérifier (une signature) et chiffrer avec la clé publique. La clé publique est destiné à être distribué, alors que la clé privée est conçu pour être maintenu privé.
Un certificat de clé publique est la combinaison entre une clé publique et à diverses informations (principalement concernant l'identité du propriétaire de la paire de clés, la personne qui contrôle de la clé privée), cette combinaison étant signée avec la clé privée de l'émetteur du certificat. Un certificat X. 509 possède un nom distinctif par sujet et un nom distinctif d'émetteur. L'émetteur nom est le nom du sujet du certificat de l'entité émettrice du certificat. Les certificats autosignés constituent un cas particulier où l'émetteur et le sujet sont les mêmes. En signant le contenu d'un certificat (c'est-à-dire en émettant le certificat), l'émetteur en affirme le contenu, en particulier la liaison entre la clé, l'identité (le sujet) et les divers attributs (qui peuvent indiquer l'intention ou le champ d'utilisation du certificat).
en outre, la spécification PKIX définit une extension (partie d'un certificat donné) qui indique si un certificat peut être utilisé comme certificat de L'AC, c'est-à-dire s'il peut être utilisé comme émetteur pour un autre certificat.
De cette, vous générez une chaîne de certificats entre le certificat d'entité finale (qui est celui que vous voulez vérifier, pour un utilisateur ou un serveur) et un certificat d'autorité de certification de confiance. Il peut y avoir des certificats CA intermédiaires (émis par d'autres certificats CA) entre le certificat d'entité finale de votre service et le certificat CA en qui vous avez confiance. Vous n'avez pas strictement besoin D'une CA racine au sommet (un certificat CA auto-signé), mais c'est souvent le cas (vous pouvez choisir de faire confiance à un certificat CA intermédiaire directement si vous le souhaitez).
pour votre cas d'utilisation, si vous produisez un certificat auto-signé pour un service spécifique, peu importe qu'il ait le drapeau CA (basic constraints extension). Vous aurez besoin d'un certificat D'AC pour pouvoir délivrer d'autres certificats (si vous voulez créer votre propre ICP). Si le certificat vous générez pour ce service est un certificat CA, il ne devrait pas faire de mal. Ce qui importe le plus, c'est la façon dont vous pouvez configurer votre client pour qu'il ait confiance en ce certificat pour ce serveur particulier (les navigateurs devraient vous permettre de faire une exception explicite assez facilement par exemple). Si le mécanisme de configuration suit un modèle D'ICP (sans utiliser d'exceptions spécifiques), puisqu'il n'y aura pas besoin de construire une chaîne (avec un seul certificat), vous devriez pouvoir importer le certificat directement dans le les ancrages de confiance de votre client, qu'il s'agisse d'un certificat de L'AC ou non (mais cela peut dépendre du mécanisme de configuration du client).
vous pouvez openssl x509 -noout -text -in $YOUR_CERT pour voir les différences entre les contenus de fichiers:
dans votre CA auto-signé, vous pouvez voir le bêti
X509v3 extensions:
X509v3 Basic Constraints:
CA:TRUE, pathlen:0
et dans votre certificat auto-signé, c'est:
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
vous devez toujours avoir une AC racine, L'AC a une clé qui peut être utilisée pour signer un certificat de niveau inférieur et un certificat racine qui peut être intégré dans les certificats racine acceptés sur le client et est utilisé pour vérifier les certificats inférieurs pour vérifier qu'ils sont valides. Auto signé signifie Juste que vous êtes votre propre CA. Chaque fois que vous créez un certificat auto-signé, vous créez une ca, puis signez un certificat de site avec cette CA.