Salut Journal,
Je me pose une question un peu philosophique juste avant la sieste digestive.
Si je souhaite offrir un accès sécurisé aux visiteurs de mon site web, il me faut utiliser https. Pour cela il me faut un jeu de clé privé/publique. Par ailleurs, si je veux garantir encore plus de sécurité, il me faut certifier ma clé publique avec un Certificate Agent (genre Verisign).
Jusque là, je crois avoir bon.
Verisign va en fait authentifier ma clé publique grace à sa clé privée. L'utilisateur (qui fait confiance à Verisign, car la clé publique de Verisign est stockée dans son navigateur) saura donc que mon serveur web est bien à moi.
Serait-il possible, dès lors, que moi aussi je certifie d'autre clés ? Et si oui, que doit faire le visiteur pour dire à son navigateur que "Lee Nux" est autentifié par Verisign et qu'il autentifie lui-même "Pierre Tramo" ?
Je me demande si je suis clair, là...
Bref, est-ce que les navigateurs supportent l'autentification de manière récursive ? Et si oui, où peuvent-ils trouver les clés publiques qui ne sont pas livrées d'origine ?
Au fait, pkoi une telle question me demanderez-vous ? Ben au vu des prix des différents certificats sur le marché, je pensais m'en créer un à moi tout seul pour mes besoins professionnels, mais je souhaitais également autentifier les clé de deux amis qui ont leur serveur web pour un petit projet et sans moyen financier.
Sur ce, je m'en retourne à ma sieste...
Journal Certificats X.509
1
mar.
2004
# Re: Certificats X.509
Posté par Olivier Tigro . Évalué à 4.
Verisign joue le rôle d'autorité de "confiance" (arf)
Pour pouvoir être toi aussi une autorité de confiance, il faudrait que tu fasses partie de la liste d'heureux élus qui sont dans la liste de ton navigateur. M$ a publié récemment une mise à jour des "certificats racines" pour IE, il existe une liste de certificats similaires pour Mozilla (SSL -> Authorities).
Nous avons décidé de nous passer du tiers de confiance (cité plus haut) en emettants nos propres certificats, c'est l'utilisateur final qui décide de faire confiance en installant le certificat en question.
Je n'ai jamais entendu parler de récursivité en la matière, vu qu'il s'agit avant tout d'un produit commercial...
Sur un site marchand, pour une question d'image, il vaut peut-être mieux que l'utilisateur final accède immédiatement à la page SSL, mais vu le tarif d'un certificat serveur "officiel" (400 à 1000 euros/an), finalement nos clients ont décidé qu'il était tolérable que l'utilisateur entre lui-même nos certificats dans la liste d'Autorités de confiance, moyennant 1 à 2 popup du naviguateur ("Voulez-vous faire confiance à XYZ, ce certificat est issu d'une autorité inconnue...")
# Re: Certificats X.509
Posté par lom (site web personnel) . Évalué à 8.
Ca ne pose pas de problème, tu peux toi même émettre des clés et certificats, à la mano avec openssl, par exemple. Ca se fait très bien, mais si tu en as beaucoup, ça devient lourd. Sinon tu peux passer à des solutions types idx-pki (v1.9.0 sortie ce week end) ou openca. Les clés de l'autorité seront celles que tu as fait certifier par Verisign.
Du coup pour valider les certificats que tu émets, il faut suivre un chemin de certification, ce qui se fait en théorie sans pb. Si l'autorité racine en haut du chemin (Verisign) est considérée de confiance, alors le certificat et les autorités intermédiaires sont de confiance. Je pense que c'est automatique et transparent dans les navigateurs. Du côté serveur, c'est la directive SSLVerifyDepth de mod_ssl qui permet de donner une longueur maximale au chemin de certification.
En espérant que ça t'aide
Bonne sieste
[^] # Re: Certificats X.509
Posté par calandoa . Évalué à 2.
Il me semble que ce qui nous intéresse serait plutôt du coté client : par exemple avec le client basique s_client inclus dans openssl, c'est l'option -verify qui fixe la longueur maximale de la chaine de certificats.
Je pense que tu peux signer les certificats d'autres personnes avec ton certificat validé par verisign, elles devront alors fournir ton certificat (signé par verisign) en plus du leur (signé par toi) pour que n'importe quel client faisant confiance à verisign leur fasse aussi confiance. Enfin je n'ai jamais essayé et je ne parierai pas plus d'une demi cacahuète sur ce que j'avance... le plus simple est que tu essaies toi même :
- tu crées un certif auto signé (A) que tu places dans la liste des certifs de confiance de ton navigateur,
- tu crées le certif (B) d'un site signé par le certif A qui devrait donc marcher sans prbs
- tu crées le certif (C) d'un autre site signé par B.
Si ce dernier marche, alors ça devrait aussi marcher avec verisign...
Si tu executes la manip, donne nous le résultat...
[^] # Re: Certificats X.509
Posté par jcs (site web personnel) . Évalué à 5.
Oui et non. Techniquement si Verisign te signe une clé RSA, tu peux signer ce que tu veux avec, y compris des certificats. Donc tu peux avoir une chaine valide si tu te contentes de vérifier les signatures. Cependant, vérifier une chaine de certificats est un peu (beaucoup) plus complexe. On se contente pas de vérifier les signatures, il existe d'autres conditions, par exemple :
- si le certificat CA racine est v1 (version 1) alors la chaine est nécessairement de longueur 1 donc ton certificat est au bout de la chaine
- l'extension BasicConstraints indique si ta clé peut signer peut signer des clés (c'est un certificat CA) et la longueur maximale de la chaine qu'elle peut signer. Ton certificat peux avoir cette extension indiquant que ton certificat n'est pas un certificat de CA, ou alors le certificat root de Verisign peut indiquer une longueur max de 1. (par exemple, les certificats délivré par le service Thawte Freemail ont cette extension avec le flag CA à faux)
- l'extension KeyUsage indique les utilisations autorisées de ta clé (signature, chiffrement, signature de clé, signature de CRL...) et donc indiquer explicitement que ta clé n'est pas autorisée à signer d'autres clés.
Ces 2 dernières extensions sont critiques ce qui signifie que si un logicel ne sait pas les traiter, alors il doit refuser d'utiliser le certificat.
Il existe d'autres vérifications (mais je ne les ai pas en tête) avant de valider une chaine de certificats et les logiciels comme OpenSSL, ou les navigateurs web implémentent des versions plus ou moins complète de l'algorithme de validation (cf. RFC 3280). Donc il y a de fortes chances que, même si tu signes un certificat avec ta clé signé par Verisign, la chaine soit invalide.
Je suis presque sûr que Verisign inclus une de ces extensions (ou alors son certificat est v1) pour éviter que tu obtiennes une clé de CA pour quelques centaines d'euros.
[^] # Re: Certificats X.509
Posté par Lee Nux . Évalué à 1.
# Re: Certificats X.509
Posté par CopainJack (site web personnel, Mastodon) . Évalué à 1.
[^] # Re: Certificats X.509
Posté par jcs (site web personnel) . Évalué à 7.
[^] # Re: Certificats X.509
Posté par Jérémy SIMON . Évalué à 2.
# Re: Certificats X.509
Posté par jcs (site web personnel) . Évalué à 4.
Plus de sécurité ? C'est très relatif. Verisign signe les clés en respectant une "politique de certification". C'est un document qui explique, entre autres, quelles sont les procédures préalables à la signature de ta clé (par exemple vérifier que tu possède bien de domaine que tu veux protéger avec ton certificat SSL). En clair Verisign apporte 2 choses :
- L'assurance que ton certificat a été émis selon certaines règles (la politique de certification). Mais quel utilisateur va aller les lire ?
- la résolution partielle du problème de distribution du certificat de CA (partiel car après tout, personne n'est obligé de faire confiance à Verisign)
Verisign va en fait authentifier ma clé publique grace à sa clé privée. L'utilisateur (qui fait confiance à Verisign, car la clé publique de Verisign est stockée dans son navigateur) saura donc que mon serveur web est bien à moi.
Non, il saura que Verisign a délivré un certificat pour le domaine toto.com selon les règles définies par la politique de certification.
Serait-il possible, dès lors, que moi aussi je certifie d'autre clés ? Et si oui, que doit faire le visiteur pour dire à son navigateur que "Lee Nux" est autentifié par Verisign et qu'il autentifie lui-même "Pierre Tramo" ?
Bref, est-ce que les navigateurs supportent l'autentification de manière récursive ? Et si oui, où peuvent-ils trouver les clés publiques qui ne sont pas livrées d'origine ?
Tu veux que Verisign te signe une clé de CA, pour que tu puisse signer toi même d'autres certificats.
La bonne nouvelle c'est que le navigateur reconstitue les chaines de certificats tout seul, c'est prévu dans les protocoles (l'algorithme de validation des chaines de certificat est dans la RFC 3280 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile) s'il connait la "root CA" (dans ton exemple Verisign).
La mauvaise c'est que Verisign ne te vendra pas de clé de CA, pour plusieurs raisons. D'abord parce que c'est très cher, Verisign ne va pas te donner le bâton avec lequel les frapper, après tout avec ta CA tu peux très bien vendre des certificats SSL tout aussi valables que ceux de Verisign pour moins cher. Ensuite il faut une infrastructure : on ne garde pas une clé de CA sur un disque dur, même chiffré, il faut un module de sécurité hardware (plusieurs milliers d'euro au bas mot) et un lieu sécurisé, une PKI pour traiter les demandes de certification qui arrivent et signer les clés publiques... Et en plus il faut payer un audit de sécurité demandé par Verisign et un avaocat pour rédiger la politique de certificattion de ta CA.
Une clé de CA distribuée à n'importe qui, ça fait déordre, et la crédibilité en prend un coup. Quand on a compris que le business de Verisign (et des autres root CA) est surtout basé sur la confiance que les gens ont dans leur clé, et donc les clés qu'ils ont signée, on comprend pourquoi ils demandent de sérieuses garanties quand ils signent une clé de CA.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.