Prawidłowa konfiguracja TLS i HTTPS

Krótko: Solidna konfiguracja TLS serwera WWW oferuje wyłącznie TLS 1.2 i TLS 1.3, stosuje zestawy szyfrów z Forward Secrecy i uwierzytelnionym szyfrowaniem (AES-GCM, ChaCha20-Poly1305) oraz certyfikat z kluczem ECDSA lub RSA o wystarczającej długości, który odnawia się automatycznie. Wskazówek dostarczają wytyczne TR-02102-2 urzędu BSI (niemiecki Federalny Urząd ds. Bezpieczeństwa w Technice Informatycznej) oraz zalecenia Server-Side TLS z TLSRef. Sprawdź wynik z zewnątrz i nie zapomnij o połączeniach, które nawiązuje samo PHP.

Dlaczego stare ustawienia TLS tak długo przetrwają

Kłódka w przeglądarce jest, więc szyfrowanie uchodzi za załatwione. Tak myśli wielu operatorów i dlatego konfiguracja TLS często przez lata pozostaje bez zmian. Pochodzi wtedy z czasu uruchomienia serwera, ze skopiowanego szablonu lub z ustawień domyślnych panelu.

Problem w tym, że zalecenia się zmieniają. Wersje protokołów są zastępowane, metody uznawane są za słabe, pojawiają się nowe metody wymiany kluczy. BSI opublikowało TR-02102 ostatnio w wersji 2026-01 z 27.01.2026 i wskazuje w niej już na hybrydowe metody postkwantowe dla TLS 1.3. Kto od lat nie przeglądał swoich ustawień, z dużym prawdopodobieństwem nie jest już na bieżąco.

Kto i tak sprawdza serwery po PHP2Shell, może przy okazji obejrzeć konfigurację TLS. Nie zamyka ona luki w PHP, ale należy do każdego rzetelnego utwardzania.

Na czym opiera się dobra konfiguracja TLS serwera WWW

Dwa źródła są dla operatorów szczególnie użyteczne. BSI TR-02102 ocenia metody kryptograficzne; część 2 dotyczy TLS. Skierowana jest głównie do programistów i planistów i dla urzędów oraz sektorów regulowanych jest często miarą. Zalecenia Server-Side TLS, dawniej utrzymywane w wiki Mozilli, są dziś kontynuowane w TLSRef i dostarczają konkretnych profili, które można skopiować.

TLSRef w wersji 6.0 rozróżnia dwa profile:

Dla stron publicznych Intermediate jest typowym punktem wyjścia. Profil wyklucza bardzo stare urządzenia, ale obejmuje aktualne przeglądarki i systemy operacyjne. Hybrydowa grupa X25519MLKEM768 wymaga aktualnej biblioteki TLS. Sprawdź, czy Państwa wersja OpenSSL ją zna, zanim ją wpiszesz.

Nginx i Apache: bezpieczny punkt wyjścia

Poniższe przykłady wdrażają profil Intermediate. Ścieżki są wartościami zastępczymi, lista zestawów szyfrów dotyczy TLS 1.2; TLS 1.3 ma własne, bezpieczne metody domyślne.

server {
    listen 443 ssl;
    server_name www.example.de;

    ssl_certificate     /etc/ssl/example/fullchain.pem;
    ssl_certificate_key /etc/ssl/example/privkey.pem;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;
    ssl_prefer_server_ciphers off;
}

server {
    listen 80;
    server_name www.example.de;
    return 301 https://$host$request_uri;
}

SSLProtocol             -all +TLSv1.2 +TLSv1.3
SSLCipherSuite          ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305
SSLHonorCipherOrder     off

Drugi blok server na stałe przekierowuje nieszyfrowane wywołania na HTTPS. Przekierowanie powinno wskazywać bezpośrednio na ostateczny adres, a nie przechodzić przez kilka etapów pośrednich. Sprawdź potem także osadzone zasoby: obrazy, skrypty lub czcionki ładowane jeszcze przez HTTP wywołują w przeglądarce ostrzeżenia albo są blokowane.

Ustawienie, że klient wybiera kolejność, odpowiada zaleceniu TLSRef: wszystkie oferowane metody uznawane są za bezpieczne, a urządzenia bez akceleracji AES mogą dzięki temu preferować ChaCha20. Po każdej zmianie przetestuj konfigurację (nginx -t lub apachectl configtest) i przeładuj usługę. Odpowiedni nagłówek HSTS i inne wytyczne dla przeglądarek opisuje poradnik Nagłówki bezpieczeństwa dla stron internetowych.

Certyfikaty: klucz, łańcuch, odnawianie

