# TLS és HTTPS helyes konfigurálása

> TLS-konfiguráció webszerverhez a BSI TR-02102 és a TLSRef alapján: protokollok, cipher suite-ok, tanúsítványok, ellenőrző parancsok Nginxhez, Apache-hoz.

Forrás: https://phpsos.de/hu/blog/tls-https-richtig-konfigurieren/  
Állapot: 2026. 10. 25.  
Szolgáltató: PHP SOS, PHP-vészhelyzeti segítség és szerverbiztonság. Azonnali segítség WhatsAppon: https://wa.me/491736494914?text=%C3%9Cdv%C3%B6zl%C3%B6m%2C%20PHP%20SOS%21%20Seg%C3%ADts%C3%A9gre%20van%20sz%C3%BCks%C3%A9g%C3%BCnk%20a%20PHP-szerver%C3%BCnkkel.%20C%C3%A9g%3A%20%E2%80%A6%20Weboldal%3A%20%E2%80%A6

**Röviden:** Egy szilárd TLS-konfiguráció webszerverhez csak a TLS 1.2-t és a TLS 1.3-at kínálja, Forward Secrecy-vel és hitelesített titkosítással (AES-GCM, ChaCha20-Poly1305) rendelkező cipher suite-okat használ, és olyan tanúsítványt, amelynek ECDSA-kulcsa vagy kellően hosszú RSA-kulcsa van, és amely automatikusan megújul. Eligazítást a BSI (a német Szövetségi Információbiztonsági Hivatal) TR-02102-2 irányelve és a TLSRef Server-Side-TLS-ajánlásai adnak. Ellenőrizze az eredményt kívülről, és ne feledkezzen meg azokról a kapcsolatokról sem, amelyeket maga a PHP épít fel.

## Miért élnek túl olyan sokáig a régi TLS-beállítások

A lakat ott van a böngészőben, tehát a titkosítás elintézettnek számít. Sok üzemeltető így gondolkodik, ezért a TLS-konfiguráció gyakran évekig változatlan marad. Ilyenkor a szerver üzembe helyezésének idejéből, egy bemásolt sablonból vagy egy panel alapértékeiből származik.

A gond: az ajánlások változnak. A protokollverziókat leváltják, egyes eljárások gyengének számítanak, új kulcscsere-eljárások jönnek. A BSI a TR-02102-t legutóbb a 2026-01-es változatban tette közzé 2026. január 27-én, és ott már a TLS 1.3-hoz tartozó hibrid poszt-kvantum eljárásokra is utal. Aki évek óta nem nézte meg a beállításait, nagy valószínűséggel már nincs az aktuális szinten.

Aki a PHP2Shell után amúgy is ellenőrzi a szervereit, a TLS-konfigurációt egy lendülettel megnézheti. A PHP-rést nem zárja le, de minden rendes keményítéshez hozzátartozik.

## Mihez igazodik a jó TLS-konfiguráció webszerverhez

Két forrás különösen hasznos az üzemeltetőknek. A **BSI TR-02102** kriptográfiai eljárásokat értékel; a 2. rész a TLS-sel foglalkozik. Főleg fejlesztőknek és tervezőknek szól, és hatóságok és szabályozott területek számára gyakran ez a mérce. A **Server-Side-TLS-ajánlásokat**, amelyeket korábban a Mozilla-wikiben gondoztak, ma a TLSRef viszi tovább, és konkrét, másolható profilokat adnak.

A TLSRef a 6.0-s változatban két profilt különböztet meg:

| Jellemző | Intermediate (a legtöbb weboldalhoz) | Modern |
|---|---|---|
| Protokollok | TLS 1.2 és TLS 1.3 | csak TLS 1.3 |
| Cipher suite-ok TLS 1.2-nél | ECDHE AES-GCM-mel vagy ChaCha20-Poly1305-tel | nincs |
| Kulcscsere-csoportok | X25519MLKEM768, X25519, prime256v1, secp384r1 | mint az Intermediate-nál |
| Tanúsítvány | ECDSA P-256 ajánlott vagy RSA 2048 bit | ECDSA P-256 |
| Tanúsítvány futamideje | 90 nap ajánlott, legfeljebb 366 nap | 90 nap |
| HSTS max-age | két év | két év |

