Un certificat SSL peut-il avoir une période de validité plus longue que son parent dans la chaîne X.509?
Lorsqu'une chaîne de certificats X.509 est composée de X1, X2 ... Xn et Xn est l'autorité de certification racine, un certificat de niveau inférieur peut-il avoir une période de validité plus longue que ses parents? Je pense que le niveau inférieur devrait être une sous-plage appropriée de niveau élevé au moins dans la pratique.
Bien que je ne puisse pas trouver une telle obligation dans la RFC2459, puis-je me fier à cette hypothèse?
Tous les commentaires sont profondément appréciés.
Il s'agit d'un point historiquement contesté.
Dans le algorithme de validation de RFC 5280 (qui remplace RFC 2459, soit dit en passant), il n'y a aucune exigence de plage de validité nidification. Cependant, certaines implémentations historiques l'ont insisté; voir par exemple le guide de style X.509 de Peter Gutmann:
Bien que cela ne soit spécifié dans aucune norme, certains logiciels nécessitent une imbrication de période de validité, dans laquelle la période de validité du sujet se situe à l'intérieur de la période de validité de l'émetteur. Cependant, la plupart des logiciels effectuent une vérification ponctuelle simple dans laquelle ils vérifient si une chaîne de certificats est valide à un certain moment (généralement l'heure actuelle). Le maintien de l'imbrication de validité requiert qu'une certaine quantité de soin soit utilisée dans la conception des périodes de validité qui se chevauchent entre les générations successives de certificats dans une hiérarchie. D'autres complications surviennent lorsqu'une CA existante est ré-enracinée ou re-parentée (par exemple une CA divisionnaire est subordonnée à une CA d'entreprise).
L'ICP Microsoft ("ADCS", alias Services de certificats Active Directory) applique l'imbrication de la période de validité, en ce sens que, lorsqu'elle émet un certificat, elle n'autorise pas la date de fin de validité de cette supérieur à celui du certificat CA actuel (en effet, tronquer la période de validité prescrite par le modèle si cela devait conduire à une telle situation).
Même si, lors du renouvellement d'un certificat d'autorité de certification, il est possible de conserver le même nom d'autorité de certification et la même clé d'autorité de certification, auquel cas l'ancien et le nouveau certificats d'autorité de certification peuvent être utilisés de manière interchangeable tant qu'aucun des deux n'est expiré, sur les certificats EE émis avant et après après le renouvellement. Autrement dit, si l'ancien certificat CA est CA1, le nouveau est CA2, le certificat EE1 a été émis avant le renouvellement et le certificat EE2 a été émis après, puis CA1-> EE1, CA1-> EE2, CA2-> EE1 et CA2-> EE2 devrait tous valider; ceci est très pratique pour assurer des transitions fluides. Bien que l'imbrication de la période de validité implique que CA1-> EE1 et CA2-> EE2 s'emboîtent, CA1-> EE2 et CA2-> EE1 peuvent ne pas s'emboîter - et c'est très bien.
Résumé: vous ne pouvez pas vous fier à l'imbrication de la période de validité, et vous ne devriez pas essayez d'imposer l'imbrication lors de la validation des certificats.
Hmm, je suis d'accord que je me serais attendu à trouver ces informations dans RFC 5280 4.1.2.5. Validité . (Soit dit en passant, le RFC 5280 rend le RFC 3280 obsolète, ce qui rend le RFC 2459 obsolète, donc vous ne devriez vraiment plus regarder le 2459).
Cela dit, vous pouvez comprendre celui-ci de manière logique (au moins pour un paramètre de type TLS standard): lorsqu'un utilisateur final valide un certificat, il doit suivre la chaîne jusqu'à la racine, en s'assurant que chaque certificat en cours de route est valide. Disons que X2 expire avant X1 (et supposons que X2 était l'émetteur de X1). Une fois X2 expiré, X1 est aussi inutile qu'inutile puisqu'il n'y a aucun moyen de construire une chaîne de validation de X1 à Xn.
Voici un cas où une autorité de certification peut émettre des certificats avec une durée de vie plus longue que la racine: les exigences stipulent que A) Tous les certificats de feuilles doivent avoir une durée de vie de 3 ans (par exemple, ils vont dans des périphériques intégrés) B) Tous les certificats de feuilles doivent être émis à partir de la même racine (disons que vous n'avez que de l'espace pour épingler une racine). Désormais, le certificat CA expirera dans 2 ans et, dans ce délai, vous prévoyez d'émettre un nouveau certificat CA pour la même clé CA. Dans ce cas, il n'y a aucun problème à émettre un certificat de feuille de 3 ans sur une racine de 2 ans.
La question que vous posez est un peu vague quant à savoir si vous recherchez l'autorité de certification/l'émetteur pour appliquer la règle "d'imbrication de validité", ou pour le client/vérificateur pour l'appliquer.
Si vous êtes le CA/l'émetteur: : c'est à vous de décider. Il existe de nombreuses autorités de certification qui n'émettront pas de certificat avec une durée de vie plus longue qu'eux-mêmes. Cela dit, je peux imaginer des scénarios dans lesquels vous pourriez vouloir faire cela.
Si vous êtes le client/vérificateur: Je ne pense pas que cela vous rapporte quoi que ce soit d'être strict à ce sujet. Vous causez intentionnellement des problèmes de compatibilité entre votre client et les autorités de certification qui ne suivent pas "l'imbrication de validité" ... pour quel gain? _ (en supposant que tous les certificats de la chaîne doivent être dans leur période de validité au moment de la validation, je suppose que c'est ce que vous appelez "validation standard" dans votre commentaire).