Czym jest SSL / HTTPS?

HTTPS to fundament zaufanego internetu: łączy klasyczny protokół HTTP z warstwą kryptograficzną, aby dane przesyłane między użytkownikiem a witryną były poufne, odporne na modyfikacje i jednoznacznie kojarzone z właściwą domeną. W praktyce oznacza to ochronę formularzy, płatności, plików cookie i całej komunikacji webowej przed przechwyceniem lub podmianą. Artykuł wyjaśnia, co faktycznie oznacza używane wciąż skrótowo pojęcie SSL, czym jest TLS, jak działa mechanizm HTTPS, jakie są rodzaje certyfikatów i jak poprawnie wdrożyć oraz utrzymać szyfrowane połączenia na stronie WWW.

Definicja i zakres pojęcia SSL / HTTPS

Pojęcie SSL / HTTPS obejmuje zestaw standardów i praktyk, których celem jest bezpieczeństwo połączeń webowych. Skrót SSL oryginalnie odnosił się do Secure Sockets Layer, historycznego protokołu kryptograficznego. Jego następcą i współczesnym standardem jest Transport Layer Security, w skrócie TLS. Gdy mówimy o HTTPS, mamy na myśli HTTP osadzone w tunelu kryptograficznym TLS. Zwyczajowo w potocznym języku nadal używa się określenia SSL, choć w kontekście technicznym powinno się mówić TLS.

HTTPS zapewnia trzy filary ochrony danych przesyłanych między przeglądarką a serwerem: poufność dzięki mechanizmom szyfrowanie, spójność dzięki kontroli i dowodom integralność oraz wiarygodność tożsamości dzięki mechanizmom autentyczność, opartym o łańcuch zaufania i podpisy cyfrowe. Centralnym elementem jest publicznie weryfikowalny certyfikat, który potwierdza powiązanie nazwy domeny z właściwym kluczem publicznym oraz z podmiotem obsługującym witrynę.

HTTPS to nie tylko warstwa techniczna; to także zespół procesów i polityk, które zaczynają się od wygenerowania pary kluczy kryptograficznych (publicznego i prywatnego), złożenia żądania certyfikacyjnego i uzyskania podpisu od zaufanego urzędu certyfikacji. Następnie ruch użytkowników jest kierowany do zabezpieczonej końcówki serwera, która negocjuje parametry protokółu, wybiera zestaw szyfrów, uwierzytelnia się certyfikatem, uzgadnia tajemnicę sesyjną i przekazuje zasoby strony przez bezpieczny kanał. Dzięki temu zarazem zwykła przeglądarka użytkownika, jak i docelowy serwer, współdzielą te same gwarancje kryptograficzne, a aplikacja webowa może polegać na stabilnych, przewidywalnych właściwościach kanału. Z perspektywy słownikowej: SSL/HTTPS to standardowy sposób zestawiania komunikacji HTTP z wykorzystaniem podpisanych certyfikatów X.509 i mechanizmów uzgadniania klucza sesyjnego, który realizuje poufność, integralność oraz uwierzytelnienie punktu końcowego serwera.

Choć HTTPS kojarzy się głównie z ikoną kłódki w pasku adresu, to pojęcie obejmuje również: polityki bezpieczeństwa przeglądarek, listy zaufanych urzędów, logi przejrzystości certyfikatów, mechanizmy odwoływania certyfikatów, a także praktyki projektowe i operacyjne (rotacja kluczy, obserwowalność, testy). Właściwe rozumienie terminu zakłada więc zarówno aspekt kryptograficzny, jak i organizacyjny.

Jak działa HTTPS: od zapytania do odpowiedzi

