Jakie przeglądarki i platformy wspierają certyfikaty SSL/TLS?

SSL i TLS (Transport Layer Security) to fundamentalne protokoły, które zapewniają szyfrowaną łączność między użytkownikiem a serwerem. Certyfikaty SSL/TLS są akceptowane przez ponad 99% ekosystemu internetowego i stanowią kluczowy filar zaufania online. Współczesny krajobraz zgodności obejmuje przeglądarki, systemy operacyjne, urządzenia mobilne, platformy chmurowe i serwery, choć zakres wsparcia dla poszczególnych wersji TLS zależy od wieku i typu urządzenia.

Treść (pokaż)

Wsparcie głównych przeglądarek internetowych dla certyfikatów SSL/TLS

Nowoczesne przeglądarki domyślnie egzekwują bezpieczne połączenia HTTPS oraz obsługują TLS 1.2 i TLS 1.3. W praktyce zapewnia to pełną kompatybilność z aktualnie wydawanymi certyfikatami oraz algorytmami ECDSA i RSA.

Dla najczęściej używanych przeglądarek zakres wsparcia prezentuje się następująco:

Przeglądarka	Silnik	TLS 1.2	TLS 1.3	Uwagi
Google Chrome	Chromium/Blink	Tak	Tak	pełna obsługa HTTPS, HSTS, CT
Mozilla Firefox	Gecko	Tak	Tak	wspiera EV, SAN i wildcard
Microsoft Edge	Chromium/Blink	Tak	Tak	ścisła zgodność ze standardami TLS
Apple Safari	WebKit	Tak	Tak	wczesna implementacja TLS 1.3 i ECDSA
Opera	Chromium/Blink	Tak	Tak	pełna obsługa współczesnych zestawów szyfrów

Mniej popularne przeglądarki (Konqueror, GNOME Web, SeaMonkey) oraz aplikacje na urządzeniach specjalistycznych (np. konsole, smart TV) również wspierają SSL/TLS, choć często z ograniczeniami wynikającymi z wieku oprogramowania.

Obsługa protokołów TLS w przeglądarkach – ewolucja wersji

Ewolucja TLS to konsekwentne usuwanie słabych wersji i podnoszenie poprzeczki bezpieczeństwa. SSL 2.0/3.0 oraz TLS 1.0/1.1 zostały zdeprecjonowane w głównych przeglądarkach i nie powinny być używane.

Poniższa tabela syntetyzuje status wersji protokołów:

Wersja	Status	Uwagi bezpieczeństwa
SSL 2.0 / SSL 3.0	Usunięte	podatności krytyczne (m.in. POODLE)
TLS 1.0 / TLS 1.1	Przestarzałe	wyłączone w Chrome/Edge/Firefox/Safari od 2020–2021
TLS 1.2	Standard	powszechnie wspierany; rekomendowane minimum
TLS 1.3	Nowoczesny	mniej rund RTT, uproszczony handshake, lepsza prywatność

Wsparcie TLS 1.3 zależy także od systemu i stosu kryptograficznego. Windows Server 2022 i nowsze macOS/iOS/Android wspierają TLS 1.3; Windows Server 2019 – nie. OpenSSL wspiera TLS 1.3 od wersji 1.1.1, a wcześniejsze wydania – nie.

Wsparcie systemów operacyjnych dla SSL/TLS

Systemy operacyjne dostarczają komponenty kryptograficzne (Schannel, Secure Transport, OpenSSL/GnuTLS), z których korzystają aplikacje. Windows 10/11, macOS i współczesne dystrybucje Linux domyślnie obsługują TLS 1.2 oraz TLS 1.3.

Syntetyczne porównanie wsparcia TLS 1.3 w popularnych stosach:

System / Stos	TLS 1.3	Notatki
Windows 11 / 10 (Schannel)	Tak	domyślnie włączone
Windows Server 2022 (Schannel)	Tak	pełne wsparcie
Windows Server 2019 (Schannel)	Nie	obsługa do TLS 1.2
macOS 10.15+ (Secure Transport)	Tak	pełna integracja z Safari i API systemu
Linux (OpenSSL ≥ 1.1.1)	Tak	zależne od wersji biblioteki i dystrybucji

Na starszych Windows obsługę TLS 1.2 bywało trzeba włączyć ręcznie. W .NET można wymusić silniejsze protokoły przez:

SchUseStrongCrypto=1

Nowoczesne systemy domyślnie mają włączone TLS 1.2/1.3, co upraszcza konfigurację i redukuje ryzyko błędów.

Obsługa SSL/TLS na urządzeniach mobilnych

Urządzenia mobilne stanowią znaczący udział w ruchu sieciowym, dlatego ich domyślna obsługa TLS jest kluczowa dla bezpieczeństwa użytkowników i aplikacji.

Najważniejsze informacje dotyczące iOS i Android prezentują się następująco:

iOS – Secure Transport i App Transport Security (ATS) domyślnie egzekwują bezpieczne połączenia;
Android – Java Security + BoringSSL; od Android 5.0 (API 21) domyślnie TLS 1.2, w nowszych wydaniach również TLS 1.3;
Przeglądarki mobilne – Chrome/Firefox/Opera na Android oraz Safari na iOS zapewniają pełną zgodność z TLS 1.2/1.3.

Problemy kompatybilności dotyczą głównie bardzo starych urządzeń, które nie otrzymują już aktualizacji bezpieczeństwa.

Wsparcie po stronie serwera i platform hostingowych

Warstwa serwerowa musi poprawnie wdrożyć certyfikaty i protokoły, aby klienci mogli bezpiecznie negocjować połączenia. Popularne serwery www wspierają SSL/TLS natywnie:

Apache – wsparcie poprzez moduł mod_ssl i dyrektywy konfiguracji;
Nginx – dyrektywy ssl_certificate i ssl_certificate_key w pliku konfiguracyjnym;
Microsoft IIS – integracja ze Schannel i magazynem certyfikatów systemu.

Platformy chmurowe udostępniają zarządzanie TLS/SSL jako usługę:

Amazon Web Services – integracja TLS/SSL w usługach (ALB/ELB, CloudFront) oraz szyfrowane łącza (VPN, Direct Connect);
Microsoft Azure – wymusza szyfrowanie w tranzycie, integracja z Azure Front Door i Application Gateway;
Google Cloud Platform – certyfikaty zarządzane i wsparcie TLS w Load Balancing.

Popularne CMS oferują łatwe włączenie HTTPS:

WordPress – WordPress.com automatycznie wystawia bezpłatne certyfikaty (TLS 1.2/1.3);
Joomla – korzysta z konfiguracji serwera www i ustawień aplikacji;
Drupal – integracja z certyfikatami serwera i modułami bezpieczeństwa.

Certyfikaty SSL/TLS – typy i kompatybilność

Zakres walidacji wpływa na poziom zaufania i widoczność informacji o podmiocie w certyfikacie:

DV (Domain Validation) – podstawowe szyfrowanie i weryfikacja kontroli nad domeną;
OV (Organization Validation) – zawiera dane organizacji, zwiększa wiarygodność;
EV (Extended Validation) – najwyższy poziom identyfikacji po rygorystycznej weryfikacji.

Różne modele adresowania nazw pozwalają elastycznie zabezpieczać wiele zasobów:

SAN (Subject Alternative Name) – jeden certyfikat dla wielu domen/subdomen;
Wildcard – ochrona domeny głównej i wszystkich subdomen w danym poziomie;
Multi‑domain – zabezpieczenie wielu niezwiązanych domen jednym certyfikatem.

Sectigo, DigiCert, GlobalSign i GeoTrust dostarczają certyfikaty kompatybilne z 99,9% przeglądarek, ponieważ ich klucze główne znajdują się w zaufanych magazynach systemów operacyjnych.

Specjalne wymagania i ograniczenia kompatybilności

Niektóre scenariusze wymagają dodatkowych ustawień i świadomości ograniczeń:

SNI (Server Name Indication) – konieczne przy wielu certyfikatach na jednym adresie IP; bardzo stare klienty SNI nie wspierają;
Cloudflare Universal SSL – w planie bezpłatnym domyślnie ECDSA; w planach płatnych dostępne również RSA;
Certificate pinning – zwiększa odporność na MITM, ale wymaga rygorystycznego zarządzania i planu na rotację kluczy.

Obsługa SSL/TLS w specjalistycznych zastosowaniach

TLS wykracza poza przeglądanie WWW, zabezpieczając integracje, pocztę, IoT i sieci korporacyjne:

Internet rzeczy (IoT) – lekkie implementacje (wolfSSL, TLS Toolkit/MatrixSSL) o rozmiarze 20–100 KB;
Kontenery i orkiestracja – Docker zabezpiecza klient–daemon i komunikację między hostami; Kubernetes obsługuje automatyczną rotację certyfikatów;
Poczta – Microsoft Exchange, Zimbra i inni stosują TLS dla SMTP/IMAP/POP;
E‑commerce – Shopify, Magento i bramki płatności egzekwują HTTPS dla transakcji;
VPN – OpenVPN (TLS) oraz WireGuard (Noise) tworzą szyfrowane tunele;
Microsoft Teams Direct Routing – często wymagany mTLS i zaufanie do DigiCert Global Root G2.

Obsługa SSL/TLS w aplikacjach i bibliotekach

Biblioteki kryptograficzne stanowią podstawę dla klientów i serwerów. Wybór implementacji ma znaczenie dla wydajności i zestawów szyfrów.

OpenSSL – najpopularniejsza biblioteka; TLS 1.3 od wersji 1.1.1;
GnuTLS / BoringSSL / NSS – szeroko stosowane w dystrybucjach i przeglądarkach;
AWS s2n – lekka implementacja TLS wykorzystywana w usługach AWS;
rustls – nowoczesna biblioteka w ekosystemie Rust;
Node.js – moduł node:tls dla klientów i serwerów;
Python Requests – wykorzystuje pakiet certifi do zaufanych CA;
OkHttp (Java) – korzysta z TLS platformy, wspiera TLS 1.2/1.3.

Specjalne funkcje i nowoczesne wdrożenia

Współczesne wdrożenia TLS łączą bezpieczeństwo z wydajnością i transparentnością ekosystemu certyfikatów:

Certificate Transparency (CT) – certyfikaty muszą mieć poprawne SCT; Chrome i Safari egzekwują rejestrację w publicznych dziennikach;
Rekordy DNS HTTPS (SVCB/HTTPS) – ułatwiają bezpieczne odkrywanie parametrów połączenia i ALPN (HTTP/2, HTTP/3);
HTTP/3 na QUIC – wymaga TLS 1.3, redukuje opóźnienia i poprawia niezawodność.

Wyzwania i migracja ze starszych protokołów

Przejście z TLS 1.0/1.1 na nowsze wersje wymagało inwentaryzacji klientów i usług. Stare urządzenia (szczególnie bez SNI) często wymagają rozwiązań zastępczych lub modernizacji.

Starsze systemy Windows/serwery – ręczne aktualizacje i wymuszenie TLS 1.2 przez rejestr/polityki;
Klienci poczty – wyłączenie TLS 1.0/1.1 (np. w Thunderbird 78+) wymusiło aktualizacje konfiguracji;
Środowiska korporacyjne – testy kompatybilności, stopniowe wycofywanie przestarzałych protokołów i cykliczne skanowanie portfela aplikacji.

Rekomendacje i najlepsze praktyki

Aby zapewnić bezpieczeństwo i kompatybilność w łańcuchu klient–serwer, wdrażaj poniższe zalecenia:

Minimum TLS 1.2, preferuj TLS 1.3 – konfiguruj serwery tak, aby oferowały TLS 1.3, utrzymując TLS 1.2 dla zgodności wstecznej;
Automatyzuj cykl życia certyfikatów (ACME) – wdroż ACME do automatycznej emisji i rotacji, szczególnie w środowiskach chmurowych i Kubernetes;
Monitoruj wygasanie i CT – ustaw alerty na odnowienia i weryfikuj obecność poprawnych SCT w certyfikatach;
Wybieraj nowoczesne zestawy szyfrów (ECDSA/RSA) – zapewnij wsparcie ECDSA oraz RSA dla starszych klientów, z priorytetem krzywych eliptycznych;
Rozsądne okresy ważności – planuj krótsze ważności zgodnie z trendem branżowym (dalsze skracanie do końca dekady);
Ostrożnie z pinningiem – stosuj pinning w aplikacjach o najwyższych wymaganiach, z procedurą awaryjnej rotacji;
IoT na zaufanych CA – unikaj certyfikatów samopodpisanych, aby zminimalizować alerty i problemy kompatybilności.