en English
X

Select Language

Powered by Google TranslateTranslate

We hope you will find the Google translation service helpful, but we don’t promise that Google’s translation will be accurate or complete. You should not rely on Google’s translation. English is the official language of our site.

en English
X

Select Language

Powered by Google TranslateTranslate

We hope you will find the Google translation service helpful, but we don’t promise that Google’s translation will be accurate or complete. You should not rely on Google’s translation. English is the official language of our site.

Przeglądarki i sprawdzanie poprawności certyfikatów

Wprowadzenie

HTTPS (przez SSL /TLS) używa szyfrowanie klucza publicznego w celu ochrony komunikacji przeglądarki przed odczytaniem lub modyfikacją podczas przesyłania przez Internet. Serwery zapewniają odwiedzającym przeglądarkom klucz publiczny, który służy do ustanowienia szyfrowanego połączenia dla wszystkich kolejnych wymian danych.

Jednak właśnie otrzymuję pracujący sam klucz publiczny nie gwarantuje, że (i przez rozszerzenie serwera) rzeczywiście należy do właściwego pilota przedmiot (tj. osoba, firma lub organizacja). Man-in-the-middle osoby atakujące mogą manipulować sieciami, aby obsługiwać własne klucze, co utrudnia komunikację.

Przeglądarki temu zapobiegają uwierzytelnianie Używanie serwerów HTTPS certyfikaty, które są dokumentami cyfrowymi, które związania klucz publiczny do konkretnego tematu. Powiązanie jest potwierdzane przez posiadanie zaufanego Instytucja Certyfikacyjna (CA), takie jak SSL.com weryfikować tożsamość potencjalnych właścicieli certyfikatów poprzez automatyczne i ręczne kontrole w kwalifikowanych bazach danych.

Ta relacja zaufania oznacza, że ​​bezpieczeństwo użytkowników sieci nie jest absolutne; wymaga raczej od użytkowników zaufania przeglądarkom i urzędom certyfikacji w celu ochrony ich bezpieczeństwa. Dlatego uważamy, że w interesie każdego użytkownika leży podstawowa wiedza na temat działania walidacji certyfikatu.

Należy pamiętać, że proces sprawdzania poprawności certyfikatu (szczegółowo opisany w standardowym dokumencie RFC 5280) jest dość zagmatwany. W tym artykule postaramy się poprowadzić Cię jedną ścieżką (przeglądarka weryfikująca SSL hosta /TLS certyfikat) i nawiguj po skomplikowanych szczegółach, które są nieistotne dla większości użytkowników.

Potrzebujesz certyfikatu? SSL.com Cię obejmuje. Porównaj opcje tutaj aby znaleźć właściwy wybór dla Ciebie, od S/MIME certyfikaty do podpisywania kodu i nie tylko.

ZAMÓW TERAZ

Certyfikaty i format X.509

Certyfikaty są plikami cyfrowymi pod każdym względem, co oznacza, że ​​muszą przestrzegać formatu pliku, aby przechowywać informacje (np. Podpisy, klucze, wystawcy itp.). Podczas gdy prywatny PKI konfiguracje mogą implementować dowolny format swoich certyfikatów, publicznie zaufanych PKIs (tzn. zaufane przez przeglądarki) muszą być zgodne z RFC 5280, co wymaga użycia X.509 v3 Format.

X.509 v3 pozwala certyfikatom zawierać dodatkowe dane, takie jak ograniczenia użytkowania lub informacje o zasadach, jak rozszerzenia, przy czym każde rozszerzenie jest albo krytyczny or nie krytyczny. Przeglądarki mogą ignorować nieprawidłowe lub nierozpoznane rozszerzenia niekrytyczne, ale są one wymagane do przetworzenia i sprawdzenia poprawności wszystkich krytycznych rozszerzeń.

Ścieżki certyfikacji i przetwarzanie ścieżek

Urzędy certyfikacji używają klucza prywatnego do kryptograficznego podpisywania wszystkich wydanych certyfikatów. Takie podpisy mogą nieodwołalnie udowodnić, że certyfikat został wydany przez określony urząd certyfikacji i że nie został zmodyfikowany po podpisaniu.

