Lorsqu'un certificat a expiré, son statut de révocation n'est plus publié. Autrement dit, le certificat a peut-être été révoqué depuis longtemps, mais il ne sera plus inclus dans la CRL. La date d'expiration du certificat est la date limite pour l'inclusion dans la CRL. C'est la raison officielle pour laquelle les certificats expirent: pour limiter la taille des CRL.

(La raison non officielle est de faire payer aux propriétaires de certificats des frais annuels.)

Vous ne pouvez donc pas faire confiance à un certificat expiré car vous ne pouvez pas vérifier son état de révocation . Il a peut-être été révoqué il y a des mois, et vous ne le sauriez pas.

Une bonne question. La réponse la plus simple est que d'avoir une date d'expiration garantit que vous avez un "audit" de temps en temps. S'il n'y avait pas de date d'expiration et que quelqu'un cessait d'utiliser un certificat (et de protéger la clé privée), personne ne le saurait jamais. Cependant, en ayant une date d'expiration, vous vous assurez que l'utilisateur retourne à l'entreprise qui lui a vendu le certificat SSL et lui paie beaucoup plus d'argent, je veux dire, qu'il a un audit et qu'il est re-validé en tant que personne ou service qu'il prétend. be (je vais essayer de ne pas tenir compte du modèle de sécurité Internet actuel).

Le problème devient alors: si vous allez avoir une période de grâce dans laquelle vous ignorez les certificats expirés, combien de temps cela dure-t-il? Un jour? Une semaine? Un mois? À un moment donné, vous devez simplement cesser de faire confiance au certificat; si vous faites ce point un jour après l'expiration, vous pouvez toujours vous demander: "Qu'est-ce qui aurait pu se passer entre aujourd'hui et hier?" Et vous tombez dans une boucle.