Aby zobaczyć, jak HTTPS realizuje definicyjne cele, warto prześledzić przebieg połączenia. Gdy użytkownik wpisuje adres strony, przeglądarka rozwiązuje nazwę domeny do adresu IP, nawiązuje połączenie sieciowe i zaczyna negocjacje TLS, zanim prześle pierwsze żądanie HTTP. W tym czasie odbywa się uzgodnienie wersji TLS i parametrów kryptograficznych, weryfikacja certyfikatu serwera oraz utworzenie klucza sesyjnego. Dopiero potem właściwe żądanie HTTP jest przesyłane po zaszyfrowanym kanale.

Negocjacja wstępna: klient wysyła komunikat ClientHello z listą wspieranych wersji TLS, metod wymiany kluczy, szyfrów i rozszerzeń (np. SNI dla nazwy domeny, ALPN dla wyboru HTTP/1.1 vs HTTP/2 vs HTTP/3). Serwer odpowiada ServerHello z wyborem parametrów.
Wymiana kluczy: nowoczesne połączenia stosują krzywe eliptyczne i wymianę ECDHE, tworząc klucz sesyjny, który zapewnia poufność i tzw. forward secrecy (ujawnienie klucza prywatnego w przyszłości nie odtajnienia przeszłej sesji).
Uwierzytelnienie serwera: serwer wysyła certyfikat i łańcuch pośredników; klient weryfikuje podpisy do zaufanego root CA, sprawdza, czy nazwa domeny zgadza się z certyfikatem oraz czy certyfikat jest ważny i nieodwołany.
Utworzenie tajemnicy: po udanym uzgodnieniu i weryfikacji obie strony wyprowadzają wspólny klucz sesyjny na podstawie zestawu parametrów wymiany.
Przełączenie do trybu szyfrowanego: dalsza komunikacja HTTP odbywa się w ramach zaszyfrowanych rekordów TLS. W HTTP/2 następuje też ustawienie ramek i multiplexing strumieni, co pozwala jednemu połączeniu równolegle przenosić wiele zasobów.
Wydajność i wznawianie: mechanizmy sesji i PSK pozwalają skrócić kolejne połączenia. TLS 1.3 redukuje liczbę komunikatów wstępnych, a opcjonalne 0-RTT umożliwia wysłanie pierwszych danych natychmiast, choć wymaga ostrożności ze względu na podatność na powtórzenie.

Przeglądarki dodatkowo stosują polityki bezpieczeństwa: mogą blokować mieszane treści, wymuszać szyfrowanie poprzez HSTS, prezentować użytkownikom ostrzeżenia przy błędach certyfikatu oraz optymalizować wybór szyfrów. Jeżeli w grę wchodzi HTTP/3, transport przebiega przez QUIC w UDP, ale nadal opiera się na TLS 1.3; negocjacje są w nim wbudowane w protokół transportowy i jeszcze szybciej dochodzi do bezpiecznej wymiany danych.

Od strony aplikacji kluczowe jest to, że zaszyfrowana jest cała treść żądania i odpowiedzi wraz z nagłówkami (z wyjątkiem metadanych na niższych warstwach, takich jak adresy IP). Ochronie podlegają identyfikatory sesji i pliki cookie, co utrudnia ich przechwycenie przez osoby trzecie. W połączeniu z dobrymi praktykami zarządzania sesją (flagi Secure, HttpOnly i SameSite dla ciasteczek) HTTPS buduje solidny fundament zaufanego kanału między klientem a serwerem.

Certyfikaty: rodzaje, wystawcy i cykl życia

Certyfikat X.509 wiąże klucz publiczny z nazwą domeny oraz, opcjonalnie, z danymi identyfikacyjnymi organizacji. Wystawiają go urzędy certyfikacji (CA), a przeglądarki i systemy operacyjne utrzymują listy zaufanych urzędów. Istnieje kilka podstawowych typów:

DV (Domain Validation): potwierdza kontrolę nad domeną. Najpopularniejszy, szybki i bezpłatny w wariancie Let’s Encrypt.
OV (Organization Validation): oprócz domeny weryfikuje podstawowe dane przedsiębiorstwa. Użyteczny, gdy odbiorcy oczekują informacji o organizacji.
EV (Extended Validation): rozbudowany proces weryfikacji prawnej i operacyjnej podmiotu; historycznie wyróżniany w interfejsie przeglądarek, dziś głównie jako aspekt zaufania korporacyjnego i zgodności.

