Ilekroć próbuję zrozumieć cokolwiek na temat SSL, zawsze mam problem ze zrozumieniem, do czego odnoszą się “klucz” i “certyfikat”. Obawiam się, że wiele osób używa ich niepoprawnie lub zamiennie. Czy istnieje jakaś standardowa różnica pomiędzy kluczem a certyfikatem?
Certyfikat zawiera klucz publiczny.
Certyfikat, poza kluczem publicznym, zawiera dodatkowe informacje, takie jak wystawca, do czego ma służyć certyfikat i inne rodzaje metadanych.
Zazwyczaj certyfikat jest podpisywany przez urząd certyfikacji (CA) przy użyciu klucza prywatnego CA. To weryfikuje autentyczność certyfikatu.
Te dwa obrazki razem wyjaśniły mi wszystko:
Źródło: linuxvoice
Źródło: infosecinstitute ](http://resources.infosecinstitute.com/ssl-dot-net-volume-1-hypothesis/)
Źródło: [ infosecinstitute ]0x3&
0x4&.
Załóżmy, że firma A ma parę kluczy [ (https://en.wikipedia.org/wiki/Public-key_cryptography) i potrzebuje opublikować swój klucz publiczny do użytku publicznego (np. ssl na swojej stronie internetowej).
Zatem klucz publiczny firmy A podpisany ważnym kluczem prywatnym CA jest nazywany certyfikatem firmy A.
Pozwól, że wyjaśnię to na przykładzie.
W normalnym PKI opartym na parze kluczy istnieją klucz prywatny i klucz publiczny.
W systemie opartym na certyfikatach mamy do czynienia z kluczem prywatnym i certyfikatem. Certyfikat zawiera więcej informacji niż klucz publiczny.
Demo (Można wygenerować certyfikat i klucz prywatny): http://www.selfsignedcertificate.com/
Możesz pobrać otwarty plik klucza prywatnego i plik certyfikatu, widzisz, że plik certyfikatu zawiera wiele informacji, jak pokazano poniżej.
Możesz dopasować swój wygenerowany certyfikat (otwierając go za pomocą edytora tekstu), oraz klucz prywatny (otwierając go za pomocą edytora tekstu) z tej strony: https://www.sslshopper.com/certificate-key-matcher.html
Jeśli certyfikat pasuje do klucza prywatnego klienta, klient jest pewien, że certyfikat jest wystawiony przez klienta lub przez zaufanego agenta klienta (CA).
Jednakże istnieją problemy w komunikacji opartej tylko na kluczu prywatnym i certyfikacie.
Ponieważ każdy może wygenerować swój własny certyfikat i klucz prywatny, więc zwykły handshake nie udowadnia niczego o serwerze poza tym, że serwer zna klucz prywatny, który pasuje do klucza publicznego certyfikatu. Jednym ze sposobów rozwiązania tego problemu jest posiadanie przez klienta zestawu jednego lub więcej certyfikatów, którym ufa. Jeśli certyfikat nie znajduje się w tym zestawie, serwer nie jest godny zaufania.
Jest kilka minusów tego prostego podejścia. Serwery powinny mieć możliwość aktualizacji kluczy do silniejszych z czasem (“key rotation”), co powoduje zastąpienie klucza publicznego w certyfikacie nowym. Niestety, teraz aplikacja kliencka musi być aktualizowana z powodu tego, co jest w zasadzie zmianą konfiguracji serwera. Jest to szczególnie problematyczne, jeśli serwer nie jest pod kontrolą twórcy aplikacji, na przykład jeśli jest to usługa sieciowa strony trzeciej. To podejście ma również problemy, jeśli aplikacja musi rozmawiać z arbitralnymi serwerami, takimi jak przeglądarka internetowa lub aplikacja poczty elektronicznej.
W celu rozwiązania tych problemów, serwery są zazwyczaj skonfigurowane z certyfikatami od dobrze znanych wystawców zwanych Certificate Authorities (CA). Podobnie jak serwer, CA posiada certyfikat i klucz prywatny. Podczas wystawiania certyfikatu dla serwera, CA podpisuje certyfikat serwera przy użyciu swojego klucza prywatnego. Klient może wtedy zweryfikować, czy serwer posiada certyfikat wydany przez CA znany platformie.
Jednak użycie CA rozwiązuje pewne problemy, ale wprowadza kolejne. Ponieważ CA wystawia certyfikaty dla wielu serwerów, nadal potrzebujesz jakiegoś sposobu, aby upewnić się, że rozmawiasz z tym serwerem, z którym chcesz. Aby rozwiązać ten problem, certyfikat wydany przez CA identyfikuje serwer albo za pomocą konkretnej nazwy, takiej jak gmail.com, albo za pomocą wieloznacznego zestawu hostów, np.
Poniższy przykład pozwoli nieco bardziej skonkretyzować te pojęcia. W poniższym fragmencie z wiersza poleceń polecenie sclient narzędzia openssl przegląda informacje o certyfikacie serwera Wikipedii. Podaje port 443, ponieważ jest to port domyślny dla HTTPS. Polecenie wysyła wynik działania openssl sclclient do openssl x509, który formatuje informacje o certyfikatach zgodnie ze standardem X.509. W szczególności, polecenie prosi o podanie tematu (subject), który zawiera informacje o nazwie serwera, oraz wystawcy (issuer), który identyfikuje CA.
$ 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
Widać, że certyfikat został wydany przez RapidSSL CA dla serwerów pasujących do adresu wikipedia.org.
Jak widać, dzięki tym dodatkowym informacjom wysyłanym przez CA do serwerów, klient może łatwo zorientować się, czy komunikuje się ze swoim serwerem, czy nie.
Certyfikat SSL** jest uzyskiwany od zaufanego Urzędu Certyfikacji, który ręczy za bezpieczne połączenie strony internetowej. Certyfikaty SSL zazwyczaj zawierają logo uwierzytelnienia, a także klucze publiczne niezbędne do szyfrowania i odszyfrowywania danych, które mają być przesyłane do komputera. Klucze SSL Funkcje
W trakcie sesji może zostać wygenerowanych kilka kluczy SSL. Służą one do szyfrowania i odszyfrowywania informacji przesyłanych do i z komputera. Klucze te służą do weryfikacji, czy informacje nie zostały zmodyfikowane lub naruszone.
Różnica w cyklu życia certyfikatów
Certyfikaty działają dłużej niż klucze SSL. Certyfikaty SSL są uzyskiwane od Urzędów Certyfikacji, które mogą być regularnie odnawiane przez banki i firmy. Klucze SSL lub klucze sesji są natomiast jednoznacznie generowane podczas sesji i wyrzucane po jej zakończeniu. Czytaj więcej tutaj
OK, rozbijmy to tak, aby osoby nietechniczne mogły to zrozumieć.
Pomyśl o tym w ten sposób. Certyfikat jest jak sejf w Twoim banku. Zawiera on wiele ważnych rzeczy; zazwyczaj rzeczy, które zawierają twoją tożsamość. Certyfikat ma klucz publiczny i potrzebuje klucza prywatnego, aby go otworzyć.
Twój sejf również wymaga dwóch kluczy do otwarcia, tak jak certyfikat.
W przypadku sejfu klucz bankiera jest jak klucz publiczny, ponieważ pozostaje w banku, a klucz publiczny pozostaje z certyfikatem. Ty masz klucz prywatny, który jest potrzebny do “zdobycia certyfikatu”, a w przykładzie sejfu oprócz klucza publicznego potrzebny jest także klucz prywatny.
Zanim będziesz mógł faktycznie otworzyć swój sejf, musisz najpierw zweryfikować swoją tożsamość (coś w rodzaju żądania certyfikatu); kiedy już zostaniesz zidentyfikowany, używasz swojego klucza prywatnego wraz z kluczem publicznym, aby otworzyć swój sejf. Jest to trochę jak składanie żądania certyfikatu, a następnie otrzymanie certyfikatu z urzędu certyfikacji (tak długo, jak możesz być zidentyfikowany (zaufany) i masz odpowiedni klucz).