Implications du certificat SSL expiré
Quelles sont les implications pour la sécurité d'un certificat SSL expiré? Par exemple, si un certificat SSL d'une autorité de certification de confiance a expiré, le canal de communication continuera-t-il à rester sécurisé?
La communication est toujours cryptée, mais le mécanisme de confiance est compromis. Mais généralement, le facteur le plus important est que les utilisateurs reçoivent des messages d'avertissement laids sur la sécurité de votre site. La plupart ne porteront pas de jugement éclairé sur l'intégrité de la connexion, ils iront simplement acheter des trucs ailleurs.
Théoriquement, un certificat expiré est un certificat qui ne doit plus être utilisé. Ceci est rendu explicite dans le profil Internet X.509 dans l'algorithme de validation de certificat (section 6.1.3, point a.2). En pratique, cela a deux conséquences:
Le propriétaire de la clé (le serveur) doit garder sa clé privée, enfin, privée. Quiconque obtient une copie de la clé privée peut emprunter l'identité du serveur. La confidentialité de certaines données n'est pas totalement immédiate; par exemple. vous devez penser à la façon dont vous effectuez vos sauvegardes. Une fois le certificat expiré, le serveur peut tout simplement cesser de se soucier de la confidentialité des clés, car la clé publique correspondante ne doit plus être utilisée. Si vous (en tant que client SSL ) décidez d'accepter un certificat de serveur expiré, vous prenez le risque d'utiliser une clé publique pour laquelle la clé privée correspondante a simplement abandonné et récupéré par un méchant.
Il existe une chose connue sous le nom de révocation . Quand une autorité de certification révoque un certificat, elle dit: "oui, c'est ma signature sur ce certificat, mais agissons tous comme si je ne l'avais jamais signé". Une situation de révocation typique est lorsque la clé privée a été compromise. L'autorité de certification publie en permanence l'état de révocation des certificats qu'elle a émis via CRL (listes de certificats révoqués) et OCSP (un protocole de vérification d'état de révocation dédié). Un client SSL est censé obtenir des informations sur l'état de révocation des certificats de serveur avant de l'accepter (dans un contexte Web/HTTPS, la plupart des clients ne s'en soucient pas). Le point clé est qu'une fois qu'un certificat a expiré, l'autorité de certification cesse de suivre son statut de révocation (cela évite que la liste de révocation de certificats se développe indéfiniment). Par conséquent, un client acceptant un certificat expiré prend le risque d'utiliser à son insu un certificat qui a été révoqué au cours de sa vie.
Comme Peter Gutmann le dit , la date de fin de validité d'un certificat "indique l'heure à laquelle vous devez payer à votre CA des frais de renouvellement pour obtenir la réémission du certificat". Le modèle commercial de l'AC commerciale repose intrinsèquement sur le fait que les clients respectent la date de fin de validité. Cela explique également pourquoi les navigateurs Web souhaitent afficher des avertissements effrayants lorsqu'un certificat expire.
Dans un sens pratique, je regarderais la date d'expiration. Si la date est expirée il y a seulement quelques jours, alors personnellement, je lui ferais confiance.
Cependant, les certificats qui ont des années après la date d'expiration auraient pu être compromis et ne devraient pas être approuvés. (En fait, si un site que vous utilisez souvent arrive soudainement avec un certificat expiré depuis assez longtemps, c'est un joli drapeau rouge.)
IE- Si le certificat a expiré hier, la connexion n'est vraiment pas moins sécurisée qu'elle ne l'était hier. Il ne devient pas automatiquement incertain une fois la date d'expiration dépassée.
Vous devez cependant tracer la ligne quelque part ... et c'est à cela que sert la date d'expiration.
Une autre réflexion sur l'expiration d'un certificat consiste à résoudre la question de l'algorithme de clé asymétrique lui-même. A partir d'une clé publique est-il possible de déterminer la clé privée? Eh bien la réponse est improbable plutôt qu'impossible. En règle générale, on suppose qu'il faudrait un million d'années à un ordinateur pour trouver la clé privée à partir d'une clé publique. Mais que faire si vous exécutez un million d'ordinateurs pendant un an. Vous pourriez vous retrouver avec la clé privée et maintenant, lorsque vous pensez à utiliser cette clé privée, il serait vraiment frustrant de réaliser que l'utilisateur a renouvelé le certificat. (Cela ne signifie PAS qu'il a payé de l'argent pour conserver l'ancien certificat, mais cela signifie qu'un nouveau certificat avec une nouvelle clé publique est en place maintenant et que le million d'ordinateurs devraient commencer leur travail à partir de zéro)
Btw, que se passe-t-il si j'utilise tous ces ordinateurs pour continuer à générer des paires de clés publiques et privées et stocker les deux dans une table à deux colonnes dans une base de données. Y a-t-il une chance de lire la clé privée directement à partir de la clé publique entrée?