X.509 to standard określający formaty certyfikatów kluczy publicznych , list unieważnionych certyfikatów, atrybutów certyfikatów i algorytm walidacji ścieżki certyfikacji, zdefiniowany przez Międzynarodowy Związek Telekomunikacyjny (ITU). X.509 ustala między innymi standardowy format certyfikatu elektronicznego oraz algorytm walidacji ścieżki certyfikacji. X.509 to także liczne specyfikacje RFC organizacji IETF .
X.509 powstał w 1988 roku jako część standardu X.500 . Opiera się na hierarchicznym systemie urzędów certyfikacji , w przeciwieństwie do zaufanych sieci (takich jak sieć zaufania OpenPGP ), w których każdy może podpisywać certyfikaty innych osób.
W systemie X.509 urząd certyfikacji przypisuje certyfikat wiążący klucz publiczny do nazwy wyróżniającej, której format jest zdefiniowany przez zalecenie X.500 , lub do nazwy alternatywnej (nazwa alternatywna ), takiej jak „ adres e-mail lub DNS rekord .
Ten certyfikat umieszcza podpis urzędu certyfikacji w ostatnim polu. Konkretnie podpis ten jest wykonywany przez kondensat wszystkich poprzednich pól certyfikatu i szyfrowanie tego kondensatu kluczem prywatnym urzędu certyfikacji. Każdy, kto ma klucz publiczny dla tego urzędu certyfikacji, może odszyfrować skrót i porównać go z własnym obliczeniem skrótu certyfikatu. Jeśli oba kondensaty są identyczne, gwarantuje to, że certyfikat jest nienaruszony, nie został zmodyfikowany. Certyfikat CA zawierający jego klucz publiczny może z kolei zostać podpisany innym certyfikatem wyższego poziomu, tworząc w ten sposób łańcuch. Na szczycie łańcucha znajdują się najważniejsze certyfikaty : certyfikaty główne .
Certyfikaty główne to niepodpisane lub samopodpisane klucze publiczne , którym ufasz. Oprogramowanie, takie jak przeglądarki internetowe lub klienci poczty e-mail, posiada certyfikaty główne wielu komercyjnych lub rządowych urzędów certyfikacji. Gdy przeglądarka otwiera bezpieczne połączenie ( TLS / SSL ) z witryną, która ma certyfikat wydany przez znany urząd, uważa tę witrynę za bezpieczną, o ile ścieżka certyfikacji jest zweryfikowana. Przejście do trybu bezpiecznego jest wtedy przezroczyste.
Jeżeli oprogramowanie (przeglądarka lub inne) nie zna urzędu certyfikacji (certyfikat wygenerowany i podpisany przez osobę fizyczną lub urząd certyfikacji nieznany lub dobrowolnie usunięty z listy akceptowanych urzędów), przeglądarka proponuje zbadanie certyfikatu, wówczas przyjąć lub odrzucić, w zależności od pokładanego w nim zaufania.
X.509 może być używany z S / MIME , TLS / SSL , SET i IPsec .
Oryginalna definicja jest dostępna w RFC 2459 (sekcja 4) lub w najnowszej wersji ( RFC 5280), która zawiera specjalizację X.509 dla aplikacji internetowych . Część uwierzytelniona zawiera następujące pola:
Nazwy nadawcy (również sygnatariusza) i posiadacza to nazwy X.501, które można również znaleźć w katalogach ISO i LDAP . Po powyższej treści następuje powtórzenie algorytmu podpisu i samego podpisu.
Żadne z pól obowiązkowych nie pozwala odróżnić urzędu certyfikacji (organizacji wydającej certyfikaty) od zwykłego posiadacza. Rozszerzenie basicConstraints zdefiniowane w X.509 w wersji 3 rozwiązuje to ograniczenie. Inną niedoskonałością tego samego typu jest to, że tylko nazwa pozwala na powiązanie certyfikatu z certyfikatem wystawcy, podczas gdy niepowtarzalność nazw nie może być zagwarantowana.
W RFC 5280 definiuje suma rozszerzeń wskazujących na przeznaczenie certyfikatu. Oto najpopularniejsze rozszerzenia:
Ogólnie rzecz biorąc, jeśli certyfikat ma kilka rozszerzeń ograniczających jego użycie, należy spełnić wszystkie warunki, aby wykorzystanie było odpowiednie. Dokument RFC 5280 podaje konkretny przykład certyfikatu zawierającego zarówno keyUsage extendedKeyUsage, w którym oba ograniczenia muszą być spełnione, aby certyfikat mógł być używany zgodnie z zamierzonymi zastosowaniami.
Oto typowe rozszerzenia certyfikatów w formacie X.509:
Łańcuch certyfikatów to lista certyfikatów (zaczynająca się od podmiotu, który ma być certyfikowany, np. Serwer), obejmująca jeden lub więcej urzędów certyfikacji (ostatni z nich jest podpisany samodzielnie), mająca następujące właściwości:
Łańcuchy certyfikatów są wykorzystywane w celu zapewnienia, że klucz publiczny i dane świadectwo (the 1 st łańcucha) odpowiadają właściciela niego. Aby to zapewnić, podpis cyfrowy jest weryfikowany za pomocą klucza publicznego kolejnego podmiotu w łańcuchu, sam podpisywany kluczem publicznym kolejnego podmiotu, aż do osiągnięcia ostatniego podmiotu w łańcuchu. Jako ostatni certyfikat jest uznawany za zaufany, wracając do niego ostatecznie wynosi autentyczną 1 st certyfikat.
Certyfikat może utracić ważność z wielu powodów, takich jak naturalny wygaśnięcie (przekroczenie terminu ważności), utrata lub kompromitacja klucza prywatnego powiązanego z certyfikatem, zmiana przynajmniej jednego pola w nazwie posiadacza / posiadacza certyfikatu oraz skrajne przypadek utraty lub kompromitacji klucza prywatnego urzędu certyfikacji, który podpisał dany certyfikat.
Dlatego standard określa format listy zawierającej certyfikaty, które utraciły ważność dla danego urzędu certyfikacji. Lista ta jest podpisana przez urząd certyfikacji, aby uniemożliwić jakąkolwiek modyfikację przez osobę nieuprawnioną.
Zawiera datę wystawienia, datę aktualizacji (obie opcjonalne) oraz samą listę w postaci par (numer seryjny unieważnionego certyfikatu; możliwa przyczyna unieważnienia) . Wzorzec może występować tylko na listach CRL w formacie 2.
Czasami irytującym ograniczeniem list CRL jest opóźnienie w propagowaniu informacji o odwołaniu. Aby to zmniejszyć, opracowano protokół walidacji certyfikatu OCSP . Zdefiniowany początkowo w RFC 2560, a następnie ponownie w RFC 6960, protokół ten dostarcza z grubsza te same informacje co listy CRL, ale potencjalnie jest bardziej aktualny.
W następstwie opublikowania pełnej kolizji wyszukiwania ataku przeciwko MD5 w 2004 roku, Arjen Lenstra , Wang Xiaoyun, a Benne de Weger zainteresował się X.509 użyciu MD5 dla uwierzytelniania certyfikatu. Ich atak spowodował sfałszowanie dwóch certyfikatów z identycznymi podpisami.
Korzystanie z kryptograficznej funkcji skrótu SHA-1 tylko częściowo rozwiązuje problem, ponieważ podobny atak jest teoretycznie możliwy, chociaż złożoność znalezienia kolizji na SHA-1 jest znacznie większa niż na MD5.
Rozwiązania:
Urzędy certyfikacji:
Narzędzia (bezpłatne):