Certyfikat SSL/TLS — co daje, czego nie gwarantuje i jak uniknąć błędów odnowienia?

Potocznie mówi się „certyfikat SSL”, choć współczesne połączenia używają TLS. Certyfikat pomaga przeglądarce potwierdzić, z jaką nazwą domeny się łączy, oraz ustanowić szyfrowane połączenie. Nie dowodzi jednak, że firma jest uczciwa, strona nie ma luk ani dane będą właściwie przetwarzane po stronie serwera.

Krótka odpowiedź: certyfikat TLS umożliwia przeglądarce uwierzytelnienie domeny i szyfrowanie transmisji HTTPS. Musi być ważny, zaufany, obejmować używaną nazwę i mieć poprawny łańcuch. Darmowy certyfikat DV może zapewnić takie samo podstawowe szyfrowanie jak płatny DV; różnice dotyczą m.in. obsługi, automatyzacji i zakresu usługi. Najważniejsze są automatyczne odnowienie, monitoring, poprawny DNS oraz test wszystkich wariantów domeny.

Co chroni HTTPS?

Prawidłowe TLS pomaga chronić transmisję przed:

• podglądem treści po drodze;
• nieautoryzowaną zmianą odpowiedzi w sieci;
• podszyciem się pod domenę bez odpowiedniego certyfikatu i klucza;
• przechwyceniem danych formularza podczas przesyłania.

Ochrona dotyczy połączenia między klientem a punktem kończącym TLS. Jeśli używasz CDN lub reverse proxy, potrzebne jest także właściwe zabezpieczenie połączenia między proxy a serwerem źródłowym.

Czego certyfikat nie gwarantuje?

Kłódka nie dowodzi, że:

• oferta jest wiarygodna;
• właściciel domeny jest podmiotem, za który się podaje w treści;
• WordPress i wtyczki są bezpieczne;
• strona nie zawiera malware;
• hasła są dobrze przechowywane;
• firma prawidłowo chroni dane po ich odebraniu;
• backup działa;
• użytkownik trafił na zamierzoną domenę, a nie podobną nazwę oszusta.

Certyfikat DV zwykle potwierdza kontrolę nad domeną, nie rzetelność działalności.

Jak przeglądarka ocenia certyfikat?

Sprawdza m.in.:

• czy certyfikat pochodzi z zaufanego łańcucha;
• czy obecna data mieści się w okresie ważności;
• czy nazwa hosta znajduje się w Subject Alternative Name;
• czy podpisy i parametry są akceptowane;
• czy serwer przesyła potrzebne certyfikaty pośrednie;
• czy połączenie używa wspieranego protokołu i szyfrów.

Certyfikat dla example.pl nie musi automatycznie obejmować www.example.pl. Obie nazwy trzeba uwzględnić albo zastosować świadomie właściwy certyfikat wielonazwowy lub wildcard.

DV, OV i EV

Nie zakładaj, że wyższy typ automatycznie zabezpiecza kod lepiej. Szyfrowanie połączenia może używać tych samych nowoczesnych mechanizmów. Wybór zależy od wymagań organizacji, nie od obietnicy „lepszego SEO”.

Czy darmowy certyfikat wystarczy?

Let's Encrypt jest publicznym, zautomatyzowanym urzędem certyfikacji. Jego certyfikaty DV są powszechnie używane do HTTPS. Dla typowej strony firmowej automatycznie odnawiany certyfikat z zaufanego urzędu zwykle realizuje potrzebę szyfrowania transmisji.

Płatna usługa może oferować:

• wsparcie człowieka;
• dodatkową walidację organizacji;
• określone warunki umowne;
• zarządzanie większym środowiskiem;
• integrację z infrastrukturą firmy.

Płacenie nie zwalnia z odnowienia, monitoringu i poprawnej konfiguracji serwera.

Jak wystawiany jest certyfikat?

Urząd musi potwierdzić kontrolę nad nazwą. Let's Encrypt opisuje m.in.:

• HTTP-01 — specjalny plik jest udostępniany pod domeną przez HTTP;
• DNS-01 — specjalny TXT trafia do DNS;
• TLS-ALPN-01 — walidacja odbywa się przez TLS według właściwego protokołu.

W hostingu proces zwykle wykonuje panel albo klient ACME. Wybór metody wpływa na wymagane porty, DNS i możliwość wildcard.

Dlaczego automatyczne odnowienie nie działa?

Typowe mechanizmy błędu:

• domena przestała wskazywać właściwy serwer;
• port lub ścieżka walidacji jest blokowana;
• proxy/CDN przechwytuje wyzwanie;
• rekord CAA nie pozwala używanemu urzędowi;
• klient nie ma już dostępu do DNS;
• token API wygasł;
• zadanie cron nie działa;
• certyfikat obejmuje nieistniejącą już nazwę;
• limit urzędu został wykorzystany przez powtarzane próby;
• serwer odnowił plik, ale nie przeładował usługi.

