Do czego służy certyfikat SSL i jakie są wymagania techniczne do jego instalacji?

Certyfikat SSL służy do szyfrowania połączenia między przeglądarką użytkownika a serwerem, zapobiegając przechwyceniu wrażliwych danych, takich jak hasła czy numery kart płatniczych. Do jego instalacji wymagany jest dostęp administracyjny do serwera WWW, wygenerowanie żądania CSR (Certificate Signing Request) oraz prawidłowa konfiguracja rekordów DNS przypisanych do domeny.

Bezpieczeństwo przesyłu informacji w internecie opiera się na kryptografii. Protokół HTTPS, który widzisz w pasku adresu, to po prostu stary protokół HTTP obudowany warstwą szyfrującą TLS. Certyfikat bezpieczeństwa działa jak cyfrowy dowód tożsamości. Weryfikuje on, czy serwer, z którym się łączysz, faktycznie należy do właściciela danej nazwy domenowej. Użytkownicy wpisują adres strony. Przeglądarka prosi serwer o przedstawienie certyfikatu. Serwer wysyła swój klucz publiczny. A to z kolei pozwala na nawiązanie bezpiecznego tunelu wymiany informacji. Zmieniliśmy te zasady na robocie lata temu, przechodząc z nieszyfrowanego ruchu na standard wymuszający szyfrowanie absolutnie każdej paczki danych. To po prostu wymóg techniczny. Kropka.

Wdrożenie takiego rozwiązania narzuca konkretne ramy działania na administratorów. Nie da się tego zrobić bez odpowiednich uprawnień. Musisz mieć kontrolę nad maszyną hostującą kod strony. Wymagane jest środowisko zdolne do obsługi szyfrowania asymetrycznego. Potrzebujesz serwera WWW, na przykład Nginx, Apache lub LiteSpeed. Zależności jest wiele. Ale omijając żargon, sprowadza się to do wygenerowania pary kluczy kryptograficznych i wgrania ich w odpowiednie katalogi na serwerze.

Jak dokładnie działa szyfrowanie danych na stronie internetowej?

Mechanika stojąca za SSL opiera się na kryptografii asymetrycznej podczas nawiązywania połączenia i symetrycznej podczas samego przesyłu danych. Użycie dwóch różnych kluczy na starcie rozwiązuje problem bezpiecznego przekazania hasła do szyfrowania właściwego. Serwer posiada klucz prywatny. Nikomu go nie udostępnia. Przeglądarka pobiera klucz publiczny. Używa go do zaszyfrowania wygenerowanego przez siebie klucza sesji. Ten klucz sesji jest następnie wysyłany do serwera. Tylko klucz prywatny serwera potrafi go odszyfrować. Brzmi to skomplikowanie. W praktyce cały ten proces, nazywany uściskiem dłoni (handshake), trwa ułamki sekund.

Wykorzystujemy obecnie protokół TLS w wersji 1.3. Starsze wersje, w tym sam oryginalny SSL z lat dziewięćdziesiątych, są dawno wycofane z użytku z powodu luk bezpieczeństwa. Używamy nazwy SSL wyłącznie z przyzwyczajenia. Poprawna technicznie terminologia to certyfikat TLS. Nowy standard TLS 1.3 drastycznie skraca czas nawiązywania połączenia. Odrzuca przestarzałe algorytmy szyfrujące. Wymusza mechanizm Perfect Forward Secrecy. Gwarantuje on, że nawet jeśli ktoś w przyszłości ukradnie klucz prywatny serwera, nie będzie w stanie odszyfrować historycznego ruchu sieciowego przechwyconego miesiące wcześniej. To twarda matematyka. Nie ma tu miejsca na domysły.

Szyfrowanie asymetryczne pochłania sporo zasobów procesora. Dlatego stosujemy je tylko na etapie wymiany klucza sesyjnego. Potem obie strony przechodzą na znacznie szybsze szyfrowanie symetryczne, używając tego samego klucza do kodowania i dekodowania paczek TCP/IP. W zdecydowanej większości przypadków obciążenie serwera z tytułu obsługi HTTPS jest dzisiaj niezauważalne dla użytkownika końcowego.

Dlaczego przeglądarki blokują strony bez kłódki?

Zastanawiacie się zresztą, dlaczego od kilku lat wejście na starą stronę HTTP kończy się wielkim czerwonym ekranem z ostrzeżeniem. Google, Mozilla i Apple podjęły wspólną, radykalną decyzję o wymuszeniu szyfrowania w całym internecie. Wynika to z faktu, że nieszyfrowany ruch tekstowy pozwala każdemu węzłowi sieciowemu po drodze na odczytanie całej zawartości transmisji. Twój dostawca internetu, właściciel kawiarni udostępniający publiczne Wi-Fi, a nawet złośliwe oprogramowanie na routerze mogą podsłuchiwać przesyłane formularze logowania. Ostrzeżenia w przeglądarkach mają na celu uświadomienie użytkownikom, że ich dane są wysyłane otwartym tekstem.