En gros, vous avez raison: les gens n'arrêtent pas comme par magie de protéger leurs clés privées dès que la date d'expiration arrive (ou ils ont peut-être cessé de les protéger il y a longtemps et personne ne le sait parce qu'ils ne les ont pas révoqués et qu'ils n'ont pas encore expiré). La date d'expiration ne dit rien sur la sécurité du certificat, mais si vous n'avez pas de limite, vous ne saurez jamais qu'un certificat peut être oublié alors qu'avec un certificat vous en savez au moins autant .

S'il y avait une période de grâce universelle de cinq jours, personne ne remarquerait l'expiration des certificats avant cinq jours plus tard, vous laissant avec un effet net identique au refus immédiat d'un certificat expiré. C'est le fait que les connexions SSL cessent de fonctionner qui crée la pression.

Je pense qu'il serait plus productif pour les applications clientes SSL d'avertir bruyamment de l'expiration imminente d'un certificat, de sorte que les utilisateurs de ces applications puissent faire pression sur leur fournisseurs de services à l'avance.

Je suis d'accord que le système actuel n'est pas optimal.

Un meilleur système de certificats pourrait avoir une période d'état "jaune" pour les certificats qui sont sur le point d'expirer ("vert" étant un certificat valide, et "rouge" "étant un certificat expiré), expirant dans un délai d'un mois. Chaque certificat de N ans expirerait après N ans + 1 mois, bien qu'ils soient idéalement mis à jour dans la période de N ans. Cependant, au cours du dernier mois, chaque application qui utilise un certificat doit présenter un avertissement léger à l'utilisateur. Pour la navigation Web, vous pouvez faire quelque chose comme colorer l'URL en jaune au lieu de vert - avec un message de survol / clic à l'effet:

Le certificat de ce site Web expirera le 25 mars 2013 et doivent être mis à jour par le propriétaire du domaine avant leur expiration. Le certificat est toujours parfaitement valide et devrait être entièrement fiable à cette date, mais les applications qui reposent sur ce certificat cesseront de fonctionner le 25 mars 2013 si le certificat n'est pas mis à jour d'ici là.

Serait-ce parfait? Probablement pas, car certaines applications peuvent ne pas transmettre ces messages à l'utilisateur et la date d'expiration sera toujours atteinte. En outre, il doit y avoir un accord codifié dans une norme pour savoir combien de temps avant l'expiration des certificats qu'ils doivent être mis à jour (un jour? Une semaine? Deux semaines? Un mois?). Mais cela semble définitivement être une amélioration.

(Certes, je suis d'accord que Microsoft a vraiment laissé tomber le ballon quand ils ont laissé leur certificat Azure expirer - c'est un signe d'incompétence pour une plate-forme essayant de prendre en charge les applications d'entreprise ).

La réponse est aussi simple que l'entreprise: "La facture n'est pas payée"

L'autorité de certification prétend pour une période de temps distincte que ce certificat est valide. Mais cela ne dit pas grand-chose sur la confiance de l'autorité de certification et les processus par le propriétaire du certificat.

Cela a à voir avec la perception et les pratiques de sécurité appropriées.

Lorsque vous créez un certificat avec, par exemple, une expiration d'un an, vous dites essentiellement "Nous ne pouvons pas garantir l'intégrité du certificat pour plus d'un an, nous allons donc déployer un nouveau certificat avant cette date . "

Ainsi, un site avec un certificat expiré est un signe que les administrateurs ne l'ont pas fait tenir leur promesse de renouveler dans le délai fixé pour eux-mêmes, ce qui suggère de mauvaises pratiques de sécurité.

C'est la même raison pour laquelle vous attrapez l'enfer pour manquer une inspection de voiture même si votre voiture semble être fonctionne bien, ou pourquoi les produits ont une date de péremption.

La durée de conservation peut être une chose intéressante pour certains produits: le fabricant déclare qu'il garantit que le produit sera valide pendant un certain temps mais il ne peut pas garantie que les propriétés d'origine seront présentes si vous consommez le produit après cette période.

Un certificat a la même chose: il a une période où l'émetteur déclare qu'il est valide. Pendant ce temps, le certificat devrait être correct. Et si ce n'est pas le cas, il y aura un rappel à ce sujet: une liste de révocation par l'émetteur dira au monde entier "Ne faites plus confiance à ce certificat, car d'une manière ou d'une autre, il pourrait être compromis".

Après la date d'expiration, l'émetteur ne gardera plus trace de ce certificat: il a dépassé la date à laquelle il était bon, donc quiconque lui fait encore confiance devrait le faire uniquement sur sa croyance, pas sur l'émetteur (ou quelqu'un d'autre) .

Après la date d'expiration, le certificat n'est pas mauvais, cassé, malodorant ... il n'est plus garanti d'avoir été révoqué. Et pourquoi ne faisons-nous pas confiance à un certificat SSL qui a expiré récemment , c'est parce que nous voulons la sécurité et que nous utilisons des certificats pour garantir quelque chose. Si nous ne pouvons pas être sûrs s'il a été (ou serait) révoqué , vous ne pouvez pas être sûr qu'il a été compromis, et vous ne disposez d'aucune sécurité qui l'utilise ...

Outre les choses déjà mentionnées (il est bon de changer régulièrement ces clés, les CA veulent être payés, ré-auditer l'identité, etc.), il y a aussi une raison technique. Les navigateurs vous informent qu'ils ne peuvent pas vérifier la validité du certificat.

Les certificats peuvent être révoqués, c'est-à-dire marqués comme invalides, au cas où leurs clés seraient compromises, l'AC signale qu'ils ont été mal émis, etc. Ces informations de révocation sont garantie d'être fournie pendant la période de validité, mais pas après. Cela permet de réduire la taille des CRL (Certificate Revocation List). Bien que les CRL soient rarement utilisées aujourd'hui dans SSL basé sur un navigateur, cela pourrait également affecter d'autres moyens de vérifier la validité.

Pour cette raison, l'application de la date de validité a un sens technique et n'est pas effectuée uniquement parce que "les certificats devraient être renouvelé pour garantir que les nouvelles vérifications "et" les CA veulent être payés ".

La définition de la date d'expiration des certificats est effectuée pour à peu près la même raison que vous devez changer votre mot de passe de temps en temps et avoir une politique pour que les utilisateurs le changent de temps en temps. Pas toujours nécessaire , mais cela peut parfois s'avérer utile.

Par exemple, votre ancien employé ayant votre poste de CA (interne) pourrait signer son site Web de phising et vous ne remarquerez aucune différence sur le tout entre son site et votre site bancaire (y compris votre navigateur indiquant que la connexion est sécurisée). Avoir une date d'expiration au moins sur l'autorité de certification interne vous oblige à la modifier de temps en temps et à éviter cela.

Vous pouvez toujours dire "Je m'en fiche" et définir la date du certificat sur par exemple. 2300 (si vous êtes propriétaire de CA). Bien sûr, des autorités commerciales externes voudront peut-être vous faire définir la date d'expiration de votre licence ;-).

Cela dépend de ce que vous sécurisez. C'est relativement sûr. Cela équivaut à une attaque de type zero-day, homme au milieu. Un attaquant devrait savoir que le certificat a expiré, savoir que vous utilisez ce certificat et s'insérer entre vous et le serveur en l'espace de quelques jours. Si vous gardez des secrets nucléaires, il est trop risqué de faire confiance. Si vous envoyez votre numéro de carte de crédit, ce serait ok pour quelques jours ou semaines (pas que vous soyez responsable de toute façon). Si vous bloguez sur les dictateurs en Iran, alors que vous êtes en Iran, vous risquez votre vie et cela ne vaut peut-être pas la peine.