Urzędy certyfikacji ustalają własność swojego klucza do podpisywania poprzez posiadanie samodzielnie wystawionego certyfikatu (zwanego korzeń) dla odpowiedniego klucza publicznego. Właściwe organy muszą przestrzegać ściśle kontrolowanych i skontrolowanych procedur w celu utworzenia, zarządzania i korzystania z roota, a także w celu zminimalizowania narażenia zwykle używają roota do wydania pośredni certyfikaty. Te półprodukty można następnie wykorzystać do wystawienia certyfikatów swoim klientom.Przeglądarki są dostarczane z wbudowaną listą zaufanych katalogów głównych. (Są to korzenie z urzędów certyfikacji, które spełniły rygorystyczne kryteria przeglądarki dotyczące włączenia). Aby zweryfikować certyfikat, przeglądarka uzyska sekwencję certyfikatów, z których każdy ma podpisany następny certyfikat w sekwencji, łącząc główny certyfikat urzędu certyfikacji z certyfikatem serwera. certyfikat.

Ta sekwencja certyfikatów nosi nazwę a ścieżka certyfikacji. Katalog główny ścieżki nosi nazwę kotwica zaufania a certyfikat serwera nazywa się liść or jednostka końcowa certyfikat.

Budowa ścieżki

Często przeglądarki muszą brać pod uwagę wiele ścieżek certyfikacji, dopóki nie znajdą prawidłowej dla danego certyfikatu. Mimo że ścieżka może zawierać certyfikaty, które „łączą się” prawidłowo ze znaną kotwicą, sama ścieżka może zostać odrzucona z powodu ograniczeń dotyczących długości ścieżki, nazwy domeny, użycia certyfikatu lub zasad.

Konstruowanie i ocena wszystkich możliwych ścieżek jest kosztownym procesem wykonywanym dla każdego nowego certyfikatu napotkanego przez przeglądarkę. Przeglądarki wdrożyły różne optymalizacje, aby zminimalizować liczbę odrzuconych ścieżek kandydatów, ale zagłębianie się w takie szczegóły znacznie wykracza poza zakres tego artykułu.

Walidacja ścieżki

Po skonstruowaniu ścieżki certyfikacji kandydata przeglądarki sprawdzają ją, korzystając z informacji zawartych w certyfikatach. Ścieżka jest prawidłowa, jeśli przeglądarki mogą kryptograficznie udowodnić, że począwszy od certyfikatu podpisanego bezpośrednio przez kotwicę zaufania, odpowiedni klucz prywatny każdego certyfikatu został użyty do wydania następnego w ścieżce, aż do certyfikatu liścia.

Algorytm walidacji ścieżki certyfikacji

RFC 5280 opisuje a standardowy algorytm , które stosują przeglądarki, aby sprawdzić ścieżkę certyfikacji certyfikatów X.509.

Zasadniczo przeglądarki iterują po wszystkich certyfikatach w ścieżce, zaczynając od kotwicy zaufania (tj. Certyfikatu głównego), weryfikując podstawowe informacje i krytyczne rozszerzenia każdego certyfikatu.

Jeśli procedura zakończy się ostatnim certyfikatem w ścieżce bez błędów, ścieżka zostanie zaakceptowana jako poprawna. Jeśli wystąpią błędy, ścieżka zostanie oznaczona jako niepoprawna.

Podstawowe przetwarzanie certyfikatu

Niezależnie od rozszerzeń przeglądarki muszą zawsze weryfikować podstawowe informacje o certyfikacie, takie jak podpis lub wystawca. Poniższe sekcje pokazują sekwencję kontroli wykonywanych przez przeglądarki.

1. Przeglądarka weryfikuje integralność certyfikatu

Podróż Ruta de la Plata w liczbach podpis na certyfikacie można zweryfikować przy użyciu normalnej kryptografii klucza publicznego. Jeśli podpis jest nieważny, certyfikat jest uważany za zmodyfikowany po jego wydaniu i dlatego zostaje odrzucony.

2. Przeglądarka weryfikuje ważność certyfikatu

Certyfikat okres ważności to przedział czasu, w którym podpisujący urząd certyfikacji gwarantuje, że zachowa informacje o swoim statusie. Przeglądarki odrzucają wszelkie certyfikaty z okresem ważności kończącym się przed datą i godziną sprawdzenia poprawności lub rozpoczynającym się po niej.

