Omówienie techniczne dostawcy obsługi zabezpieczeń Schannel

Artykuł
09/02/2016

Data opublikowania: sierpień 2016

Dotyczy: Windows Vista, Windows Server 2008, Windows 7, Windows 8.1, Windows Server 2008 R2, Windows Server 2012 R2, Windows Server 2012, Windows 8

W tym temacie dla specjalistów IT znajduje się opis dostawcy obsługi zabezpieczeń (SSP) Schannel (Secure Channel) oraz usług uwierzytelniania udostępnianych przez tego dostawcę przy użyciu protokołów TLS (Transport Layer Security) i SSL (Secure Sockets Layer).

Ten temat zawiera następujące sekcje:

Co to są protokoły TLS i SSL oraz Schannel?
Typowe scenariusze użycia protokołów TLS i SSL
Schannel SSP Technical Overview
Zależności w protokołach TLS i SSL

Uwaga

Protokół TLS jest opisany w temacie Transport Layer Security protokołu.

Protokół DTLS obsługiwany przez dostawcę SSP Schannel jest opisany w temacie Protokół datagramów Transport Layer Security.

Co to są protokoły TLS i SSL oraz Schannel?

Jednym z problemów, jakie występują podczas administrowania siecią, jest zabezpieczenie danych wysyłanych między aplikacjami za pośrednictwem niezaufanej sieci. Można w tym celu użyć protokołów TLS/SSL, aby uwierzytelnić serwery i komputery klienckie, a następnie szyfrować komunikaty wysyłane między uwierzytelnionymi stronami.

Protokoły TLS, SSL, DTLS i PCT (Private Communications Transport) są oparte na szyfrowaniu kluczem publicznym. Pakiet protokołów uwierzytelniania Schannel udostępnia te protokoły. Wszystkie protokoły w pakiecie Schannel używają modelu klient-serwer. Listę obsługiwanych protokołów zawiera temat Mechanizmy szyfrowania i protokoły obsługiwane przez dostawcę obsługi zabezpieczeń Schannel.

Podczas procesu uwierzytelniania komputer kliencki używający protokołu TLS/SSL wysyła wiadomość do serwera obsługującego protokół TLS/SSL, a serwer w odpowiedzi przesyła odpowiednie informacje uwierzytelniające. Klient i serwer dodatkowo wymieniają się kluczami sesji, po czym dialog uwierzytelniania kończy się. Komunikacja z użyciem protokołu SSL między serwerem a klientem może rozpocząć się po zakończeniu uwierzytelniania. Jest ona realizowana przy użyciu kluczy szyfrowania symetrycznego, które są ustalane w procesie uwierzytelniania.

W przypadku użycia protokołu TLS/SSL i uwierzytelniania serwerów względem klientów nie trzeba przechowywać kluczy w kontrolerach domen ani w bazie danych, na przykład w usługach domenowych Active Directory. Klient potwierdza poprawność poświadczeń serwera przy użyciu certyfikatów zaufanych głównych urzędów certyfikacji (CA), które są ładowane podczas instalowania systemu operacyjnego Windows Server. Dlatego też, jeśli serwer nie wymaga uwierzytelniania użytkowników, użytkownicy nie muszą zakładać kont przed utworzeniem bezpiecznego połączenia z serwerem.

Historia i standardy protokołów TLS i SSL

Protokół SSL został opracowany przez firmę Netscape Communications Corporation w 1994 r. w celu zabezpieczenia transakcji realizowanych za pośrednictwem sieci World Wide Web. Niedługo potem organizacja Internet Engineering Task Force (IETF) rozpoczęła pracę nad standardem protokołu, który miał realizować te same funkcje. Jako podstawę do pracy zastosowano protokół SSL 3.0, który ewoluował w protokół TLS. Implementacja protokołu TLS, począwszy od systemu Windows Server 2003, jest ściśle zgodna ze specyfikacją zdefiniowaną w następujących dokumentach wymienionych w bazie danych dokumentów RFC organizacji IETF:

Protokoły TLS i SSL są powszechnie uznawane za protokoły umożliwiające nawiązywanie bezpiecznych połączeń HTTP (HTTPS) na potrzeby transakcji internetowych między przeglądarkami i serwerami sieci Web. Protokoły TLS i SSL mogą być również używane przez inne protokoły poziomu aplikacji, na przykład FTP (File Transfer Protocol), LDAP (Lightweight Directory Access Protocol) i SMTP (Simple Mail Transfer Protocol). Protokoły TLS i SSL umożliwiają uwierzytelnianie serwerów, uwierzytelnianie klientów i szyfrowanie danych oraz zapewniają integralność danych w sieciach takich jak sieć World Wide Web.

Różnice między protokołami TLS i SSL

Mimo niewielkich różnic między protokołem SSL 3.0 i różnymi wersjami protokołu TLS w niniejszym przewodniku stosowany jest wspólny termin — TLS/SSL.

Uwaga

Protokoły TLS i SSL 3.0 nie są wymienne, choć różnice między nimi są niewielkie. Jeśli klient i serwer nie obsługują tego samego protokołu, muszą uzgodnić wspólny protokół w celu pomyślnego nawiązania komunikacji.

Ponieważ protokół SSL kilkukrotnie okazał się podatny na ataki, organizacja IETF opracowała standardy internetowe na potrzeby bardziej bezpiecznego protokołu — TLS. Poniżej wymieniono usprawnienia wprowadzone w protokole TLS względem oferowanej przez protokół SSL możliwości bezpiecznej komunikacji za pośrednictwem niezaufanych sieci.

Algorytm MAC (Message Authentication Code) używany w protokole SSL został zastąpiony algorytmem HMAC (keyed-Hash Message Authentication Code).
Protokół TLS jest standardowym protokołem internetowym, zaś protokół SSL ma wiele wersji.
Protokół TLS oferuje dodatkowe komunikaty alertów.
Protokół SSL wymaga certyfikatów wystawionych przez główny urząd certyfikacji lub znajdujących się w łańcuchu zależności od głównego urzędu certyfikacji. Jeśli używany jest protokół TLS, nie zawsze konieczne jest stosowanie certyfikatów znajdujących się w łańcuchu zależności od głównego urzędu certyfikacji. Można zamiast niego użyć urzędu pośredniczącego.
Algorytmy Fortezza nie są zawarte w dokumentach RFC dotyczących protokołu TLS, ponieważ nie są dostępne do publicznego przeglądu.

Zalety protokołów TLS i SSL

Protokoły TLS/SSL mają wiele zalet, których brak w przypadku innych metod uwierzytelniania klientów i serwerów. W poniższej tabeli opisano niektóre z tych zalet:

Zaleta	Opis
Silne uwierzytelnianie, poufność komunikatów i integralność	Protokoły TLS/SSL pozwalają zabezpieczyć przesyłane dane przy użyciu szyfrowania. Protokoły TLS/SSL umożliwiają uwierzytelnienie serwerów, a także opcjonalnie klientów — pozwala to udowodnić tożsamość systemów uczestniczących w bezpiecznej komunikacji. Gwarantuje to również integralność danych poprzez zastosowanie wartości sprawdzania integralności. Oprócz ochrony przed ujawnieniem danych protokoły zabezpieczeń TLS/SSL mogą być również używane do ochrony przed atakami opartymi na maskowaniu, atakami „man in the middle”, atakami „bucket brigade”, a także atakami opartymi na wycofywaniu i powtarzaniu.
Współdziałanie	Protokoły TLS/SSL działają w większości przeglądarek internetowych, a także na większości systemów operacyjnych i serwerów sieci Web. Są często stosowane w programach do czytania grup dyskusyjnych, na serwerach LDAP, a także w wielu innych aplikacjach dostępnych na rynku.
Elastyczność algorytmów	Protokoły TLS/SSL oferują różne opcje w zakresie mechanizmów uwierzytelniania, algorytmów szyfrowania i algorytmów wyznaczania wartości skrótu, których można używać podczas nawiązywania bezpiecznej sesji.
Łatwość wdrażania	Wiele aplikacji w systemach operacyjnych Windows Server używa protokołów TLS/SSL w niewidoczny dla użytkownika sposób. Protokołu TLS można używać, aby bezpieczniej przeglądać witryny z użyciem programu Internet Explorer i usług Internet Information Services (IIS). Jeśli serwer ma już zainstalowany certyfikat serwera, wystarczy zaznaczyć pole wyboru w programie Internet Explorer.
Łatwość użycia	Ponieważ protokoły TLS/SSL są implementowane poniżej warstwy aplikacji, większość operacji jest całkowicie niewidoczna dla komputera klienckiego. Pozwala to chronić klientów przed atakami, nawet jeśli nie korzystają z żadnych zabezpieczeń komunikacji.

