Ilekroć próbuję zrozumieć cokolwiek na temat SSL, zawsze mam trudności z ustaleniem, do czego odnoszą się „klucz” i „certyfikat”. Obawiam się, że wiele osób używa ich nieprawidłowo lub zamiennie. Czy istnieje standardowa różnica między kluczem a certyfikatem?
Odpowiedzi:
Certyfikat zawiera klucz publiczny.
Certyfikat, oprócz tego, że zawiera klucz publiczny, zawiera dodatkowe informacje, takie jak wystawca, przeznaczenie certyfikatu i inne typy metadanych.
Zazwyczaj sam certyfikat jest podpisywany przez urząd certyfikacji (CA) przy użyciu klucza prywatnego urzędu certyfikacji. To weryfikuje autentyczność certyfikatu.
opensslPolecenie może dekodować i parsuj je lub możesz użyć narzędzia online, takiego jak to: lapo.it/asn1js
Powiedzmy, że firma A ma parę kluczy i musi opublikować swój klucz publiczny do publicznego użytku (aka ssl na swojej stronie internetowej).
Tak więc klucz publiczny firmy A podpisany prawidłowym kluczem prywatnym urzędu certyfikacji nazywa się certyfikatem firmy A.
Pozwól mi wyjaśnić przykładem.
W zwykłej PKI opartej na parach kluczy istnieje klucz prywatny i klucz publiczny.
W systemie opartym na certyfikatach istnieje klucz prywatny i certyfikat. Certyfikat zawiera więcej informacji niż klucz publiczny.
Demo (Możesz wygenerować certyfikat i klucz prywatny): http://www.selfsignedcertificate.com/
Możesz pobrać otwórz plik klucza prywatnego i plik certyfikatu, zobaczysz, że plik certyfikatu zawiera wiele informacji, jak pokazano poniżej.
Możesz dopasować wygenerowany certyfikat (otwieranie przez edytor tekstowy) i klucz prywatny (otwieranie przez edytor tekstowy) z tej strony: https://www.sslshopper.com/certificate-key-matcher.html
Jeśli certyfikat jest zgodny z kluczem prywatnym klienta, klient jest pewien, że certyfikat ten jest nadawany przez klienta lub przez zaufanego agenta klienta (CA).
Występują jednak problemy tylko z komunikacją opartą na kluczu prywatnym i certyfikacie .
Ponieważ każdy może wygenerować własny certyfikat i klucz prywatny, więc prosty uścisk dłoni nie dowodzi niczego o serwerze poza tym, że serwer zna klucz prywatny pasujący do klucza publicznego certyfikatu. Jednym ze sposobów rozwiązania tego problemu jest posiadanie przez klienta zestawu co najmniej jednego certyfikatu, któremu ufa. Jeśli certyfikatu nie ma w zestawie, serwerowi nie można ufać .
To proste podejście ma kilka wad. Z czasem serwery powinny mieć możliwość aktualizacji do silniejszych kluczy („rotacja kluczy”), która zastępuje klucz publiczny w certyfikacie nowym. Niestety, teraz aplikacja kliencka musi zostać zaktualizowana z powodu zmiany konfiguracji serwera. Jest to szczególnie problematyczne, jeśli serwer nie znajduje się pod kontrolą dewelopera aplikacji, na przykład, jeśli jest to usługa internetowa innej firmy. Takie podejście ma również problemy, jeśli aplikacja musi rozmawiać z dowolnymi serwerami, takimi jak przeglądarka internetowa lub aplikacja e-mail.
Aby zaradzić tym wadom, serwery są zwykle konfigurowane za pomocą certyfikatów od znanych wydawców zwanych urzędami certyfikacji. Platforma hosta (klient) zazwyczaj zawiera listę dobrze znanych urzędów certyfikacji, którym ufa. Podobnie jak serwer, urząd certyfikacji ma certyfikat i klucz prywatny. Wydając certyfikat dla serwera, urząd certyfikacji podpisuje certyfikat serwera za pomocą swojego klucza prywatnego. Klient może następnie sprawdzić, czy serwer ma certyfikat wydany przez urząd certyfikacji znany platformie.
Jednak podczas rozwiązywania niektórych problemów korzystanie z urzędów certyfikacji wprowadza inne. Ponieważ urząd certyfikacji wystawia certyfikaty dla wielu serwerów, nadal potrzebujesz sposobu, aby upewnić się, że rozmawiasz z wybranym serwerem. Aby rozwiązać ten problem, certyfikat wydany przez urząd certyfikacji identyfikuje serwer za pomocą konkretnej nazwy, takiej jak gmail.com lub zestawu hostów z symbolami wieloznacznymi, takich jak * .google.com.
Poniższy przykład uczyni te pojęcia nieco bardziej konkretnymi. W poniższym fragmencie z wiersza polecenia polecenie s_client narzędzia openssl sprawdza informacje o certyfikacie serwera Wikipedii. Określa port 443, ponieważ jest to domyślny port HTTPS. Polecenie wysyła dane wyjściowe openssl s_client do openssl x509, który formatuje informacje o certyfikatach zgodnie ze standardem X.509. W szczególności polecenie pyta o podmiot, który zawiera informacje o nazwie serwera, oraz wystawcę, który identyfikuje urząd certyfikacji.
$ openssl s_client -connect wikipedia.org:443 | openssl x509 -noout -subject -issuer
subject= /serialNumber=sOrr2rKpMVP70Z6E9BT5reY008SJEdYv/C=US/O=*.wikipedia.org/OU=GT03314600/OU=See www.rapidssl.com/resources/cps (c)11/OU=Domain Control Validated - RapidSSL(R)/CN=*.wikipedia.org
issuer= /C=US/O=GeoTrust, Inc./CN=RapidSSL CA
Możesz zobaczyć, że certyfikat został wydany dla serwerów pasujących do * .wikipedia.org przez RapidSSL CA.
Jak widać, dzięki tym dodatkowym informacjom wysyłanym przez CA do serwerów, klient może łatwo wiedzieć, czy komunikuje się ze swoim serwerem, czy nie.
Certyfikat SSL jest uzyskiwany od zaufanego urzędu certyfikacji, który gwarantuje bezpieczne połączenie z witryną. Certyfikaty SSL zwykle zawierają logo uwierzytelniania, a także klucze publiczne niezbędne do szyfrowania i deszyfrowania danych, które mają zostać wysłane na komputer. Funkcje kluczy SSL
Podczas sesji można wygenerować kilka kluczy SSL . Służą do szyfrowania i deszyfrowania informacji przesyłanych do iz komputera. Klucze służą do sprawdzenia, czy informacje nie zostały zmodyfikowane lub zmienione.
Różnica cyklu życia
Certyfikaty trwają dłużej niż klucze SSL. Certyfikaty SSL są uzyskiwane od urzędu certyfikacji, który może być regularnie odnawiany przez banki i firmy. Z drugiej strony klucze SSL lub klucze sesji są generowane jednoznacznie podczas sesji i odrzucane po zakończeniu sesji.
OK, rozwiążmy to, aby ludzie nietechniczni mogli to zrozumieć.
Pomyśl o tym w ten sposób. Certyfikat jest jak sejf w twoim banku. Zawiera wiele ważnych rzeczy; ogólnie rzeczy, które zawierają twoją tożsamość. Certyfikat ma klucz publiczny i potrzebuje klucza prywatnego, aby go otworzyć.
Twoja skrytka depozytowa wymaga otwarcia dwóch kluczy, podobnie jak certyfikat.
W przypadku sejfu klucz bankiera jest podobny do klucza publicznego, ponieważ pozostaje w banku, a klucz publiczny pozostaje z certyfikatem. Masz klucz prywatny, który jest potrzebny do „zdobycia certyfikatu”, aw przykładzie skrytki depozytowej klucz prywatny jest potrzebny oprócz klucza publicznego.
Przed faktycznym otwarciem sejfu musisz najpierw zweryfikować swoją tożsamość (coś w rodzaju żądania certyfikatu); po zidentyfikowaniu, używasz klucza prywatnego wraz z kluczem publicznym, aby otworzyć swoją skrzynkę bezpieczeństwa. To trochę tak, jak wysłanie żądania certyfikatu, a następnie uzyskanie certyfikatu od urzędu certyfikacji (o ile można go zidentyfikować (zaufać) i masz odpowiedni klucz).