Twoja strona ma kłódkę w przeglądarce, więc „już jest bezpieczna". To zdanie, które słyszymy najczęściej, i najbardziej mylące. Kłódka mówi tylko, że istnieje ważny certyfikat dla tej domeny: nic nie mówi o tym, jakie wersje protokołu akceptujesz, jakie szyfry negocjujesz, czy łańcuch jest kompletny ani kiedy wygasa. Dlatego narzędzia analityczne dają ocenę, od A+ do F, i dlatego dwie strony z kłódką mogą być na przeciwnych biegunach. Ten przewodnik wyjaśnia, co mierzy każda część tej oceny, jaka konfiguracja jest rozsądna w 2026 roku i jak sprawdzić swoją dwoma poleceniami.
Co ocenia nota TLS
Poważne narzędzia łączą siedem kontroli. Dwie pierwsze są eliminujące: jeśli zawiodą, ocena spada do F bez patrzenia na resztę.
- Ważny certyfikat: wystawiony przez uznany urząd, dla właściwej domeny, w okresie ważności.
- Kompletny łańcuch: certyfikat pośredni, który łączy Twój z urzędem głównym, jest wysyłany razem z nim.
- Wersje protokołu: jakie TLS akceptujesz, a jakie odrzucasz.
- Szyfry: jakie algorytmy oferujesz i w jakiej kolejności.
- Przekierowanie: czy HTTP prowadzi do HTTPS na całej stronie.
- HSTS: czy mówisz przeglądarce, żeby nigdy więcej nie używała HTTP.
- Znane podatności: niebezpieczna renegocjacja, kompresja, ataki z własnymi nazwami z poprzedniej dekady.
Wersje: tylko 1.2 i 1.3
TLS 1.0 i 1.1 są przestarzałe od 2020 roku i przeglądarki je odrzucają. Jeśli Twój serwer nadal je akceptuje, ocena spada, bo atakujący może zmusić starego klienta do ich użycia. TLS 1.2 to akceptowalne minimum; TLS 1.3 to obecny standard: mniej wymian przy łączeniu, obowiązkowe nowoczesne szyfry i brak niebezpiecznych opcji z wcześniejszych wersji. Poprawna konfiguracja dziś to akceptowanie 1.2 i 1.3 i niczego więcej. Jeśli używasz Vercela, Netlify, Cloudflare albo hostingu zarządzanego, tak już jest; jeśli administrujesz własnym nginxem albo load balancerem, sprawdź to.
Szyfry: co naprawdę się liczy
Szyfr określa, jak wymieniany jest klucz i jak chroniony jest ruch. Dwie rzeczy robią różnicę. Pierwsza to doskonała poufność w przód (szyfry zaczynające się od ECDHE): jeśli ktoś w przyszłości ukradnie Twój klucz prywatny, nie odszyfruje ruchu, który nagrał wcześniej. Druga to unikanie złamanych lub słabych algorytmów: RC4, 3DES, starych trybów CBC i czystej wymiany klucza RSA. Rozsądna lista dla TLS 1.2 sprowadza się do ECDHE z AES-GCM lub ChaCha20; w TLS 1.3 protokół i tak dopuszcza tylko nowoczesne szyfry, kolejny powód, żeby go włączyć.
Łańcuch certyfikatów: niewidoczny błąd
Twój certyfikat jest podpisany przez pośredni, a pośredni przez główny, który urządzenia już znają. Serwer musi wysłać Twój certyfikat i pośredni. Jeśli zapomnisz o pośrednim, Chrome na desktopie pobierze go sam i nie zobaczysz żadnego błędu; ale wiele telefonów, curl, boty AI i integracje płatnicze zawiodą z komunikatem „certyfikat niezaufany". To najczęstszy błąd na serwerach konfigurowanych ręcznie i najtrudniejszy do zauważenia, bo „u mnie działa". Sprawdź to tak:
openssl s_client -connect twojadomena.com:443 -servername twojadomena.com </dev/null 2>/dev/null | grep -E "s:|i:|Verify return"W łańcuchu muszą pojawić się co najmniej dwa certyfikaty, a weryfikacja musi zakończyć się Verify return code: 0 (ok).
Domena i nazwy alternatywne
Certyfikat musi obejmować dokładnie te nazwy, których używasz: twojadomena.com i www.twojadomena.com to dwie różne nazwy. Certyfikat tylko dla domeny głównej sprawia, że www zwraca błąd, i odwrotnie. Współczesne certyfikaty wymieniają kilka nazw w polu SAN, a wildcardy (*.twojadomena.com) obejmują subdomeny jednego poziomu. Sprawdź też zapomniane subdomeny: api, app, staging z wygasłymi certyfikatami to klasyka.
Wygaśnięcie: coraz krótsze
Certyfikaty Let's Encrypt trwają 90 dni, maksimum dopuszczane dziś przez przeglądarki to 398, a branża uzgodniła stopniowe obniżanie go do 47 dni w 2029 roku. Przekaz jest jasny: odnawianie musi być automatyczne. Platformy zarządzane robią to same; jeśli masz własny serwer, użyj klienta ACME z zaplanowanym odnawianiem i przede wszystkim zewnętrznego alertu, który ostrzeże Cię, gdy zostanie mniej niż 14 dni. Awaria przez wygasły certyfikat jest najgłupsza i najczęstsza.
Przekierowanie i HSTS
Cały ruch HTTP musi przekierowywać na HTTPS kodem 301, na wszystkich ścieżkach, nie tylko na stronie głównej. A gdy wszystko działa po HTTPS, nagłówek Strict-Transport-Security mówi przeglądarce, żeby nie próbowała HTTP przez wskazany czas, co likwiduje małą lukę pierwszego żądania. Z includeSubDomains i preload możesz dodać swoją domenę do listy, którą przeglądarki mają fabrycznie. To typowa różnica między A a A+. Jak to skonfigurować, w nagłówki bezpieczeństwa HTTP.
Treść mieszana
Szczegół, który nie wpływa na ocenę certyfikatu, ale wpływa na kłódkę: jeśli Twoja strona HTTPS ładuje obrazek, skrypt lub czcionkę po HTTP, przeglądarka to blokuje albo oznacza stronę jako niebezpieczną. Zwykle pochodzi to z URL-i skopiowanych ze starego szablonu. Poszukaj w źródle http:// i zmień na ścieżki względne lub HTTPS.
Jeśli jesteś na platformie zarządzanej
Vercel, Netlify, Cloudflare Pages, Railway czy Render wystawiają i odnawiają certyfikat, wymuszają nowoczesne wersje i wybierają bezpieczne szyfry. Nie musisz niczego z tego dotykać. Co pozostaje Twoje: dodanie HSTS, usunięcie treści mieszanej, przekierowanie domen alternatywnych i pilnowanie subdomen, które wskazują gdzie indziej.
Dlaczego to ważne poza oceną
Słaby TLS pozwala przechwytywać sesje w sieciach publicznych, a źle skonfigurowany certyfikat sprawia, że Twoja strona nie działa na urządzeniach, których nie widzisz. Operatorzy płatności wymagają co najmniej TLS 1.2 dla zgodności z PCI DSS. Google używa HTTPS jako sygnału rankingowego, a przeglądarki oznaczają jako „niebezpieczne" wszystko, co go nie ma. I bardziej przyziemnie: certyfikat wygasający w sobotni poranek to strona leżąca, dopóki ktoś nie zauważy.
Sprawdź to w trzydzieści sekund
curl -sIL http://twojadomena.com | grep -iE "^(HTTP|location|strict-transport)"
openssl s_client -connect twojadomena.com:443 -servername twojadomena.com -tls1_1 </dev/null 2>&1 | grep -iE "alert|error" | head -1Pierwsze musi pokazać 301 na https://, a potem nagłówek HSTS. Drugie próbuje połączyć się przez TLS 1.1 i musi zawieść: jeśli się połączy, akceptujesz przestarzałą wersję.
Scanaris sprawdza Twój TLS przy każdym skanie
Scanaris sprawdza wersje protokołu, szyfry, kompletny łańcuch, nazwy certyfikatu, dni do wygaśnięcia, przekierowanie i HSTS, a przed wygaśnięciem certyfikatu ostrzega Cię e-mailem. Każde znalezisko ma fix prompt z dokładną konfiguracją dla Twojego serwera lub platformy. To kontrole tylko do odczytu: łączy się z Twoją stroną tak samo, jak zrobiłaby to przeglądarka. Żeby zobaczyć wszystko, co sprawdza w trzydzieści sekund, przeczytaj jak w 5 minut sprawdzić, czy Twoja strona jest bezpieczna.
Często zadawane pytania
Jaka jest różnica między SSL a TLS?
SSL to stara nazwa protokołu, wycofana lata temu jako niebezpieczna. Dziś używa się TLS, ale ludzie nadal mówią „certyfikat SSL". W praktyce: gdy czytasz SSL, myśl TLS.
Czy potrzebuję płatnego certyfikatu?
Nie. Darmowe certyfikaty Let's Encrypt albo te wystawiane przez Twoją platformę szyfrują dokładnie tak samo. Płatne dodają walidację organizacji lub gwarancje, nie większe bezpieczeństwo połączenia.
Dlaczego dostaję B, skoro mój certyfikat jest ważny?
Zwykle dlatego, że akceptujesz TLS 1.0 lub 1.1, oferujesz słabe szyfry albo nie wysyłasz nagłówka HSTS. Certyfikat to tylko jedna z siedmiu sprawdzanych rzeczy.