3. Przeglądarka sprawdza stan odwołania certyfikatu

Wydawany certyfikat powinien być używany przez cały okres ważności. Oczywiście różne okoliczności mogą spowodować utratę ważności certyfikatu przed jego naturalnym wygaśnięciem.

Takie okoliczności mogą obejmować zmianę nazwiska lub podejrzenie ujawnienia klucza prywatnego przez podmiot. W takich przypadkach urząd certyfikacji musi odwołać odpowiedni certyfikat, a użytkownicy ufają również urzędom certyfikacji, które powiadamiają przeglądarki o stanie odwołania ich certyfikatów.

RFC 5280 zaleca, aby urzędy certyfikacji używały w tym celu list odwołania.

Listy odwołania certyfikatów (CRL)

Urzędy certyfikacji okresowo wydają podpisaną, opatrzoną znacznikami czasu listę unieważnionych certyfikatów o nazwie a lista odwołania certyfikatów (CRL). Listy CRL są rozprowadzane w publicznie dostępnych repozytoriach, a przeglądarki mogą pobierać i sprawdzać najnowszą listę CRL urzędu certyfikacji podczas sprawdzania poprawności certyfikatu.

Jedną z wad tej metody jest to, że szczegółowość czasowa unieważnienia jest ograniczona do okresu wystawienia listy CRL. Przeglądarka zostanie powiadomiona o unieważnieniu dopiero po zaplanowaniu aktualizacji wszystkich aktualnie wystawionych list CRL. W zależności od polityki podpisującego urzędu certyfikacji może to zająć godzinę, dzień lub nawet tydzień.

Protokół statusu certyfikatu online (OCSP)

Istnieją inne alternatywne metody uzyskiwania informacji o statusie odwołania, przy czym najpopularniejsze to Protokół statusu certyfikatu online (OCSP).

Opisane w standardowym dokumencie RFC6960, OCSP pozwala przeglądarce zażądać statusu odwołania określonego certyfikatu z internetowego serwera OCSP (zwanego również plikiem odpowiadać). Po prawidłowej konfiguracji OCSP jest znacznie bardziej natychmiastowy i pozwala uniknąć wspomnianego wyżej problemu z opóźnieniem aktualizacji listy CRL. Dodatkowo, Zszywanie OCSP poprawia wydajność i szybkość.

4. Przeglądarka weryfikuje wystawcę

Certyfikaty są zwykle powiązane z dwoma podmiotami:

  1. Podróż Ruta de la Plata w liczbach emitent, czyli podmiot posiadający klucz podpisujący i
  2. Podróż Ruta de la Plata w liczbach przedmiot, który odnosi się do właściciela klucza publicznego, który uwierzytelnia certyfikat.

Przeglądarki sprawdzają, czy certyfikat emitent pole jest takie samo jak przedmiot pole poprzedniego certyfikatu na ścieżce. Większość dla większego bezpieczeństwa PKI implementacje sprawdzają również, czy klucz wystawcy jest taki sam jak klucz, który podpisał bieżący certyfikat. (Należy zauważyć, że nie dotyczy to kotwicy zaufania, ponieważ korzenie są wydawane samodzielnie - tj. Mają tego samego wystawcę i podmiot).

Przetwarzanie ograniczeń

Format X.509 v3 umożliwia urzędowi certyfikacji zdefiniowanie ograniczeń lub ograniczeń dotyczących sprawdzania poprawności każdego certyfikatu i używania go jako rozszerzenia krytycznego. Każdy certyfikat na ścieżce może nakładać dodatkowe ograniczenia, których muszą przestrzegać wszystkie kolejne certyfikaty.

Ograniczenia certyfikatów rzadko wpływają na przeciętnego użytkownika Internetu, choć są dość powszechne w rozwiązaniach SSL dla przedsiębiorstw. Ograniczenia funkcjonalne mogą służyć kilku celom operacyjnym, ale ich najistotniejszym zastosowaniem jest ograniczenie znanych problemów związanych z bezpieczeństwem.

5. Przeglądarka sprawdza ograniczenia nazw