Blokada strony bez certyfikatu to mechanizm ochronny. Przeglądarki takie jak Chrome weryfikują łańcuch zaufania. Sprawdzają, czy certyfikat został wystawiony przez zaufany urząd certyfikacji (Certificate Authority – CA). Weryfikują datę ważności. Sprawdzają, czy nazwa domeny w certyfikacie zgadza się z adresem w pasku. Jeśli którykolwiek z tych warunków nie jest spełniony, połączenie zostaje zerwane na poziomie protokołu, zanim strona w ogóle zacznie się ładować. Błąd. Użytkownik widzi komunikat `ERR_CERT_AUTHORITY_INVALID` lub podobny. Odstrasza to bez mała większość odwiedzających.

Jakie są bezwzględne wymagania techniczne do instalacji certyfikatu SSL?

Wymagania techniczne do instalacji certyfikatu SSL zależą w dużej mierze od architektury twojego hostingu. Nie zainstalujesz niczego, jeśli nie masz odpowiednich uprawnień dostępowych. W środowiskach współdzielonych robisz to przez graficzny panel zarządzania. Na serwerach VPS lub dedykowanych musisz skonfigurować wszystko samodzielnie z linii komend. Omijając ogólniki, musisz spełnić konkretne warunki brzegowe.

• Pełny dostęp do zarządzania strefą DNS domeny, by móc udowodnić urzędowi certyfikacji, że jesteś właścicielem adresu, najczęściej poprzez dodanie specjalnego rekordu TXT lub umieszczenie pliku weryfikacyjnego w głównym katalogu serwera WWW na czas trwania walidacji.
• Obsługa rozszerzenia SNI (Server Name Indication).
• Wygenerowany plik CSR oraz klucz prywatny.
• Wolny port 443 na zaporze sieciowej.

Zatrzymam się przy SNI. Kiedyś przypisywało się jeden adres IP do jednego certyfikatu SSL. To było drogie i całkowicie niepraktyczne rozwiązanie przy wyczerpującej się puli adresów IPv4. Rozszerzenie SNI pozwala serwerowi WWW sprawdzić, o jaką domenę pyta przeglądarka jeszcze przed rozpoczęciem procesu deszyfrowania. Dzięki temu na jednym adresie IP możemy hostować setki zaszyfrowanych stron internetowych. Każdy współczesny serwer (Nginx, Apache) wspiera SNI domyślnie.

Prawda jest zresztą absolutnie taka, że cała ta branża certyfikatów płatnych to dzisiaj trochę relikt przeszłości oparty na strachu. Kiedyś płaciło się setki złotych za zielony pasek w przeglądarce, a teraz przeglądarki i tak go ukrywają. Wciskają nam kity o prestiżu walidacji EV, podczas gdy zwykły użytkownik nawet nie wie, gdzie kliknąć żeby sprawdzić dane rejestrowe firmy. Let’s Encrypt zabił ten rynek z marżą i bardzo dobrze. Nie ma sensu przepłacać za coś, co z technicznego punktu widzenia realizuje dokładnie to samo uderzenie kryptograficzne w warstwie przesyłowej. Płacisz po prostu za wirtualną pieczątkę na pliku tekstowym.

Co to jest żądanie CSR i jak je wygenerować na serwerze?

Certificate Signing Request to zakodowany blok tekstu zawierający informacje o twojej domenie, nazwie firmy, lokalizacji oraz twój klucz publiczny. Generujesz go na własnym serwerze. Następnie wysyłasz ten tekst do urzędu certyfikacji. Urząd podpisuje go swoim kluczem prywatnym i odsyła ci gotowy certyfikat CRT. Nigdy, pod żadnym pozorem, nie wysyłasz nikomu swojego klucza prywatnego. Klucz prywatny nie opuszcza twojej maszyny.

W środowisku Linux proces ten wykonujemy za pomocą narzędzia OpenSSL. Wywołanie komendy z terminala tworzy od razu dwa pliki. Robimy to wpisując w konsolę następujące polecenie:

openssl req -new -newkey rsa:2048 -nodes -keyout nazwadomeny.key -out nazwadomeny.csr

