TLS un HTTPS pareiza konfigurēšana

Īsi sakot: Solīda TLS konfigurācija tīmekļa serverim piedāvā tikai TLS 1.2 un TLS 1.3, izmanto šifrēšanas komplektus ar Forward Secrecy un autentificētu šifrēšanu (AES-GCM, ChaCha20-Poly1305) un sertifikātu ar ECDSA vai pietiekami garu RSA atslēgu, kas pagarinās automātiski. Orientieri dod BSI (Vācijas Federālā informācijas drošības biroja) vadlīnija TR-02102-2 un TLSRef Server-Side TLS ieteikumi. Pārbaudiet rezultātu no ārpuses un neaizmirstiet savienojumus, ko veido pats PHP.

Kāpēc vecie TLS iestatījumi tik ilgi saglabājas

Atslēdziņa pārlūkprogrammā ir, tātad šifrēšana skaitās nokārtota. Tā domā daudzi operatori, un tāpēc TLS konfigurācija bieži paliek nemainīta gadiem. Tā tad ir cēlusies no servera iestatīšanas laika, no nokopēta parauga vai no paneļa noklusējuma vērtībām.

Problēma: ieteikumi mainās. Protokolu versijas tiek nomainītas, metodes vairs netiek uzskatītas par drošām, parādās jaunas atslēgu apmaiņas metodes. BSI TR-02102 pēdējo reizi publicējis versijā 2026-01 no 27.01.2026 un tur jau norāda uz hibrīdām pēckvantu metodēm TLS 1.3. Kas savus iestatījumus gadiem nav pārskatījis, ļoti iespējams, vairs neatbilst aktuālajam stāvoklim.

Kas tāpat tagad pārbauda serverus pēc PHP2Shell, TLS konfigurāciju var apskatīt vienlaikus. Tā PHP ievainojamību neaizver, bet pieder pie katras sakārtotas nostiprināšanas.

Uz ko balstās laba TLS konfigurācija tīmekļa serverim

Divi avoti ir operatoriem Eiropā īpaši noderīgi. BSI TR-02102 vērtē kriptogrāfijas metodes; 2. daļa aplūko TLS. Tā galvenokārt paredzēta izstrādātājiem un plānotājiem, un iestādēm un regulētām nozarēm tā bieži ir mērauklā. Server-Side TLS ieteikumus, agrāk kopta Mozilla wiki, tagad turpina TLSRef, un tie piedāvā konkrētus, kopējamus profilus.

TLSRef 6.0 versijā izšķir divus profilus:

Publiskām vietnēm Intermediate ir ierastais sākumpunkts. Profils izslēdz ļoti vecas ierīces, bet aptver aktuālos pārlūkus un operētājsistēmas. Hibrīdā grupa X25519MLKEM768 prasa aktuālu TLS bibliotēku. Pārbaudiet, vai jūsu OpenSSL versija to pazīst, pirms to ierakstāt.

Nginx un Apache: drošs sākumpunkts

Turpmākie piemēri īsteno Intermediate profilu. Ceļi ir vietturi, šifrēšanas komplektu saraksts attiecas uz TLS 1.2; TLS 1.3 nāk ar saviem drošajiem noklusējuma paņēmieniem.

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

Otrais server bloks nešifrētus izsaukumus pastāvīgi pāradresē uz HTTPS. Pāradresācijai jāvirza tieši uz galīgo adresi, nevis cauri vairākām starpstacijām. Pēc tam pārbaudiet arī iekļautos resursus: attēli, skripti vai fonti, kas joprojām tiek ielādēti pa HTTP, pārlūkā izraisa brīdinājumus vai tiek bloķēti.

Iestatījums, ka secību izvēlas klients, atbilst TLSRef ieteikumam: visas piedāvātās metodes uzskata par drošām, un ierīces bez AES paātrinājuma tā var dot priekšroku ChaCha20. Pēc katras izmaiņas konfigurāciju pārbaudiet (nginx -t resp. apachectl configtest) un pakalpojumu pārlādējiet. Piemēroto HSTS galveni un citus pārlūka norādījumus apraksta ceļvedis Drošības galvenes vietnēm.

Sertifikāti: atslēgas, ķēde, pagarināšana

