Le navigateur ne demande pas de certificat client
Contexte:
Je mets à jour une application interne vers un processus d'authentification en deux étapes. Je veux ajouter un processus d'authentification de certificat client (via une carte à puce) en plus d'un formulaire de nom d'utilisateur/mot de passe traditionnel. L'application est écrite en C #, hébergée sur IIS7 et ciblant Chrome et IE8.
Problème:
J'ai des problèmes pour que l'application demande à l'utilisateur un certificat client. J'ai débogué l'application avec l'aide de Fiddler. Lorsque j'ai un certificat de client de test enregistré dans le répertoire de l'utilisateur de Fiddler (C:\Documents and Settings\USER\My Documents\Fiddler2), l'application fonctionne comme prévu. Je suis invité à entrer un numéro PIN protégeant la carte à puce et, une fois entré correctement, me conduit au formulaire de connexion. Lorsque je ferme Fiddler, l'application génère à la place une erreur 403 Forbidden (puisque Fiddler ne fonctionne plus et pointe vers son certificat. Ce que je n'ai pas pu comprendre, c'est pourquoi l'application ne demandera pas normalement un certificat.
Configuration actuelle du serveur:
- Le certificat auto-signé a été créé
- 443 La liaison pointe vers un certificat auto-signé
- L'authentification anonyme est activée
- Le certificat auto-signé a été ajouté à la CA racine approuvée et à la CA intermédiaire (j'ai lu qu'une autre personne l'avait dans les deux plutôt que dans la CA racine approuvée et qui a résolu leur problème, bien qu'aucune configuration n'ait fonctionné pour nous).
- J'ai effacé le reste des certificats de l'autorité de certification racine de confiance dont je n'avais pas besoin (j'ai lu ailleurs que le fait d'avoir trop de certificats provoquerait l'étouffement de SSL).
Je suis à court d'idées pour essayer autre chose que de recommencer à zéro sur un autre serveur. Quelqu'un sait-il quel est le problème? Cela semble être assez simple et il me manque quelque chose de mineur. Toutes les idées sont les bienvenues.
Mise à jour:
Après avoir passé plus de temps avec ce problème aujourd'hui, je crois fermement que cela a à voir avec IIS7 qui n'est pas configuré correctement (je ne l'ai pas configuré à l'origine). Je pense que cela parce que j'ai activé le suivi des demandes ayant échoué, regardé les fichiers .xml suivants en cours de génération et vu qu'une erreur 500 était lancée.
Chrome lance un message "L'accès à la page Web a été refusé" plutôt qu'un message "403 - Interdit: l'accès est refusé". Je ne sais pas si cela aide. Je sais que lorsque je ne fais pas de certificats requis, le site fonctionnera comme prévu. Exiger un certificat est l'endroit où il échoue.
Le pool d'applications est défini sur .Net 4.0 | Classique | Service réseau.
Votre problème est que le navigateur n'obtient pas la demande de fournir un certificat client ou qu'il existe une option liée à la sécurité pour l'empêcher de se produire. IE n'offre de certificat que si le site Web est dans la zone correcte (intranet ou sites de confiance). Veuillez vérifier cela avant tout.
Si cela ne vous aide pas, voyez ceci réponse pour l'étape suivante. La documentation netsh dit:
clientcertnegotiation
Optional. Specifies whether the negotiation of certificate is enabled or disabled. Default is disabled.
Activez cela et même le navigateur le plus stupide devrait remarquer qu'il est censé offrir un certificat pour l'authentification. Pour diagnostiquer davantage votre problème, vous pouvez utiliser WireShark pour voir la négociation en action.
Essayez openssl s_client -connect yourip:443 -prexit Et voyez si l'autorité de certification (votre certificat auto-signé) est envoyée au client dans les noms des AC de certificat client acceptables.
vous devez d'abord installer openssl si vous ne l'avez pas
Dans tous les navigateurs que j'ai vus, le navigateur ne vous invitera pas à sélectionner un certificat s'il n'a aucun certificat signé par une autorité de certification approuvée par le serveur. Assurez-vous donc que votre serveur est configuré avec les bonnes autorités de certification. Comme Boklucius l'a suggéré, vous pouvez utiliser openssl pour examiner la liste des autorités de certification approuvées que votre serveur envoie aux clients et voir si l'autorité de certification avec laquelle vous avez signé vos certificats client en fait partie.
Pour ajouter une leçon assez douloureuse au mélange: assurez-vous de quitter Skype (ou toute autre application) qui mange le port 443.
L'idée est donc ici si vous exécutez un environnement de développement sur la même machine (client et IIS) et que votre équipe utilise Skype ou une autre application pour communiquer.
Regardez les heures s'écouler pendant que vous essayez de déboguer ce problème, en faisant apparemment tout "bien", netsh http sslcerts et ainsi de suite, même en redémarrant mais en vain. Eh bien, il s'avère que Skype en mangera 443, alors éteignez-le et "pouf", votre certificat vous invite.
Alors n'hésitez pas à jeter des objets contre le mur, à crier des obscénités ou tout simplement "Rage, rage contre la mort de la lumière".
Je lancerai une suggestion "essayez de redémarrer le navigateur", en particulier si vous avez installé le certificat pendant que le navigateur était en cours d'exécution.
Assurez-vous également que Fiddler ne vous gêne pas. Si vous le décryptez SSL, il corrompra le message vers IE et il n'a pas le certificat installé, il ne peut donc pas l'offrir. Éteignez le violoneux, et le tour est joué, l'invite de certificat apparaît.