System zapyta o kilka parametrów. Najważniejszy z nich to Common Name (CN). Tutaj wpisujesz dokładny adres domeny, którą chcesz zabezpieczyć. Jeśli wpiszesz `mojastrona.pl`, certyfikat nie zadziała dla `www.mojastrona.pl`, chyba że wykupisz wersję Wildcard lub podasz obie nazwy w atrybutach SAN (Subject Alternative Name). Po wygenerowaniu plików, kopiujesz zawartość pliku CSR i wklejasz ją w formularzu zamówienia u wybranego dostawcy SSL.

Jakie rodzaje walidacji (DV, OV, EV) wybrać dla konkretnego biznesu?

Na rynku funkcjonują zasadniczo trzy typy certyfikatów, różniące się wyłącznie procedurą weryfikacji właściciela domeny. Pod kątem siły szyfrowania nie różnią się absolutnie niczym. Darmowy certyfikat zabezpiecza dane dokładnie tym samym algorytmem AES-256 co najdroższy certyfikat bankowy.

Domain Validation (DV) to podstawowy typ. Urząd sprawdza tylko to, czy masz kontrolę nad domeną. Wysyła maila na adres [email protected] lub prosi o wrzucenie pliku na serwer FTP. Cały proces trwa kilkanaście sekund i jest w pełni zautomatyzowany. To rozwiązanie w zupełności pokrywa zapotrzebowanie ogromnej większości stron w internecie, blogów, małych i średnich sklepów internetowych.

Extended Validation (EV) to procedura wymagająca przesłania do urzędu dokumentów rejestrowych firmy, odpisów z KRS, a czasami nawet odbycia rozmowy telefonicznej z weryfikatorem. Trwa to od kilku dni do tygodnia. Kiedyś certyfikaty EV barwiły pasek adresu przeglądarki na zielono, wyświetlając obok kłódki pełną nazwę spółki. Obecnie producenci przeglądarek usunęli tę funkcję. Przesunęli informacje o firmie głęboko w ustawienia kłódki. Skutek jest taki, że konwersja w sklepach z certyfikatem EV wcale nie jest wyższa niż w tych z certyfikatem DV. Klienci po prostu widzą zamkniętą kłódkę i to im wystarcza do podjęcia decyzji o zakupie.

Czy darmowy certyfikat Let’s Encrypt wystarczy do sklepu internetowego?

Oczywiście. To mit, że do obsługi płatności potrzebujesz płatnego certyfikatu komercyjnego. Bramki płatności takie jak PayU, Przelewy24 czy Stripe przekierowują użytkownika na swoje własne, zabezpieczone serwery lub ładują formularze w bezpiecznych ramkach iframe. Twój serwer nie przetwarza bezpośrednio danych z kart kredytowych. Let’s Encrypt wydaje certyfikaty DV ważne przez 90 dni. Możesz je odnawiać automatycznie za pomocą skryptów cron na serwerze. Wdrażając to rozwiązanie zdejmujesz z siebie problem corocznego, ręcznego kupowania i podmieniania plików na hostingu.

Wdrażaliśmy w zeszłym miesiącu certyfikat dla małej hurtowni budowlanej na warszawskim Targówku. Serwer działał na przestarzałym Apache 2.2. Generowanie żądania CSR przeszło gładko po terminalu. Ale wgranie paczki od dostawcy komercyjnego wywaliło błąd niezgodności klucza prywatnego. Okazało się, że panel hostingowy podmieniał w locie znaki nowej linii w pliku PEM formatując go pod Windowsa. Zmarnowaliśmy na to diagnozowanie prawie cztery godziny. Czasem najprostsze wdrożenia potrafią zablokować produkcję przez zwykły błąd parsera tekstu na starym systemie. Let’s Encrypt z użyciem klienta Certbot pominąłby ten problem całkowicie, bo sam modyfikuje konfigurację demona bez ingerencji ludzkiej w schowku systemowym.

Najczęstsze błędy podczas wdrażania protokołu HTTPS w aplikacjach webowych

Sama instalacja certyfikatu na serwerze WWW to dopiero pierwsza faza wdrożenia. Prawdziwe problemy zaczynają się na poziomie aplikacji i kodu strony. Najbardziej uciążliwym zjawiskiem jest tak zwany Mixed Content (zawartość mieszana). Występuje on w sytuacji, gdy strona ładuje się poprawnie po bezpiecznym protokole HTTPS, ale jej zasoby pobierane są po starym, nieszyfrowanym HTTP.