Ograniczenia protokołów TLS i SSL

Istnieje kilka ograniczeń dotyczących używania protokołów TLS/SSL. Zostały one wymienione w poniższej tabeli.

Ograniczenie	Opis
Zwiększone obciążenie procesora	Jest to największe ograniczenie związane z implementacją protokołów TLS/SSL. Szyfrowanie, a szczególnie operacje związane z użyciem klucza publicznego, intensywnie korzystają z procesora. Z tego powodu w przypadku użycia protokołu SSL mogą wystąpić problemy dotyczące wydajności. Niestety nie ma sposobu na określenie stopnia utraty wydajności. Wydajność może być różna w zależności od tego, jak często nawiązywane są połączenia i jak długo trwają. Protokół TLS używa najwięcej zasobów podczas nawiązywania połączeń.
Koszty administracyjne	Środowisko protokołów TLS/SSL jest złożone i wymaga obsługi oraz konserwacji. Administrator systemu musi skonfigurować system i zarządzać certyfikatami.

Zwiększone obciążenie procesora

Jest to największe ograniczenie związane z implementacją protokołów TLS/SSL. Szyfrowanie, a szczególnie operacje związane z użyciem klucza publicznego, intensywnie korzystają z procesora. Z tego powodu w przypadku użycia protokołu SSL mogą wystąpić problemy dotyczące wydajności. Niestety nie ma sposobu na określenie stopnia utraty wydajności. Wydajność może być różna w zależności od tego, jak często nawiązywane są połączenia i jak długo trwają. Protokół TLS używa najwięcej zasobów podczas nawiązywania połączeń.

Koszty administracyjne

Środowisko protokołów TLS/SSL jest złożone i wymaga obsługi oraz konserwacji. Administrator systemu musi skonfigurować system i zarządzać certyfikatami.

Typowe scenariusze użycia protokołów TLS i SSL

Wiele osób postrzega protokoły TLS i SSL jako protokoły, które są używane w przeglądarkach w celu bezpiecznego przeglądania Internetu. Są to jednak protokoły ogólnego przeznaczenia, których można używać w każdej sytuacji, w której wymagane są uwierzytelnianie i ochrona danych. Możliwość dostępu do tych protokołów za pośrednictwem interfejsu dostawcy usług zabezpieczeń (SSPI) oznacza, że można używać ich na potrzeby prawie każdej aplikacji. Wiele aplikacji jest obecnie modyfikowanych tak, aby wykorzystywały funkcje udostępniane przez protokoły TLS/SSL. W poniższej tabeli przedstawiono przykłady użycia protokołów TLS/SSL.