W zależności od potrzeb certyfikat może obejmować jedną domenę, wiele nazw (SAN) lub wzorce z gwiazdką (wildcard). W kontekście operacyjnym istotne są też algorytmy kluczy: RSA 2048/3072 bitów jest powszechny, ECDSA na krzywych P-256 i P-384 zapewnia krótsze klucze i wyższą wydajność, ale wymaga wsparcia po stronie klientów. W praktyce coraz częściej stosuje się pary RSA i ECDSA równolegle, aby serwer mógł odpowiedzieć najkorzystniejszym kluczem w zależności od możliwości klienta.

Proces wydania zwykle obejmuje wygenerowanie pary kluczy, stworzenie CSR (żądania certyfikacyjnego) oraz przejście walidacji kontroli nad domeną. Mechanizmy ACME (z których korzysta m.in. Let’s Encrypt) automatyzują ten proces poprzez wyzwania http-01, dns-01 lub tls-alpn-01. Znacząco upraszcza to wdrożenia w środowiskach chmurowych i CI/CD, a krótkie okresy ważności (np. 90 dni) sprzyjają rotacji i redukują ryzyko kompromitacji.

Utrzymanie certyfikatów obejmuje regularne odnowienia oraz monitorowanie ich ważności i łańcuchów pośrednich. Weryfikacja odwołania odbywa się przez CRL lub OCSP; OCSP stapling pozwala serwerowi dostarczyć świeżą odpowiedź OCSP w trakcie handshaku, zmniejszając opóźnienie i ryzyko błędów po stronie klienta. Dla przejrzystości ekosystemu urzędy publikują każdy wydany certyfikat w logach Certificate Transparency, co ułatwia wykrywanie nadużyć. Operatorzy serwisów mogą subskrybować powiadomienia i audytować swoją przestrzeń nazw.

Warto zaznaczyć, że mechanizmy przypinania kluczy w nagłówkach (HPKP) są obecnie odradzane z powodu ryzyka trwałej blokady. Zamiast tego poleca się monitorowanie logów CT, solidną procedurę odzyskiwania i ostrożne zarządzanie łańcuchami pośrednimi. Zaawansowane środowiska mogą rozważać mTLS (wzajemne uwierzytelnienie klienta i serwera) dla paneli administracyjnych lub komunikacji usługowej oraz DANE/TLSA w oparciu o DNSSEC, choć wsparcie przeglądarek dla DANE jest ograniczone.

Najważniejszym aktywem jest klucz prywatny. Powinien być generowany i przechowywany w sposób bezpieczny (np. w HSM lub co najmniej z restrykcyjnymi uprawnieniami w systemie), nigdy nieudostępniany i rotowany według polityki bezpieczeństwa. Utrata kontroli nad kluczem prywatnym wymaga natychmiastowego odwołania certyfikatu i wydania nowego.

Wdrożenie na stronie: praktyczny przewodnik

Proces wdrożenia HTTPS można podzielić na planowanie, uzyskanie certyfikatu, konfigurację serwera, migrację adresów i testy. W małej witrynie będzie to kilkanaście kroków, w dużej organizacji – projekt cross-funkcyjny z udziałem zespołów sieciowych, bezpieczeństwa, SEO i aplikacyjnych.

