Certyfikat klucza publicznego - Public key certificate

Certyfikat klucza publicznego *.comifuro.net, wydany przez Let's Encrypt

W kryptografii , o certyfikat klucza publicznego , znany również jako cyfrowego certyfikatu lub zaświadczenia tożsamości , jest dokument elektroniczny używany udowodnić własność klucza publicznego . Certyfikat zawiera informacje o kluczu, informacje o tożsamości jego właściciela (tzw. podmiot) oraz podpis cyfrowy podmiotu, który zweryfikował zawartość certyfikatu (tzw. wystawca). Jeśli podpis jest ważny, a oprogramowanie badające certyfikat ufa wystawcy, może użyć tego klucza do bezpiecznej komunikacji z podmiotem certyfikatu. W szyfrowaniu wiadomości e-mail , podpisaniu kodu iW systemach podpisu elektronicznego, podmiotem certyfikatu jest zazwyczaj osoba lub organizacja. Jednak w Transport Layer Security (TLS) podmiotem certyfikatu jest zwykle komputer lub inne urządzenie, chociaż certyfikaty TLS mogą identyfikować organizacje lub osoby oprócz ich podstawowej roli w identyfikowaniu urządzeń. TLS, czasami nazywany starszą nazwą Secure Sockets Layer (SSL), wyróżnia się tym, że jest częścią HTTPS , protokołu do bezpiecznego przeglądania sieci .

W typowym schemacie infrastruktury klucza publicznego (PKI) wystawcą certyfikatu jest urząd certyfikacji (CA), zwykle firma, która pobiera od klientów opłaty za wydawanie im certyfikatów. Natomiast w sieci zaufania osoby fizyczne podpisują swoje klucze bezpośrednio, w formacie, który pełni podobną funkcję do certyfikatu klucza publicznego.

Najpopularniejszy format certyfikatów kluczy publicznych jest zdefiniowany przez X.509 . Ponieważ X.509 jest bardzo ogólny, format jest dodatkowo ograniczony przez profile zdefiniowane dla pewnych przypadków użycia, takie jak Public Key Infrastructure (X.509) zgodnie z definicją w RFC  5280 .

Rodzaje certyfikatów

Role certyfikatu głównego, certyfikatu pośredniego i certyfikatu podmiotu końcowego jak w łańcuchu zaufania .

Certyfikat serwera TLS/SSL

W TLS (zaktualizowany zamiennik SSL) serwer musi przedstawić certyfikat w ramach początkowej konfiguracji połączenia. Klient łączący się z tym serwerem wykona algorytm sprawdzania poprawności ścieżki certyfikacji :

  1. Temat certyfikatu odpowiada nazwie hosta (tj. nazwie domeny), z którą klient próbuje się połączyć;
  2. Certyfikat jest podpisany przez zaufany urząd certyfikacji.

Podstawowa nazwa hosta ( nazwa domeny witryny internetowej) jest wymieniona jako nazwa pospolita w polu Temat certyfikatu. Certyfikat może być ważny dla wielu nazw hostów (wielu witryn internetowych). Takie certyfikaty są powszechnie nazywane certyfikatami alternatywnej nazwy podmiotu (SAN) lub certyfikatami ujednoliconej komunikacji (UCC) . Te certyfikaty zawierają pole Alternatywna nazwa podmiotu , chociaż wiele urzędów certyfikacji umieszcza je również w polu Nazwa pospolita podmiotu, aby zapewnić zgodność z poprzednimi wersjami. Jeśli niektóre nazwy hostów zawierają gwiazdkę (*), certyfikat może być również nazywany certyfikatem wieloznacznym .

Serwer TLS można skonfigurować za pomocą certyfikatu z podpisem własnym. W takim przypadku klienci zazwyczaj nie będą mogli zweryfikować certyfikatu i zerwą połączenie, chyba że sprawdzanie certyfikatu zostanie wyłączone.

Zgodnie z aplikacjami certyfikaty SSL można podzielić na trzy typy:

  • SSL z walidacją domeny;
  • SSL walidacji organizacji;
  • SSL z rozszerzoną walidacją.

Certyfikat klienta TLS/SSL

