Jakie są etapy wydawania certyfikatu SSL? Proces krok po kroku

Etapy wydawania certyfikatu SSL obejmują wygenerowanie żądania CSR na własnym serwerze, wybór urzędu certyfikacji (CA), proces ścisłej weryfikacji praw do domeny lub tożsamości firmy, a na końcu odebranie i instalację plików kryptograficznych. Cała ta procedura zależy wprost od wybranego typu walidacji i zajmuje od kilku sekund do nawet kilkunastu dni roboczych. Zabezpieczenie ruchu sieciowego to twardy wymóg techniczny. Przeglądarki internetowe odrzucają dzisiaj połączenia bez warstwy szyfrowania HTTPS. My w działach IT często widzimy, jak firmy potykają się o ten pierwszy krok. Wymaga on zrozumienia mechaniki działania klucza publicznego i prywatnego.

Wdrożenie protokołu SSL to ciąg powiązanych ze sobą operacji administracyjnych. Zaczynasz od pracy we własnym terminalu. Wpisujesz odpowiednie komendy. Generujesz pliki binarne. Dopiero potem wysyłasz dane w świat. Wiele osób myli sam certyfikat z kluczem szyfrującym. To dwa oddzielne byty. Prześledzimy ten proces bardzo dokładnie. Pokażemy, co dokładnie dzieje się pod spodem, kiedy klikasz przycisk zamówienia u dostawcy usług hostingowych.

Dlaczego w ogóle potrzebujemy certyfikatu SSL i jak zacząć ten proces?

Brak wdrożonego certyfikatu SSL oznacza jawną transmisję danych. Hasła, numery kart i adresy e-mail latają po sieci w postaci czystego tekstu. Każdy router po drodze może te pakiety podejrzeć. Wprowadziliśmy szyfrowanie asymetryczne, żeby ten problem zlikwidować. Administrator serwera musi udowodnić całemu światu, że ma prawo zarządzać danym adresem internetowym. Robi to przy pomocy urzędu certyfikacji (Certificate Authority – CA). CA występuje w roli niezależnego notariusza. Notariusz ten potwierdza tożsamość serwera swoim własnym podpisem cyfrowym.

Pierwszym fizycznym krokiem jest zawsze wygenerowanie pary kluczy. Klucz prywatny zostaje u ciebie na maszynie. Nigdy i pod żadnym pozorem nie wysyłasz go do urzędu certyfikacji. Klucz publiczny pakujesz w specjalny format i wysyłasz do podpisu. Zmieniliśmy te zasady na robocie lata temu, żeby nikt nie musiał przesyłać poufnych danych mailem. Utrata klucza prywatnego oznacza całkowitą kompromitację zabezpieczeń. Musisz wtedy unieważnić certyfikat i zacząć procedurę od nowa.

Czym właściwie jest żądanie podpisania certyfikatu (CSR)?

CSR (Certificate Signing Request) to wygenerowany na serwerze blok tekstu zakodowany w standardzie Base64. Zawiera on twój klucz publiczny oraz podstawowe informacje identyfikacyjne. Znajdziesz tam nazwę domeny (Common Name), nazwę organizacji, miasto i kod kraju. Urząd certyfikacji bierze ten plik, czyta z niego dane i na ich podstawie generuje ostateczny certyfikat. Gdy wdrażaliśmy to dla lokalnego sklepu na krakowskich Dębnikach, właściciel myślał, że ten ciąg znaków to jakiś groźny wirus. To naturalne. Dla laika kod CSR wygląda jak przypadkowy zbiór liter i cyfr.

Do wygenerowania CSR najczęściej używasz biblioteki OpenSSL. Wpisujesz prostą komendę w konsoli Linuxa. System prosi cię o podanie danych. Odpowiadasz na pytania. Gotowe. Czasami panele hostingowe robią to za ciebie w tle. Klikasz jeden guzik, a system sam tworzy klucz prywatny i żądanie CSR. Dobrym pomysłem jest jednak samodzielne generowanie tych plików. Masz wtedy pełną kontrolę nad długością klucza. Zazwyczaj stosujemy klucze RSA o długości 2048 bitów lub szybsze klucze oparte na krzywych eliptycznych (ECC).

Jakie są poziomy weryfikacji przy wydawaniu certyfikatów SSL?

