# Prawidłowa konfiguracja TLS i HTTPS

> Konfiguracja TLS serwera WWW wg BSI TR-02102 i TLSRef: protokoły, zestawy szyfrów, certyfikaty i polecenia kontrolne dla Nginx, Apache i klientów PHP.

Źródło: https://phpsos.de/pl/blog/tls-https-richtig-konfigurieren/  
Stan: 25.10.2026  
Dostawca: PHP SOS, Pomoc awaryjna PHP i bezpieczeństwo serwerów. Natychmiastowa pomoc przez WhatsApp: https://wa.me/491736494914?text=Dzie%C5%84%20dobry%2C%20PHP%20SOS%2C%20potrzebujemy%20pomocy%20z%20naszym%20serwerem%20PHP.%20Firma%3A%20%E2%80%A6%20Strona%20internetowa%3A%20%E2%80%A6

**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:

| Cecha | Intermediate (dla większości stron) | Modern |
|---|---|---|
| Protokoły | TLS 1.2 i TLS 1.3 | tylko TLS 1.3 |
| Zestawy szyfrów TLS 1.2 | ECDHE z AES-GCM lub ChaCha20-Poly1305 | brak |
| Grupy wymiany kluczy | X25519MLKEM768, X25519, prime256v1, secp384r1 | jak Intermediate |
| Certyfikat | zalecany ECDSA P-256 lub RSA 2048 bitów | ECDSA P-256 |
| Okres ważności certyfikatu | zalecane 90 dni, najwyżej 366 dni | 90 dni |
| HSTS max-age | dwa lata | dwa lata |

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.

```nginx
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;
}
```

```apache
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](https://phpsos.de/pl/ratgeber/sicherheits-header/).

> **Wskazówka:**
> Panele takie jak Plesk czy cPanel często nadpisują własne zmiany w generowanych plikach. Ustawiaj wytyczne TLS tam przez przewidziane w panelu ustawienia lub szablony.

## 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ą:

```bash
# 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
<?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](https://phpsos.de/pl/blog/nginx-fuer-php-absichern/), a miary dla całego utwardzania w artykule [Benchmarki CIS i moduły BSI](https://phpsos.de/pl/blog/cis-benchmarks-bsi-bausteine/).

## 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](https://phpsos.de/pl/leistungen/server-haertung/); związek z aktualną sytuacją wyjaśnia artykuł [Czym jest PHP2Shell?](https://phpsos.de/pl/php2shell/was-ist-php2shell/).


## Częste pytania

**Czy nadal muszę oferować TLS 1.0 i TLS 1.1?**  
Z reguły nie. Aktualne zalecenia, takie jak profil Intermediate z TLSRef, ustalają TLS 1.2 jako dolną granicę. Kto potrzebuje starszych protokołów dla starych urządzeń, powinien podjąć tę decyzję świadomie, udokumentować ją i ograniczyć do oddzielnej usługi.

**Czy darmowy certyfikat jest mniej bezpieczny niż kupiony?**  
Dla szyfrowania nie ma to znaczenia. Decydują typ klucza, długość klucza, kompletny łańcuch certyfikatów i niezawodne automatyczne odnawianie. Różnice dotyczą zakresu weryfikacji, okresu ważności i obsługi ze strony dostawcy.

**Czy wystarczy HTTPS między odwiedzającym a CDN?**  
Nie. Także połączenie między CDN a serwerem źródłowym powinno być szyfrowane i weryfikować certyfikat źródła. W przeciwnym razie dane na drugim odcinku przechodzą przez sieć bez szyfrowania lub bez weryfikacji.

**Co TLS ma wspólnego z PHP2Shell?**  
Bezpośrednio nic. TLS chroni dane w transporcie, a PHP2Shell dotyczy interpretera PHP na serwerze. Szyfrowane połączenie równie niezawodnie przenosi także żądania atakujące, dlatego aktualizacja PHP pozostaje obowiązkowa niezależnie od tego.

## Źródła

- [BSI TR-02102: metody kryptograficzne, część 2 TLS](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/Technische-Richtlinien/TR-nach-Thema-sortiert/tr02102/tr-02102.html)
- [TLSRef: wytyczne TLS po stronie serwera (Server-Side TLS Guidelines)](https://docs.tlsref.org/)
- [Dokumentacja Nginx](https://nginx.org/en/docs/)
- [Serwer HTTP Apache: dokumentacja](https://httpd.apache.org/docs/)