Wybór strategii certyfikacji: pojedyncze certyfikaty dla każdej domeny, SAN dla kilku subdomen lub wildcard dla całej gałęzi. W środowiskach wielochmurowych przydatne są certyfikaty zarządzane przez dostawcę CDN lub load balancer.
Pozyskanie certyfikatu: automatyzacja przez ACME zmniejsza ryzyko wygaśnięć. Dla zasobów za WAF/CDN rozważ walidację dns-01, aby uniknąć problemów z trasowaniem.
Konfiguracja końcówki TLS: w serwerach HTTP należy włączyć TLS 1.2 i TLS 1.3, skonfigurować preferowane szyfry, włączyć OCSP stapling, SNI i ALPN. Jeżeli ruch terminowany jest na CDN, upewnij się, że połączenie między CDN a originem też jest szyfrowane, najlepiej z walidacją certyfikatu po stronie CDN (tryb strict).
Migracja adresów: ustaw przekierowania 301 z HTTP do HTTPS, zaktualizuj linki kanoniczne, mapy witryny, pliki robots i konfigurację narzędzi analitycznych. Zadbaj o aktualizację adresów w e-mailach transakcyjnych, integracjach API i aplikacjach mobilnych.
Porządkowanie zasobów: unikaj mieszanego wczytywania; zasoby zewnętrzne (obrazy, skrypty, czcionki) wczytuj z HTTPS lub hostuj lokalnie. Rozważ nagłówek CSP z dyrektywą upgrade-insecure-requests, aby tymczasowo wymusić szyfrowane odpowiedniki.
Polityki bezpieczeństwa: ustaw HSTS z rozsądnymi parametrami i po testach dodaj domenę do listy preload, jeżeli cała powierzchnia domeny działa w HTTPS. Skonfiguruj bezpieczne flagi dla ciasteczek i dodatkowe nagłówki: X-Content-Type-Options, Referrer-Policy, Permissions-Policy.
Integracje zwrotne i webhooki: pamiętaj o aktualizacji endpointów odbierających powiadomienia i callbacki. Niektóre systemy wymagają zaufanych łańcuchów pośrednich lub konkretnego formatu certyfikatu.
Obserwowalność: monitoruj wykrywanie wygaśnięć, błędy łańcucha, alerty z logów CT i wyniki narzędzi audytowych. Zaplanuj automatyczne odnowienia i testy dymne po rotacji certyfikatów.

Jeżeli używasz load balancerów, pamiętaj o spójności konfiguracji we wszystkich regionach i środowiskach. W systemach mikroserwisowych rozważ ujednolicenie biblioteki TLS i polityk szyfrów, aby uprościć utrzymanie. W środowiskach z intensywnym ruchem warto włączyć buforowanie i kompresję na wyższych warstwach, a równocześnie testować wpływ na opóźnienia TLS, korzystając z narzędzi syntetycznych i RUM.

Konfiguracja i twardnienie: wersje, szyfry, nagłówki

Bezpieczna konfiguracja TLS polega na zrównoważeniu kompatybilności i siły kryptografii. Minimalnym standardem jest włączenie TLS 1.2 i TLS 1.3 oraz wyłączenie przestarzałych wersji. Preferowane zestawy szyfrów powinny używać AEAD (np. AES-GCM lub ChaCha20-Poly1305) i ephemerycznej wymiany kluczy ECDHE. W środowiskach z klientami mobilnymi ChaCha20-Poly1305 bywa korzystniejszy na urządzeniach bez sprzętowego AES. Unikaj RC4, 3DES, słabych krzywych i trybów CBC. W TLS 1.3 zestaw szyfrów jest uproszczony, co ogranicza ryzyko błędnej konfiguracji.

Polityka HSTS powinna być wprowadzana ostrożnie: zacznij od krótkiego max-age, obserwuj błędy i dopiero po pełnym pokryciu HTTPS rozważ includeSubDomains i preload. Preload wymaga spełnienia określonych warunków dla całej domeny i subdomen oraz świadomej zgody na nieodwracalność do czasu wygaśnięcia wpisu na liście przeglądarek. Równolegle zastosuj twardnienie nagłówkami: X-Frame-Options lub odpowiednią polityką ramek w CSP, X-Content-Type-Options nosniff, Referrer-Policy ograniczającą wyciek adresów, Permissions-Policy kontrolującą dostępy do funkcji przeglądarki oraz poprawne flagi Secure, HttpOnly i SameSite dla ciasteczek.

