# TLS und HTTPS richtig konfigurieren

> TLS-Konfiguration für Webserver nach BSI TR-02102 und TLSRef: Protokolle, Cipher Suites, Zertifikate und Prüfbefehle für Nginx, Apache und PHP-Clients.

Quelle: https://phpsos.de/blog/tls-https-richtig-konfigurieren/  
Stand: 25.10.2026  
Anbieter: PHP SOS, PHP-Notfallhilfe und Server-Sicherheit. Soforthilfe per WhatsApp: https://wa.me/491736494914?text=Hallo%20PHP%20SOS%2C%20wir%20brauchen%20Hilfe%20mit%20unserem%20PHP-Server.%20Firma%3A%20%E2%80%A6%20Website%3A%20%E2%80%A6

**Kurz gesagt:** Eine solide TLS-Konfiguration für Webserver bietet nur TLS 1.2 und TLS 1.3 an, nutzt Cipher Suites mit Forward Secrecy und authentifizierter Verschlüsselung (AES-GCM, ChaCha20-Poly1305) und ein Zertifikat mit ECDSA- oder ausreichend langem RSA-Schlüssel, das sich automatisch verlängert. Orientierung geben die BSI-Richtlinie TR-02102-2 und die Server-Side-TLS-Empfehlungen von TLSRef. Prüfen Sie das Ergebnis von außen und vergessen Sie nicht die Verbindungen, die PHP selbst aufbaut.

## Warum alte TLS-Einstellungen so lange überleben

Das Schloss im Browser ist da, also gilt die Verschlüsselung als erledigt. So denken viele Betreiber, und deshalb bleibt die TLS-Konfiguration oft jahrelang unverändert. Sie stammt dann aus der Zeit der Servereinrichtung, aus einer kopierten Vorlage oder aus den Standardwerten eines Panels.

Das Problem: Empfehlungen ändern sich. Protokollversionen werden abgelöst, Verfahren gelten als schwach, neue Schlüsselaustauschverfahren kommen hinzu. Das BSI hat die TR-02102 zuletzt in der Version 2026-01 vom 27.01.2026 veröffentlicht und weist dort bereits auf hybride Post-Quanten-Verfahren für TLS 1.3 hin. Wer seine Einstellungen seit Jahren nicht angesehen hat, liegt mit hoher Wahrscheinlichkeit nicht mehr auf dem aktuellen Stand.

Wer ohnehin gerade Server nach PHP2Shell überprüft, kann die TLS-Konfiguration in einem Zug mit ansehen. Sie schließt die PHP-Lücke nicht, gehört aber zu jeder sauberen Härtung.

## Woran sich eine gute TLS-Konfiguration für Webserver orientiert

Zwei Quellen sind für Betreiber in Deutschland besonders nützlich. Die **BSI TR-02102** bewertet kryptografische Verfahren; Teil 2 behandelt TLS. Sie richtet sich vor allem an Entwickler und Planer und ist für Behörden und regulierte Bereiche oft der Maßstab. Die **Server-Side-TLS-Empfehlungen**, früher im Mozilla-Wiki gepflegt, werden heute unter TLSRef weitergeführt und liefern konkrete, kopierbare Profile.

TLSRef unterscheidet in Version 6.0 zwei Profile:

| Merkmal | Intermediate (für die meisten Websites) | Modern |
|---|---|---|
| Protokolle | TLS 1.2 und TLS 1.3 | nur TLS 1.3 |
| Cipher Suites TLS 1.2 | ECDHE mit AES-GCM oder ChaCha20-Poly1305 | keine |
| Schlüsselaustausch-Gruppen | X25519MLKEM768, X25519, prime256v1, secp384r1 | wie Intermediate |
| Zertifikat | ECDSA P-256 empfohlen oder RSA 2048 Bit | ECDSA P-256 |
| Zertifikatslaufzeit | 90 Tage empfohlen, höchstens 366 Tage | 90 Tage |
| HSTS max-age | zwei Jahre | zwei Jahre |

