Klient Tls nie widzi certyfikatu. TLS i SSL: Wymagana minimalna wiedza

Oprogramowanie Kontynent TLS VPN– system zapewniający bezpieczny zdalny dostęp do aplikacji internetowych wykorzystujący algorytmy szyfrowania GOST. Continent TLS VPN zapewnia kryptograficzną ochronę ruchu HTTP na poziomie sesji. Informacje są szyfrowane przy użyciu algorytmu GOST 28147–89.

Identyfikacja i uwierzytelnianie użytkowników zdalnych

Identyfikacja i uwierzytelnianie użytkowników odbywa się przy użyciu certyfikatów klucza publicznego standardu x.509v3 (GOST R 31.11–94, 34.10–2001). Continent TLS VPN sprawdza kluczowe certyfikaty względem list odwołanych certyfikatów (CRL). Certyfikaty wydawane są przez zewnętrzny urząd certyfikacji.

Jeżeli procedury uwierzytelnienia zakończą się pomyślnie, żądanie użytkownika zostaje przekierowane poprzez protokół HTTP do bezpiecznej sieci na odpowiedni serwer WWW. W takim przypadku do sesji HTTP każdego użytkownika dodawane są specjalne identyfikatory (identyfikator klienta i identyfikator IP).

Kryptograficzna ochrona przesyłanych informacji

Continent TLS VPN zapewnia kryptograficzną ochronę ruchu HTTP na poziomie sesji. Informacje są szyfrowane przy użyciu algorytmu GOST 28147–89. Funkcję skrótu oblicza się za pomocą algorytmu GOST R 34.11–94, GOST R 34.11–2012. Generowanie i weryfikacja podpisu elektronicznego odbywa się zgodnie z algorytmem GOST R 34.10–2001, GOST R 34.10–2012.

Ukrywanie chronionych serwerów i tłumaczenie adresów

Continent TLS VPN filtruje żądania i przesyła adresy żądań do serwerów internetowych w sieci firmowej. Tłumaczenie adresów odbywa się zgodnie z zasadami ustalonymi przez administratora „Continent TLS VPN”.

Tolerancja błędów i skalowalność

Continent TLS VPN obsługuje działanie w wysokowydajnej konstrukcji klastra z równoważeniem obciążenia (zewnętrzny moduł równoważenia obciążenia). Zwiększoną odporność na awarie osiąga się poprzez dodanie do klastra redundantnego węzła. Jednocześnie rozbudowa elementów klastra bilansującego może być prowadzona w sposób nieograniczony. Awaria elementu klastra nie powoduje zerwania połączeń, ponieważ obciążenie rozkłada się równomiernie na pozostałe elementy.

Monitorowanie i rejestrowanie zdarzeń

W Continent TLS VPN administrator zawsze może uzyskać informację operacyjną o aktualnym stanie nawiązanych połączeń oraz statystyki dotyczące jego działania. Zdarzenia związane z bezpieczeństwem informacji są rejestrowane na serwerze. Wszystkie zdarzenia mogą zostać przesłane na wskazany serwer w formacie syslog w celu dalszej analizy, co maksymalnie upraszcza integrację z systemami SIEM.

Wygodne narzędzia do zarządzania

Połączenie narzędzi lokalnych i zdalnych z interfejsem WWW oraz wygodną graficzną konsolą zarządzania zapewnia elastyczną konfigurację Continent TLS VPN zgodnie z wymogami polityk bezpieczeństwa.

Obsługiwane protokoły

Continent TLS VPN obsługuje protokoły TLS v.1, TLS v.2.

Doświadczenie użytkownika za pośrednictwem dowolnej przeglądarki internetowej

Korzystając z aplikacji klienta Continent TLS VPN, użytkownicy mogą uzyskać dostęp do chronionych zasobów z dowolnej przeglądarki internetowej. Klient Continent TLS VPN to lokalny serwer proxy, przechwytujący ruch przeglądarki do chronionych serwerów internetowych i pakuje go do tunelu http. Dzięki temu użytkownik może pracować z dowolną przeglądarką internetową zainstalowaną na swoim urządzeniu.

Korzystanie z przyjaznego dla użytkownika oprogramowania klienckiego

Korzystanie z przyjaznego dla użytkownika oprogramowania klienckiego Continent TLS VPN Client lub CryptoPro CSP w wersji 3.6.1 może być używane jako klient na urządzeniu użytkownika.

Ostatnio coraz częściej mówi się o TLS i SSL, coraz bardziej istotne staje się stosowanie certyfikatów cyfrowych, a nawet pojawiły się firmy, które są gotowe udostępnić każdemu bezpłatne certyfikaty cyfrowe, aby zapewnić szyfrowanie ruchu pomiędzy odwiedzanymi witrynami a przeglądarką klienta. Jest to oczywiście konieczne ze względów bezpieczeństwa, aby nikt w sieci nie mógł odebrać danych przesyłanych od klienta do serwera i z powrotem. Jak to wszystko działa i jak z tego korzystać? Aby to zrozumieć, być może musimy zacząć od teorii, a następnie pokazać to w praktyce. A więc SSL i TLS.

