przeglądarka nie skłoniło do certyfikatu klienta

Question

Tło:

Ja aktualizację wewnętrznego aplikacji do procesu uwierzytelniania dwuetapowego. Chcę dodać proces uwierzytelniania certyfikatu klienta (za pośrednictwem karty inteligentnej) na podstawie tradycyjnej nazwy użytkownika/hasła. Aplikacja jest napisana w języku C#, hostowana na IIS7 i kieruje na Chrome i IE8.

Problem:

Mam problemy z dotarciem do wniosku poprosi użytkownika o certyfikat klienta. Debugowałem aplikację przy pomocy Fiddlera. Kiedy mam certyfikat klienta testowego zapisany w katalogu użytkownika Fiddlera (C: \ Documents and Settings \ USER \ Moje dokumenty \ Fiddler2), aplikacja działa zgodnie z oczekiwaniami. Zostałem poproszony o podanie numeru PIN chroniącego kartę inteligentną, a po poprawnym wprowadzeniu do formularza logowania. Kiedy zamykam Skrzypek, aplikacja zgłasza błąd 403 Forbidden (ponieważ Fiddler nie działa i wskazuje na swój certyfikat). To, czego nie byłem w stanie wymyślić, to dlaczego aplikacja nie będzie zwykle pytać o certyfikat.

Obecna konfiguracja serwera:

• Własna Signed Certificate został stworzony
• 443 Wiązanie wskazuje na Jaźni podpisany certyfikat
• Anonymous Uwierzytelnianie jest Włączone
• Self Signed Certificate został dodany do obu zaufany główny urząd certyfikacji i pośredni urząd certyfikacji (czytałem, że inna osoba miała go w obu przypadkach, a nie tylko zaufany główny urząd certyfikacji, i że rozwiązał ich problem, chociaż żadna konfiguracja nie działała dla nas).
• Usunąłem pozostałe certyfikaty w zaufanym głównym urzędzie certyfikacji, których nie potrzebowałem (czytałem gdzie indziej, że zbyt duża liczba certyfikatów spowodowałaby, że SSL się dusi).

Brakuje mi pomysłów na wypróbowanie innych niż uruchamianie od zera na innym serwerze. Czy ktoś wie, co to może być problem? Wygląda na to, że powinno być dość proste i że brakuje mi czegoś nieznacznego. Wszelkie pomysły są mile widziane.

Aktualizacja:

Po spędzeniu więcej czasu z tym problemem dzisiaj jestem przekonany, że ma do czynienia z IIS7 nie jest poprawnie skonfigurowany (nie ustawić go pierwotnie). Myślę, że to dlatego, że włączono śledzenie nieudanych żądań, sprawdziłem generowane kolejne pliki xml i zobaczyłem, że został zgłoszony błąd 500.

Chrome wyświetla komunikat "Dostęp do strony nie został odrzucony" zamiast "403 - Zabroniono: Odmowa dostępu". Nie wiem, czy to pomaga. Wiem, że gdy nie będę wymagać certyfikatów, strona będzie działać zgodnie z przeznaczeniem. Wymaganie certyfikatu następuje w przypadku niepowodzenia.

Pula aplikacji jest ustawiona na .Net 4.0 | Klasyczny | Usługa sieciowa.

Answer 1

Twój problem polega na tym, że przeglądarka nie otrzymuje żądania dostarczenia certyfikatu klienta lub istnieje opcja związana z bezpieczeństwem, aby go zablokować. IE oferuje certyfikat tylko wtedy, gdy witryna jest we właściwej strefie (intranet lub zaufane witryny). Proszę to sprawdzić przed wszystkim.

Jeśli to nie pomoże, przejdź do następnego kroku w następującej answer. Netsh dokumentacja mówi:

clientcertnegotiation 
Optional. Specifies whether the negotiation of certificate is enabled or disabled. Default is disabled. 

Włącz że nawet najgłupszy przeglądarka powinna zauważyć, że ma do zaoferowania certyfikat uwierzytelniania. Aby zdiagnozować problem dalej, możesz użyć WireShark, aby zobaczyć negocjacje w akcji.

Answer 2

Wypróbuj openssl s_client -connect yourip:443 -prexit Sprawdź, czy CA (certyfikat z podpisem własnym) jest wysyłany do klienta w dozwolonych nazwach urzędów certyfikatów klientów.

trzeba najpierw zainstalować OpenSSL jeśli nie masz

Answer 3

w każdej przeglądarce widziałem, przeglądarka nie poprosi, aby wybrać certyfikat, jeśli nie ma żadnych certyfikatów podpisanych przez CA zaufanie do serwera. Dlatego upewnij się, że twój serwer jest skonfigurowany z odpowiednimi urzędami certyfikacji. Jak zasugerował Boklucius, możesz użyć openssl do sprawdzenia listy zaufanych ośrodków CA wysyłanych przez Twój serwer do klientów i sprawdzić, czy urząd certyfikacyjny, z którym podpisałeś certyfikaty klienta, jest wśród nich.

Answer 4

Aby dodać raczej bolesną lekcję do mieszanki: Upewnij się rzucić Skype (lub dowolnej innej aplikacji), który zjada porcie 443.

Więc Chodzi o to, czy używasz środowiska dev na tym samym komputerze (zarówno klient, jak i IIS), a Twój zespół używa komunikacji Skype lub innej aplikacji.

Oglądaj godziny mijają podczas próby i debugowania tego problemu, pozornie robiąc wszystko "dobrze", netsh http sslcerts i takie, nawet ponowne uruchomienie, ale bezskutecznie. Cóż, okazuje się, że Skype zje 443, więc wyłącz to i "puf" idzie do twojego zgłoszenia.

Następnie możesz rzucać rzeczy pod ścianę, krzyczeć wulgaryzmy lub po prostu "Wściekłość, wściekłość przeciw umieraniu światła".

Answer 5

Upewnij się także, że skrzypek nie przeszkadza. Jeśli odszyfrujesz SSL, spowoduje to uszkodzenie wiadomości z powrotem do IE i nie ma zainstalowanego certyfikatu, więc nie może go zaoferować. Wyłącz skrzypce, a na końcu pojawi się monit o certyfikat.