Konfigurer TLS og HTTPS rigtigt

Kort sagt: En solid TLS-konfiguration til webservere tilbyder kun TLS 1.2 og TLS 1.3, bruger cipher suites med Forward Secrecy og autentificeret kryptering (AES-GCM, ChaCha20-Poly1305) og et certifikat med ECDSA- eller tilstrækkeligt lang RSA-nøgle, som fornyes automatisk. Vejledning giver BSI-retningslinjen TR-02102-2 (BSI er det tyske forbundsagentur for informationssikkerhed) og Server-Side-TLS-anbefalingerne fra TLSRef. Kontrollér resultatet udefra, og glem ikke de forbindelser, PHP selv opbygger.

Hvorfor gamle TLS-indstillinger overlever så længe

Låsen i browseren er der, så krypteringen anses for afklaret. Sådan tænker mange driftsansvarlige, og derfor forbliver TLS-konfigurationen ofte uændret i årevis. Den stammer så fra tidspunktet for serveropsætningen, fra en kopieret skabelon eller fra et kontrolpanels standardværdier.

Problemet: Anbefalinger ændrer sig. Protokolversioner afløses, metoder anses for svage, nye nøgleudvekslingsmetoder kommer til. BSI har senest udgivet TR-02102 i versionen 2026-01 af 27.01.2026 og peger dér allerede på hybride post-kvantemetoder til TLS 1.3. Den, der ikke har set på sine indstillinger i årevis, ligger med høj sandsynlighed ikke længere på det aktuelle niveau.

Den, der alligevel gennemgår servere efter PHP2Shell, kan kigge på TLS-konfigurationen i samme omgang. Den lukker ikke PHP-sårbarheden, men hører til enhver ordentlig hærdning.

Hvad en god TLS-konfiguration til webservere bygger på

To kilder er særligt nyttige for driftsansvarlige i Europa. BSI TR-02102 vurderer kryptografiske metoder; del 2 behandler TLS. Den henvender sig først og fremmest til udviklere og planlæggere og er ofte målestokken for myndigheder og regulerede områder. Server-Side-TLS-anbefalingerne, tidligere vedligeholdt i Mozilla-wikien, føres i dag videre under TLSRef og leverer konkrete profiler, der kan kopieres.

TLSRef skelner i version 6.0 mellem to profiler:

For offentlige websites er Intermediate det sædvanlige udgangspunkt. Profilen udelukker meget gamle enheder, men dækker aktuelle browsere og operativsystemer. Den hybride gruppe X25519MLKEM768 forudsætter et aktuelt TLS-bibliotek. Kontrollér, om jeres OpenSSL-version kender den, før I tilføjer den.

Nginx og Apache: et sikkert udgangspunkt

De følgende eksempler gennemfører Intermediate-profilen. Stier er pladsholdere, listen over cipher suites gælder for TLS 1.2; TLS 1.3 medbringer egne, sikre standardmetoder.

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

Den anden server-blok sender ukrypterede kald permanent videre til HTTPS. Omdirigeringen bør pege direkte på den endelige adresse og ikke løbe via flere mellemstationer. Kontrollér derefter også indlejrede ressourcer: Billeder, scripts eller skrifttyper, der stadig indlæses via HTTP, udløser advarsler i browseren eller bliver blokeret.

Indstillingen, hvor klienten vælger rækkefølgen, svarer til TLSRef-anbefalingen: Alle tilbudte metoder anses for sikre, og enheder uden AES-acceleration kan på den måde foretrække ChaCha20. Efter hver ændring testes konfigurationen (nginx -t hhv. apachectl configtest), og tjenesten genindlæses. Den passende HSTS-header og yderligere browserkrav beskriver vejledningen Sikkerhedsheadere til websites.

Certifikater: Nøgle, kæde, fornyelse

En stor del af TLS-problemerne i praksis har intet med cipher suites at gøre, men med certifikater. Typiske fejl er en ufuldstændig kæde, hvor mellemcertifikatet mangler, udløbne certifikater på sidedomæner og private nøgler med for vide filrettigheder.

Tre regler hjælper:

1. Forny automatisk og overvåg fornyelsen. Korte løbetider, som TLSRef anbefaler, er kun praktikable med automatisering.
2. Beskyt private nøgler: kun læsbare for root og webserverprocessen, aldrig i webroot, aldrig i et repository.
3. Registrér alle navne: hoveddomæne, www, subdomæner til shop, staging, mailwebgrænseflade og paneler.

Den, der bruger certifikater flere steder, f.eks. på CDN, load balancer og oprindelsesserver, bør føre en oversigt: hvilket certifikat der er installeret hvor, hvem der fornyer det, og hvornår det udløber. Mangler denne oversigt, opdages et udløbet certifikat ofte først, når kunder henvender sig.

Sådan kontrollerer I jeres konfiguration udefra

De følgende kommandoer er rene kontroller og ændrer intet. Erstat værtsnavnet med jeres eget:

# TLS 1.3 og TLS 1.2 bør fungere
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 bør mislykkes
openssl s_client -connect www.example.de:443 -servername www.example.de -tls1_1 </dev/null
# Løbetid og indehaver af det leverede certifikat
openssl s_client -connect www.example.de:443 -servername www.example.de </dev/null 2>/dev/null | openssl x509 -noout -subject -dates

Et mislykket TLS-1.1-test kan også skyldes, at jeres lokale OpenSSL-version slet ikke længere tilbyder den gamle protokol. Til en fuldstændig rapport over alle tilbudte metoder egner en specialiseret TLS-scanner sig. Kontrollér her hvert subdomæne for sig, for de kører ofte med egne indstillinger.

Glemt: TLS dér, hvor PHP selv er klient

PHP-applikationer opbygger selv mange forbindelser: til betalingsudbydere, forsendelsesudbydere, grænseflader, mailservere og databaser. Her er den hyppigste fejl ikke en svag indstilling, men en deaktiveret kontrol af certifikatet, ofte som hurtig løsning på et problem under udviklingen.

<?php
// Sikkert: Certifikat og værtsnavn kontrolleres (bevar standardadfærden)
$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);

Søg i koden efter CURLOPT_SSL_VERIFYPEER med false og efter verify_peer i stream-kontekster. Hvert fund ophæver i praksis TLS' beskyttelse for den forbindelse. Hvor tjenester ligger bag et CDN, bør også strækningen mellem CDN og oprindelsesserver bruge et gyldigt, kontrolleret certifikat. Yderligere webserverindstillinger til PHP-opsætninger finder I under Konfigurer Nginx sikkert til PHP, målestokke for hele hærdningen under CIS-benchmarks og BSI-moduler.

Hvordan hjælper PHP SOS konkret?

• Vi registrerer alle værtsnavne og tjenester med TLS, herunder paneler, staging og mailwebgrænseflader.
• Vi afstemmer indstillingerne med TR-02102 og den passende TLSRef-profil og dokumenterer bevidste afvigelser.
• Vi omstiller certifikater til automatisk fornyelse med overvågning.
• Vi søger i applikationskoden efter deaktiverede certifikatkontroller og viser rettelsen.

TLS er en byggesten i vores serverhærdning til PHP-webservere; sammenhængen med den aktuelle situation forklarer Hvad er PHP2Shell?.

Ofte stillede spørgsmål

Kilder

• BSI TR-02102: Kryptografiske metoder, del 2 TLS
• TLSRef: Server-Side TLS Guidelines
• Nginx-dokumentation
• Apache HTTP Server: Dokumentation