Co to jest SSL i czym jest TLS?

SSL - Secure Socket Layer, warstwa bezpiecznych gniazd. TLS - Transport Layer Security, bezpieczeństwo warstwy transportowej. SSL to wcześniejszy system, TLS pojawił się później i jest oparty na specyfikacji SSL 3.0 opracowanej przez Netscape Communications. Protokoły te mają jednak jedno zadanie – zapewnić bezpieczny transfer danych pomiędzy dwoma komputerami w Internecie. Ten transfer jest używany w przypadku różnych stron internetowych, poczty e-mail, wiadomości i wielu innych. W zasadzie można w ten sposób przekazać dowolną informację, o czym poniżej.

Bezpieczną transmisję zapewnia uwierzytelnianie i szyfrowanie przesyłanych informacji. Zasadniczo te protokoły, TLS i SSL, działają tak samo; nie ma zasadniczych różnic. Można powiedzieć, że TLS jest następcą SSL, chociaż można z nich korzystać jednocześnie, nawet na tym samym serwerze. Takie wsparcie jest niezbędne, aby zapewnić współpracę zarówno z nowymi klientami (urządzeniami i przeglądarkami), jak i starszymi, nie obsługującymi TLS. Kolejność występowania tych protokołów wygląda następująco:

SSL 1.0 - nigdy nie opublikowany
SSL 2.0 – luty 1995
SSL 3.0 – 1996
TLS 1.0 – styczeń 1999 r
TLS 1.1 – kwiecień 2006
TLS 1.2 – sierpień 2008

Jak działają SSL i TLS

Zasada działania SSL i TLS, jak powiedziałem, jest taka sama. Na protokole TCP/IP tworzony jest szyfrowany kanał, w ramach którego dane przesyłane są za pośrednictwem protokołu aplikacji - HTTP, FTP i tak dalej. Oto jak można to przedstawić graficznie:

Protokół aplikacji jest „owinięty” w protokół TLS/SSL, który z kolei jest opakowany w protokół TCP/IP. Zasadniczo dane protokołu aplikacji są przesyłane przez protokół TCP/IP, ale są szyfrowane. I tylko maszyna, która nawiązała połączenie, może odszyfrować przesyłane dane. Dla wszystkich innych osób odbierających przesyłane pakiety informacja ta będzie bez znaczenia, jeśli nie będzie w stanie jej odszyfrować.

Połączenie jest nawiązywane w kilku etapach:

1) Klient nawiązuje połączenie z serwerem i żąda bezpiecznego połączenia. Można to osiągnąć albo nawiązując połączenie z portem, który początkowo ma współpracować z SSL/TLS, np. 443, albo dodatkowo prosząc klienta o nawiązanie bezpiecznego połączenia po nawiązaniu zwykłego.

2) Klient nawiązując połączenie podaje listę algorytmów szyfrowania, które „zna”. Serwer sprawdza otrzymaną listę z listą algorytmów, które sam serwer „zna” i wybiera najbardziej niezawodny algorytm, po czym informuje klienta, jakiego algorytmu użyć

3) Serwer przesyła klientowi swój certyfikat cyfrowy podpisany przez urząd certyfikacji oraz klucz publiczny serwera.

4) Klient może skontaktować się z serwerem zaufanego urzędu certyfikacji, który podpisał certyfikat serwera i sprawdzić, czy certyfikat serwera jest ważny. Ale może nie. W systemie operacyjnym zazwyczaj są już zainstalowane certyfikaty główne urzędów certyfikacji, względem których weryfikowane są podpisy certyfikatów serwerów np. przez przeglądarki.

5) Generowany jest klucz sesji dla bezpiecznego połączenia. Odbywa się to w następujący sposób:
— Klient generuje losową sekwencję cyfrową
— Klient szyfruje go kluczem publicznym serwera i wysyła wynik do serwera
— Serwer odszyfrowuje otrzymaną sekwencję za pomocą klucza prywatnego
Biorąc pod uwagę, że algorytm szyfrowania jest asymetryczny, tylko serwer może odszyfrować sekwencję. W przypadku szyfrowania asymetrycznego stosowane są dwa klucze – prywatny i publiczny. Wiadomość wysłana publicznie jest szyfrowana, a wiadomość wysyłana prywatnie jest odszyfrowywana. Nie da się odszyfrować wiadomości, jeśli posiadasz klucz publiczny.

6) Spowoduje to nawiązanie szyfrowanego połączenia. Przesyłane za jego pośrednictwem dane są szyfrowane i deszyfrowane do momentu zakończenia połączenia.