Certyfikaty klienta są mniej powszechne niż certyfikaty serwera i służą do uwierzytelniania klienta łączącego się z usługą TLS, na przykład w celu zapewnienia kontroli dostępu. Ponieważ większość usług zapewnia dostęp osobom, a nie urządzeniom, większość certyfikatów klienta zawiera adres e-mail lub imię i nazwisko, a nie nazwę hosta. Ponadto, ponieważ uwierzytelnianie jest zwykle zarządzane przez dostawcę usług, certyfikaty klienta zwykle nie są wystawiane przez publiczny urząd certyfikacji, który udostępnia certyfikaty serwera. Zamiast tego operator usługi, która wymaga certyfikatów klienta, zazwyczaj obsługuje własny wewnętrzny urząd certyfikacji, który je wystawia. Certyfikaty klienta są obsługiwane przez wiele przeglądarek internetowych, ale większość usług używa haseł i plików cookie do uwierzytelniania użytkowników zamiast certyfikatów klienta.

Certyfikaty klienta są bardziej powszechne w systemach RPC , w których są używane do uwierzytelniania urządzeń w celu zapewnienia, że ​​tylko autoryzowane urządzenia mogą wykonywać określone wywołania RPC.

Certyfikat e-mail

W protokole S/MIME dla bezpiecznej poczty e-mail nadawcy muszą odkryć, którego klucza publicznego użyć dla danego odbiorcy. Otrzymują te informacje z certyfikatu e-mail. Niektóre zaufane publicznie urzędy certyfikacji udostępniają certyfikaty poczty e-mail, ale częściej do komunikacji w danej organizacji używany jest protokół S/MIME, a organizacja ta prowadzi własny urząd certyfikacji, któremu ufają uczestnicy tego systemu poczty e-mail.

Certyfikat EMV

Karty płatnicze EMV są wstępnie załadowane certyfikatem wydawcy karty, podpisanym przez urząd certyfikacji EMV w celu potwierdzenia autentyczności karty płatniczej podczas transakcji płatniczej. Certyfikat EMV CA jest ładowany do terminali kart ATM lub POS i służy do walidacji certyfikatu wydawcy karty.

Certyfikat podpisywania kodu

Certyfikatów można również używać do sprawdzania poprawności podpisów w programach, aby upewnić się, że nie zostały one naruszone podczas dostarczania.

Certyfikat kwalifikowany

Certyfikat identyfikujący osobę, zwykle do celów podpisu elektronicznego . Najczęściej stosuje się je w Europie, gdzie rozporządzenie eIDAS je standaryzuje i wymaga ich uznania.

Certyfikat główny

Certyfikat z podpisem własnym używany do podpisywania innych certyfikatów. Czasami nazywany również kotwicą zaufania lub korzeniem zaufania .

Certyfikat pośredni

Certyfikat używany do podpisywania innych certyfikatów. Certyfikat pośredni musi być podpisany przez inny certyfikat pośredni lub certyfikat główny.

Certyfikat podmiotu końcowego lub liścia

Każdy certyfikat, którego nie można użyć do podpisania innych certyfikatów. Na przykład certyfikaty serwera i klienta TLS/SSL, certyfikaty poczty e-mail, certyfikaty podpisywania kodu i certyfikaty kwalifikowane są certyfikatami jednostek końcowych.

Certyfikat oparty na rolach

Zdefiniowane w polityce certyfikacji X.509 dla Federalnego Urzędu Certyfikacji Mostów, certyfikaty oparte na rolach „identyfikują określoną rolę, w imieniu której subskrybent jest upoważniony do działania, a nie nazwę subskrybenta i są wydawane w celu wspierania przyjętych praktyk biznesowych ”.

Certyfikat grupowy

Zdefiniowane w Polityce Certyfikacji X.509 dla Federalnego Urzędu Certyfikacji Mostów, dla „przypadków, w których istnieje kilka podmiotów działających w jednym charakterze i gdy niezaprzeczalność transakcji nie jest pożądana”.

Certyfikat z podpisem własnym

Certyfikat z tematem zgodnym z jego wystawcą oraz podpis, który można zweryfikować za pomocą własnego klucza publicznego. Większość typów certyfikatów może być z podpisem własnym. Certyfikaty z podpisem własnym są również często nazywane certyfikatami oleju węża, aby podkreślić ich niewiarygodność.

Pola wspólne

