Jessaye de travailler avec lAPI OpenSSL C, je suis encore relativement nouveau dans tout cela, et je trouve beaucoup dinformations mitigées, donc je pense quil est sage de demander des idées / opinions / clarifications.
Quoi quil en soit, le programme client nécessite un certificat ou un répertoire à charger qui contient un « TrustStore ». Est-ce juste une autre signification pour le certificat CA du serveur lui-même dans le cas où je créerais mes propres certificats SSL pour ledit serveur?
Et si oui, est-ce que lautorité de certification intermédiaire fonctionnera à cette fin en remplacement de lautorité de certification racine?
Je pense que je suis sur la bonne voie. Cependant, je voulais juste quelques éclaircissements pour éviter de faire une véritable erreur stupide, car jai entendu des informations contradictoires à ce sujet. Certains disent que le client a besoin de lautorité de certification racine elle-même; dautres sources disent quils ninstallent que lautorité de certification intermédiaire pour des raisons de sécurité, ce qui semble logique.
Je suis généralement un peu confus quant au fonctionnement de la chaîne de confiance en ce qui concerne une connexion client. En fait, je n’ai jamais eu besoin que de générer un CSR et d’installer un certificat sur le serveur Web, donc le côté client est un peu nouveau pour moi.
Cette question a été posée à l’origine ici sur Stack Overflow, il a été suggéré que je demande à la communauté info-sec.
Commentaires
- Je pense que vous utilisez la mauvaise phrase: un certificat auto-signé est un certificat où le certificat de lémetteur est le certificat lui-même. Vous signifie un certificat qui est signé par votre propre autorité de certification à la place. Dans ce cas: lautorité de certification racine est généralement placée dans le magasin de confiance et le certificat intermédiaire signé par lautorité de certification racine et le certificat feuille signé par le certificat intermédiaire sont envoyés lors de létablissement de liaison TLS .
- Possible duplication de Comment fonctionne SSL / TLS PKI?
Réponse
tl; dr Si le certificat contient une variante de CA:TRUE, il est logique de le distribuer, sinon, il ny a aucun avantage à le distribuer.
La chaîne de confiance elle-même peut être expliquée en termes de structure du certificat.
Si nous partons du certificat de votre serveur (ie le certificat que vous utiliseriez généralement pour apache):
- votre certificat de serveur est généré par une autorité de certification, basée sur un CSR que vous fournissez. Ce CSR contient votre clé publique et certaines autres informations que lautorité de certification pourrait ou non être intéressée à utiliser.
- lautorité de certification reçoit votre CSR et (généralement) crée un certificat signé à laide dune autorité de certification intermédiaire. Votre certificat aura deux clés publiques: une pour le sujet (qui est la clé publique extraite de votre CSR) et une pour la partie émettrice, qui est le certificat intermédiaire de lautorité de certification.
- lautorité de certification » Le certificat intermédiaire est lui-même un certificat signé (avec quelques options spéciales), où la clé de sujet sera la clé publique de lautorité de certification intermédiaire (qui est la même clé publique que celle trouvée dans la clé publique de lémetteur de votre certificat de serveur). la clé de signature (ou démission) sera le certificat racine de lAC (autrement, ce sera un autre intermédiaire).
- le certificat racine de lautorité de certification est (généralement) un certificat auto-signé. En pratique, cela signifie que les clés émetteur et sujet sont la même clé publique.
Vous pouvez voir cela en vérifiant les certificats dans la nature, par exemple:
$ openssl s_client -connect google.com:443 < /dev/null CONNECTED(00000003) depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA verify return:1 depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2 verify return:1 depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN = *.google.com verify return:1 --- Certificate chain 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.google.com i:/C=US/O=Google Inc/CN=Google Internet Authority G2 1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2 i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority La chaîne de confiance que cela construit peut être résumée comme (je commence par le » bottom « – le certificat Equifax):
- lautorité de certification racine (Equifax) délègue les activités quotidiennes à une autorité de certification intermédiaire (GeoTrust) et signe un certificat représentant ce fait (cest-à-dire en définissant lautorité de certification: TRUE, KeyUsage: keyCertSign). En dautres termes, lautorité de certification racine «fait confiance» à lintermédiaire pour émettre des certificats en son nom (espérons-le après avoir terminé une série détapes de validation obligatoires).
- dans cette chaîne, lintermédiaire (Geotrust) a en outre délégué à une autorité de certification Google (CN = Google Internet Authority G2).
- le délégué (alias lautorité de certification intermédiaire de Google) signe ensuite un CSR, qui est en fait un document indiquant que pour un ensemble de noms (t le CN, et éventuellement les noms alternatifs du sujet), une paire de clés privée / publique est valide / de confiance (la confiance ici provient du fait quils ont validé la revendication de parler pour un nom donné – dans ce cas, lautorité de certification Google a émis un certificat pour * .google.com).
Notez que les autorités de certification (racine) sont généralement auto-signées – une autorité de certification est généralement approuvée car elle respecte un ensemble de processus et de procédures censés garantir quelle ne délivre pas de certificats aux personnes qui ne devrait pas les avoir. Cest pourquoi je ne peux pas sortir et me procurer un certificat indiquant que je suis Google.Il sagit donc dune sorte de convention (quoique soutenue par des mécanismes formels), et si vous démarrez votre propre autorité de certification, la distribution de ses certificats racine (et intermédiaires) réalise exactement la même chose que la distribution des certificats dautres autorités de certification: elle rend les certificats émis par cette autorité de certification être acceptée comme valide (cest-à-dire digne de confiance) par le système.
En termes plus pratiques, le trust store (pour openSSL) est à peu près un ensemble de fichiers avec une convention de dénomination spécifique. Voir https://www.openssl.org/docs/faq.html#USER5 :
Quand un certificat est vérifié, son autorité de certification racine doit être « approuvée » par OpenSSL, cela signifie généralement que le certificat de lautorité de certification doit être placé dans un répertoire ou un fichier et le programme approprié configuré pour le lire
Ce répertoire est / etc / ssl / certs (il y en a dautres, comme / etc / pki sur RH-likes).
https://superuser.com/questions/437330/how-do-you-add-a-certificate-authority-ca-to-ubuntu#719047 fournit un aperçu supplémentaire de la façon dont on ajoute un certificat au magasin, comme https://askubuntu.com/questions/73287/how-do-i-install-a-root-certificate ,
La version courte est que update-ca-certificates automatise le processus, et est loutil couramment utilisé.
La version légèrement plus longue est que les certificats doivent être stockés par hachage (par exemple dans des fichiers nommés based sur la sortie de openssl x509 -hash -in cert.pem), afin quopenSSL puisse valider efficacement les chaînes.
Voir https://www.openssl.org/docs/man1.0.2/apps/c_rehash.html pour plus dinformations.
a mis à jour pour répondre aux questions dans les commentaires:
Le certificat du serveur , dans cette discussion, est défini comme fiable ou non basé sur sa chaîne de confiance. Si vous réfléchissez au fonctionnement (par exemple) de curl https://google.com, cest un peu plus facile à comprendre:
- curl ouvre une connexion TLS à google, qui renvoie un certificat.
- curl regarde ce certificat « utilisateur final » – cest-à-dire le certificat du serveur, et recherche spécifiquement lémetteur.
- si lémetteur est « connu » dans le trust store, le reste de la chaîne de confiance est validé (cest-à-dire que le certificat de lémetteur du certificat serveur est vérifié, et si il a un émetteur autre que lui-même, cet émetteur est vérifié, etc.). Ce nest que si la chaîne de confiance complète peut être validée que le certificat est considéré comme valide.
Cependant, il serait absolument impossible de distribuer des chaînes de confiance si les certificats des utilisateurs finaux devaient être inclus. Je nai pas de chiffres sur le nombre de sites Web, mais sur la base du fait quAlexa fournit un top 1M, vous supposeriez quil est supérieur à 1 million.
Ce qui est en quelque sorte le point de une chaîne de confiance: vous avez généralement besoin davoir les certificats démetteur à portée de main, mais vous navez pas besoin que les certificats finaux soient distribués, car ils vous indiquent qui est lémetteur.
Et vous pouvez vérifier quils ne le sont pas. » t mens, car vous pouvez vérifier la clé publique de lémetteur (et la chaîne de confiance qui établit quil sagit de la clé appropriée), et valider si le certificat de lutilisateur final (cest-à-dire le serveur) a vraiment été signé par la contrepartie privée de lémetteur. clé publique.
Donc non, vous ne devriez pas distribuer les certificats de lutilisateur final, mais seulement la chaîne de confiance – ou, en termes plus simples: distribuer tous les certificats que vous générez où les BasicConstraints (légitimement) disent quelque chose au moins CA: TRUE. Ne distribuez rien qui ne remplit pas cette condition, car cest une perte de temps et despace disque – tout ce qui ne dit pas CA: TRUE peut être validé par rapport à quelque chose qui le fait.
Commentaires
Réponse
Un certificat auto-signé est exactement cela: cest signé moi-même (cest sa propre ancre de confiance).
Par conséquent, pour être fiable, il doit être placé manuellement et explicitement dans la liste des ancres de confiance de lapplication. La façon de procéder dépend du système dexploitation et de lapplication.
Par exemple, si vous utilisez le stockage de certificats interne de Windows, vous devez placer ce certificat auto-signé dans le magasin «autorité de certification racine de confiance», sinon le certificat ne sera pas accepté. OpenSSL utilise un système de stockage différent, spécifique à lapplication: vous devrez également installer le certificat en tant quautorité de certification de confiance, mais la manière de le faire dépend largement de lapplication et du système dexploitation que vous utilisez (voir cet article pour quelques instructions génériques).
Commentaires
- Cela signifie donc le Trust Store " est exactement le même que celui installé dans apache, par exemple? Ce ' s la partie la plus déroutante, i ' ma
GNU/Linuxutilisateur, le répertoire vers lequel je devais me lier dans lapplication cliente, était/etc/ssl/certs. Cependant, je nai pas pu trouver une explication claire de ce quest exactement le processus de ce côté des choses. Au moins vous comprenez ma question ici, le point principal derrière cela est décrire le client et lui faire confiance au serveur auquel il se connecte. - Ce que je ' m essayer de faire exactement est de créer une autorité de certification, et je suppose que le certificat est signé par lautorité de certification (intermédiaire), donc dans ce cas, cela signifie-t-il que lautorité de certification est lancre de confiance, donc le Ca intermédiaire doit être installé dans le répertoire des certificats de confiance? Merci davoir répondu.
- Votre question est donc plus générale. Jai ' proposé de le fermer avec un lien vers la réponse que vous cherchez.
/etc/ssl/certsrépertoire? Comme ils contiennent tous les clés publiques?