Certyfikat główny

Tuż powyżej wspomniałem o certyfikacie głównym. Jest to certyfikat centrum autoryzacji, którego podpis potwierdza, że podpisywany certyfikat jest tym, który należy do odpowiedniej usługi. Sam certyfikat zazwyczaj zawiera szereg pól informacyjnych, w których znajdują się informacje o nazwie serwera, na który certyfikat został wystawiony oraz okresie ważności tego certyfikatu. Jeżeli ważność certyfikatu wygasła, zostaje ona unieważniona.

Prośba o podpis (CSR, prośba o podpisanie certyfikatu)

Aby uzyskać podpisany certyfikat serwera należy wygenerować żądanie podpisu (CSR, Certyfikat Sign Request) i wysłać to żądanie do centrum autoryzacyjnego, które zwróci podpisany certyfikat zainstalowany bezpośrednio na serwerze. Poniżej zobaczymy jak to zrobić w praktyce. W pierwszej kolejności generowany jest klucz szyfrujący, następnie na podstawie tego klucza generowana jest prośba o podpis, czyli plik CSR.

Certyfikat klienta

Certyfikat klienta można wygenerować zarówno do użytku urządzenia, jak i użytkownika. Zazwyczaj takie certyfikaty są używane w weryfikacji dwukierunkowej, gdzie klient weryfikuje, czy serwer jest tym, za kogo się podaje, a serwer robi to samo w zamian. Ta interakcja nazywana jest uwierzytelnianiem dwukierunkowym lub uwierzytelnianiem wzajemnym. Uwierzytelnianie dwukierunkowe podnosi poziom bezpieczeństwa w porównaniu do uwierzytelniania jednokierunkowego, a także może zastąpić uwierzytelnianie za pomocą loginu i hasła.

Łańcuch działań generowania certyfikatów

Przyjrzyjmy się jak od samego początku przebiegają czynności związane z generowaniem certyfikatów oraz w praktyce.

Pierwszą rzeczą do zrobienia jest wygenerowanie certyfikatu głównego. Certyfikat główny jest z podpisem własnym. A potem tym certyfikatem będą podpisane inne certyfikaty.

$ openssl genrsa -out root.key 2048 Generowanie klucza prywatnego RSA, moduł o długości 2048 bitów ......+++ ...... ............... ...........+++ e to 65537 (0x10001) $ openssl req -new -key root.key -out root.csr Zostaniesz poproszony o wprowadzenie informacji, które zostaną uwzględnione w Twoim żądaniu certyfikatu . To, co zamierzasz wprowadzić, to tak zwana nazwa wyróżniająca lub nazwa wyróżniająca. Jest sporo pól, ale możesz zostawić niektóre puste. W przypadku niektórych pól będzie to wartość domyślna. Jeśli wpiszesz „.”, pole pozostanie puste. ----- Nazwa kraju (2-literowy kod):RU Nazwa stanu lub prowincji (pełna nazwa):nie dotyczy Nazwa miejscowości (np. miasto):Sankt-Petersburg Nazwa organizacji (np. firma) :Nazwa jednostki organizacyjnej mojej firmy (np. sekcja): Nazwa zwyczajowa usługi IT (np. nazwa FQDN serwera lub TWOJA nazwa): Adres e-mail certyfikatu głównego mojej firmy: [e-mail chroniony] Wprowadź następujące „dodatkowe” atrybuty, które mają zostać przesłane wraz z żądaniem certyfikatu. Hasło wezwania: Opcjonalna nazwa firmy: Moja firma $ openssl x509 -req -days 3650 -in root.csr -signkey root.key -out root.pem Podpis ok topic=/C=RU/ST=N/A/L=Sankt-Petersburg/O=Moja firma/OU=Usługa IT/CN=Certyfikat główny mojej firmy/ [e-mail chroniony] Pobieranie klucza prywatnego

Tym samym najpierw wygenerowaliśmy klucz prywatny, potem prośbę o podpis, a następnie podpisaliśmy własnym kluczem własne żądanie i otrzymaliśmy własny certyfikat cyfrowy, wydawany na 10 lat. Podczas generowania certyfikatu nie musisz wprowadzać hasła wezwania.

Klucz prywatny MUSI być przechowywany w bezpiecznym miejscu, mając go możesz podpisać w swoim imieniu dowolny certyfikat. Powstały certyfikat główny można wykorzystać do sprawdzenia, czy certyfikat na przykład serwera został podpisany przez nas, a nie przez kogoś innego. Są to działania, jakie wykonują centra autoryzacyjne podczas generowania własnych certyfikatów. Po utworzeniu certyfikatu głównego możesz rozpocząć generowanie certyfikatu serwera.

Wyświetl informacje o certyfikacie

Treść certyfikatu można przeglądać w następujący sposób:

$ openssl x509 -noout -issuer -enddate -in root.pem wystawca= /C=RU/ST=N/A/L=Sankt-Petersburg/O=Moja firma/OU=Usługa IT/CN=Certyfikat główny mojej firmy/ [e-mail chroniony] notAfter=22 stycznia 11:49:41 2025 GMT

Widzimy, kto wystawił ten certyfikat i kiedy upływa jego data ważności.

Certyfikat serwera

Aby podpisać certyfikat dla serwera musimy wykonać następujące czynności:

1) Wygeneruj klucz
2) Wygeneruj prośbę o podpis
3) Wyślij plik CSR do centrum autoryzacyjnego lub podpisz go samodzielnie

Certyfikat serwera może obejmować łańcuch certyfikatów podpisujących certyfikat serwera, ale może być również przechowywany w oddzielnym pliku. W zasadzie wszystko wygląda mniej więcej tak samo, jak przy generowaniu certyfikatu głównego

$ openssl genrsa -out serwer.key 2048 Generowanie klucza prywatnego RSA, moduł o długości 2048 bitów ..................... ................................................. . +++........................+++ e to 65537 (0x10001) $ openssl req -new -key serwer.klucz - serwer wyjściowy .csr Zaraz zostaniesz poproszony o podanie informacji, które zostaną uwzględnione w Twoim żądaniu certyfikatu. To, co zamierzasz wprowadzić, to tak zwana nazwa wyróżniająca lub nazwa wyróżniająca. Jest sporo pól, ale możesz zostawić niektóre puste. W przypadku niektórych pól będzie to wartość domyślna. Jeśli wpiszesz „.”, pole pozostanie puste. ----- Nazwa kraju (2-literowy kod):RU Nazwa stanu lub prowincji (pełna nazwa):nie dotyczy Nazwa miejscowości (np. miasto):Sankt-Petersburg Nazwa organizacji (np. firma) :Nazwa jednostki organizacyjnej mojej firmy (np. sekcja): Nazwa zwyczajowa usługi IT (np. nazwa FQDN serwera lub TWOJA nazwa): www.mycompany.com Adres e-mail: [e-mail chroniony] Wprowadź następujące „dodatkowe” atrybuty, które mają zostać przesłane wraz z żądaniem certyfikatu. Hasło wezwania: Opcjonalna nazwa firmy: $ openssl x509 -req -in serwer.csr -CA root.pem -CAkey root.key -CAcreateserial -out serwer. pem -days 365 Podpis ok topic=/C=RU/ST=N/A/L=Saint-Petersburg/O=Moja firma/OU=IT Service/CN=www.mycompany.com/ [e-mail chroniony] Uzyskiwanie klucza prywatnego urzędu certyfikacji $ openssl x509 -noout -issuer -subject -enddate -in serwer.pem Issuer= /C=RU/ST=N/A/L=Sankt-Petersburg/O=Moja firma/OU=Usługa IT/CN =Certyfikat główny mojej firmy/ [e-mail chroniony] temat= /C=RU/ST=N/A/L=Sankt-Petersburg/O=Moja firma/OU=Usługa IT/CN=www.mojafirma.com/emailAd [e-mail chroniony] notAfter=25 stycznia 12:22:32 2016 GMT

W ten sposób certyfikat serwera zostanie podpisany i będziemy wiedzieć, która organizacja wystawiła ten certyfikat. Gotowy certyfikat po podpisaniu można wykorzystać zgodnie z jego przeznaczeniem, np. zainstalować na serwerze WWW.

Instalowanie certyfikatu SSL/TLS na serwerze z nginx

Aby zainstalować certyfikat SSL/TLS na serwerze WWW nginx, musisz wykonać kilka prostych kroków:

1) Skopiuj pliki .key i .pem na serwer. W różnych systemach operacyjnych certyfikaty i klucze mogą być przechowywane w różnych katalogach. Na przykład w Debianie jest to katalog /etc/ssl/certs dla certyfikatów i /etc/ssl/private dla kluczy. W CentOS jest to /etc/pki/tls/certs i /etc/pki/tls/private

2) Zapisz niezbędne ustawienia w pliku konfiguracyjnym hosta. Tak to mniej więcej powinno wyglądać (tylko przykład):

Serwer (słuchaj 443; nazwa_serwera www.mojafirma.com; root html; indeks indeks.html indeks.htm; ssl on; certyfikat_ssl serwer.pem; klucz_certyfikatu ssl serwer.key; limit czasu_ssl_session 5m; # SSLv3 nie jest zalecane!!! # Jest tutaj na przykład tylko ssl_protocols SSLv3 TLSv1; ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv3:+EXP; ssl_prefer_server_ciphers on; lokalizacja / ( try_files $uri $uri/ =404; ) )

3) Uruchom ponownie Nginx