Ważny jest też porządek w łańcuchu certyfikatów: dostarczaj pełny łańcuch wraz z certyfikatem pośrednim preferowanym przez CA, aby uniknąć problemów na starszych urządzeniach. Włącz OCSP stapling i cache odpowiedzi OCSP, co przyspiesza weryfikację. Dla wydajności włącz sesje z ticketami i testuj wpływ na pamięć i bezpieczeństwo. Jeżeli terminujesz TLS na CDN lub proxy, ustaw pełną weryfikację originu i rozważ mTLS dla wrażliwych kanałów administracyjnych.

Nie zapominaj o operacyjnym twardnieniu: odseparuj dostęp do kluczy i certyfikatów, stosuj zasadę najmniejszych uprawnień, loguj ręce, które dotykają materiału kryptograficznego, a rotację planuj i testuj w bezpiecznym oknie zmian. Dokumentuj profile szyfrów i wersje w repozytorium infrastruktury jako kod, aby uniknąć dryfu konfiguracji.

Wydajność, SEO i doświadczenie użytkownika

Połowa sukcesu HTTPS to bezpieczeństwo, druga połowa – percepcja i szybkość. Wbrew dawnym obawom koszt wydajnościowy TLS jest zazwyczaj pomijalny w porównaniu z opóźnieniami sieci i czasem generowania odpowiedzi. Włączenie HTTP/2 lub HTTP/3 przynosi korzyści: multiplexing strumieni, kompresję nagłówków, lepsze wykorzystanie jednego połączenia i stabilniejszy throughput przy stratnych łączach. ChaCha20-Poly1305 bywa szybszy na urządzeniach mobilnych, a nowoczesne biblioteki TLS wykorzystują akcelerację sprzętową AES-GCM.

W zakresie UX użytkownicy oczekują kłódki, a przeglądarki wyraźnie oznaczają strony bez HTTPS jako potencjalnie niebezpieczne. W e-commerce brak HTTPS podważa zaufanie, a w aplikacjach SaaS uniemożliwia poprawne działanie nowoczesnych API przeglądarkowych. Z punktu widzenia SEO HTTPS jest sygnałem rankingowym i ułatwia konsolidację wersji adresów. Migracja powinna obejmować 301 z http do https, aktualizację linków kanonicznych, mapy witryny i konfigurację narzędzi analitycznych. Po migracji obserwuj indeksację, błędy pokrycia i mieszane treści, które mogą zostać zablokowane.

Wydajnościowo kluczowe są: prawidłowy dobór CDN, minimalizacja liczby połączeń, użycie HTTP/2 push zostało w praktyce zastąpione lepszym cache i preloadingiem, a w HTTP/3 poprawa w pierwszym bajcie bywa znacząca na sieciach mobilnych. OCSP stapling i skrócone handshaki obniżają opóźnienie w pierwszym połączeniu. Pamiętaj też o buforowaniu zasobów, kompresji, optymalizacji obrazów i lazy loadingu, które mają znacznie większy wpływ na odczuwalną szybkość niż sama warstwa TLS.

Diagnostyka, testy i najczęstsze błędy

Nawet poprawnie wdrożone HTTPS wymaga stałej obserwacji. Audyt zacznij od narzędzi zewnętrznych oceniających konfigurację TLS i nagłówki bezpieczeństwa. Testy syntetyczne z różnych regionów ujawnią problemy z łańcuchem certyfikatów, walidacją OCSP lub SNI. W przeglądarce panel Security i DevTools pokazują szczegóły sesji, protokołu i ostrzeżenia o mieszanych treściach.