Für öffentliche Websites ist Intermediate der übliche Ausgangspunkt. Das Profil schließt sehr alte Geräte aus, deckt aber aktuelle Browser und Betriebssysteme ab. Die hybride Gruppe X25519MLKEM768 setzt eine aktuelle TLS-Bibliothek voraus. Prüfen Sie, ob Ihre OpenSSL-Version sie kennt, bevor Sie sie eintragen.

## Nginx und Apache: ein sicherer Ausgangspunkt

Die folgenden Beispiele setzen das Intermediate-Profil um. Pfade sind Platzhalter, die Liste der Cipher Suites gilt für TLS 1.2; TLS 1.3 bringt eigene, sichere Standardverfahren mit.

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

Der zweite `server`-Block leitet unverschlüsselte Aufrufe dauerhaft auf HTTPS um. Die Umleitung sollte direkt auf die endgültige Adresse zeigen und nicht über mehrere Zwischenstationen laufen. Prüfen Sie danach auch eingebundene Ressourcen: Bilder, Skripte oder Schriften, die noch per HTTP geladen werden, lösen im Browser Warnungen aus oder werden blockiert.

Die Einstellung, dass der Client die Reihenfolge wählt, entspricht der TLSRef-Empfehlung: Alle angebotenen Verfahren gelten als sicher, und Geräte ohne AES-Beschleunigung können so ChaCha20 bevorzugen. Nach jeder Änderung die Konfiguration testen (`nginx -t` beziehungsweise `apachectl configtest`) und den Dienst neu laden. Den passenden HSTS-Header und weitere Browser-Vorgaben beschreibt der Ratgeber [Sicherheits-Header für Websites](https://phpsos.de/ratgeber/sicherheits-header/).

> **Tipp:**
> Panels wie Plesk oder cPanel überschreiben eigene Änderungen an generierten Dateien häufig. Setzen Sie TLS-Vorgaben dort über die vorgesehenen Einstellungen oder Vorlagen des Panels.

## Zertifikate: Schlüssel, Kette, Verlängerung

Ein Großteil der TLS-Probleme in der Praxis hat nichts mit Cipher Suites zu tun, sondern mit Zertifikaten. Typische Fehler sind eine unvollständige Kette, bei der das Zwischenzertifikat fehlt, abgelaufene Zertifikate auf Nebendomains und private Schlüssel mit zu weiten Dateirechten.

Drei Regeln helfen:

1. **Automatisch verlängern** und die Verlängerung überwachen. Kurze Laufzeiten, wie TLSRef sie empfiehlt, sind nur mit Automatisierung praktikabel.
2. **Private Schlüssel schützen:** nur für root und den Webserver-Prozess lesbar, nie im Webroot, nie in einem Repository.
3. **Alle Namen erfassen:** Hauptdomain, www, Subdomains für Shop, Staging, Mail-Weboberfläche und Panels.

Wer Zertifikate an mehreren Stellen einsetzt, etwa auf CDN, Load Balancer und Ursprungsserver, sollte eine Übersicht führen: welches Zertifikat wo installiert ist, wer es verlängert und wann es abläuft. Fehlt diese Übersicht, fällt ein abgelaufenes Zertifikat oft erst auf, wenn Kunden sich melden.

## So prüfen Sie Ihre Konfiguration von außen

Die folgenden Befehle sind reine Prüfungen und verändern nichts. Ersetzen Sie den Hostnamen durch Ihren eigenen:

```bash
# TLS 1.3 und TLS 1.2 sollten funktionieren
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 sollte scheitern
openssl s_client -connect www.example.de:443 -servername www.example.de -tls1_1 </dev/null
# Laufzeit und Inhaber des ausgelieferten Zertifikats
openssl s_client -connect www.example.de:443 -servername www.example.de </dev/null 2>/dev/null | openssl x509 -noout -subject -dates
```

Ein Fehlschlag beim TLS-1.1-Test kann auch daran liegen, dass Ihre lokale OpenSSL-Version das alte Protokoll gar nicht mehr anbietet. Für einen vollständigen Bericht über alle angebotenen Verfahren eignet sich ein spezialisierter TLS-Scanner. Prüfen Sie dabei jede Subdomain einzeln, denn sie laufen oft mit eigenen Einstellungen.

## Vergessen: TLS dort, wo PHP selbst Client ist

PHP-Anwendungen bauen selbst viele Verbindungen auf: zu Zahlungsanbietern, Versanddienstleistern, Schnittstellen, Mailservern und Datenbanken. Hier ist der häufigste Fehler nicht eine schwache Einstellung, sondern eine abgeschaltete Prüfung des Zertifikats, oft als schnelle Lösung für ein Problem in der Entwicklung.

```php
<?php
// Sicher: Zertifikat und Hostname werden geprüft (Standardverhalten beibehalten)
$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);
```

Suchen Sie im Code nach `CURLOPT_SSL_VERIFYPEER` mit `false` und nach `verify_peer` in Stream-Kontexten. Jede Fundstelle hebt den Schutz von TLS für diese Verbindung praktisch auf. Wo Dienste hinter einem CDN liegen, sollte auch die Strecke zwischen CDN und Ursprungsserver ein gültiges, geprüftes Zertifikat verwenden. Weitere Webserver-Einstellungen für PHP-Setups finden Sie unter [Nginx für PHP sicher konfigurieren](https://phpsos.de/blog/nginx-fuer-php-absichern/), Maßstäbe für die gesamte Härtung unter [CIS-Benchmarks und BSI-Bausteine](https://phpsos.de/blog/cis-benchmarks-bsi-bausteine/).

## Wie hilft PHP SOS konkret?

- Wir erfassen alle Hostnamen und Dienste mit TLS, einschließlich Panels, Staging und Mail-Weboberflächen.
- Wir gleichen die Einstellungen mit TR-02102 und dem passenden TLSRef-Profil ab und dokumentieren bewusste Abweichungen.
- Wir stellen Zertifikate auf automatische Verlängerung mit Überwachung um.
- Wir suchen im Anwendungscode nach abgeschalteten Zertifikatsprüfungen und zeigen die Korrektur.

TLS ist ein Baustein unserer [Server-Härtung für PHP-Webserver](https://phpsos.de/leistungen/server-haertung/); den Bezug zur aktuellen Lage erklärt [Was ist PHP2Shell?](https://phpsos.de/php2shell/was-ist-php2shell/).


## Häufige Fragen

**Muss ich TLS 1.0 und TLS 1.1 noch anbieten?**  
In aller Regel nicht. Aktuelle Empfehlungen wie das Intermediate-Profil von TLSRef setzen TLS 1.2 als Untergrenze. Wer ältere Protokolle für Altgeräte braucht, sollte das bewusst entscheiden, dokumentieren und auf einen getrennten Dienst beschränken.

**Ist ein kostenloses Zertifikat weniger sicher als ein gekauftes?**  
Für die Verschlüsselung macht das keinen Unterschied. Entscheidend sind Schlüsseltyp, Schlüssellänge, eine vollständige Zertifikatskette und eine zuverlässige automatische Verlängerung. Unterschiede gibt es bei Prüfumfang, Laufzeit und Service des Anbieters.

**Reicht HTTPS zwischen Besucher und CDN?**  
Nein. Auch die Verbindung zwischen CDN und Ursprungsserver sollte verschlüsselt sein und das Zertifikat des Ursprungs prüfen. Sonst laufen Daten auf dem zweiten Teilstück unverschlüsselt oder ungeprüft durchs Netz.

**Was hat TLS mit PHP2Shell zu tun?**  
Direkt nichts. TLS schützt Daten auf dem Transportweg, PHP2Shell betrifft den PHP-Interpreter auf dem Server. Eine verschlüsselte Verbindung transportiert auch Angriffsanfragen zuverlässig, deshalb bleibt das PHP-Update unabhängig davon Pflicht.

## Quellen

- [BSI TR-02102: Kryptographische Verfahren, Teil 2 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-Dokumentation](https://nginx.org/en/docs/)
- [Apache HTTP Server: Dokumentation](https://httpd.apache.org/docs/)