4) Wejdź za pomocą przeglądarki na port serwera 443 - https://www.mycompany.com i sprawdź jego funkcjonalność.

Instalowanie certyfikatu SSL/TLS na serwerze z uruchomionym Apache

Instalacja certyfikatu SSL/TLS na Apache wygląda podobnie.

1) Skopiuj pliki klucza i certyfikatu na serwer do odpowiednich katalogów

2) Włącz moduł ssl dla Apache za pomocą polecenia „a2enmod ssl”, jeśli nie jest jeszcze włączony

3) Utwórz hosta wirtualnego, który będzie nasłuchiwał portu 443. Konfiguracja będzie wyglądać mniej więcej tak:

Administrator serwera [e-mail chroniony] Katalog główny dokumentu /var/www Opcje FollowSymLinks ZezwólOverride Brak Opcje Indeksy FollowSymLinks MultiViews ZezwólOverride Brak Kolejność zezwalaj, odmawiaj zezwalania wszystkim Alias skryptu /cgi-bin/ /usr/lib/cgi-bin/ Zezwalaj na brak opcji +ExecCGI -MultiViews +SymLinksIfOwnerMatch Kolejność zezwalaj, odmawiaj Zezwól wszystkim ErrorLog $(APACHE_LOG_DIR)/error.log LogLevel warn CustomLog $(APACHE_LOG_DIR)/ssl_access.log połączone SSLEngine na SSLCertificateFile /etc/ssl/certs/server.pem SSLCertificateKeyFile /etc/ssl/private/server.key # Ta dyrektywa dodaje plik zawierający listę # wszystkich certyfikatów, które podpisały certyfikat serwera #SSLCertificateChainFile /etc/apache2/ssl.crt/server-ca.crt Opcje SSLOpcje + StdEnvVars Opcje SSLOpcje + StdEnvVars BrowserMatch "MSIE" \ nokeepalive ssl-unclean-shutdown \ downgrade-1.0 force-response-1.0 BrowserMatch "MSIE " ssl-unclean-shutdown

Jednocześnie jest jeszcze coś do zrobienia. Znajdź w pliku httpd.conf, Apache2.conf lub ports.conf, w zależności od systemu, następującą sekcję konfiguracji:

Posłuchaj 443

Jeśli nie ma takiego warunku należy go dodać do config. I jeszcze jedno: musisz dodać linię

NazwaWirtualny Host *:443

Ta linia może znajdować się w pliku httpd.conf, Apache2.conf lub ports.conf

4) Uruchom ponownie serwer WWW Apache

Tworzenie certyfikatu klienta

Certyfikat klienta jest tworzony w podobny sposób jak certyfikat serwera.

$ openssl genrsa -out klient.key 2048 Generowanie klucza prywatnego RSA, moduł o długości 2048 bitów ..............+++ ..... .............................+++ e to 65537 (0x10001) $ openssl req -new -key klient.klucz -out klient.csr Zostaniesz poproszony o wprowadzenie informacji, które zostaną uwzględnione w Twoim żądaniu certyfikatu. To, co zamierzasz wprowadzić, to tak zwana nazwa wyróżniająca lub nazwa wyróżniająca. Jest sporo pól, ale możesz zostawić niektóre puste. W przypadku niektórych pól będzie to wartość domyślna. Jeśli wpiszesz „.”, pole pozostanie puste. ----- Nazwa kraju (2-literowy kod):RU Nazwa stanu lub prowincji (pełna nazwa):Saint-Petersburg Nazwa miejscowości (np. miasto):^C mnorin@mnorin-work:~/Temp/certs/CA$ openssl req -new -key klient.klucz -out klient.csr Zostaniesz poproszony o wprowadzenie informacji, które zostaną uwzględnione w Twoim żądaniu certyfikatu. To, co zamierzasz wprowadzić, to tak zwana nazwa wyróżniająca lub nazwa wyróżniająca. Jest sporo pól, ale możesz zostawić niektóre puste. W przypadku niektórych pól będzie to wartość domyślna. Jeśli wpiszesz „.”, pole pozostanie puste. ----- Nazwa kraju (2-literowy kod):RU Nazwa stanu lub prowincji (pełna nazwa):nie dotyczy Nazwa miejscowości (np. miasto):Saint-Petrersburg Nazwa organizacji (np. firma):Nazwa jednostki organizacyjnej mojej firmy (np. sekcja):Engineering Nazwa zwyczajowa (np. nazwa FQDN serwera lub TWOJA nazwa):Ivan Ivanov Adres e-mail: [e-mail chroniony] Wprowadź następujące „dodatkowe” atrybuty, które mają zostać przesłane wraz z żądaniem certyfikatu. Hasło wezwania: Opcjonalna nazwa firmy: $ openssl x509 -req -in klient.csr -CA root.pem -CAkey root.key -CAcreateserial -out klient. pem -days 365 Podpis ok temat=/C=RU/ST=N/A/L=Sankt-Petrersburg/O=Moja firma/OU=Inżynieria/CN=Iwan Iwanow/ [e-mail chroniony] Uzyskiwanie klucza prywatnego urzędu certyfikacji $ openssl x509 -noout -issuer -subject -enddate -in klient.pem wystawca= /C=RU/ST=N/A/L=Sankt-Petersburg/O=Moja firma/OU=Usługa IT/CN =Certyfikat główny mojej firmy/ [e-mail chroniony] topic= /C=RU/ST=N/A/L=Sankt-Petrersburg/O=Moja firma/OU=Inżynieria/CN=Iwan Iwanow/e-mail [e-mail chroniony] notAfter=25 stycznia 13:17:15 2016 GMT