Błędny łańcuch certyfikatów: brak pośredniego certyfikatu powoduje ostrzeżenia lub blokadę połączenia na części urządzeń. Rozwiązanie: dołącz pełny łańcuch i używaj zalecanego pośrednika.
Niezaufany urząd: błąd typu NET::ERR_CERT_AUTHORITY_INVALID wskazuje na samopodpisany certyfikat lub nieznany root. Rozwiązanie: użyj certyfikatu od publicznie zaufanego CA lub popraw instalację łańcucha.
Wygaśnięty certyfikat: NET::ERR_CERT_DATE_INVALID. Rozwiązanie: automatyzuj odnowienia, monitoruj ważność i testuj procesy rotacji.
Niezgodność nazwy: CERT_COMMON_NAME_INVALID. Rozwiązanie: upewnij się, że certyfikat obejmuje dokładną domenę i subdomeny (SAN), a SNI jest poprawnie skonfigurowane.
Wersje/szyfry nieobsługiwane: ERR_SSL_VERSION_OR_CIPHER_MISMATCH. Rozwiązanie: włącz TLS 1.2 i 1.3, usuń przestarzałe szyfry, zapewnij kompatybilność z popularnymi klientami.
Mieszane treści: część zasobów ładowana po HTTP. Rozwiązanie: popraw adresy, użyj CSP z upgrade-insecure-requests i monitoruj w Raportach CSP.
Problemy z OCSP/CRL: czasem powodują opóźnienia lub błędy. Rozwiązanie: włącz OCSP stapling i cache, zapewnij wysoką dostępność połączeń do dostawcy OCSP.
Konflikt z CDN lub WAF: niezgodny tryb walidacji originu. Rozwiązanie: ustaw tryb pełny ze ścisłą weryfikacją i zapewnij certyfikat na originie.
Błędy w HTTP/3: część sieci blokuje UDP. Rozwiązanie: utrzymuj HTTP/2 jako ścieżkę zapasową i monitoruj negocjacje ALPN.

Przydatne źródła diagnostyczne to skanery konfiguracji TLS, testery nagłówków bezpieczeństwa, raporty z logów CT oraz monitorowanie syntetyczne ścieżek klienta. W praktyce największą liczbę incydentów powodują wygaśnięcia certyfikatów i mieszane treści – obie kategorie da się niemal całkowicie wyeliminować automatyzacją i kontrolą jakości w pipeline wdrożeniowym.

FAQ

Co dokładnie oznacza skrót SSL i czy jest poprawny w kontekście współczesnego internetu?

SSL to historyczna nazwa protokołu kryptograficznego; obecnym standardem jest TLS. Potocznie wiele osób mówi SSL, lecz technicznie mamy do czynienia z TLS, a HTTPS to HTTP działający wewnątrz bezpiecznego kanału TLS.
Czy każda strona potrzebuje HTTPS, nawet jeśli nie ma logowania ani płatności?

Tak. HTTPS chroni dane użytkownika, zapobiega podmianie treści i poprawia wiarygodność, a przeglądarki uznają strony bez HTTPS za niebezpieczne. Dodatkowo jest to wymagane przez wiele API i funkcji przeglądarkowych.
Czy Let’s Encrypt jest bezpieczny i wystarczający dla witryn firmowych?

Tak. Certyfikaty DV od Let’s Encrypt są publicznie zaufane, wspierane przez główne przeglądarki i spełniają wymagania kryptograficzne. Jeśli potrzebujesz poświadczenia tożsamości organizacji, rozważ OV/EV, lecz pod względem bezpieczeństwa kanału DV jest wystarczający.
Czym różnią się DV, OV i EV?

DV potwierdza kontrolę nad domeną, OV dodatkowo weryfikuje dane organizacji, a EV przeprowadza rozszerzoną weryfikację prawną i operacyjną. Wszystkie zapewniają szyfrowanie; różnią się poziomem zapewnienia tożsamości podmiotu.
Czy certyfikat samopodpisany nadaje się do produkcyjnej strony?