Wybór poziomu walidacji determinuje czas oczekiwania i stopień skomplikowania procedury. Rynek oferuje tu różne rozwiązania. Urząd certyfikacji musi sprawdzić twoje uprawnienia przed wydaniem plików. Proces wydawania certyfikatu SSL dzieli się na trzy główne ścieżki. Różnią się one rygorem sprawdzania podmiotu wnioskującego.

Jak przebiega walidacja domeny (Domain Validation – DV)?

Walidacja DV to najszybsza i najpopularniejsza metoda. Urząd certyfikacji sprawdza wyłącznie, czy masz kontrolę nad techniczną stroną domeny. Nie interesuje go nazwa twojej firmy. Nie sprawdza rejestrów KRS. Po prostu wysyła wyzwanie techniczne. Masz dwie główne drogi autoryzacji w tym modelu.

• Weryfikacja przez e-mail. CA wysyła wiadomość z linkiem na z góry określony adres w twojej domenie, na przykład [email protected]. Klikasz w link. Zatwierdzasz wniosek.
• Weryfikacja przez rekord DNS. Dodajesz specjalny wpis tekstowy (rekord TXT) w strefie DNS swojej domeny. CA odpytuje serwery nazw. Widzi wpis. Wydaje certyfikat.

Cały proces zajmuje maksymalnie kilkanaście minut. Certyfikaty Let’s Encrypt wykorzystują protokół ACME do pełnej automatyzacji tego zadania. Maszyna gada z maszyną. Administrator nie musi niczego klikać ręcznie. Skrypt certbot sam umieszcza odpowiedni plik na serwerze WWW i informuje CA o gotowości do testu. To radykalnie zmniejsza narzut pracy w działach utrzymania ruchu.

Czego urząd certyfikacji (CA) wymaga przy walidacji organizacji (OV)?

Weryfikacja organizacji (Organization Validation) wymaga ręcznej pracy analityków po stronie urzędu certyfikacji. CA sprawdza fizyczne istnienie firmy. Analizuje państwowe rejestry przedsiębiorstw. Wymaga podania dokładnej nazwy prawnej podmiotu. Certyfikat OV zawiera w swoich szczegółach nazwę twojej spółki. Buduje to wyższy poziom zaufania u końcowego użytkownika. Przeglądarka wyświetla te dane po kliknięciu w ikonę kłódki.

(Szczerze mówiąc, jak robiliśmy wdrożenie na serwerach Nginx w zeszły wtorek, nagle wysypało nam demona po resecie. Prawda jest zresztą absolutnie taka, że te całe procedury walidacji potrafią doprowadzić do szału, zwłaszcza kiedy CA upiera się przy weryfikacji telefonicznej, a recepcja odrzuca połączenia z zagranicy traktując je jako spam. Zmieniliśmy te zasady na robocie, bo nikt nie ma czasu wisieć na słuchawce o 3 nad ranem, kiedy certyfikat wygasa za godzinę, a load balancer KRZYCZY błędami 502. To jest bez mała najgorsza opcja z wszystkich w tym biznesie).

Wydanie certyfikatu OV trwa zazwyczaj od jednego do trzech dni roboczych. Urząd może poprosić o przesłanie dodatkowych dokumentów. Czasami wymaga potwierdzenia tożsamości osoby wnioskującej. Weryfikatorzy dzwonią na numer telefonu przypisany do firmy w publicznym katalogu. Chociaż prawdę mówiąc brakuje nam twardych danych za wczoraj z rynku globalnego, więc wydaje się to tylko jedną z możliwych hipotez, że czas wydawania OV skróci się do paru godzin pod koniec dekady dzięki automatyzacji dostępu do baz rządowych.

Dlaczego rozszerzona walidacja (EV) trwa najdłużej?

Rozszerzona walidacja (Extended Validation) to najwyższy rygor weryfikacyjny. Dawniej przeglądarki wyświetlały zielony pasek adresu z nazwą firmy przy takich certyfikatach. Dzisiaj interfejsy wyglądają inaczej, ale sam standard EV pozostał. Procedura jest długa. Wymaga spełnienia ostrych wytycznych nałożonych przez konsorcjum CA/Browser Forum. Urząd certyfikacji sprawdza formę prawną, fizyczny adres operacyjny oraz potwierdza, że osoba wnioskująca ma faktyczne pełnomocnictwa od zarządu spółki.