Oto niektóre z najczęstszych pól w certyfikatach. Większość certyfikatów zawiera szereg pól niewymienionych tutaj. Należy zauważyć, że pod względem reprezentacji certyfikatu X.509 certyfikat nie jest „płaski”, ale zawiera te pola zagnieżdżone w różnych strukturach w certyfikacie.

  • Numer seryjny : Używany do jednoznacznej identyfikacji certyfikatu w systemach CA. W szczególności służy to do śledzenia informacji o odwołaniu.
  • Temat : Podmiot, do którego należy certyfikat: maszyna, osoba fizyczna lub organizacja.
  • Wystawca : podmiot, który zweryfikował informacje i podpisał certyfikat.
  • Nie wcześniej : Najwcześniejsza godzina i data ważności certyfikatu. Zwykle ustawiany na kilka godzin lub dni przed wydaniem certyfikatu, aby uniknąć problemów z przesunięciem zegara .
  • Nie po : godzina i data, po której certyfikat stracił ważność.
  • Użycie klucza : prawidłowe zastosowania kryptograficzne klucza publicznego certyfikatu. Typowe wartości to weryfikacja podpisu cyfrowego, szyfrowanie klucza i podpisywanie certyfikatu.
  • Rozszerzone użycie klucza : aplikacje, w których można używać certyfikatu. Typowe wartości obejmują uwierzytelnianie serwera TLS, ochronę poczty e-mail i podpisywanie kodu.
  • Klucz publiczny : klucz publiczny należący do podmiotu certyfikatu.
  • Algorytm podpisu : zawiera algorytm mieszający i algorytm szyfrowania. Na przykład „sha256RSA”, gdzie sha256 to algorytm mieszający, a RSA to algorytm szyfrowania.
  • Podpis : Treść certyfikatu jest haszowana (wykorzystywany jest algorytm haszujący w polu „Signature Algorithm”), a następnie hash jest szyfrowany (wykorzystywany jest algorytm szyfrowania w polu „Signature Algorithm”) za pomocą klucza prywatnego wystawcy.

Przykładowy certyfikat

To jest przykład zdekodowanego certyfikatu SSL/TLS pobranego ze strony SSL.com. Nazwa zwyczajowa (CN) wystawcy jest wyświetlana jako SSL.com EV SSL Intermediate CA RSA R3, co oznacza , że jest to certyfikat Extended Validation (EV). W polu znajduje się zweryfikowana informacja o właścicielu strony (SSL Corp) Subject. X509v3 Subject Alternative NamePole zawiera listę nazw domen objętych świadectwem. X509v3 Extended Key UsageI X509v3 Key Usagepola pokazać wszystkie odpowiednie zastosowanie.

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            72:14:11:d3:d7:e0:fd:02:aa:b0:4e:90:09:d4:db:31
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, ST=Texas, L=Houston, O=SSL Corp, CN=SSL.com EV SSL Intermediate CA RSA R3
        Validity
            Not Before: Apr 18 22:15:06 2019 GMT
            Not After : Apr 17 22:15:06 2021 GMT
        Subject: C=US, ST=Texas, L=Houston, O=SSL Corp/serialNumber=NV20081614243, CN=www.ssl.com/postalCode=77098/businessCategory=Private Organization/street=3100 Richmond Ave/jurisdictionST=Nevada/jurisdictionC=US
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (2048 bit)
                Modulus:
                    00:ad:0f:ef:c1:97:5a:9b:d8:1e ...
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Authority Key Identifier: 
                keyid:BF:C1:5A:87:FF:28:FA:41:3D:FD:B7:4F:E4:1D:AF:A0:61:58:29:BD

            Authority Information Access: 
                CA Issuers - URI:http://www.ssl.com/repository/SSLcom-SubCA-EV-SSL-RSA-4096-R3.crt
                OCSP - URI:http://ocsps.ssl.com

            X509v3 Subject Alternative Name: 
                DNS:www.ssl.com, DNS:answers.ssl.com, DNS:faq.ssl.com, DNS:info.ssl.com, DNS:links.ssl.com, DNS:reseller.ssl.com, DNS:secure.ssl.com, DNS:ssl.com, DNS:support.ssl.com, DNS:sws.ssl.com, DNS:tools.ssl.com
            X509v3 Certificate Policies: 
                Policy: 2.23.140.1.1
                Policy: 1.2.616.1.113527.2.5.1.1
                Policy: 1.3.6.1.4.1.38064.1.1.1.5
                  CPS: https://www.ssl.com/repository

            X509v3 Extended Key Usage: 
                TLS Web Client Authentication, TLS Web Server Authentication
            X509v3 CRL Distribution Points:

                Full Name:
                  URI:http://crls.ssl.com/SSLcom-SubCA-EV-SSL-RSA-4096-R3.crl

            X509v3 Subject Key Identifier: 
                E7:37:48:DE:7D:C2:E1:9D:D0:11:25:21:B8:00:33:63:06:27:C1:5B
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            CT Precertificate SCTs: 
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : 87:75:BF:E7:59:7C:F8:8C:43:99 ...
                    Timestamp : Apr 18 22:25:08.574 2019 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
                                30:44:02:20:40:51:53:90:C6:A2 ...
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : A4:B9:09:90:B4:18:58:14:87:BB ...
                    Timestamp : Apr 18 22:25:08.461 2019 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
                                30:45:02:20:43:80:9E:19:90:FD ...
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : 55:81:D4:C2:16:90:36:01:4A:EA ...
                    Timestamp : Apr 18 22:25:08.769 2019 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
                                30:45:02:21:00:C1:3E:9F:F0:40 ...
    Signature Algorithm: sha256WithRSAEncryption
         36:07:e7:3b:b7:45:97:ca:4d:6c ...