Nie. Samopodpisane certyfikaty nie są zaufane przez przeglądarki i prowadzą do ostrzeżeń. Mogą być użyte do testów lub w kontrolowanych środowiskach z ręcznym zaufaniem, ale nie do publicznego serwisu.
Czy HTTPS ukrywa cały adres URL i nazwę domeny?

Nie. HTTPS szyfruje treść żądania i odpowiedzi oraz nagłówki HTTP, ale metadane na niższych warstwach, takie jak adresy IP i nazwa domeny widoczna w SNI (dla starszych rozwiązań – w TLS 1.3 z ECH możliwe jest ukrycie części informacji) mogą być obserwowalne. Trwają prace nad lepszą ochroną metadanych.
Czy HTTPS zastępuje VPN?

Nie. HTTPS chroni pojedyncze połączenia aplikacyjne, podczas gdy VPN tworzy szyfrowany tunel dla całego ruchu sieciowego. To różne narzędzia o komplementarnych zastosowaniach.
Jakie są koszty wdrożenia HTTPS?

Certyfikaty DV mogą być bezpłatne (np. Let’s Encrypt). Koszty dotyczą głównie pracy wdrożeniowej, automatyzacji odnowień, monitoringu i ewentualnie wsparcia komercyjnego dla OV/EV lub HSM.
Czy muszę coś robić po włączeniu HTTPS, czy to jednorazowe zadanie?

To proces ciągły: odnowienia certyfikatów, monitorowanie wygaśnięć, aktualizacje szyfrów i wersji TLS, utrzymanie HSTS, testy mieszanych treści i audyty konfiguracji.
Co to jest HSTS i kiedy włączyć preload?

HSTS wymusza użycie HTTPS po pierwszej wizycie. Preload dodaje domenę do listy w przeglądarkach, co wymusza HTTPS od pierwszego połączenia. Włącz preload dopiero, gdy cała domena i subdomeny konsekwentnie obsługują HTTPS i nie ma potrzeby akceptacji połączeń HTTP.
Jak naprawić mieszane treści po migracji?

Zastąp adresy http:// ich odpowiednikami https://, zaktualizuj szablony, pliki konfiguracyjne, zasoby zewnętrzne. Tymczasowo możesz włączyć CSP upgrade-insecure-requests, ale docelowo linki powinny wskazywać bezpośrednio zaszyfrowane zasoby.
Czy certyfikat wildcard jest lepszy niż SAN?

Zależy od scenariusza. Wildcard ułatwia objęcie wielu subdomen w jednej gałęzi, ale zwiększa ryzyko operacyjne w razie wycieku klucza. SAN pozwala precyzyjnie wskazać domeny i bywa bezpieczniejszy organizacyjnie.
Czy HTTP/2 i HTTP/3 wymagają HTTPS?

W praktyce tak w przeglądarkach: HTTP/2 i HTTP/3 są obsługiwane jedynie przez warstwę TLS (HTTP/3 jest ściśle związany z TLS 1.3 w QUIC). Po stronie serwerów i narzędzi możliwe są konfiguracje inne, ale nie dla typowego ruchu przeglądarkowego.
Co z pinningiem kluczy i nagłówkiem HPKP?

HPKP jest odradzany ze względu na ryzyko trwałej blokady. Lepszą praktyką jest monitorowanie logów Certificate Transparency, staranne zarządzanie łańcuchem pośredników i procedury rotacji kluczy.
Czym jest mTLS i kiedy go użyć?

mTLS to wzajemne uwierzytelnianie klienta i serwera za pomocą certyfikatów po obu stronach. Stosuj je w komunikacji usługowej, panelach administracyjnych i kanałach o podwyższonym zaufaniu, rzadko w publicznym webie dla anonimowych użytkowników.
Czy muszę się martwić o odwoływanie certyfikatów?

Tak, miej przygotowaną procedurę odwołania w razie kompromitacji klucza lub błędu w certyfikacie. Włącz OCSP stapling i monitoruj odwołania, choć krótkie okresy ważności znacznie ograniczają okno ryzyka.