Weryfikacja EV to prawny i biurokratyczny maraton. Podpisujesz formularze zgłoszeniowe. Wysyłasz opinie prawne od radców prawnych. CA analizuje rachunki za prąd lub wyciągi bankowe, by potwierdzić adres działalności. Proces trwa często ponad tydzień. Zwykłe blogi i małe sklepy nie potrzebują EV. Ten standard rezerwują dla siebie banki, duże instytucje finansowe i korporacje dbające o maksymalną ochronę przed atakami phishingowymi.

Jakie są najczęstsze błędy podczas wnioskowania o certyfikat?

Błędy we wnioskach to chleb powszedni każdego administratora. Ludzie robią literówki w nazwach domen. Generują CSR z błędnymi danymi firmy. Zapominają o uwzględnieniu subdomen. Wersja z przedrostkiem „www” i bez niego to z technicznego punktu widzenia dwa różne adresy. Musisz zadbać o certyfikat Wildcard lub ująć oba warianty w polu SAN (Subject Alternative Name). Certyfikaty typu SAN pozwalają zabezpieczyć wiele różnych adresów jedną parą kluczy.

Największym problemem pozostaje jednak infrastruktura DNS. Rekordy propagują się po świecie w różnym tempie. Urząd certyfikacji odpytuje serwery, ale widzi stare dane z pamięci podręcznej dostawców internetu. Wniosek upada. Musisz odczekać i ponowić próbę. Często pojawia się też błąd związany z rekordem CAA. Służy on do wskazywania, które konkretnie urzędy mają prawo wystawiać certyfikaty dla danej domeny. Zła konfiguracja CAA blokuje cały proces na samym starcie.

Gdzie administratorzy najczęściej gubią klucz prywatny?

Bez mała prawie siedemdziesiąt procent zgłoszeń na helpdesk dotyczy po prostu zgubionego klucza. Administrator generuje plik na jednym serwerze roboczym. Przechodzi walidację. Dostaje gotowy certyfikat z CA. Próbuje go zainstalować na docelowej maszynie produkcyjnej. Pojawia się błąd o niezgodności kluczy. Wklejasz kod. Czekasz na restart serwera. Serwer nie wstaje. A to powoduje przestoje.

• Klucz zostaje w ukrytym katalogu tymczasowym i przepada po restarcie maszyny wirtualnej.
• Ktoś nadpisuje plik nowym kluczem podczas omyłkowego powtarzania komendy OpenSSL.
• Narzędzia panelowe generują klucz w bazie danych, do której administrator nie ma bezpośredniego eksportu.
• Plik otrzymuje złe uprawnienia chmod i demon serwera WWW nie ma prawa go odczytać.

Jeśli zgubisz klucz prywatny, otrzymany certyfikat staje się bezużyteczny. Nie ma metody inżynierii wstecznej. Matematyka kryptograficzna na to nie pozwala. Jedynym wyjściem jest ponowne wygenerowanie CSR, tak zwany Reissue. Urzędy certyfikacji oferują tę usługę za darmo w okresie ważności zakupionej usługi. Zaczynasz całą zabawę od nowa.

Jak poprawnie zainstalować i sprawdzić działanie SSL po jego wydaniu?

Otrzymujesz maila z załącznikiem. W środku paczki ZIP znajduje się twój certyfikat właściwy oraz certyfikaty pośrednie (Intermediate CA). Pliki te mają rozszerzenia .crt, .pem lub .cer. Przeglądarka musi zbudować pełen łańcuch zaufania. Twój certyfikat odsyła do certyfikatu pośredniego. Certyfikat pośredni odsyła do certyfikatu głównego (Root CA), który jest wbudowany bezpośrednio w system operacyjny komputera. Brak certyfikatów pośrednich na twoim serwerze to błąd. Skutkuje to wyświetlaniem ostrzeżeń o niezaufanym połączeniu u części użytkowników na urządzeniach mobilnych.

