Afin d'être accepté comme émetteur pour d'autres certificats, un certificat CA doit être marqué comme tel: il doit contenir une Basic Constraints extension avec le L'indicateur cA est défini sur TRUE . Si un client (par exemple un navigateur Web) voit une prétendue chaîne de certificats de serveur, avec le certificat «X.com», non marqué comme CA, utilisé comme CA intermédiaire, alors le client rejettera la chaîne, en application de la norme algorithme de validation de certificat, dans section 6.1.4, étape (k):

  (k) Si le certificat i est un certificat de version 3, vérifiez que le L'extension basicConstraints est présente et que cA est défini sur TRUE. (Si le certificat i est un certificat de version 1 ou 2, l'application DOIT alors soit vérifier que le certificat i est un certificat CA par des moyens hors bande, soit rejeter le certificat. Les implémentations conformes peuvent choisir de rejeter toutes les versions 1 et 2 certificats intermédiaires.)  

Notez les commentaires sur les certificats "version 1" et "version 2". Les certificats X.509 modernes sont de "version 3" (leur champ version contient 2, pas 0 ou 1). Les versions précédentes du format X.509 n'avaient pas de place pour les extensions, donc pas de Contraintes de base . La vulnérabilité flagrante que vous craigniez, avec tout propriétaire de certificat pouvant agir en tant qu'autorité de certification, était effectivement flagrante. Mais il a fallu plusieurs années pour que les gens se rattrapent.

Heureusement, toutes les implémentations actuelles de SSL considèrent les certificats v1 et v2 comme "définitivement non-CA", tout comme les certificats v3 qui n'ont pas de contraintes de base extension.

Dans le même ordre d'idées, Internet Explorer, jusque vers 2003 (si je me souviens bien), n'a pas vérifié l'indicateur cA ... et c'était en effet un problème sérieux, qui a été rapidement résolu une fois découvert. Cela en dit long sur X.509 que personne n’avait testé cela depuis un certain temps, car IE avait déjà pris en charge SSL en 1996 et les certificats v3 étaient standardisés au début de 1999 (donc, comme c’est le cas pour Web thing, ils étaient déjà déployés à ce moment-là, et le standard était plus une documentation de la pratique existante qu'autre chose).

Quant à votre question spécifique: combien de temps cette chaîne s'étend-elle? Il n'y a pas de limite intrinsèque, dans la norme X.509, sur la longueur de la chaîne, tant que tous les certificats de la chaîne sont dûment marqués comme CA (sauf peut-être le dernier) et ont les signatures appropriées et tous les champs des certificats correspondent comme ils devraient. Cependant, la certification est une délégation de confiance et la confiance se dilue très rapidement lorsqu'elle est trop déléguée. Ainsi, des chaînes trop longues sont une forte indication que tout le processus PKI a mal tourné.

De plus, les chaînes longues peuvent atteindre des limites internes dans certaines implémentations. La construction de chaînes (l'opération qui prépare les chaînes potentielles à être validées) peut devenir onéreuse (avec des certificats spécialement conçus, elle peut avoir un coût factoriel pour une longueur de chaîne donnée), les implémentations doivent donc inclure un mécanisme de protection, qui est souvent une longueur de chaîne maximale interne. Les chaînes pratiquement rencontrées ont une longueur de 2 à 4 certificats (c'est-à-dire une racine, trois CA intermédiaires au maximum, puis le certificat d'entité finale). Mon propre code a tendance à rejeter les chaînes au-delà de 8 certificats, et cette limite arbitraire n'a jamais été, d'après mon expérience, un problème.

Lorsqu'une autorité de certification racine signe un certificat pour une autorité de certification intermédiaire, le certificat signé a un ensemble de champs spéciaux (en particulier, un indicateur d'autorité de certification dans l'extension Basic Constraints), qui le désigne comme une autorité de certification certificat. Les certificats signés pour les domaines, comme vous le feriez auprès de votre autorité de certification, n'ont pas ce champ défini. Votre navigateur ne les considérera donc pas pour la chaîne de certificats de confiance vers l'autorité de certification racine.

Combien de temps cette chaîne s'étend-elle?

Il n'y a pas de limite spécifiée, mais les clients (navigateurs, programmes de messagerie, etc.) peuvent avoir une limite interne quant au nombre de sauts qu'ils sont prêts à suivre.

Je ne peux pas utiliser X.com pour signer un certificat pour un autre domaine, disons Y.com. Si non, pourquoi pas? Si oui, je ne vois pas l'objectif de la signature.

Non, car le certificat de X.com n'est pas marqué comme un certificat de signature.

Ou plutôt: oui, vous pourriez , la technologie sous-jacente ne vous empêche pas de le faire. Mais les navigateurs sont programmés pour vérifier la contrainte de base CA: true pour tous les certificats de signature et intermédiaires, et ne feront pas confiance à la signature si ce n'est pas vrai.

Convaincre une CA signer pour vous un certificat intermédiaire n'est pas une mince affaire, car ils jalonnent leur réputation en affirmant que vous ne signerez rien qui ne devrait pas être signé. Pas une petite garantie.

Malheureusement, X.com ne peut pas signer Y.com pour des raisons de sécurité. Prenons l'exemple suivant:

1. Mallory tente d'effectuer une attaque MITM sur Alice et Bob. Il possède un certificat valide signé par Verisign pour Z.com.
2. Alice envoie le certificat valide pour X.com à Bob, signé par Verisign.
3. Mallory intercepte cette connexion, signe un certificat pour X.com avec son certificat pour Z.com et l'envoie à bob.
4. Maintenant, Mallory peut déchiffrer toutes les données provenant de Bob car il a la clé privée du certificat qu'il a envoyé, signé par Z.com.

Répondant directement à votre question, NON. Dans votre cas, la chaîne ne s'étendra pas. Afin de valider un certificat donné, le navigateur doit vérifier la signature de l'autorité de certification sur le certificat. Cela se fait en utilisant la clé publique (certificat numérique) de l'autorité de certification. Les navigateurs sont livrés avec ces certificats CA déjà installés (Il est possible d'installer manuellement un certificat dans un navigateur)

Si vous utilisez le certificat de X.com pour signer un certificat pour un autre domaine Y.com , les navigateurs ne pourront pas valider votre certificat car vous n'êtes pas dans la liste des autorités de certification de confiance et un avertissement de sécurité sera émis.

Fondamentalement, les certificats sont utilisés pour vérifier l'authenticité du serveur. Ceci est nécessaire pour empêcher les attaques MITM. Sinon, un attaquant pourrait prétendre qu'il est le vrai serveur et votre navigateur enverrait volontiers des messages chiffrés avec la clé privée de l'attaquant.Par conséquent, seuls les certificats signés par des autorités de certification de confiance sont approuvés par le navigateur.