Jeżeli potrzebujesz certyfikatu klienta w formacie PKCS12 utwórz go:

$ openssl pkcs12 -export -in klient.pem -inkey klient.klucz -certfile root.pem -out iivanov.p12 Wprowadź hasło eksportu: Weryfikacja - wprowadź hasło eksportu:

Teraz możesz używać certyfikatu klienta do pracy z naszym serwerem.

Konfigurowanie nginx do korzystania z certyfikatów klienta

Najczęściej, jak już mówiłem, stosuje się uwierzytelnianie jednokierunkowe, zwykle sprawdzany jest tylko certyfikat serwera. Zobaczmy, jak zmusić serwer WWW Nginx do weryfikacji certyfikatu klienta. Aby pracować z certyfikatami klienta, konieczne jest dodanie opcji do sekcji serwera:

# Certyfikaty główne, którymi podpisany jest klient. ssl_client_certificate /etc/nginx/certs/clientroot.pem; # Możliwe opcje: na | wyłączone | opcjonalne | opcjonalny_no_ca ssl_verify_client opcjonalny; # Głębokość weryfikacji łańcucha certyfikatów, którymi podpisany jest klient ssl_verify_ głębokość 2;

Następnie należy ponownie uruchomić ustawienia lub cały serwer i sprawdzić działanie.

Konfigurowanie Apache do korzystania z certyfikatów klienta

Apache można również skonfigurować, dodając dodatkowe opcje w sekcji hosta wirtualnego:

# Katalog zawierający certyfikaty główne do weryfikacji klienta SSLCARevocationPath /etc/apache2/ssl.crl/ # lub plik zawierający certyfikaty SSLCARevocationFile /etc/apache2/ssl.crl/ca-bundle.crl # Opcja weryfikacji klienta. Możliwe opcje: # brak, opcjonalne, wymagają i opcjonalne_no_ca SSLVerifyClient require # Wyświetl głębokość łańcucha podpisów. Domyślnie 1 SSLVerifyDepth 2

Jak widać, opcje są w przybliżeniu takie same jak w przypadku nginx, ponieważ proces weryfikacji jest zorganizowany jednolicie.

Słuchanie informacji o certyfikacie za pomocą openssl

Aby przetestować interakcję serwera z certyfikatami klienta, możesz sprawdzić, czy połączenie jest nawiązywane przy użyciu protokołu TLS/SSL.

Po stronie serwera zaczynamy nasłuchiwać na porcie za pomocą openssl:

Openssl s_server -accept 443 -cert serwer.pem -key serwer.klucz -stan

Po stronie klienta uzyskujemy dostęp do serwera na przykład za pomocą culr:

Zwiń -k https://127.0.0.1:443

W konsoli po stronie serwera możesz obserwować proces wymiany informacji pomiędzy serwerem a klientem.

Możesz także użyć opcji -verify [głębokość weryfikacji] i -Verify [głębokość weryfikacji]. Opcja small-case prosi klienta o certyfikat, ale jego dostarczenie nie jest wymagane. Pisane wielką literą — jeśli certyfikat nie zostanie podany, wystąpi błąd. Zacznijmy nasłuchiwać po stronie serwera w ten sposób:

Openssl s_server -accept 443 -cert serwer.pem -key serwer.klucz -stan -Sprawdź 3

Od strony serwera błąd wygląda następująco:

140203927217808:błąd:140890C7:Procedury SSL:SSL3_GET_CLIENT_CERTIFICATE:peer nie zwrócił certyfikatu:s3_srvr.c:3287:

Od strony klienta tak:

Curl: (35) błąd:14094410:Procedury SSL:SSL3_READ_BYTES:Błąd uzgadniania alertu sslv3

Dodajmy certyfikat i nazwę domeny po stronie klienta (możesz wpisać nazwę hosta dla adresu 127.0.0.1 w pliku /etc/hosts w celu sprawdzenia):

Curl https://www.mycompany.com:443 --cacert root.pem --cert client.pem --key klient.key

Teraz połączenie się powiedzie i będziesz mógł zainstalować certyfikat serwera na serwerze WWW, przekazać klientowi certyfikat klienta i pracować z nim.