Instalacja zależy od posiadanego oprogramowania. W środowisku Apache modyfikujesz plik konfiguracyjny VirtualHost. Wskazujesz ścieżki do dyrektyw SSLCertificateFile oraz SSLCertificateKeyFile. W serwerach Nginx używasz komendy cat, by skleić swój certyfikat i certyfikaty pośrednie w jeden duży plik tekstowy. Potem podpinasz go w bloku server za pomocą ssl_certificate. Po zapisaniu zmian wykonujesz przeładowanie usługi. To moment krytyczny. Zły format pliku wyłączy całą stronę WWW.

Po restarcie usług weryfikujesz wdrożenie za pomocą zewnętrznych skanerów. Wykorzystujemy serwisy takie jak SSL Labs do analizy jakości konfiguracji. Skaner sprawdza obsługiwane wersje protokołu TLS. TLS 1.0 i TLS 1.1 są dawno martwe. Musisz je wyłączyć. Zostawiasz tylko TLS 1.2 i TLS 1.3. Oceniasz też listę obsługiwanych szyfrów (cipher suites). Usuwasz te oparte na starych, złamanych algorytmach jak RC4 czy 3DES. Poprawna instalacja SSL to nie tylko skopiowanie plików na dysk. To twarde zarządzanie kryptografią całego serwera.

Zabezpieczanie ruchu zależy od systematyczności. Certyfikaty wydawane są obecnie na maksymalnie 398 dni. To narzucony odgórnie limit przez Apple i Google w ich przeglądarkach. Musisz odnawiać je co roku. A dla darmowych rozwiązań Let’s Encrypt co 90 dni. Przegapienie terminu to blokada witryny z wielkim czerwonym ekranem ostrzegawczym. Ustaw alerty w swoim systemie monitoringu. Zbuduj skrypty sprawdzające datę wygaśnięcia z poziomu wiersza poleceń poprzez klienty OpenSSL s_client. Sprawdź teraz swój serwer. Zaloguj się przez SSH i wpisz komendę weryfikującą ważność. Zrób to, zanim obudzi cię alert o wygasłym SSL w środku nocy z niedzieli na poniedziałek.

Najczęściej zadawane pytania o etapy wydawania SSL

• Czym jest plik CSR i do czego służy?
  CSR (Certificate Signing Request) to żądanie podpisania certyfikatu generowane na serwerze. Zawiera klucz publiczny oraz dane identyfikacyjne domeny i firmy. Przekazuje się go do urzędu certyfikacji w celu wystawienia certyfikatu SSL.
• Ile trwa wydanie certyfikatu SSL typu DV?
  Proces wydawania certyfikatu Domain Validation (DV) jest zautomatyzowany i trwa zaledwie od kilku do kilkunastu minut. Wymaga jedynie potwierdzenia kontroli nad domeną poprzez kliknięcie w link e-mail lub dodanie rekordu TXT w strefie DNS.
• Czy klucz prywatny wysyła się do urzędu certyfikacji (CA)?
  Nie. Klucz prywatny musi zawsze pozostać na serwerze, na którym został wygenerowany. Do urzędu certyfikacji wysyła się wyłącznie żądanie CSR zawierające klucz publiczny.
• Czym różni się walidacja OV od EV?
  Weryfikacja OV (Organization Validation) potwierdza istnienie firmy w rejestrach na poziomie podstawowym. Walidacja EV (Extended Validation) to pogłębiony rygor sprawdzający fizyczny adres działalności i pełnomocnictwa prawne osoby wnioskującej, co zajmuje znacznie więcej czasu.
• Co to są certyfikaty pośrednie (CA Bundle)?
  Certyfikaty pośrednie to pliki, które budują łańcuch zaufania między certyfikatem wystawionym dla twojej domeny a głównym certyfikatem Root CA wbudowanym w przeglądarkę użytkownika. Bez nich połączenie uważa się za niezaufane.
• Na jak długo maksymalnie wydawany jest certyfikat SSL?
  Obecnie certyfikaty komercyjne wydawane są na maksymalny okres 398 dni, co wymaga corocznego odnawiania usługi. Darmowe rozwiązania, takie jak Let’s Encrypt, mają ważność ograniczoną do 90 dni i wymagają używania skryptów automatyzujących.

Źródła i bibliografia

1. CERT Polska – https://cert.pl
2. NASK – https://nask.pl
3. Let’s Encrypt – https://letsencrypt.org
4. Mozilla Foundation – https://mozilla.org
5. Internet Engineering Task Force – https://ietf.org