Przeglądarki natychmiast reagują na takie zachowanie. Blokują skrypty JS, arkusze stylów CSS i obrazki ładowane bez szyfrowania. W rezultacie strona wygląda na całkowicie zepsutą. Rozjeżdża się układ graficzny. Kłódka w pasku adresu znika lub pojawia się na niej żółty trójkąt ostrzegawczy. By naprawić ten stan rzeczy, musisz zaktualizować wszystkie odnośniki w bazie danych. W systemie WordPress wykonujemy w tym celu zapytania SQL korzystając z narzędzi typu WP-CLI lub wtyczek do wyszukiwania i zamiany ciągów znaków. Zamieniamy `http://mojastrona.pl` na `https://mojastrona.pl` w tabelach postów i opcji.

Kolejnym powszechnym błędem jest pętla przekierowań (Redirect Loop). Zjawisko to występuje masowo przy konfiguracji chmury Cloudflare. Jeśli ustawisz w panelu Cloudflare tryb Flexible SSL, chmura łączy się z przeglądarką po HTTPS, ale ruch do twojego fizycznego serwera przesyła po HTTP. Jeśli twój serwer ma jednocześnie ustawione wymuszanie HTTPS w pliku .htaccess, odrzuca on żądanie HTTP i każe chmurze połączyć się po HTTPS. Chmura odbiera to polecenie i znowu uderza po HTTP. Pętla zamyka się uderzając o limit. I nagle klient dzwoni, że strona NIE DZIAŁA, bo przeglądarka wyświetla błąd zbyt wielu przekierowań. Rozwiązanie to zmiana trybu na Full lub Strict w panelu zewnętrznym.

Jak wymusić bezpieczne połączenie przez plik htaccess?

Zaraz po weryfikacji poprawności działania certyfikatu, musimy wymusić na serwerze, by każda próba wejścia na nieszyfrowaną wersję strony kończyła się bezwzględnym przekierowaniem 301 na wersję bezpieczną. W środowisku serwera Apache realizujemy to edytując plik .htaccess znajdujący się w głównym katalogu domeny. Dodajemy na samej górze następujące dyrektywy:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Te trzy linijki kodu sprawdzają, czy zmienna określająca stan protokołu jest wyłączona. Jeśli tak, serwer przepisuje cały adres URL podmieniając protokół i odsyła do przeglądarki kod błędu 301 oznaczający trwałe przeniesienie zasobu. Przekazuje to od razu moc SEO do nowej struktury linków u robota indeksującego Google.

Automatyzacja odnawiania certyfikatów i zarządzanie wygasaniem

Darmowe certyfikaty Let’s Encrypt wymusiły na administratorach zmianę podejścia do zarządzania cyklem życia kluczy kryptograficznych. Ważność ograniczona do 90 dni sprawia, że ręczne generowanie CSR i wgrywanie plików mija się z celem. Wdrożyliśmy w branży protokół ACME (Automated Certificate Management Environment).

Pozwala on na instalację na serwerze małego agenta, na przykład programu Certbot. Narzędzie to łączy się z urzędem certyfikacji, udowadnia własność domeny tworząc tymczasowy plik w katalogu `.well-known/acme-challenge`, pobiera nowy klucz publiczny i samodzielnie przeładowuje konfigurację serwera Nginx lub Apache. Dodajemy po prostu zadanie do systemowego harmonogramu cron, które uruchamia się dwa razy dziennie. Skrypt sprawdza, czy certyfikat wygasa w ciągu najbliższych 30 dni. Jeśli nie, kończy pracę. Jeśli tak, odnawia go w tle. Zapominamy o problemie wygasających kłódek.

Z płatnymi certyfikatami OV i EV automatyzacja jest znacznie trudniejsza z uwagi na konieczność ponownej weryfikacji danych rejestrowych firmy przez człowieka. To kolejny argument za przejściem na darmowe rozwiązania oparte na samej walidacji domeny, o ile polityka bezpieczeństwa korporacji sztywno nie narzuca innych wymogów u audytora zewnętrznego.

Przestańcie polegać na ręcznych przypomnieniach w kalendarzu. Skonfigurujcie odnawianie kluczy za pomocą skryptów w terminalu i zajmijcie się optymalizacją bazy danych. Szyfrowanie to standard, który ma po prostu działać w tle serwera bez waszej codziennej ingerencji. Sprawdźcie już teraz z poziomu konsoli, kiedy wygasają wasze usługi i napiszcie prosty skrypt w bashu do ich nadzorowania.

Bibliografia

1. Naukowa i Akademicka Sieć Komputerowa – https://nask.pl
2. Ministerstwo Cyfryzacji – https://www.gov.pl/web/cyfryzacja
3. Zespół Reagowania na Incydenty Bezpieczeństwa Komputerowego – https://cert.pl
4. Urząd Komunikacji Elektronicznej – https://uke.gov.pl
5. Wydawnictwo Naukowe PWN – https://pwn.pl