Bezpieczeństwo

W przypadku korzystania z protokołu SSL/TLS jedną z głównych metod jest metoda MITM (Man In The Middle). Metoda ta opiera się na użyciu certyfikatu serwera i klucza w jakimś węźle, który będzie nasłuchiwał ruchu i deszyfrował informacje wymieniane pomiędzy serwerem a klientem. Aby uporządkować słuchanie, możesz użyć na przykład programu sslsniff. Dlatego zazwyczaj zaleca się przechowywanie certyfikatu głównego i klucza na komputerze, który nie jest podłączony do sieci; w celu podpisania należy przynieść prośby o podpis na dysku flash, podpisać i również je zabrać. I oczywiście rób kopie zapasowe.

Najogólniej tak właśnie wykorzystywane są certyfikaty cyfrowe oraz protokoły TLS i SSL. Jeśli masz pytania/dodatki, napisz w komentarzach.

Wpis został opublikowany przez autora w kategorii oznaczonej , .

Nawigacja po wpisach

: 29 komentarzy

cl-service.com
Klient sam generuje CSR zamawiając certyfikat, przy czym decyduje również o przechowywaniu klucza prywatnego, do wystawienia certyfikatu nie jest nam potrzebny klucz prywatny, a klient w żaden sposób go nam nie przekazuje. Naturalnie, jeśli dzieje się to na zwykłym serwerze wirtualnym, wówczas administratorzy z dostępem root do serwera mają również dostęp do przechowywanych tam kluczy.
Życzący.
Temat cycków nie jest poruszany, gdyż opisana technologia PKI nie ma nic wspólnego z tytułem tematu. Przynajmniej nie bez powodu podałem linki do RFC.
P.S. Był taki dowcip o psie i pchle.
Życzący.
Nie chciałem Cię w żaden sposób urazić. Szukałem informacji na temat różnicy w praktyce pomiędzy SSl a TLS i Twój link był pierwszy w Google. Zaintrygował mnie tytuł tematu. Wszystko super, tak trzymaj!
DrAibolit
Dziękujemy za wnikliwe wyjaśnienia dotyczące certyfikacji cyfrowej. Jestem w tym nowy =)
Mam nadzieję, że możesz wyjaśnić następujące pytanie.
Ponieważ temat oszustw jest bardzo rozwinięty w branży internetowej, chciałbym dowiedzieć się, jak samodzielnie rozpoznać „wszy” stron, które odwiedzam (zwłaszcza tam, gdzie znajdują się środki pieniężne i płatnicze, inwestycje itp.) i na ich podstawie to określa stopień mojego zaufania (często muszę się rejestrować, zostawiać dane osobowe, dokonywać zakupów, transakcji, inwestycji). Jeśli dobrze rozumiem, posiadanie tego certyfikatu pozwala na dokonanie takiej oceny. Cóż, z drugiej strony zdobycie go nie stanowi problemu i jest nawet bezpłatne.
Jak lub za pomocą jakiego programu można sprawdzić, czy witryna posiada certyfikat cyfrowy? i najlepiej jego kategorię, która jest nadawana w przypadku wystawienia przez specjalny organ SSL DV (certyfikat wydawany jest z weryfikacją tylko domeny), SSL OV (z weryfikacją organizacji), EV (z rozszerzoną weryfikacją osoby prawnej). Oszukańcze witryny najprawdopodobniej nie będą korzystać z najnowszej opcji certyfikacji.
Byłbym szczęśliwy, gdybyś powiedział mi więcej sposobów określania wiarygodności witryn))
1. mnorin Autor postu
  Nie natknąłem się jeszcze na żaden konkretny program do tych celów, ale mogę dać kilka wskazówek w tej kwestii.
  Możesz użyć na przykład Chromium lub Google Chrome. Weźmy na przykład stronę https://www.thawte.com/ – firmy, która faktycznie zajmuje się certyfikatami cyfrowymi.
  Pasek adresu będzie zawierał nazwę firmy i zieloną kłódkę. Oznacza to, że organizacja jest zweryfikowana, jest to co najmniej SSL OV.
  Jeśli klikniesz na kłódkę, a w rozwijanym oknie „Szczegóły”, a następnie „Wyświetl certyfikat”, zobaczysz informacje o certyfikacie. W przypadku Thawte certyfikat jest podpisany następującym certyfikatem: „thawte Extended Validation SHA256 SSL CA”, a certyfikat dla click.alfabank.ru również jest podpisany przez Thawte, ale innym certyfikatem. Jest to „thawte EV SSL CA - G3”, czyli one również przeszły rozszerzoną weryfikację.
  Coś takiego.
Rusłan
Sekcja „Jak działają SSL i TLS”, „Klient generuje losową sekwencję cyfrową”.

