Kort gezegd: Een degelijke TLS-configuratie voor webservers biedt alleen TLS 1.2 en TLS 1.3 aan, gebruikt cipher suites met forward secrecy en geauthenticeerde versleuteling (AES-GCM, ChaCha20-Poly1305) en een certificaat met een ECDSA-sleutel of een voldoende lange RSA-sleutel dat zich automatisch verlengt. Richtsnoer zijn de BSI-richtlijn (BSI is de Duitse federale dienst voor informatiebeveiliging) TR-02102-2 en de Server-Side-TLS-aanbevelingen van TLSRef. Controleer het resultaat van buitenaf en vergeet de verbindingen niet die PHP zelf opbouwt.
Waarom oude TLS-instellingen zo lang blijven bestaan
Het slotje in de browser staat er, dus de versleuteling geldt als afgehandeld. Zo denken veel beheerders, en daarom blijft de TLS-configuratie vaak jarenlang ongewijzigd. Ze stamt dan uit de tijd van de serverinrichting, uit een gekopieerd sjabloon of uit de standaardwaarden van een paneel.
Het probleem: aanbevelingen veranderen. Protocolversies worden afgelost, methoden gelden als zwak, nieuwe sleuteluitwisselingsmethoden komen erbij. De BSI heeft de TR-02102 het laatst gepubliceerd in versie 2026-01 van 27-01-2026 en wijst daarin al op hybride post-kwantummethoden voor TLS 1.3. Wie zijn instellingen al jaren niet heeft bekeken, loopt met grote waarschijnlijkheid niet meer op het actuele niveau.
Wie na PHP2Shell toch servers controleert, kan de TLS-configuratie in één keer meenemen. Ze dicht de PHP-kwetsbaarheid niet, maar hoort bij elke zorgvuldige hardening.
Waarop een goede TLS-configuratie voor webservers is gebaseerd
Twee bronnen zijn voor beheerders in Europa bijzonder nuttig. De BSI TR-02102 beoordeelt cryptografische methoden; deel 2 behandelt TLS. Ze richt zich vooral op ontwikkelaars en planners en is voor overheden en gereguleerde sectoren vaak de maatstaf. De Server-Side-TLS-aanbevelingen, vroeger bijgehouden in de Mozilla-wiki, worden tegenwoordig onder TLSRef voortgezet en leveren concrete, te kopiëren profielen.
TLSRef onderscheidt in versie 6.0 twee profielen:
| Kenmerk | Intermediate (voor de meeste websites) | Modern |
|---|---|---|
| Protocollen | TLS 1.2 en TLS 1.3 | alleen TLS 1.3 |
| Cipher suites TLS 1.2 | ECDHE met AES-GCM of ChaCha20-Poly1305 | geen |
| Sleuteluitwisselingsgroepen | X25519MLKEM768, X25519, prime256v1, secp384r1 | als Intermediate |
| Certificaat | ECDSA P-256 aanbevolen of RSA 2048 bit | ECDSA P-256 |
| Looptijd certificaat | 90 dagen aanbevolen, maximaal 366 dagen | 90 dagen |
| HSTS max-age | twee jaar | twee jaar |
Voor openbare websites is Intermediate het gebruikelijke uitgangspunt. Het profiel sluit zeer oude apparaten uit, maar dekt actuele browsers en besturingssystemen. De hybride groep X25519MLKEM768 vereist een actuele TLS-bibliotheek. Controleer of uw OpenSSL-versie haar kent voordat u haar opneemt.
Nginx en Apache: een veilig uitgangspunt
De volgende voorbeelden voeren het Intermediate-profiel door. Paden zijn plaatshouders, de lijst met cipher suites geldt voor TLS 1.2; TLS 1.3 brengt eigen, veilige standaardmethoden mee.
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
Het tweede server-blok verwijst onversleutelde aanroepen permanent door naar HTTPS. De doorverwijzing hoort rechtstreeks naar het definitieve adres te wijzen en niet via meerdere tussenstations te lopen. Controleer daarna ook ingesloten bronnen: afbeeldingen, scripts of lettertypen die nog via HTTP worden geladen, veroorzaken in de browser waarschuwingen of worden geblokkeerd.
De instelling dat de client de volgorde kiest, komt overeen met de TLSRef-aanbeveling: alle aangeboden methoden gelden als veilig en apparaten zonder AES-versnelling kunnen zo ChaCha20 prefereren. Test na elke wijziging de configuratie (nginx -t respectievelijk apachectl configtest) en laad de dienst opnieuw. De passende HSTS-header en andere browservoorschriften beschrijft de gids Beveiligingsheaders voor websites.
Panelen zoals Plesk of cPanel overschrijven eigen wijzigingen in gegenereerde bestanden vaak. Stel TLS-voorschriften daar in via de daarvoor bedoelde instellingen of sjablonen van het paneel.
Certificaten: sleutel, keten, verlenging
Een groot deel van de TLS-problemen in de praktijk heeft niets met cipher suites te maken, maar met certificaten. Typische fouten zijn een onvolledige keten waarin het tussencertificaat ontbreekt, verlopen certificaten op nevendomeinen en private sleutels met te ruime bestandsrechten.
Drie regels helpen:
- Automatisch verlengen en de verlenging bewaken. Korte looptijden, zoals TLSRef die aanbeveelt, zijn alleen met automatisering haalbaar.
- Private sleutels beschermen: alleen leesbaar voor root en het webserverproces, nooit in de webroot, nooit in een repository.
- Alle namen inventariseren: hoofddomein, www, subdomeinen voor webshop, staging, webinterface voor e-mail en panelen.
Wie certificaten op meerdere plaatsen inzet, bijvoorbeeld op CDN, load balancer en oorspronkelijke server, doet er goed aan een overzicht bij te houden: welk certificaat waar is geïnstalleerd, wie het verlengt en wanneer het verloopt. Ontbreekt dat overzicht, dan valt een verlopen certificaat vaak pas op wanneer klanten zich melden.
Zo controleert u uw configuratie van buitenaf
De volgende opdrachten zijn pure controles en wijzigen niets. Vervang de hostnaam door uw eigen:
# TLS 1.3 en TLS 1.2 horen te werken
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 hoort te mislukken
openssl s_client -connect www.example.de:443 -servername www.example.de -tls1_1 </dev/null
# Looptijd en houder van het uitgeleverde certificaat
openssl s_client -connect www.example.de:443 -servername www.example.de </dev/null 2>/dev/null | openssl x509 -noout -subject -dates
Een mislukte TLS-1.1-test kan er ook aan liggen dat uw lokale OpenSSL-versie het oude protocol helemaal niet meer aanbiedt. Voor een volledig rapport over alle aangeboden methoden is een gespecialiseerde TLS-scanner geschikt. Controleer daarbij elk subdomein afzonderlijk, want die draaien vaak met eigen instellingen.
Vergeten: TLS waar PHP zelf client is
PHP-toepassingen bouwen zelf veel verbindingen op: naar betaalproviders, verzenddiensten, interfaces, mailservers en databases. De meest voorkomende fout is hier niet een zwakke instelling, maar een uitgeschakelde controle van het certificaat, vaak als snelle oplossing voor een probleem tijdens de ontwikkeling.
<?php
// Veilig: certificaat en hostnaam worden gecontroleerd (standaardgedrag behouden)
$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);
Zoek in de code naar CURLOPT_SSL_VERIFYPEER met false en naar verify_peer in stream-contexten. Elke vindplaats heft de bescherming van TLS voor die verbinding in de praktijk op. Liggen diensten achter een CDN, dan hoort ook het traject tussen CDN en oorspronkelijke server een geldig, gecontroleerd certificaat te gebruiken. Meer webserverinstellingen voor PHP-opstellingen vindt u onder Nginx veilig configureren voor PHP, maatstaven voor de hele hardening onder CIS-benchmarks en BSI-bouwstenen.
Hoe helpt PHP SOS concreet?
- Wij inventariseren alle hostnamen en diensten met TLS, inclusief panelen, staging en webinterfaces voor e-mail.
- Wij vergelijken de instellingen met TR-02102 en het passende TLSRef-profiel en documenteren bewuste afwijkingen.
- Wij zetten certificaten om naar automatische verlenging met bewaking.
- Wij zoeken in de applicatiecode naar uitgeschakelde certificaatcontroles en tonen de correctie.
TLS is een bouwsteen van onze serverhardening voor PHP-webservers; het verband met de actuele situatie legt Wat is PHP2Shell? uit.
Veelgestelde vragen
Moet ik TLS 1.0 en TLS 1.1 nog aanbieden?
In de regel niet. Actuele aanbevelingen zoals het Intermediate-profiel van TLSRef nemen TLS 1.2 als ondergrens. Wie oudere protocollen nodig heeft voor oude apparaten, moet dat bewust beslissen, documenteren en beperken tot een afzonderlijke dienst.
Is een gratis certificaat minder veilig dan een gekocht certificaat?
Voor de versleuteling maakt dat geen verschil. Beslissend zijn het sleuteltype, de sleutellengte, een volledige certificaatketen en een betrouwbare automatische verlenging. Verschillen zijn er in de omvang van de controle, de looptijd en de service van de aanbieder.
Is HTTPS tussen bezoeker en CDN genoeg?
Nee. Ook de verbinding tussen CDN en oorspronkelijke server hoort versleuteld te zijn en het certificaat van de oorspronkelijke server te controleren. Anders lopen gegevens op het tweede traject onversleuteld of ongecontroleerd door het netwerk.
Wat heeft TLS met PHP2Shell te maken?
Rechtstreeks niets. TLS beschermt gegevens tijdens het transport, PHP2Shell betreft de PHP-interpreter op de server. Een versleutelde verbinding vervoert ook aanvalsverzoeken betrouwbaar, daarom blijft de PHP-update hoe dan ook verplicht.