Existe-t-il un cache d'état de certificat SSL / TLS sur Windows, IE et Outlook et comment il a été géré?
Aujourd'hui, j'ai changé le certificat SSL utilisé par plus de 3 000 clients Outlook. Ce faisant, j'ai changé le certificat pour un "plus ancien" qui avait le même nom de sujet, l'expiration et tout le reste. Seule l'empreinte numérique et un SAN nom changé. Une fois que les rapports sont arrivés d'un problème, j'ai annulé le changement. (1 heure)
Il semble que ce faisant, plusieurs instances déployées d'Outlook se soient bloquées, et malgré mes 15 années de travail avec Outlook en tant que support, je n'ai pas pu récupérer le profil et j'ai dû le recréer. (Je ne veux pas répéter ce processus pour les 20+ profils restants)
Je ne peux que supposer qu'un cache SSL existe dans Windows, Outlook ou dans sa dépendance IE.
Cela m'amène à ma question:
Quelles données SSL existent dans le IE bouton d'état SSL? S'agit-il d'un cache de données HTTP Web ou de données de certificat?
Existe-t-il un cache SSL par application et/ou un cache global? (par exemple schannel, etc.)
Comment éditer ou gérer ce cache?
Voici une image de l'éditeur SSL en IE (voir "Clear SSL State")
Mise à jour:
Même si le certificat est correctement formé, décocher la zone de texte suivante dans la configuration d'Outlook semble résoudre le problème
Le bouton 'Clear SSL State' est là pour purger le cache SSL des certificats clients sélectionnés utilisés pour l'authentification auprès des services SSL. Il est juste là pour accélérer le travail des certificats clients (en partie en se souvenant du certificat que vous avez utilisé pour vous authentifier sur un certain site). Il ne met pas en cache les certificats SSL précédemment vus.
Outlook + Exchange peut utiliser des certificats clients pour l'authentification, mais ce n'est pas une configuration courante; la plupart des sites s'en tiennent à NTLM ou Kerberos sur SSL.
Outlook + IMAP ne peut pas utiliser de certificats clients, mais je peux très bien me tromper; Je n'ai pas entendu parler d'un cas où ils sont utilisés.
À la place, vous pouvez rencontrer des problèmes avec le validateur SSL Windows.
Normalement, la gestion SSL se fait par processus. L'implémentation SSL DLL se souviendra, par exemple, des sessions SSL et pourra négocier des poignées de main abrégées (c'est à ce moment qu'un le client se reconnecte à un serveur et accepte de réutiliser le secret partagé symétrique qu'il a établi dans une connexion précédente. Internet Explorer a désormais l'habitude de générer plusieurs processus, mais inclut quelques astuces pour partager les informations de session SSL sur l'ensemble de ce processus. disparaît quand tous les processus IE sont fermés, cependant.
Ce qui reste dans le cache sont les CRL. Lorsque Windows souhaite valider un certificat (par exemple un certificat de serveur), il essaie d'obtenir des informations de révocation, donc des réponses CRL ou OCSP, téléchargées à partir de l'URL qui se trouvent dans les certificats eux-mêmes. Windows mettra en cache la liste de révocation de certificats, et c'est un cache sur disque car il résiste aux redémarrages. Windows mettra également en cache la CRL "négative", c'est-à-dire les échecs d'obtention d'une CRL à partir d'une URL donnée. Si Windows n'a pas pu obtenir une liste de révocation de certificats à partir d'une URL spécifique, il peut s'abstenir de réessayer la même URL pendant huit heures - et même un redémarrage peut ne pas suffire pour la déverrouiller. C'est souvent gênant.
De la même façon que le cache CRL, Windows peut également télécharger des certificats d'autorité de certification intermédiaires, à l'aide de l'URL des certificats (le Authority Information Access extension). Ces certificats d'autorité de certification peuvent également être mis en cache, bien qu'ils n'apparaissent pas nécessairement dans les magasins de certificats (comme visible depuis certmgr.msc).
Voir cet article de blog pour quelques informations sur le cache CRL Windows.
Lorsque vous utilisez l'authentification client basée sur un certificat dans un contexte Active Directory, les choses deviennent plus complexes, car:
- Le client SSL valide le certificat de serveur SSL.
- Le serveur SSL valide le certificat du serveur AD.
- Le serveur AD valide le certificat client SSL.
Les trois validations effectuées sur des machines distinctes, avec des règles subtilement distinctes, et le mappage des certificats sur les comptes AD peuvent échouer de plusieurs manières.