Prywatny (ale publicznie zaufany) pośredni urząd certyfikacji z odpowiednim ograniczenia nazw może zapewnić organizacji szczegółową kontrolę nad zarządzaniem i wydawaniem certyfikatów. Certyfikaty mogą być ograniczone do określonej domeny lub drzewa domen (tj. W tym subdomen) dla nazwy domeny firmy lub organizacji. Ograniczenia nazwy są często używane w przypadku certyfikatów pośrednich CA zakupionych od publicznie zaufanego urzędu certyfikacji, aby zapobiec wystawianiu przez pośredni ośrodek CA całkowicie ważnych certyfikatów dla domen zewnętrznych (np. google.com).

6. Przeglądarka sprawdza ograniczenia zasad

Polityka certyfikatów to dokument prawny opublikowany przez urząd certyfikacji, oficjalnie opisujący procedury stosowane przy wydawaniu certyfikatów i zarządzaniu nimi. Urzędy certyfikacji mogą wystawiać certyfikat na podstawie jednej lub więcej zasad, a łącza do nich są zawarte w każdym wydanym certyfikacie, aby strony ufające mogły ocenić te zasady przed podjęciem decyzji o zaufaniu do tego certyfikatu.

Ze względów prawnych i operacyjnych certyfikaty mogą nakładać ograniczenia na zasady, którym mogą podlegać. Jeśli okaże się, że certyfikat zawiera krytyczne ograniczenia zasad, przeglądarki muszą je zweryfikować przed kontynuowaniem. (Jednak w świecie rzeczywistym rzadko spotykane są krytyczne ograniczenia polityczne i dlatego nie będą uwzględniane w dalszej części tego artykułu).

7. Przeglądarka sprawdza podstawowe ograniczenia (inaczej długość ścieżki)

Format X.509 v3 umożliwia wystawcom zdefiniowanie maksymalnej długości ścieżki obsługiwanej przez certyfikat. Zapewnia to kontrolę nad tym, jak daleko każdy certyfikat może zostać umieszczony na ścieżce certyfikacji. To naprawdę ważne - przeglądarki ignorowały długość ścieżki certyfikacji, dopóki badacz tego nie zademonstrował, w 2009 roku prezentacja, jak wykorzystał certyfikat liścia swojej witryny internetowej, aby wykuć ważny certyfikat dla dużej witryny handlu elektronicznego.

8. Przeglądarka weryfikuje użycie klucza

Rozszerzenie „użycie klucza” określa przeznaczenie klucza zawartego w certyfikacie. Przykłady takich celów obejmują szyfrowanie, podpisy, podpisywanie certyfikatów i tak dalej. Przeglądarki odrzucają certyfikaty naruszające ich ograniczenia użycia kluczy, takie jak napotykanie certyfikatu serwera z kluczem przeznaczonym tylko do podpisywania listy CRL.

9. Przeglądarka kontynuuje przetwarzanie wszystkich pozostałych krytycznych rozszerzeń

Po przetworzeniu wyżej wymienionych rozszerzeń przeglądarki przystępują do sprawdzania wszystkich pozostałych rozszerzeń, które aktualny certyfikat określa jako krytyczne, przed przejściem do następnego. Jeśli przeglądarka osiągnie certyfikat liścia ścieżki bez błędu, ścieżka zostanie zaakceptowana jako poprawna. Jeśli wystąpią jakiekolwiek błędy, ścieżka zostanie oznaczona jako nieprawidłowa i nie zostanie nawiązane bezpieczne połączenie.

Wnioski

Sieć WWW to złożony system połączonych ze sobą i stale ewoluujących ruchomych części. Bezpieczeństwo przeglądarki nie jest zatem rozwiązanym problemem i mamy nadzieję, że ten artykuł dostarczył pewnego wglądu w złożoność nawet jednego komponentu, któremu tu przyjrzeliśmy. Zaufanie odgrywa główną rolę w zapewnianiu bezpieczeństwa w Internecie, dlatego zachęcamy do uzyskania dodatkowych informacji na temat polityki certyfikatów urzędu certyfikacji. (Zapraszam do recenzji Zasady SSL.com tutaj, w rzeczywistości.)

Dziękujemy za wybranie SSL.com, gdzie naszym zdaniem bezpieczniej Internet to lepszy Internet.

Subskrybuj biuletyn SSL.com

Nie przegap nowych artykułów i aktualizacji z SSL.com