Certyfikaty SSL – jak to wygląda od kuchni, czyli kto i kiedy podpisuje certyfikat

Ostatnio poopowiadałem jak działają certyfikaty od strony biznesowej. Teraz czas na techniczną część. Przeciętny użytkownik internetu w dzisiejszych czasach utożsamia certyfikat z zieloną kłódeczką w pasku adresu. Kłódeczka albo jest zielona i jest bezpiecznie, albo jest szara kłódeczka z jakimś trójkącikiem i nie jest bezpiecznie. Niewiele osób zastanawia się jak to tak naprawdę działa. Życie pokazało mi, że niezrozumienie tematu panuje nawet w środowiskach developerskich.

Klucz prywatny i klucz publiczny

Certyfikat składa się z części prywatnej (klucz prywatny). Ten plik musimy pilnować jak oka z głowie. Jeżeli ktoś go wykradnie będzie mógł się podszywać pod nas. Drugą częścią jest klucz publiczny. Ten możemy rozdawać na lewo i prawo jako naszą wizytówkę. Każdy chętny będzie mógł go pobrać przez przeglądarkę. Klucz prywatny tworzymy sami (nie wysyłamy go do wystawcy certyfikatu), natomiast klucz publiczny dostaniemy od wystawcy certyfikatu. Jedyne miejsce gdzie taki plik ma prawo być, to jest sam serwer. Strona będzie zaszyfrowana, tylko przy kombinacji klucza prywatnego i publicznego. Klucz prywatny tworzymy za pomocą polecenia openssl

openssl genrsa -out host.key 2048

W powyższym przykładzie, 2048 to długość klucza (2kB). Im dłuższy klucz tym bezpieczniejszy, ale za długi powoduje zbytnie obciążenie serwera i przeglądarki klienta. Wspomniana wartość jest optymalna. Możemy ustawić hasło do klucza prywatnego, ale będzie się to wiązało z podawaniem go przy każdym restarcie serwera www. Dlatego też się tego nie robi.

Zatem jak wystawca certyfikatu wystawia nam certyfikat – CSR?

Skoro nie możemy wysłać klucza prywatnego, to jak wystawca łączy nasz klucz prywatny z certyfikatem? Do tego celu służy CSR (Certificate Signing Request) – łączy on nasz klucz prywatny z danymi jakie mają się wyświetlać w certyfikacie (do podejrzenia w szczegółach certyfikatu).
Żeby wygenerować taki plik używamy polecenia

openssl req -new -key host.key -out host.csr

Następnie podajemy nasze dane. Musimy sprawdzić czy wszystkie dane są wprowadzone poprawnie. Jeżeli zauważymy literówkę już po podpisaniu, to cały proces niestety musimy zacząć od nowa. Taki plik dostarczamy do naszego wystawcy certyfikatu i czekamy na tzw. „podpisanie certyfikatu”. Powinniśmy sprawdzić jeszcze raz wprowadzone dane poleceniem:

openssl req -noout -text -in host.csr

Podpisanie certyfikatu

W następnej kolejności wystawca certyfikatu powinien podpisać nasz certyfikat. Ale jak to wygląda od strony technicznej? Otóż co nie powinno być zaskoczeniem, że nasz wystawca certyfikatu także posiada swój klucz prywatny i publiczny. I też kiedyś musiał wystawić CSR do podpisania przez RootCA. A sam RootCA podpisuje się sam 🙂 Ale dzięki temu, że przeglądarka ma RootCA zaimplementowany w samej sobie nie powoduje to błędów.

Wystawca certyfikatu za pomocą swojego klucza prywatnego i naszego CSR, generuje nam nasz certyfikat. Jest to tak pomyślane, że po tych operacjach nasza przeglądarka, znając tylko nasz klucz publiczny i klucz publiczny certyfikatu, którym został on podpisany jest w stanie sprawdzić jego poprawność. Taka magia kryptografii 🙂

Łańcuch certyfikatów

Jeżeli spojrzymy sobie na przykładową stronę https://mariusz.giat.pl i w przeglądarce klikniemy w kłódkę , rozwiniemy menu i wybierzemy więcej informacji ukaże nam się zakładka bezpieczeństwo.

Wybieramy „Wyświetl certyfikaty”

i zakładkę „Szczegóły”

Możemy tutaj zobaczyć tzw. łańcuch certyfikatu. Ponieważ przeglądarki znają zazwyczaj (choć nie koniecznie) tylko najwyższy poziom na serwerze, dobrze jest umieścić plik z łańcuchem, żeby serwer także podawał go użytkownikom. Co się stanie, jeżeli tego nie zrobimy? Może się okazać, że na jednych przeglądarkach strona będzie się wyświetlać bez błędów, a na innych pokaże błąd łańcucha certyfikatu. Od technicznej strony patrząc, taki plik to połączone wszystkie klucze publiczne od naszego certyfikatu po Root CA. Możemy go pobrać ze strony wystawcy certyfikatów.

Należy tutaj pamiętać, że klucz prywatny znamy tylko dla swojego certyfikatu. Dla zobrazowania całości przygotowałem powyższy proces

Mam nadzieję, że temat certyfikatów jest już trochę bardziej zrozumiały. Następnym razem pokażę Wam jak skonfigurować serwer webowy aby móc korzystać z certyfikatu.