Alert powinien wykrywać certyfikat widoczny z internetu, nie tylko sukces lokalnego zadania.

CAA i kontrola wystawiania

Rekord CAA pozwala ograniczyć urzędy certyfikacji uprawnione do wystawiania certyfikatów dla domeny. To zaawansowana warstwa, która wymaga inwentaryzacji wszystkich używanych urzędów i nazw.

Błędny CAA może zablokować legalne odnowienie. Brak CAA nie oznacza, że każdy może dowolnie wystawić certyfikat bez potwierdzenia kontroli nad domeną.

Certyfikat wildcard

Wildcard, np. *.example.pl, może obejmować wiele subdomen jednego poziomu, ale:

• nie obejmuje automatycznie domeny głównej example.pl;
• nie obejmuje głębszej nazwy a.b.example.pl;
• zwykle wymaga walidacji DNS;
• zwiększa zakres wpływu kompromitacji jednego klucza, jeśli ten sam klucz jest szeroko używany.

Nie wybieraj wildcard tylko dla wygody, jeśli potrzebujesz dwóch nazw.

Przekierowanie HTTP do HTTPS

Po poprawnym uruchomieniu HTTPS ustaw jedno stałe przekierowanie wszystkich wariantów do wersji kanonicznej. Najpierw potwierdź, że certyfikat działa dla adresu docelowego.

Nie używaj przekierowania jako sposobu ukrycia błędu certyfikatu — przeglądarka musi ustanowić TLS przed otrzymaniem odpowiedzi HTTP z przekierowaniem.

Mixed content

Strona HTTPS może odwoływać się do obrazu, skryptu lub fontu przez http://. Przeglądarka może taki zasób zablokować albo oznaczyć stronę jako nie w pełni bezpieczną.

Napraw źródłowe adresy w:

• bazie WordPressa;
• motywie i CSS;
• integracjach;
• ustawieniach CDN;
• osadzonych materiałach.

Nie polegaj wyłącznie na wtyczce zamieniającej adresy w locie.

HSTS — dopiero po pełnym teście

HSTS instruuje przeglądarkę, by używała HTTPS przez określony czas. Błędne wdrożenie, zwłaszcza z includeSubDomains lub preload, może zablokować dostęp do subdomen bez działającego TLS.

Przed włączeniem:

• zinwentaryzuj wszystkie subdomeny;
• uruchom na nich HTTPS;
• zacznij od krótkiego okresu;
• przygotuj plan odnowienia;
• rozumiej konsekwencje preload.

Kiedy unieważnić certyfikat?

Unieważnienie jest potrzebne m.in. po ujawnieniu klucza prywatnego albo przejęciu infrastruktury, które mogło pozwolić na nieautoryzowane użycie. Let's Encrypt opisuje procedury potwierdzenia kontroli oraz revocation.

Samo usunięcie certyfikatu z serwera nie unieważnia go. Po incydencie wygeneruj nowy klucz i sprawdź inne systemy, do których stary klucz trafił.

Monitoring certyfikatu

Sprawdzaj:

• termin ważności z odpowiednim wyprzedzeniem;
• domenę i www;
• krytyczne subdomeny;
• łańcuch zaufania;
• nazwę hosta;
• odpowiedź przez IPv4 i IPv6;
• origin za CDN;
• wynik ostatniego odnowienia;
• alert po błędzie ACME.

Nie czekaj na zgłoszenie użytkownika z ekranem ostrzegawczym.

Checklista TLS

• ☐ Certyfikat pochodzi z zaufanego urzędu.
• ☐ Obejmuje wszystkie używane nazwy.
• ☐ Łańcuch jest kompletny.
• ☐ Automatyczne odnowienie przeszło test.
• ☐ Certyfikat publiczny jest monitorowany.
• ☐ CAA jest zgodne z używanym urzędem.
• ☐ HTTP prowadzi jednym przekierowaniem do HTTPS.
• ☐ Nie ma mixed content.
• ☐ IPv4, IPv6, CDN i origin są sprawdzone.
• ☐ Klucz prywatny ma ograniczony dostęp.
• ☐ Istnieje procedura po ujawnieniu klucza.

Certyfikat jest procesem, nie jednorazową kłódką

Prawidłowe HTTPS wymaga zgodnego DNS, bezpiecznego klucza, kompletnej listy nazw, aktualnego serwera i działającego odnowienia. Największą wartość daje automatyzacja połączona z niezależnym monitoringiem — wtedy błąd jest wykrywany przed końcem ważności, a nie przez klienta próbującego otworzyć stronę.