Scenariusz	Opis
Transakcje SSL z witryną internetową handlu elektronicznego	Ta sytuacja reprezentuje typowy sposób użycia protokołu SSL podczas komunikacji między przeglądarką a serwerem sieci Web. Przykładem może być witryna handlu elektronicznego, w której klienci muszą podawać numery kart kredytowych. Protokół najpierw sprawdza, czy certyfikat witryny internetowej jest ważny, a następnie wysyła informacje o karcie kredytowej jako tekst zaszyfrowany. W przypadku tego typu transakcji, jeśli certyfikat serwera pochodzi z zaufanego źródła, uwierzytelniany jest tylko serwer. W witrynie internetowej, w której realizowane są transakcje (na przykład w formularzu zamówienia), musi być włączony protokół TLS/SSL.
Dostęp uwierzytelnionego klienta do witryny internetowej zabezpieczonej z użyciem protokołu SSL	Klient i serwer wymagają certyfikatów pochodzących od wzajemnie zaufanego urzędu certyfikacji (CA). Dostawca SSP Schannel pozwala, aby certyfikaty klientów były mapowane na konta użytkowników lub komputerów w systemie operacyjnym Windows Server. Mapowanie może być w relacji jeden-do-jednego lub wiele-do-jednego. Można następnie zarządzać nimi przy użyciu przystawki Użytkownicy i komputery usługi Active Directory, a użytkownicy mogą uwierzytelniać się w witrynie internetowej bez konieczności podawania hasła. Mapowanie w relacji wiele-do-jednego ma kilka zastosowań. Jeśli na przykład wielu użytkowników ma otrzymać dostęp do poufnych materiałów, można utworzyć grupę, zamapować certyfikaty użytkowników na grupę i nadać grupie odpowiednie uprawnienia do materiałów. W przypadku relacji jeden-do-jednego serwer ma kopię certyfikatu klienta, a kiedy użytkownik zaloguje się z komputera klienckiego, serwer sprawdza, czy są one identyczne. Takie mapowanie jeden-do-jednego jest zazwyczaj używane w przypadku materiałów prywatnych — na przykład w witrynie internetowej banku, gdzie tylko jedna osoba ma prawo dostępu do konta osobistego.
Dostęp zdalny	Popularnym sposobem użycia dostawcy SSP Schannel jest praca zdalna. Tej technologi można użyć, aby zapewnić uwierzytelnianie i ochronę danych podczas zdalnego logowania się do systemów lub sieci opartych na systemie Windows. Użytkownicy mogą w bardziej bezpieczny sposób uzyskiwać dostęp do poczty e-mail lub aplikacji przedsiębiorstwa z domu lub podczas podróży, co pozwala zmniejszyć ryzyko ujawnienia informacji innym osobom korzystającym z Internetu.
Dostęp do programu SQL Server	Podczas nawiązywania połączenia z serwerem, na którym działa program SQL Server, może być wymagane uwierzytelnienie komputera klienckiego. Można skonfigurować klienta lub serwer tak, aby wymagane było szyfrowania przesyłanych między nimi danych. Informacje bardzo poufne, na przykład finansowe lub medyczne bazy danych, można chronić tak, aby nie można było uzyskać nieautoryzowanego dostępu ani ujawnić informacji w sieci.
Poczta e-mail	Jeśli używany jest serwer Exchange, można używać dostawcy SSP Schannel, aby chronić dane przesyłane między serwerami w intranecie lub Internecie. Aby uzyskać pełne zabezpieczenie na całej trasie, może być wymagane użycie standardu S/MIME (Secure/Multipurpose Internet Mail Extensions). Jednak ochrona danych podczas ich wymiany między serwerami pozwala używać Internetu do bezpiecznego przesyłania poczty e-mail między oddziałami tej samej firmy, jak również podczas komunikacji z firmami zależnymi i partnerami. Można to robić niezależnie od tego, czy używany jest standard S/MIME.

Architektura dostawcy SSP Schannel

Pakiet protokołów uwierzytelniania Schannel w systemach operacyjnych Windows Server zawiera obsługę protokołu TLS. Na poniższym diagramie przedstawiono relacje między dostawcą SSP Schannel i innymi technologiami. Aplikacje klienckie lub aplikacje serwera wykorzystują bibliotekę Secur32.dll i wywołania interfejsu SSPI, aby komunikować się z usługą podsystemu lokalnego uwierzytelniania zabezpieczeń (LSASS).

Architektura dostawcy SSP Schannel

Schannel Architecture

W poniższej tabeli wymieniono opisy elementów uczestniczących w obsłudze protokołów TLS/SSL.

Elementy podsystemu zabezpieczeń używane podczas uwierzytelniania z użyciem protokołu TLS i SSL

Element	Opis
Schannel.dll	Protokół uwierzytelniania TLS/SSL. Ten protokół umożliwia uwierzytelnianie za pośrednictwem kanału szyfrowanego zamiast mniej bezpiecznego kanału nieszyfrowanego.
Lsasrv.dll	Usługa LSASS wymusza zasady zabezpieczeń i pełni rolę menedżera pakietów zabezpieczeń dla urzędu zabezpieczeń lokalnych.
Netlogon.dll	W odniesieniu do usług protokołu TLS usługa Netlogon przekazuje informacje o certyfikacie użytkownika za pośrednictwem kanału SSL do kontrolera domeny w celu zmapowania certyfikatu użytkownika na konto użytkownika.
Secur32.dll	Dostawca wielu mechanizmów uwierzytelniania, który implementuje interfejs SSPI.

Pakiet protokołów uwierzytelniania jest udostępniany przez dostawcę SSP Schannel, który jest obsługiwany za pośrednictwem interfejsu programowania aplikacji (API) SSPI udostępniającego usługi zabezpieczeń dla systemów operacyjnych Windows Server.