Duża część problemów z TLS w praktyce nie ma nic wspólnego z zestawami szyfrów, lecz z certyfikatami. Typowe błędy to niekompletny łańcuch, w którym brakuje certyfikatu pośredniego, wygasłe certyfikaty na domenach pobocznych oraz klucze prywatne ze zbyt szerokimi uprawnieniami do plików.

Pomagają trzy zasady:

1. Odnawiać automatycznie i monitorować odnawianie. Krótkie okresy ważności, jakie zaleca TLSRef, są praktyczne tylko z automatyzacją.
2. Chronić klucze prywatne: odczyt tylko dla roota i procesu serwera WWW, nigdy w webroot, nigdy w repozytorium.
3. Uwzględnić wszystkie nazwy: domenę główną, www, subdomeny sklepu, stagingu, interfejsu WWW poczty i paneli.

Kto stosuje certyfikaty w kilku miejscach, na przykład na CDN, load balancerze i serwerze źródłowym, powinien prowadzić zestawienie: który certyfikat jest gdzie zainstalowany, kto go odnawia i kiedy wygasa. Bez takiego zestawienia wygasły certyfikat często wychodzi na jaw dopiero wtedy, gdy zgłaszają się klienci.

Jak sprawdzić konfigurację z zewnątrz

Poniższe polecenia to wyłącznie kontrole i niczego nie zmieniają. Zastąp nazwę hosta własną:

# TLS 1.3 i TLS 1.2 powinny działać
openssl s_client -connect www.example.de:443 -servername www.example.de -tls1_3 </dev/null
openssl s_client -connect www.example.de:443 -servername www.example.de -tls1_2 </dev/null
# TLS 1.1 powinno zawieść
openssl s_client -connect www.example.de:443 -servername www.example.de -tls1_1 </dev/null
# Okres ważności i podmiot wydanego certyfikatu
openssl s_client -connect www.example.de:443 -servername www.example.de </dev/null 2>/dev/null | openssl x509 -noout -subject -dates

Niepowodzenie testu TLS 1.1 może wynikać także z tego, że lokalna wersja OpenSSL w ogóle nie oferuje już starego protokołu. Do pełnego raportu o wszystkich oferowanych metodach nadaje się wyspecjalizowany skaner TLS. Sprawdzaj przy tym każdą subdomenę osobno, ponieważ często działają z własnymi ustawieniami.

Pomijane: TLS tam, gdzie PHP samo jest klientem

Aplikacje PHP same nawiązują wiele połączeń: z dostawcami płatności, firmami kurierskimi, interfejsami API, serwerami poczty i bazami danych. Najczęstszym błędem nie jest tu słabe ustawienie, lecz wyłączona weryfikacja certyfikatu, często jako szybkie obejście problemu na etapie programowania.

<?php
// Bezpiecznie: certyfikat i nazwa hosta są weryfikowane (zachować zachowanie domyślne)
$ch = curl_init('https://api.partner.example/v1/status');
curl_setopt_array($ch, [
    CURLOPT_RETURNTRANSFER => true,
    CURLOPT_SSL_VERIFYPEER => true,
    CURLOPT_SSL_VERIFYHOST => 2,
    CURLOPT_TIMEOUT        => 10,
]);
$antwort = curl_exec($ch);

Wyszukaj w kodzie CURLOPT_SSL_VERIFYPEER z wartością false oraz verify_peer w kontekstach strumieni. Każde znalezisko praktycznie znosi ochronę TLS dla tego połączenia. Tam, gdzie usługi znajdują się za CDN, także odcinek między CDN a serwerem źródłowym powinien używać ważnego, weryfikowanego certyfikatu. Dalsze ustawienia serwera WWW dla konfiguracji PHP znajdziesz w artykule Bezpieczna konfiguracja Nginx dla PHP, a miary dla całego utwardzania w artykule Benchmarki CIS i moduły BSI.

Jak konkretnie pomaga PHP SOS?

• Spisujemy wszystkie nazwy hostów i usługi z TLS, łącznie z panelami, stagingiem i interfejsami WWW poczty.
• Porównujemy ustawienia z TR-02102 i odpowiednim profilem TLSRef oraz dokumentujemy świadome odstępstwa.
• Przestawiamy certyfikaty na automatyczne odnawianie z monitoringiem.
• Szukamy w kodzie aplikacji wyłączonych weryfikacji certyfikatów i pokazujemy poprawkę.

TLS jest elementem naszego utwardzania serwerów PHP; związek z aktualną sytuacją wyjaśnia artykuł Czym jest PHP2Shell?.

Częste pytania

Źródła

• BSI TR-02102: metody kryptograficzne, część 2 TLS
• TLSRef: wytyczne TLS po stronie serwera (Server-Side TLS Guidelines)
• Dokumentacja Nginx
• Serwer HTTP Apache: dokumentacja