Liela daļa TLS problēmu praksē nav saistīta ar šifrēšanas komplektiem, bet ar sertifikātiem. Tipiskas kļūdas ir nepilna ķēde, kurā trūkst starpsertifikāta, beigušies sertifikāti blakus domēniem un privātās atslēgas ar pārāk plašām failu tiesībām.

Palīdz trīs noteikumi:

1. Pagarināt automātiski un uzraudzīt pagarināšanu. Īsi derīguma termiņi, kādus iesaka TLSRef, praktiski iespējami tikai ar automatizāciju.
2. Aizsargāt privātās atslēgas: lasāmas tikai root un tīmekļa servera procesam, nekad ne tīmekļa saknē, nekad ne repozitorijā.
3. Aptvert visus vārdus: galvenais domēns, www, apakšdomēni veikalam, staging, pasta tīmekļa saskarnei un paneļiem.

Kas sertifikātus lieto vairākās vietās, piemēram, CDN, slodzes balansētājā un origin serverī, tam jāved pārskats: kurš sertifikāts kur instalēts, kas to pagarina un kad tas beidzas. Ja pārskata nav, beidzies sertifikāts bieži pamanāms tikai tad, kad ziņo klienti.

Kā pārbaudīt konfigurāciju no ārpuses

Turpmākās komandas ir tīras pārbaudes un neko nemaina. Aizstājiet hostvārdu ar savu:

# TLS 1.3 un TLS 1.2 vajadzētu darboties
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 vajadzētu neizdoties
openssl s_client -connect www.example.de:443 -servername www.example.de -tls1_1 </dev/null
# Piegādātā sertifikāta derīguma termiņš un īpašnieks
openssl s_client -connect www.example.de:443 -servername www.example.de </dev/null 2>/dev/null | openssl x509 -noout -subject -dates

TLS 1.1 testa neveiksme var būt arī tāpēc, ka jūsu lokālā OpenSSL versija vecāko protokolu vispār vairs nepiedāvā. Pilnam pārskatam par visām piedāvātajām metodēm der specializēts TLS skeneris. Pārbaudiet katru apakšdomēnu atsevišķi, jo tie bieži darbojas ar saviem iestatījumiem.

Aizmirsts: TLS tur, kur PHP pats ir klients

PHP lietojumprogrammas pašas veido daudz savienojumu: uz maksājumu sniedzējiem, piegādes pakalpojumiem, saskarnēm, pasta serveriem un datubāzēm. Šeit biežākā kļūda nav vājš iestatījums, bet izslēgta sertifikāta pārbaude, bieži kā ātrs risinājums problēmai izstrādes laikā.

<?php
// Droši: sertifikāts un hostvārds tiek pārbaudīti (saglabāt noklusējuma uzvedību)
$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);

Meklējiet kodā CURLOPT_SSL_VERIFYPEER ar false un verify_peer straumju kontekstos. Katrs atradums šim savienojumam praktiski atceļ TLS aizsardzību. Kur pakalpojumi atrodas aiz CDN, arī posmam starp CDN un origin serveri jāizmanto derīgs, pārbaudīts sertifikāts. Citus tīmekļa servera iestatījumus PHP uzstādījumiem atradīsiet rakstā Nginx droša konfigurēšana PHP, mērauklas visai nostiprināšanai rakstā CIS Benchmarks un BSI moduļi.

Kā PHP SOS palīdz konkrēti?

• Mēs apkopojam visus hostvārdus un pakalpojumus ar TLS, ieskaitot paneļus, staging un pasta tīmekļa saskarnes.
• Mēs salīdzinām iestatījumus ar TR-02102 un piemēroto TLSRef profilu un dokumentējam apzinātas atkāpes.
• Mēs pārejam uz sertifikātu automātisku pagarināšanu ar uzraudzību.
• Mēs meklējam lietojumprogrammas kodā izslēgtas sertifikātu pārbaudes un parādām labojumu.

TLS ir viens no mūsu PHP tīmekļa serveru nostiprināšanas elementiem; saistību ar pašreizējo situāciju skaidro raksts Kas ir PHP2Shell?.

Biežāk uzdotie jautājumi

Avoti

• BSI TR-02102: kriptogrāfijas metodes, 2. daļa TLS
• TLSRef: Server-Side TLS Guidelines
• Nginx dokumentācija
• Apache HTTP Server: dokumentācija