Interfejs dostawcy obsługi zabezpieczeń (SSPI) firmy Microsoft jest podstawą do uwierzytelniania w systemie operacyjnym Windows. Oznacza to, że aplikacje i usługi infrastruktury, które wymagają uwierzytelniania, używają do tego celu interfejsu SSPI. Jeśli wymagane jest uwierzytelnienie klienta i serwera, aby możliwa była bezpieczniejsza komunikacja, żądania uwierzytelniania są kierowane do interfejsu SSPI, który realizuje proces uwierzytelniania niezależnie od aktualnie używanego protokołu sieciowego. Interfejs SSPI jest implementacją ogólnego interfejsu API usług zabezpieczeń (GSSAPI). Więcej informacji na temat interfejsu GSSAPI zawierają poniższe dokumenty RFC w bazie danych dokumentów RFC organizacji IETF.

Informacje o architekturze interfejsu SSPI dla wszystkich dostawców SSP, a także informacje o roli dostawcy uwierzytelniania Kerberos w tej architekturze zawiera temat Security Support Provider Interface Architecture.

Dostawcy SSP Schannel można używać, aby uzyskiwać dostęp do usług sieci Web, na przykład poczty e-mail lub informacji osobowych publikowanych w witrynach internetowych. Dostawca SSP Schannel używa certyfikatów kluczy publicznych do uwierzytelniania stron. Pakiet zawiera cztery protokoły uwierzytelniania. Podczas uwierzytelniania stron wybierany jest jeden z tych czterech protokołów (w podanej poniżej kolejności preferencji):

TLS, wersja 1.2
TLS, wersja 1.1
TLS, wersja 1.0
SSL, wersja 3.0

Dostawca SSP Schannel następnie wybiera najlepszy możliwy protokół uwierzytelniania obsługiwany przez klienta i serwer. Jeśli na przykład serwer obsługuje wszystkie cztery protokoły dostawcy Schannel, a komputer kliencki tylko protokół SSL 3.0, dostawca Schannel użyje do uwierzytelniania protokołu SSL 3.0.

Zarządzanie zaufanymi wystawcami na potrzeby uwierzytelniania klientów

W systemach wcześniejszych niż Windows Server 2012 i Windows 8 aplikacje lub procesy, które używały dostawcy SSP Schannel (w tym HTTP.sys i IIS), mogły udostępnić listę zaufanych wystawców obsługiwanych na potrzeby uwierzytelniania klientów. Te informacje były udostępniane za pośrednictwem listy zaufania certyfikatów (CTL).

Jeśli wymagane jest uwierzytelnienie komputera klienckiego przy użyciu protokołu SSL lub TLS, serwer można skonfigurować tak, aby wysyłał listę zaufanych wystawców certyfikatów. Ta lista zawiera zbiór wystawców certyfikatów, którym serwer ufa, a także podpowiada komputerowi klienckiemu, który certyfikat kliencki wybrać, jeśli dostępnych jest wiele certyfikatów. Dodatkowo łańcuch certyfikatów wysyłany przez komputer kliencki do serwera wymaga weryfikacji względem skonfigurowanej listy zaufanych wystawców.

W systemach Windows Server 2012 i Windows 8 wprowadzono następujące zmiany w podstawowym procesie uwierzytelniania:

Nie jest już możliwe zarządzanie listami zaufanych wystawców na podstawie listy zaufania certyfikatów (CTL).
Wysyłanie listy zaufanych wystawców jest domyślnie wyłączone. Domyślną wartością klucza rejestru SendTrustedIssuerList jest teraz 0 (funkcja domyślnie wyłączona) zamiast 1.
Zachowana jest zgodność z wcześniejszymi wersjami systemów operacyjnych Windows.

Zarządzanie jest łatwiejsze dzięki użyciu istniejących poleceń cmdlet do zarządzania certyfikatami, które są dostępne w dostawcy programu Windows PowerShell, a także narzędzi wiersza polecenia takich jak certutil.exe. Chociaż maksymalna wielkość listy zaufanych urzędów certyfikacji obsługiwana przez dostawcę SSP Schannel (16 kB) jest taka sama jak w systemie Windows Server 2008 R2, w systemie Windows Server 2012 istnieje nowy dedykowany magazyn certyfikatów na potrzeby wystawców uwierzytelniania klientów, dzięki czemu niepowiązane certyfikaty nie są dołączane do komunikatów klient/serwer.