Byłem pewien, że klient generuje sesyjne klucze prywatne i odpowiednio klucze publiczne (które oczywiście nazwałeś „sekwencją cyfrową”). Klucz publiczny jest przekazywany do serwera, a serwer szyfruje pakiety do klienta za pomocą publicznego klucza sesji klienta.

Proszę o wyjaśnienie.
Nowicjusz
Artykuł jest bardzo przydatny! Są nawet praktyczne przykłady =) Ale jednego nie rozumiem - jaka jest różnica między certyfikatem głównym a certyfikatem serwera? czy to to samo?
Witalij
Cześć.
Hoster zaoferował usługę - SSL dla serwerów wirtualnych. Skorzystaliśmy z tego. Okazało się, że dla poziomu trzeciego, tj. Certyfikat http://www.site.ru jest nieprawidłowy, tylko dla site.ru. Co więcej, odwiedzający stale przełączają się na protokół https, niezależnie od tego, czy odwiedzają site.ru, czy http://www.site.ru. Oczywiście w drugim przypadku przeglądarka zaczyna przeklinać rozdzierająco, a odwiedzający w ogóle nie trafia na stronę.
Jednak dla tych, którym udało się wejść na tę witrynę, witryna zaczęła wyglądać krzywo, część menu zniknęła, a niektóre obrazy w wynikach wyszukiwania przestały być wyświetlane przez niektóre komponenty.

Aby zainstalować oprogramowanie klienta Continent TLS, potrzebujesz:

Rysunek 33. Okno startowe kreatora instalacji oprogramowania „Continent TLS Client”.

Rysunek 34. Okno umowy licencyjnej na oprogramowanie Continent TLS Client.

3. Zaznacz pole „Akceptuję warunki umowy licencyjnej” i kliknij przycisk „Dalej”. Na ekranie pojawi się okno umożliwiające wprowadzenie klucza licencyjnego dostarczonego z oprogramowaniem Continent TLS Client na nośniku papierowym lub elektronicznym.

Rysunek 35. Okno do wprowadzenia klucza licencyjnego oprogramowania Continent TLS Client.

4. Wprowadź klucz licencyjny i kliknij Dalej. Na ekranie pojawi się okno dialogowe umożliwiające wybór ścieżki instalacji oprogramowania klienta Continent TLS.

Rysunek 36. Okno wyboru ścieżki instalacji oprogramowania Continent TLS Client.

5. Pozostaw domyślną ścieżkę instalacji. Kliknij Następny". Na ekranie pojawi się okno dialogowe „Uruchom konfigurator”.

Rysunek 37. Okno uruchamiania konfiguratora oprogramowania Continent TLS Client.

6. Zaznacz checkbox „Uruchom konfigurator po zakończeniu instalacji”.

Rysunek 38. Okno gotowości do instalacji oprogramowania klienta Continent TLS.

8. Kliknij przycisk „Zainstaluj”. Rozpocznie się instalacja komponentu.

Rysunek 39. Proces instalacji oprogramowania klienta Continent TLS.

9. Na ekranie wyświetli się okno dialogowe ustawień oprogramowania „Continent TLS Client”.

Rysunek 40. Konfigurowanie oprogramowania klienta Continent TLS.

Aby skonfigurować oprogramowanie, którego potrzebujesz:

a) W sekcji „Ustawienia klienta Continent TLS” pozostaw wartość „Port” na domyślnej wartości 8080.

b) W sekcji „Ustawienia serwera chronionego”, w polu „Adres” ustaw nazwę serwera TLS: lk.budget.gov.ru.

c) W sekcji „Ustawienia serwera chronionego”, w polu „Certyfikat” określ plik certyfikatu serwera TLS skopiowany do katalogu lokalnego w punkcie 3.1 niniejszego Przewodnika.

Rysunek 41. Konfigurowanie oprogramowania klienta Continent TLS. Wybór certyfikatu.

d) Jeżeli stacja robocza użytkownika nie korzysta z zewnętrznego serwera proxy, kliknij przycisk „OK”.

e) W przeciwnym razie podaj adres i port używanego zewnętrznego serwera proxy organizacji.

Rysunek 42. Konfigurowanie usługi oprogramowania Continent TLS Client. Konfigurowanie zewnętrznego serwera proxy.

f) Kliknij przycisk „OK”.

10. Na ekranie wyświetli się okno dialogowe umożliwiające zakończenie instalacji oprogramowania klienta Continent TLS.

Rysunek 43. Okno dialogowe zakończenia instalacji oprogramowania klienta Continent TLS.

11. Kliknij przycisk „Gotowe”.

12. Na ekranie pojawi się dialog o konieczności ponownego uruchomienia stacji roboczej użytkownika.

Rysunek 44. Dialog o konieczności ponownego uruchomienia stacji roboczej Użytkownika.

13. Kliknij przycisk „Nie”.