Résumé : Nous avons deux environnements Windows Server + II6 différents qui sont compatibles avec le protocole SSL. L'un se comporte comme nous le souhaitons et l'autre non.
Configurations du serveur :
- Windows Server 2003 SP2
- IIS 6
- Les pages sont configurées pour l'authentification du client SSL.
Détails : Nous avons une VM de production qui est configurée pour héberger un site Web IIS 6 avec quelques pages nécessitant une authentification client SSL pour activer le CAC. Sur cette VM de production, la page présente le certificat du serveur, puis meurt avant de demander le certificat du client. Afin de tester la configuration du serveur, nous avons créé une page "Hello World" avec la même configuration que ces pages CAC, et nous avons obtenu les mêmes résultats. Nous avons ensuite pris cette page et l'avons placée sur une machine virtuelle connue pour fonctionner avec les mêmes versions OS/IIS et avons configuré la page de la même manière. La page se comporte correctement en demandant le certificat du client puis en chargeant la page.
Mesures que nous avons prises pour résoudre ce problème :
- Vérification de l'intégrité du chemin de certificat sur les deux machines.
- Diffusion des métabases IIS entre les deux VM pour vérifier les incohérences.
- Création et installation d'un nouveau certificat de serveur sur la VM cassée.
- Modification de l'option "Exiger les certificats des clients" au lieu de "Accepter les certificats des clients".
- J'ai vérifié le journal IIS pour les erreurs. Tous les accès reviennent à 200.
Nous avons trouvé une option qui résout notre problème, mais qui en crée de nouveaux. Il existe une option permettant de négocier les certificats clients pour toutes les pages, ce qui entraîne l'apparition de l'invite de certificat, mais toutes les pages doivent le faire, ce qui va à l'encontre de l'objectif de la session SSL.
Il est également important : Ce VM cassé a été STIGgé selon les spécifications du gouvernement. Nous pensons que cela peut être la cause sous-jacente. Cependant, nous ne pouvons pas contrôler la possibilité d'enlever le STIG. Par conséquent, nous devons travailler avec nos limites actuelles.