Jak to działa

Lista zaufanych wystawców jest konfigurowana przy użyciu magazynów certyfikatów: jednego domyślnego globalnego magazynu certyfikatów komputera i jednego opcjonalnego dla każdej witryny. Źródło listy jest określane w następujący sposób:

Jeśli dla witryny skonfigurowany jest konkretny magazyn poświadczeń, będzie on używany jako źródło.
Jeśli w magazynie określonym przez aplikację nie ma żadnych certyfikatów, dostawca Schannel sprawdza magazyn wystawców uwierzytelniania klienta na komputerze lokalnym. Jeśli są w nim certyfikaty, dostawca Schannel używa tego magazynu jako źródła.
Jeśli ani w globalnym, ani w lokalnym magazynie nie ma certyfikatów, dostawca SSP Schannel używa magazynu zaufanych głównych urzędów certyfikacji jako źródła listy zaufanych wystawców (tak samo działa system Windows Server 2008 R2).

Można utworzyć listę prawdopodobnych nazw wystawców certyfikatów, która będzie służyć jako podpowiedź dla użytkownika końcowego podczas wybierania wystawcy. Tę listę można konfigurować przy użyciu zasad grupy.

Jeśli magazyn zaufanych głównych urzędów certyfikacji zawiera mieszankę certyfikatów wystawców głównych (z podpisem własnym) i urzędów certyfikacji (CA), domyślnie na serwer wysyłane będą tylko certyfikaty wystawców urzędów certyfikacji.

Jak skonfigurować dostawcę Schannel, aby używał magazynu certyfikatów zaufanych wystawców

Dostawca SSP Schannel domyślnie używa do zarządzania listą zaufanych wystawców magazynów opisanych powyżej. Do zarządzania certyfikatami można nadal używać istniejących poleceń cmdlet do zarządzania certyfikatami w dostawcy programu Windows PowerShell, a także narzędzi wiersza polecenia takich jak certutil.exe.

Informacje o zarządzaniu certyfikatami przy użyciu dostawcy programu Windows PowerShell zawiera temat Polecenia cmdlet do administrowania usługami AD CS w systemie Windows.

Informacje o zarządzaniu certyfikatami za pomocą narzędzia do obsługi certyfikatów zawiera temat certutil.exe.

Informacje o tym, jakie dane są zdefiniowane dla poświadczenia dostawcy Schannel (między innymi informacje o magazynie zdefiniowanym przez aplikację) zawiera temat Struktura SCHANNEL_CRED (Windows).

Konfigurowanie aplikacji lub funkcji tak, aby używała magazynu wystawców uwierzytelniania klienta

Niektóre technologie nie używają domyślnie magazynu wystawców uwierzytelniania klienta. W takich sytuacjach należy skonfigurować technologię tak, aby używała tego magazynu.

Na przykład serwer sieci Web HTTP.sys, który implementuje stos serwera HTTP systemu Windows, nie jest domyślnie skonfigurowany tak, aby używać magazynu wystawców uwierzytelniania klienta.

Aby skonfigurować serwer HTTP.sys tak, aby używał magazynu wystawców uwierzytelniania klienta, można użyć następującego polecenia:

netsh http add sslcert ipport=0.0.0.0:443 certhash=GUID hash value appid={GUID application identifier}  sslctlstorename=ClientAuthIssuer

Aby znaleźć wartości parametrów certhash i appid na używanym serwerze, można użyć następującego polecenia:

netsh http show sslcert

Wartości domyślne dla trybów zaufania

Dostawca SSP Schannel obsługuje trzy tryby zaufania uwierzytelniania klienta. Tryb zaufania określa sposób weryfikacji łańcucha certyfikatów klienta. Jest to ustawienie obowiązujące w całym systemie i skonfigurowane w rejestrze, w wartości ClientAuthTrustMode typu REG_DWORD w kluczu HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel.