Wykorzystanie w Unii Europejskiej

W Unii Europejskiej (zaawansowane) podpisy elektroniczne na dokumentach prawnych są powszechnie wykonywane przy użyciu podpisów cyfrowych z towarzyszącymi im certyfikatami tożsamości. Jednak tylko kwalifikowane podpisy elektroniczne (wymagające użycia kwalifikowanego dostawcy usług zaufania i urządzenia do składania podpisu) mają taką samą moc jak podpis fizyczny.

Urzędy certyfikacji

Procedura uzyskania certyfikatu klucza publicznego

W modelu zaufania X.509 za podpisywanie certyfikatów odpowiada urząd certyfikacji (CA). Certyfikaty te działają jako wprowadzenie między dwiema stronami, co oznacza, że ​​urząd certyfikacji działa jako zaufana strona trzecia. CA przetwarza żądania od osób lub organizacji żądających certyfikatów (zwanych subskrybentami), weryfikuje informacje i potencjalnie podpisuje certyfikat jednostki końcowej na podstawie tych informacji. Aby skutecznie pełnić tę rolę, urząd certyfikacji musi mieć co najmniej jeden powszechnie zaufany certyfikat główny lub certyfikat pośredniczący oraz odpowiednie klucze prywatne. Urzędy certyfikacji mogą osiągnąć to szerokie zaufanie, umieszczając swoje certyfikaty główne w popularnym oprogramowaniu lub uzyskując podpis krzyżowy od innego urzędu certyfikacji delegującego zaufanie. Inne urzędy certyfikacji cieszą się zaufaniem w stosunkowo niewielkiej społeczności, takiej jak firma, i są dystrybuowane przez inne mechanizmy, takie jak Zasady grupy systemu Windows .

Urzędy certyfikacji są również odpowiedzialne za utrzymywanie aktualnych informacji o unieważnieniach wydanych przez siebie certyfikatów, wskazując, czy certyfikaty są nadal ważne. Dostarczają te informacje za pośrednictwem protokołu OCSP ( Online Certificate Status Protocol ) i/lub list odwołania certyfikatów (CRL). Niektóre z większych urzędów certyfikacji na rynku to IdenTrust , DigiCert i Sectigo .

Programy root

Niektóre główne programy zawierają listę urzędów certyfikacji, które są domyślnie zaufane. Ułatwia to użytkownikom końcowym weryfikację certyfikatów, a osobom lub organizacjom, które żądają certyfikatów, łatwiej będzie wiedzieć, które urzędy certyfikacji mogą wydać certyfikat, który będzie powszechnie zaufany. Jest to szczególnie ważne w przypadku protokołu HTTPS, w którym operator witryny zazwyczaj chce uzyskać certyfikat, któremu ufają prawie wszyscy potencjalni odwiedzający jego witrynę.

Zasady i procesy używane przez dostawcę do decydowania, którym urzędom certyfikacji powinno ufać jego oprogramowanie, nazywane są programami root. Najbardziej wpływowe programy root to:

Przeglądarki inne niż Firefox zazwyczaj korzystają z funkcji systemu operacyjnego, aby zdecydować, które urzędy certyfikacji są zaufane. Na przykład Chrome w systemie Windows ufa urzędom certyfikacji zawartym w programie Microsoft Root, podczas gdy w systemie macOS lub iOS Chrome ufa urzędom certyfikacji w programie Apple Root. Edge i Safari również korzystają z odpowiednich magazynów zaufania systemu operacyjnego, ale każdy z nich jest dostępny tylko w jednym systemie operacyjnym. Firefox korzysta ze sklepu zaufania programu Mozilla Root na wszystkich platformach.

