TryQuickToolBox

Wie HTTPS und TLS wirklich funktionieren: Handshake und Zertifikate

Security2026-10-30TryQuickToolBox

Warum HTTPS wichtig ist (und warum es oft missverstanden wird)

Sie haben wahrscheinlich schon das Schloss-Symbol in Ihrem Browser gesehen und angenommen, die Website sei „sicher“. Aber was bedeutet das wirklich? HTTPS geht nicht nur um Verschlüsselung; es geht um Identität, Integrität und Vertrauen. Viele Entwickler behandeln TLS als Blackbox – einmal konfiguriert und vergessen. Das führt zu Fehlkonfigurationen, abgelaufenen Zertifikaten und verwundbaren Cipher Suites.

In diesem Artikel erklären wir, wie HTTPS und TLS tatsächlich funktionieren, vom Handshake bis zur Zertifikatsvalidierung, und zeigen Ihnen, wie Sie es richtig einrichten. Kein Schnickschnack, nur praktisches Wissen, das Sie heute anwenden können.

Der TLS-Handshake: Was vor dem ersten Byte passiert

Wenn ein Client (Browser) eine Verbindung zu einem Server über HTTPS herstellt, führen sie einen TLS-Handshake durch. Dieser stellt einen sicheren Kanal her. Hier eine vereinfachte Version (TLS 1.3):

  1. Client Hello: Der Client sendet unterstützte Cipher Suites, einen Zufallswert und einen Key Share (für den Schlüsselaustausch).
  2. Server Hello: Der Server wählt eine Cipher Suite, sendet seinen eigenen Zufallswert und Key Share und präsentiert seine Zertifikatskette.
  3. Authentifizierung: Der Client überprüft das Serverzertifikat gegen vertrauenswürdige CAs und prüft den Hostnamen.
  4. Schlüsselableitung: Beide Seiten berechnen das gemeinsame Geheimnis mit ECDHE (Elliptic Curve Diffie-Hellman Ephemeral).
  5. Finished: Beide senden verschlüsselte „Finished“-Nachrichten, um den Handshake zu bestätigen.

Danach werden Anwendungsdaten mit symmetrischen Schlüsseln verschlüsselt. TLS 1.3 reduziert die Round Trips auf einen, was die Latenz verbessert.

Schlüsselaustausch: ECDHE vs. RSA

Ältere TLS-Versionen verwendeten RSA-Schlüsselaustausch, der keine Forward Secrecy bietet. Wenn der private Schlüssel des Servers kompromittiert wird, kann vergangener Datenverkehr entschlüsselt werden. Moderne Setups verwenden ECDHE, das Forward Secrecy bietet – jede Sitzung hat eindeutige Schlüssel.

# Beispiel: Unterstützte Schlüsselaustauschalgorithmen prüfen
openssl s_client -connect example.com:443 -cipher 'ECDHE'

Zertifikate: Die Vertrauensanker

Ein Zertifikat bindet einen öffentlichen Schlüssel an eine Identität (Domainname). Es wird von einer Zertifizierungsstelle (CA) signiert, der der Client vertraut. Browser werden mit einem Speicher vertrauenswürdiger Root-CAs ausgeliefert.

Wenn Sie eine Website besuchen, sendet der Server eine Kette: Endzertifikat (für Ihre Domain) → Intermediate CA → Root CA. Der Client überprüft jede Signatur bis zu einem vertrauenswürdigen Root.

Arten von Zertifikaten

Schritte der Zertifikatsvalidierung

Browser prüfen:

Wenn eine Prüfung fehlschlägt, erhalten Sie eine Warnung. Umgehen Sie diese Warnungen niemals in der Produktion.

HTTPS auf Ihrem Server konfigurieren

Schauen wir uns eine typische Nginx-Konfiguration für HTTPS mit modernen TLS-Einstellungen an.

server {
    listen 443 ssl http2;
    server_name example.com;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/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';
    ssl_prefer_server_ciphers off;

    # HSTS (mit Vorsicht verwenden)
    add_header Strict-Transport-Security "max-age=63072000" always;
}

Hinweise:

Zertifikate mit Let's Encrypt erhalten

Let's Encrypt bietet kostenlose DV-Zertifikate. Verwenden Sie Certbot, um Ausstellung und Erneuerung zu automatisieren:

sudo certbot --nginx -d example.com -d www.example.com

Certbot ändert Ihre Nginx-Konfiguration und richtet einen Cron-Job für die Erneuerung ein. Testen Sie die Erneuerung immer mit --dry-run.

Häufige Fallstricke und wie man sie vermeidet

Testen Ihrer HTTPS-Konfiguration

Verwenden Sie Online-Tools wie SSL Labs oder Kommandozeilen-Tools, um Ihre Einrichtung zu überprüfen.

# Zertifikatsdetails prüfen
openssl s_client -connect example.com:443 -servername example.com | openssl x509 -noout -text

# TLS 1.3-Unterstützung testen
openssl s_client -connect example.com:443 -tls1_3

Achten Sie auf:

FAQ

Was ist der Unterschied zwischen TLS und SSL?

SSL ist der Vorgänger von TLS. TLS 1.0 war im Wesentlichen SSL 3.1. Heute wird „SSL“ oft umgangssprachlich verwendet, aber Sie sollten immer TLS 1.2 oder 1.3 verwenden.

Brauche ich ein kostenpflichtiges Zertifikat für HTTPS?

Nein. Kostenlose DV-Zertifikate von Let's Encrypt werden von allen gängigen Browsern vertraut und bieten die gleiche Verschlüsselung wie kostenpflichtige. Kostenpflichtige Zertifikate bieten Garantien und Support, aber die Verschlüsselung ist identisch.

Wie wirkt sich HTTPS auf die Performance aus?

TLS fügt durch den Handshake Latenz hinzu, aber TLS 1.3 reduziert dies auf einen Round Trip. Mit Session Resumption und HTTP/2 ist der Overhead minimal. Die Ver- und Entschlüsselungskosten sind auf modernen CPUs gering.

Bereit, die TLS-Konfiguration Ihres Servers zu überprüfen? Verwenden Sie unseren Nginx Log Analyzer, um ungewöhnliche Verkehrsmuster zu erkennen und sicherzustellen, dass Ihr HTTPS-Setup wie erwartet funktioniert.