Nyilvános weboldalaknál az Intermediate a szokásos kiindulópont. A profil kizárja a nagyon régi eszközöket, de lefedi a mai böngészőket és operációs rendszereket. Az X25519MLKEM768 hibrid csoport friss TLS-könyvtárat feltételez. Mielőtt beírja, ellenőrizze, ismeri-e az Ön OpenSSL-verziója.

## Nginx és Apache: biztonságos kiindulópont

A következő példák az Intermediate profilt valósítják meg. Az útvonalak helyőrzők, a cipher suite-ok listája a TLS 1.2-re érvényes; a TLS 1.3 saját, biztonságos alapértelmezett eljárásokat hoz magával.

```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
```

A második `server` blokk tartósan HTTPS-re irányítja a titkosítatlan hívásokat. Az átirányítás közvetlenül a végleges címre mutasson, és ne több köztes állomáson haladjon át. Ezután ellenőrizze a beágyazott erőforrásokat is: a még HTTP-n betöltött képek, szkriptek vagy betűtípusok a böngészőben figyelmeztetést váltanak ki, vagy blokkolják őket.

Az a beállítás, hogy a kliens választja a sorrendet, megfelel a TLSRef ajánlásának: az összes kínált eljárás biztonságosnak számít, és az AES-gyorsítás nélküli eszközök így előnyben részesíthetik a ChaCha20-at. Minden módosítás után tesztelje a konfigurációt (`nginx -t`, illetve `apachectl configtest`), és töltse újra a szolgáltatást. A megfelelő HSTS-fejlécet és további böngészői előírásokat a [Biztonsági fejlécek weboldalakhoz](https://phpsos.de/hu/ratgeber/sicherheits-header/) útmutató írja le.

> **Tipp:**
> Az olyan panelek, mint a Plesk vagy a cPanel, a generált fájlokon végzett saját módosításokat gyakran felülírják. A TLS-előírásokat ott a panel erre szolgáló beállításaival vagy sablonjaival adja meg.

## Tanúsítványok: kulcs, lánc, megújítás

A gyakorlatban a TLS-problémák nagy része nem a cipher suite-okkal, hanem a tanúsítványokkal függ össze. Tipikus hibák a hiányos lánc, amelyből a köztes tanúsítvány hiányzik, a lejárt tanúsítványok mellékdomaineken, és a túl tág fájljogokkal rendelkező privát kulcsok.

Három szabály segít:

1. **Automatikusan megújítani**, és a megújítást felügyelni. A rövid futamidők, ahogyan a TLSRef ajánlja, csak automatizálással kivitelezhetők.
2. **Védeni a privát kulcsokat:** csak a root és a webszerver-folyamat számára olvashatók, soha nem a webrootban, soha nem egy repositoryban.
3. **Minden nevet felvenni:** főtartomány, www, aldomainek a webshophoz, stagingre, a levelezés webes felületéhez és a panelekhez.

Aki tanúsítványokat több helyen használ, például CDN-en, terheléselosztón és origin szerveren, vezessen áttekintést: melyik tanúsítvány hol van telepítve, ki újítja meg, és mikor jár le. Ha ez az áttekintés hiányzik, egy lejárt tanúsítvány gyakran csak akkor tűnik fel, amikor az ügyfelek jelentkeznek.

## Így ellenőrizze a konfigurációt kívülről

A következő parancsok tisztán ellenőrzések, és semmit sem módosítanak. A hosztnevet cserélje a sajátjára:

```bash
# A TLS 1.3-nak és a TLS 1.2-nek működnie kell
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
# A TLS 1.1-nek el kell buknia
openssl s_client -connect www.example.de:443 -servername www.example.de -tls1_1 </dev/null
# A kiszolgált tanúsítvány futamideje és birtokosa
openssl s_client -connect www.example.de:443 -servername www.example.de </dev/null 2>/dev/null | openssl x509 -noout -subject -dates
```

A TLS 1.1-teszt kudarca azon is múlhat, hogy a helyi OpenSSL-verziója a régi protokollt egyáltalán nem kínálja már. Az összes kínált eljárásról szóló teljes jelentéshez egy specializált TLS-szkenner alkalmas. Közben minden aldomaint külön ellenőrizzen, mert gyakran saját beállításokkal futnak.

## Elfelejtve: TLS ott, ahol a PHP maga a kliens

A PHP-alkalmazások maguk is sok kapcsolatot építenek fel: fizetési szolgáltatókhoz, szállítmányozókhoz, interfészekhez, levelezőszerverekhez és adatbázisokhoz. Itt a leggyakoribb hiba nem egy gyenge beállítás, hanem a tanúsítvány-ellenőrzés kikapcsolása, gyakran gyors megoldásként egy fejlesztési problémára.

```php
<?php
// Biztonságos: a tanúsítványt és a hosztnevet ellenőrzi (az alapértelmezett viselkedést megtartani)
$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);
```

Keresse a kódban a `false` értékű `CURLOPT_SSL_VERIFYPEER`-t és a `verify_peer`-t a stream-kontextusokban. Minden találat gyakorlatilag feloldja a TLS védelmét az adott kapcsolatnál. Ahol a szolgáltatások CDN mögött vannak, a CDN és az origin szerver közötti szakasz is érvényes, ellenőrzött tanúsítványt használjon. További webszerver-beállításokat PHP-környezetekhez a [Az Nginx biztonságos konfigurálása PHP-hez](https://phpsos.de/hu/blog/nginx-fuer-php-absichern/) cikkben talál, a teljes keményítés mércéit a [CIS-benchmarkok és BSI-modulok](https://phpsos.de/hu/blog/cis-benchmarks-bsi-bausteine/) cikkben.

## Hogyan segít konkrétan a PHP SOS?

- Felmérjük az összes hosztnevet és TLS-t használó szolgáltatást, beleértve a paneleket, a stagingt és a levelezés webes felületeit.
- A beállításokat összevetjük a TR-02102-vel és a megfelelő TLSRef-profillal, és dokumentáljuk a tudatos eltéréseket.
- A tanúsítványokat automatikus megújításra, felügyelettel állítjuk át.
- Az alkalmazáskódban kikapcsolt tanúsítvány-ellenőrzéseket keresünk, és megmutatjuk a javítást.

A TLS a [PHP-webszerverek keményítésének](https://phpsos.de/hu/leistungen/server-haertung/) egyik eleme; a mai helyzethez fűződő kapcsolatot a [Mi a PHP2Shell?](https://phpsos.de/hu/php2shell/was-ist-php2shell/) magyarázza el.


## Gyakori kérdések

**Továbbra is kínálnom kell a TLS 1.0-t és a TLS 1.1-et?**  
Általában nem. A friss ajánlások, például a TLSRef Intermediate profilja, a TLS 1.2-t jelölik meg alsó határként. Aki régi eszközök miatt régebbi protokollokra szorul, döntsön erről tudatosan, dokumentálja, és korlátozza egy különálló szolgáltatásra.

**Kevésbé biztonságos az ingyenes tanúsítvány, mint a vásárolt?**  
A titkosítás szempontjából nincs különbség. A kulcstípus, a kulcshossz, a teljes tanúsítványlánc és a megbízható automatikus megújítás számít. Különbségek az ellenőrzés mélységében, a futamidőben és a szolgáltató ügyfélszolgálatában vannak.

**Elég a HTTPS a látogató és a CDN között?**  
Nem. A CDN és az origin szerver közötti kapcsolatot is titkosítani kell, és az origin tanúsítványát ellenőrizni kell. Különben az adatok a második szakaszon titkosítatlanul vagy ellenőrizetlenül haladnak át a hálózaton.

**Mi köze a TLS-nek a PHP2Shellhez?**  
Közvetlenül semmi. A TLS az adatokat védi az átviteli úton, a PHP2Shell a szerveren lévő PHP-értelmezőt érinti. Egy titkosított kapcsolat a támadó kéréseket is megbízhatóan továbbítja, ezért a PHP-frissítés ettől függetlenül kötelező.

## Források

- [BSI TR-02102: Kriptográfiai eljárások, 2. rész: 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: Server-Side TLS Guidelines](https://docs.tlsref.org/)
- [Nginx dokumentáció](https://nginx.org/en/docs/)
- [Apache HTTP Server: dokumentáció](https://httpd.apache.org/docs/)