Mozilla Root Program działa publicznie, a jego lista certyfikatów jest częścią przeglądarki internetowej Firefox o otwartym kodzie źródłowym , więc jest szeroko stosowany poza Firefoksem. Na przykład, chociaż nie ma wspólnego programu rootowania Linuksa, wiele dystrybucji Linuksa, takich jak Debian, zawiera pakiet, który okresowo kopiuje zawartość listy zaufania Firefoksa, która jest następnie używana przez aplikacje.

Programy root zazwyczaj zapewniają szereg ważnych celów wraz z zawartymi w nich certyfikatami. Na przykład niektóre urzędy certyfikacji mogą być uważane za zaufane w przypadku wydawania certyfikatów serwera TLS, ale nie w przypadku certyfikatów podpisywania kodu. Wskazuje na to zestaw bitów zaufania w systemie przechowywania certyfikatów głównych.

Certyfikaty i bezpieczeństwo witryny

Najczęstszym zastosowaniem certyfikatów są witryny internetowe oparte na protokole HTTPS . Przeglądarka internetowa sprawdza, czy serwer sieciowy HTTPS jest autentyczny, dzięki czemu użytkownik może czuć się bezpiecznie, że jego interakcja ze stroną internetową nie jest podsłuchiwana i że strona internetowa jest tym, za kogo się podaje. To zabezpieczenie jest ważne dla handlu elektronicznego . W praktyce operator witryny internetowej uzyskuje certyfikat, składając wniosek do urzędu certyfikacji z żądaniem podpisania certyfikatu . Żądanie certyfikatu to dokument elektroniczny, który zawiera nazwę strony internetowej, informacje o firmie oraz klucz publiczny. Dostawca certyfikatu podpisuje żądanie, tworząc w ten sposób certyfikat publiczny. Podczas przeglądania sieci ten certyfikat publiczny jest podawany do dowolnej przeglądarki internetowej, która łączy się z witryną internetową i udowadnia przeglądarce, że dostawca uważa, że ​​wystawił certyfikat właścicielowi witryny internetowej.

Na przykład, gdy użytkownik łączy się https://www.example.com/ze swoją przeglądarką, a przeglądarka nie wyświetla żadnego komunikatu ostrzegawczego dotyczącego certyfikatu, użytkownik może być teoretycznie pewien, że interakcja z https://www.example.com/jest równoznaczna z interakcją z podmiotem w kontakcie z adresem e-mail wymienionym w rejestratora publicznego pod adresem „example.com”, mimo że ten adres e-mail może nie być wyświetlany w żadnym miejscu witryny. Żadna inna gwarancja nie jest dorozumiana. Ponadto relacje między nabywcą certyfikatu, operatorem witryny internetowej a generatorem treści witryny internetowej mogą być wątłe i nie są gwarantowane. W najlepszym razie certyfikat gwarantuje unikalność witryny internetowej, pod warunkiem, że sama witryna nie została naruszona (zhakowana) lub proces wydawania certyfikatu został zniweczony.

Dostawca certyfikatów może zdecydować się na wydanie trzech rodzajów certyfikatów, z których każdy wymaga innego stopnia rygoru weryfikacji. W celu zwiększenia rygorów (i oczywiście kosztów) są to: Walidacja domeny, Walidacja organizacji i Walidacja rozszerzona. Te rygory są luźno uzgadniane przez dobrowolnych uczestników forum CA/Browser .

Poziomy walidacji

Walidacja domeny

Dostawca certyfikatu wyda nabywcy certyfikat z walidacją domeny (DV), jeśli nabywca może wykazać jedno kryterium weryfikacji: prawo do administracyjnego zarządzania dotkniętymi domenami DNS.

Walidacja organizacji

Dostawca certyfikatu wyda nabywcy certyfikat klasy walidacji organizacji (OV), jeśli nabywca może spełnić dwa kryteria: prawo do administracyjnego zarządzania daną nazwą domeny i być może faktyczne istnienie organizacji jako osoby prawnej. Dostawca certyfikatu publikuje swoje kryteria weryfikacji OV w swojej polityce certyfikacji .

Rozszerzona walidacja

Aby uzyskać certyfikat Extended Validation (EV), nabywca musi przekonać dostawcę certyfikatu o jego tożsamości prawnej, w tym ręczną weryfikację przez człowieka. Podobnie jak w przypadku certyfikatów OV, dostawca certyfikatu publikuje kryteria weryfikacji pojazdów elektrycznych w ramach swojej polityki certyfikacji .

