Konfigurera TLS och HTTPS rätt

Kort sagt: En solid TLS-konfiguration för webbservrar erbjuder bara TLS 1.2 och TLS 1.3, använder cipher suites med Forward Secrecy och autentiserad kryptering (AES-GCM, ChaCha20-Poly1305) och ett certifikat med ECDSA- eller tillräckligt lång RSA-nyckel som förnyas automatiskt. Vägledning ger riktlinjen TR-02102-2 från BSI (den tyska federala myndigheten för informationssäkerhet) och Server-Side-TLS-rekommendationerna från TLSRef. Kontrollera resultatet utifrån och glöm inte de anslutningar som PHP själv bygger upp.

Varför gamla TLS-inställningar överlever så länge

Låset i webbläsaren finns där, alltså anses krypteringen vara avklarad. Så tänker många driftansvariga, och därför förblir TLS-konfigurationen ofta oförändrad i åratal. Den härstammar då från tiden då servern sattes upp, från en kopierad mall eller från en panels standardvärden.

Problemet: Rekommendationer ändras. Protokollversioner ersätts, metoder anses svaga, nya nyckelutbytesmetoder tillkommer. BSI har senast publicerat TR-02102 i versionen 2026-01 av den 27.01.2026 och hänvisar där redan till hybrida post-kvantmetoder för TLS 1.3. Den som inte har tittat på sina inställningar på åratal ligger med stor sannolikhet inte längre på aktuell nivå.

Den som ändå går igenom servrar efter PHP2Shell kan titta på TLS-konfigurationen i samma veva. Den stänger inte PHP-sårbarheten men hör till varje ordentlig härdning.

Vad en bra TLS-konfiguration för webbservrar utgår från

Två källor är särskilt användbara för driftansvariga i Europa. BSI TR-02102 bedömer kryptografiska metoder; del 2 behandlar TLS. Den riktar sig främst till utvecklare och planerare och är för myndigheter och reglerade områden ofta måttstocken. Server-Side-TLS-rekommendationerna, tidigare underhållna i Mozillas wiki, förs i dag vidare under TLSRef och ger konkreta profiler som går att kopiera.

TLSRef skiljer i version 6.0 mellan två profiler:

För offentliga webbplatser är Intermediate den vanliga utgångspunkten. Profilen utesluter mycket gamla enheter men täcker aktuella webbläsare och operativsystem. Den hybrida gruppen X25519MLKEM768 förutsätter ett aktuellt TLS-bibliotek. Kontrollera att er OpenSSL-version känner till den innan ni för in den.

Nginx och Apache: en säker utgångspunkt

Följande exempel genomför Intermediate-profilen. Sökvägar är platshållare, listan över cipher suites gäller för TLS 1.2; TLS 1.3 har egna, säkra standardmetoder med sig.

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

Det andra server-blocket leder okrypterade anrop permanent om till HTTPS. Omdirigeringen bör peka direkt på den slutliga adressen och inte gå via flera mellanstationer. Kontrollera därefter även inbäddade resurser: bilder, skript eller typsnitt som fortfarande laddas via HTTP utlöser varningar i webbläsaren eller blockeras.

Inställningen att klienten väljer ordningen motsvarar TLSRef-rekommendationen: Alla erbjudna metoder anses säkra, och enheter utan AES-acceleration kan på så sätt föredra ChaCha20. Testa konfigurationen efter varje ändring (nginx -t respektive apachectl configtest) och ladda om tjänsten. Lämplig HSTS-header och andra webbläsarföreskrifter beskriver guiden Säkerhetsheaders för webbplatser.

Certifikat: nyckel, kedja, förnyelse

En stor del av TLS-problemen i praktiken har inget med cipher suites att göra utan med certifikat. Typiska fel är en ofullständig kedja där mellancertifikatet saknas, utgångna certifikat på underordnade domäner och privata nycklar med för vida filrättigheter.

Tre regler hjälper:

1. Förnya automatiskt och övervaka förnyelsen. Korta giltighetstider, som TLSRef rekommenderar, är bara praktiskt genomförbara med automatisering.
2. Skydda privata nycklar: läsbara bara för root och webbserverprocessen, aldrig i webbroten, aldrig i ett repository.
3. Registrera alla namn: huvuddomän, www, underdomäner för butik, staging, webbgränssnitt för e-post och paneler.

Den som använder certifikat på flera ställen, till exempel på CDN, lastbalanserare och ursprungsserver, bör föra en översikt: vilket certifikat som är installerat var, vem som förnyar det och när det går ut. Saknas översikten märks ett utgånget certifikat ofta först när kunderna hör av sig.

Så kontrollerar ni er konfiguration utifrån

Följande kommandon är rena kontroller och ändrar ingenting. Ersätt värdnamnet med ert eget:

# TLS 1.3 och TLS 1.2 ska fungera
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 ska misslyckas
openssl s_client -connect www.example.de:443 -servername www.example.de -tls1_1 </dev/null
# Giltighetstid och innehavare för det levererade certifikatet
openssl s_client -connect www.example.de:443 -servername www.example.de </dev/null 2>/dev/null | openssl x509 -noout -subject -dates

Ett misslyckande vid TLS-1.1-testet kan också bero på att er lokala OpenSSL-version inte längre erbjuder det gamla protokollet alls. För en fullständig rapport över alla erbjudna metoder lämpar sig en specialiserad TLS-skanner. Kontrollera då varje underdomän för sig, eftersom de ofta körs med egna inställningar.

Glömt: TLS där PHP själv är klient

PHP-applikationer bygger själva upp många anslutningar: till betalleverantörer, fraktleverantörer, gränssnitt, e-postservrar och databaser. Här är det vanligaste felet inte en svag inställning utan en avstängd kontroll av certifikatet, ofta som snabb lösning på ett problem under utvecklingen.

<?php
// Säkert: certifikat och värdnamn kontrolleras (behåll standardbeteendet)
$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ök i koden efter CURLOPT_SSL_VERIFYPEER med false och efter verify_peer i stream-kontexter. Varje fynd upphäver i praktiken TLS-skyddet för den anslutningen. Där tjänster ligger bakom ett CDN bör även sträckan mellan CDN och ursprungsserver använda ett giltigt, kontrollerat certifikat. Fler webbserverinställningar för PHP-miljöer hittar ni under Konfigurera Nginx säkert för PHP, måttstockar för hela härdningen under CIS-benchmarks och BSI-moduler.

Hur hjälper PHP SOS konkret?

• Vi registrerar alla värdnamn och tjänster med TLS, inklusive paneler, staging och webbgränssnitt för e-post.
• Vi jämför inställningarna med TR-02102 och lämplig TLSRef-profil och dokumenterar medvetna avvikelser.
• Vi ställer om certifikat till automatisk förnyelse med övervakning.
• Vi söker i applikationskoden efter avstängda certifikatkontroller och visar rättelsen.

TLS är en modul i vår serverhärdning för PHP-webbservrar; kopplingen till det aktuella läget förklarar Vad är PHP2Shell?.

Vanliga frågor

Källor

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