Wartość	Tryb zaufania	Opis
0	Zaufanie do komputera (tryb domyślny)	Wymagane jest, aby certyfikat klienta był wystawiony z użyciem certyfikatu z listy zaufanych wystawców.
1	Zaufanie wyłącznie do certyfikatu głównego	Wymagane jest, aby certyfikat klienta znajdował się w łańcuchu zależności od certyfikatu głównego, który jest zawarty w magazynie zaufanych wystawców określonym przez funkcję wywołującą. Certyfikat musi być również wystawiony na podstawie listy zaufanych wystawców.
2	Zaufanie wyłącznie do urzędu certyfikacji	Wymagane jest, aby certyfikat klienta znajdował się w łańcuchu zależności od certyfikatu pośredniego urzędu certyfikacji lub certyfikatu głównego, który znajduje się w magazynie zaufanych wystawców określonym przez funkcję wywołującą.

Informacje o niepowodzeniach uwierzytelniania spowodowanych problemami z konfiguracją listy zaufanych wystawców zawiera artykuł 280256 w Bazie wiedzy Microsoft Knowledge Base.

Zależności w protokołach TLS i SSL

Protokoły TLS i SSL są zależne od kilku pokrewnych technologii i zasobów, które są niezbędne do ich prawidłowego działania. W poniższej tabeli przedstawiono te technologie i zasoby oraz opisano, w jaki sposób są one powiązane z uwierzytelnianiem za pomocą protokołów TLS/SSL.

Zależność	Opis
System operacyjny	Uwierzytelnianie za pomocą protokołów TLS i SSL jest zależne od funkcji klienta, które są wbudowane w systemy operacyjne Windows Server oraz klienckie systemy operacyjne Windows. Jeśli klient lub serwer korzysta z systemu operacyjnego, który nie obsługuje protokołów TLS/SSL, nie można używać uwierzytelniania za pomocą protokołów TLS/SSL.
Połączenia sieciowe TCP/IP	Aby możliwe było uwierzytelnianie za pomocą protokołu TLS lub SSL, wymagane jest połączenie sieciowe między klientem i serwerem docelowym oparte na protokołach TCP/IP. Aby uzyskać więcej informacji, zobacz temat TCP/IP.
Domena Active Directory	Jeśli aplikacja serwera wymaga uwierzytelnienia klienta, dostawca SSP Schannel automatycznie próbuje zmapować certyfikat dostarczany przez klienta na konto użytkownika. Użytkowników logujących się przy użyciu certyfikatu klienta można uwierzytelniać, ręcznie tworząc mapowania, które wiążą informacje zawarte w certyfikacje z kontem użytkownika w systemie Windows. Jeśli po utworzeniu i włączeniu mapowania certyfikatu klient zaprezentuje certyfikat, aplikacja serwera automatycznie powiąże tego użytkownika z odpowiednim kontem użytkownika w systemie operacyjnym Windows. Aby używać mapowania certyfikatów, należy korzystać z kont użytkowników w usługach domenowych Active Directory. Aby uzyskać więcej informacji, zobacz temat Omówienie usług domenowych Active Directory.
Zaufane urzędy certyfikacji	Ponieważ uwierzytelnianie opiera się na certyfikatach cyfrowych, ważnym elementem obsługi protokołów TLS/SSL jest korzystanie z urzędów certyfikacji (takich jak Verisign lub Usługi certyfikatów Active Directory). Urząd certyfikacji jest wzajemnie zaufanym certyfikatem wystawionym przez firmę inną niż Microsoft, który potwierdza tożsamość podmiotu żądającego certyfikatu (zazwyczaj jest nim użytkownik lub komputer), a następnie jest używany do wygenerowania dla niego certyfikatu. Certyfikat wiąże tożsamość podmiotu żądającego z kluczem publicznym. Urzędy certyfikacji również odnawiają i odwołują certyfikaty w razie potrzeby. Jeśli na przykład dla klienta zostanie zaprezentowany certyfikat serwera, komputer kliencki może podjąć próbę dopasowania urzędu certyfikacji serwera do listy zaufanych urzędów certyfikacji klienta. Jeśli urząd wystawiający certyfikaty jest zaufany, klient sprawdzi, czy certyfikat jest autentyczny i nie został zmieniony przez niepowołane osoby. Więcej informacji o urzędach certyfikacji zawiera temat Usługi certyfikatów Active Directory — omówienie.

Zobacz też

Dokumentacja techniczna dostawcy obsługi zabezpieczeń Schannel

Udostępnij przez