Do 2019 r. główne przeglądarki, takie jak Chrome i Firefox, zazwyczaj oferowały użytkownikom wizualne wskazanie tożsamości prawnej, gdy witryna przedstawiała certyfikat EV. Dokonano tego poprzez pokazanie legalnej nazwy przed domeną i jasnozielonego koloru, aby podkreślić zmianę. Większość przeglądarek wycofała tę funkcję, nie zapewniając użytkownikowi wizualnej różnicy w rodzaju używanego certyfikatu. Zmiana ta była następstwem obaw o bezpieczeństwo zgłaszanych przez ekspertów medycyny sądowej i udanych prób zakupu certyfikatów EV w celu podszywania się pod znane organizacje, co dowodzi nieskuteczności tych wskaźników wizualnych i wskazuje na potencjalne nadużycia.

Słabości

Przeglądarka internetowa nie wyświetli żadnego ostrzeżenia, jeśli witryna nagle przedstawi inny certyfikat, nawet jeśli ten certyfikat ma mniejszą liczbę bitów klucza, nawet jeśli ma innego dostawcę, a poprzedni certyfikat miał datę wygaśnięcia daleko w przyszłość. Tam, gdzie dostawcy certyfikatów podlegają jurysdykcji rządów, rządy te mogą mieć swobodę nakazania dostawcy wygenerowania dowolnego certyfikatu, na przykład do celów egzekwowania prawa. Zależni dostawcy certyfikatów hurtowych mają również swobodę generowania dowolnego certyfikatu.

Wszystkie przeglądarki internetowe mają wbudowaną obszerną listę zaufanych certyfikatów głównych , z których wiele jest kontrolowanych przez organizacje, które mogą być nieznane użytkownikowi. Każda z tych organizacji może wydać dowolny certyfikat dla dowolnej witryny internetowej i mieć gwarancję, że przeglądarki internetowe zawierające jej certyfikaty główne zaakceptują go jako autentyczny. W takim przypadku użytkownicy końcowi muszą polegać na twórcy oprogramowania przeglądarki, aby zarządzać jego wbudowaną listą certyfikatów, oraz na dostawcach certyfikatów, aby zachowywali się prawidłowo i informowali programistę przeglądarki o problematycznych certyfikatach. Chociaż rzadko zdarzały się przypadki, w których wydano fałszywe certyfikaty: w niektórych przypadkach przeglądarki wykryły oszustwo; w innych minęło trochę czasu, zanim twórcy przeglądarek usunęli te certyfikaty ze swojego oprogramowania.

Lista wbudowanych certyfikatów również nie ogranicza się do tych dostarczonych przez programistę przeglądarki: użytkownicy (i do pewnego stopnia aplikacje) mogą dowolnie rozszerzać listę do specjalnych celów, takich jak firmowy intranet. Oznacza to, że jeśli ktoś uzyska dostęp do komputera i może zainstalować nowy certyfikat główny w przeglądarce, ta przeglądarka rozpozna strony internetowe korzystające z wstawionego certyfikatu jako legalne.

Aby zapewnić możliwe do udowodnienia bezpieczeństwo , to poleganie na czymś zewnętrznym względem systemu powoduje, że każdy schemat certyfikacji klucza publicznego musi opierać się na pewnym specjalnym założeniu konfiguracji, takim jak istnienie urzędu certyfikacji .

Przydatność a niezabezpieczone strony internetowe

Pomimo ograniczeń opisanych powyżej, protokół TLS uwierzytelniany certyfikatem jest uważany za obowiązkowy we wszystkich wytycznych dotyczących bezpieczeństwa, gdy witryna internetowa przechowuje informacje poufne lub przeprowadza istotne transakcje. Dzieje się tak, ponieważ w praktyce, pomimo opisanych powyżej słabości , witryny internetowe zabezpieczone certyfikatami klucza publicznego są nadal bezpieczniejsze niż niezabezpieczone witryny http:// .

Normy

Wydział Bezpieczeństwa Komputerowego Narodowego Instytutu Standardów i Technologii ( NIST ) udostępnia dokumenty zawierające wytyczne dotyczące certyfikatów klucza publicznego:

  • SP 800-32 Wprowadzenie do technologii klucza publicznego i federalnej infrastruktury PKI
  • SP 800-25 Agencja Federalna Wykorzystanie technologii klucza publicznego do podpisów cyfrowych i uwierzytelniania

Zobacz też

Bibliografia