Der Browser muss mehr als einen Server erreichen.

Du öffnest eine bekannte Website und siehst statt der Anmeldung eine Zertifikatswarnung. Das Netzwerk funktioniert offenbar: Ein Server antwortet. Trotzdem fehlt eine wesentliche Voraussetzung für eine geschützte Verbindung. Der Browser kann die Gegenstelle nicht unter den erwarteten Bedingungen authentifizieren. Ein Klick auf „trotzdem fortfahren“ würde die offene Frage nicht beantworten.

HTTPS verbindet die Regeln von HTTP mit einer TLS-geschützten Verbindung. Transport Layer Security schützt Daten zwischen den beteiligten TLS-Endpunkten vor Mitlesen und unbemerkter Veränderung und authentifiziert üblicherweise den Server. Dazu kommen Zertifikatsprüfung, authentifizierte Schlüsselvereinbarung und symmetrischer Schutz zusammen. Die Anwendung entscheidet weiterhin, welche angemeldete Person welche Daten sehen darf.

Den vollständigen Weg von der URL über DNS und Routing bis zum fertigen Dokument erklärt der Webseitenaufruf aus Welle 5. Hier untersuchen wir den Teil, der zwischen erreichbarem Server und vertrauenswürdigem Verbindungskanal liegt. Die kryptografischen Bausteine vertieft Verschlüsselung, Hashing und Signaturen.

HTTPS schützt HTTP auf dem Verbindungsweg.

HTTP beschreibt Anfragen, Antworten, Methoden und Statuscodes. Bei gewöhnlichem unverschlüsseltem HTTP kann eine geeignete Zwischenstelle Inhalte lesen oder verändern. Bei HTTPS liegen beispielsweise Pfad, Abfrageparameter, Header und Antwortinhalt innerhalb des geschützten Kanals. Ein Beobachter auf dem Transportweg kann sie unter den Sicherheitsannahmen des Protokolls nicht einfach aus den übertragenen Daten lesen.

Die Endpunkte sehen die verarbeiteten Inhalte weiterhin. Endet TLS an einem Reverse Proxy oder CDN, entschlüsselt dieser den Verkehr. Eine Verbindung vom Proxy zum Anwendungsserver ist ein eigener Abschnitt mit eigenen Schutzanforderungen. Das Zertifikat des öffentlichen Eingangs beweist nicht, dass auch dieser interne Abschnitt verschlüsselt ist. Ebenso bleiben serverseitige Protokolle, Datenbankzugriffe und lokale Bildschirmaufnahmen außerhalb des Transportschutzes.

HTTPS verbirgt auch nicht pauschal alle Metadaten. IP-Adressen, Zeitpunkte und Datenmengen bleiben für beteiligte Netzstellen beobachtbar. DNS und die Sichtbarkeit des angefragten Servernamens hängen von zusätzlich eingesetzten Verfahren und der konkreten Verbindung ab. Ein verschlüsselter HTTP-Pfad ist deshalb kein vollständiges Anonymitätsversprechen. Ein VPN verschiebt wiederum Vertrauensgrenzen, ohne diese Fragen automatisch zu beseitigen.

TLS 1.3 vereinbart Schlüssel und prüft die Gegenstelle.

Wir betrachten einen neuen, zertifikatsbasierten TLS-1.3-Handshake über einen bereits aufgebauten TCP-Transport. Wiederaufnahme, Vorabdaten und weitere Varianten lassen wir zunächst weg. Die aktuelle Spezifikation ist RFC 9846 von Juli 2026. Sie ersetzt RFC 8446, behält die Versionsnummer TLS 1.3 bei und präzisiert beziehungsweise verschärft einzelne Anforderungen. Eine neue RFC-Nummer ist hier keine neue TLS-Version.

  1. ClientHello: Der Browser nennt unterstützte Parameter und sendet im betrachteten Normalfall einen frischen öffentlichen Beitrag zur Schlüsselvereinbarung. Der private Beitrag bleibt beim Client.
  2. ServerHello: Der Server wählt passende Parameter und liefert seinen öffentlichen Beitrag. Beide Seiten können daraus bereits Handshake-Schlüssel ableiten. Zu diesem Zeitpunkt ist die Gegenstelle noch nicht abschließend als der richtige Server bestätigt.
  3. Servernachrichten geschützt übertragen: Es folgen unter anderem EncryptedExtensions, Certificate, CertificateVerify und Finished. CertificateVerify bindet den bisherigen Handshake durch eine Signatur an den privaten Zertifikatsschlüssel. Finished sichert den Handshake mit einem aus den Geheimnissen abgeleiteten Wert ab.
  4. Browser prüft: Er prüft Zertifikatskette, erwarteten Namen, Zeitgültigkeit und weitere Richtlinien sowie die kryptografischen Handshake-Nachweise. Erst die zusammenpassenden Prüfungen authentifizieren die erwartete Gegenstelle.
  5. Client schließt ab: Auch der Client sendet Finished. Für die Anwendungsdaten werden getrennt abgeleitete Verkehrsschlüssel verwendet; HTTP läuft anschließend geschützt über diese Verbindung.
Neuer zertifikatsbasierter TLS-1.3-HandshakeClientHello und ServerHello enthalten öffentliche Beiträge zur Schlüsselvereinbarung. Danach werden Handshake-Schlüssel abgeleitet, bevor der Server sein Zertifikat und seine Nachweise geschützt überträgt. Der Browser prüft Identität und Handshake. Nach Client Finished werden HTTP-Anwendungsdaten mit getrennten Verkehrsschlüsseln übertragen. Modell ohne Wiederaufnahme und ohne 0-RTT.1 · Browser → ServerClientHello + KeyShareÖffentlicher Clientbeitrag2 · Server → BrowserServerHello + KeyShareHandshake-Schlüssel ableiten3 · Server → BrowserGeschützt: Extensions,Certificate, CertificateVerify,Finished4 · Browser prüftKette + Name + GültigkeitSignatur + Finished5 · Client FinishedAnwendungsdaten miteigenen VerkehrsschlüsselnVereinbarung beginnt vor derabgeschlossenen Identitätsprüfung.
Eigene vereinfachte Nachrichtenfolge. Sie zeigt TLS über einen vorhandenen zuverlässigen Transport, keinen zusätzlichen TCP-Aufbau und keinen HTTP/3-Ablauf.

Der Zertifikatsschlüssel verschlüsselt in diesem TLS-1.3-Ablauf nicht unmittelbar sämtliche Webdaten. Er dient dem Identitätsnachweis durch Signieren. Die ephemere Schlüsselvereinbarung und anschließende Ableitung liefern andere Schlüssel für den laufenden Schutz. Auch Handshake- und Anwendungsschlüssel sind getrennt. Diese Trennung erklärt, warum eine einfache Reihenfolge „erst Zertifikat, dann irgendwann Schlüsselaushandlung“ den tatsächlichen Ablauf verzerrt.

Ein Clientzertifikat ist für gewöhnliche Websites nicht zwingend. Optional kann der Server auch den Client auf TLS-Ebene authentifizieren. Die übliche Passwort- oder Passkey-Anmeldung erfolgt dagegen auf Anwendungsebene innerhalb der geschützten Verbindung. Sie ist eine eigene Prüfung und ersetzt nicht die Serverauthentifizierung. Bei wiederaufgenommenen Verbindungen können gespeicherte Sitzungsgeheimnisse den Ablauf verkürzen; 0-RTT-Vorabdaten haben besondere Wiederholungsrisiken und sind kein pauschaler Standardweg für beliebige Aktionen.

Ein Zertifikat bindet Namen an einen öffentlichen Schlüssel.

Ein X.509-Zertifikat enthält unter anderem einen öffentlichen Schlüssel, Angaben zum Aussteller, eine Seriennummer, einen Gültigkeitszeitraum und Erweiterungen. Für einen Webzugriff sind die passenden Namenseinträge im Subject Alternative Name, kurz SAN, entscheidend. Die ausstellende Certificate Authority, kurz CA, signiert diese Angaben. Der private Server-Schlüssel gehört nicht in das Zertifikat und wird dem Browser nicht mitgeschickt.

Ein Zertifikat für portal.example.com passt nicht automatisch zu files.example.com. Ein DNS-Name in einem Zertifikat deckt auch nicht beliebige Zugriffe über eine eingegebene IP-Adresse ab; dafür gelten passende IP-Namenseinträge und Prüfregeln. Ein alter Common-Name-Eintrag ist kein Ersatz für die moderne SAN-Prüfung nach RFC 9525. Auch eine richtige DNS-Auflösung allein beweist keine passende TLS-Identität.

Die CA prüft nach ihren Richtlinien die Voraussetzungen für die Ausstellung. Ein domainvalidiertes Zertifikat belegt einen überprüften Bezug zur betreffenden Domain. Es ist kein Gütesiegel für Produkte, Inhalte oder Zahlungsabsichten. Eine Phishingwebsite kann ein gültiges Zertifikat für ihren eigenen täuschend ähnlichen Namen erhalten. Deshalb muss der Browser den tatsächlich erwarteten Namen prüfen, und der Benutzer muss auf der richtigen Website sein.

Vertrauen endet an einem bereits bekannten Anker.

Der Browser vertraut einem Zertifikat nicht deshalb, weil es sich selbst „vertrauenswürdig“ nennt. Er versucht einen gültigen Zertifizierungspfad zu einem lokal akzeptierten Trust Anchor zu bilden. Häufig signiert eine Intermediate CA das Serverzertifikat; deren Berechtigung führt wiederum zu einem Root-Schlüssel im Trust Store. Dieser Speicher wird nach Regeln des Browsers, Betriebssystems beziehungsweise der Organisation verwaltet.

Zertifizierungspfad zum vertrauten Root-AnkerDer Server liefert sein Zertifikat und die benötigten Zwischenzertifikate. Der Client prüft Signaturen und Einschränkungen bis zu einem bereits lokal akzeptierten Trust Anchor. Ein mitgesendetes Root-Zertifikat erzeugt kein neues Vertrauen. Name und Zeitgültigkeit werden zusätzlich geprüft.ServerzertifikatSAN: portal.example.comSigniert von Intermediate CAIntermediate CADarf Zertifikate ausstellen.Signiert vom nächsten AusstellerRoot / Trust AnchorSchon lokal akzeptierterSchlüssel + VertrauensregelnPrüfrichtung: zum AnkerZusätzlich: Name, Zeit, Zwecke,Einschränkungen und RichtlinienMitgesendet ≠ vertrauenswürdig
Eigener vereinfachter Pfad mit einer Intermediate CA. Alternative Ketten und mehrere Zwischenstellen sind möglich; der Root muss üblicherweise nicht vom Server mitgeliefert werden.

Zur Prüfung gehören mehr als passende Signaturen. Zertifikatszweck, CA-Berechtigung, Einschränkungen und anwendbare Richtlinien müssen passen. Ein selbst signiertes Root-Zertifikat wird durch seine eigene Signatur nicht automatisch vertrauenswürdig. Vertrauen entsteht durch die kontrollierte Aufnahme des Ankers. Ein Angreifer könnte ebenfalls ein selbst signiertes Zertifikat erzeugen; die bloße Existenz einer Signatur unterscheidet diese Fälle nicht.

Self-signed-Zertifikate können in bewusst eingerichteten Umgebungen sinnvoll sein. Dafür muss das Vertrauen beispielsweise über einen gesicherten Verwaltungsweg explizit hergestellt werden. In einer Organisation ist oft eine verwaltete interne CA zweckmäßiger. Ein unverifiziert aus einer Warnseite importiertes Root-Zertifikat kann dagegen weitreichendes Vertrauen schaffen. Der Eingriff ist wesentlich größer als eine lokale optische Reparatur des Browsersymbols.

Erneuerung und Widerruf sind unterschiedliche Betriebsaufgaben.

Zertifikate haben einen Zeitraum mit Beginn und Ende ihrer Gültigkeit. Der Client vergleicht diesen mit seiner Uhrzeit. Die Erneuerung beschafft rechtzeitig ein neues Zertifikat und installiert es an den richtigen TLS-Endpunkten. Ein automatischer Job kann erfolgreich ein Zertifikat ablegen, während der öffentliche Proxy noch das alte ausliefert. Entscheidend ist deshalb auch die Prüfung der tatsächlich verwendeten Konfiguration.

ACME automatisiert wesentliche Teile der Beantragung und Verwaltung. Ein ACME-Client weist gegenüber der CA über eine geeignete Challenge die Kontrolle über den angefragten Namen nach. Bei einer HTTP-Challenge wird ein bestimmter Inhalt erreichbar gemacht, bei einer DNS-Challenge ein vorgegebener DNS-Eintrag. Nach erfolgreicher Autorisierung kann ein Zertifikat ausgestellt werden. Let's Encrypt ist ein Beispiel für eine CA mit ACME-Unterstützung, nicht der Name des Protokolls.

Automatisierung benötigt begrenzte Berechtigungen. Zugangsdaten für DNS-Änderungen sind schützenswert; möglichst kleine Berechtigungen begrenzen mögliche Schäden. Ausstellung, sichere Schlüsselablage, Installation, gegebenenfalls Reload und Ablaufüberwachung gehören zusammen. Eine nachvollziehbare Alarmierung sollte früh genug greifen, damit ein defekter Job nicht erst als Browserwarnung auffällt. Konkrete Laufzeiten und Erneuerungsintervalle richten sich nach CA und Client und sind keine unveränderlichen Naturkonstanten.

Widerruf betrifft dagegen ein Zertifikat, das vor seinem regulären Ablauf nicht weiter akzeptiert werden soll, beispielsweise nach einem Schlüsselverlust. Mechanismen wie Sperrlisten und Statusinformationen unterstützen das. Welche Informationen ein Browser tatsächlich prüft und wie er mit nicht erreichbaren Statusdiensten umgeht, hängt vom Produkt und dessen Richtlinien ab. Widerruf ist daher keine Garantie, dass ein gestohlenes Zertifikat augenblicklich überall wirkungslos wird. Schlüsselwechsel, Ersatzinstallation und Vorfallbehandlung bleiben notwendig.

Eine Warnung wird durch die Ursache gelöst.

Im Praxisfall erscheint beim erwarteten https://portal.example.com/ eine Zertifikatswarnung. Gib dort zunächst keine Zugangsdaten oder vertraulichen Inhalte ein. Prüfe die tatsächlich angezeigte URL, den Fehlertext und die Uhrzeit deines Geräts. Halte Beobachtungen ohne Sitzungsgeheimnisse fest. Nutze für eine Meldung einen bereits bekannten Kontaktweg und keine ungeprüften Kontaktdaten aus einer verdächtigen Seite.

  • Abgelaufen oder noch nicht gültig: Die Installation kann veraltet sein; ebenso kann eine falsche lokale Uhr den Zeitraum unzutreffend bewerten. Die Ursache muss unterschieden werden.
  • Name passt nicht: Ein falsches Zertifikat, eine falsche URL oder eine fehlerhafte Zuordnung am Proxy ist möglich. Eine funktionierende IP-Verbindung beseitigt diesen Fehler nicht.
  • Unbekannter Aussteller: Ein interner Dienst kann einen nicht verwalteten Anker verwenden. Ebenso kann eine unerwartete Zwischenstelle beteiligt sein. Blindes Importieren löst die Vertrauensfrage nicht.
  • Zwischenzertifikat fehlt: Der Server liefert möglicherweise keine brauchbare Kette. Dass ein anderer Rechner den Besuch schafft, kann an vorhandenen Zwischenzertifikaten oder anderen Trust Stores liegen.
  • Kette oder Richtlinie ungültig: Signaturen, Zwecke oder andere Einschränkungen können scheitern. Die genaue Diagnose gehört zur zuständigen Administration.

Der Administrator prüft anschließend am eigenen freigegebenen Dienst die ausgelieferte Kette, SAN-Einträge, Zeitgültigkeit und Auswahl des Zertifikats für den Hostnamen. Bei mehreren Loadbalancern kann nur ein Teil der Instanzen veraltet sein. Diese Liste ist eine Diagnosehilfe, kein Auftrag für Scans fremder Systeme. Im Lernbeispiel werden keine realen Server abgefragt, Zertifikate importiert oder Prüfungen abgeschaltet.

Die richtige Entscheidung für Benutzer ist bei ungeklärter Warnung der Abbruch und die sichere Verifikation. Auch bei einem bekannten internen Dienst muss eine mögliche Ausnahme aus einem nachvollziehbaren, verwalteten Vertrauensmodell folgen. „Hat gestern noch funktioniert“ ist kein Nachweis der heutigen Gegenstelle. Ein unerwartetes Warnfenster kann eine Betriebsstörung oder einen ernsthaften Sicherheitsbefund anzeigen.

HTTP/2 und HTTP/3 tragen HTTP unterschiedlich.

Bei üblichen HTTPS-Verbindungen mit HTTP/1.1 oder HTTP/2 läuft TLS über TCP. Innerhalb des Handshakes wird über ALPN das passende Anwendungsprotokoll vereinbart. HTTP/2 kann mehrere gleichzeitige Anfragen über dieselbe Verbindung abwickeln. Für jede einzelne Bilddatei ist daher nicht automatisch ein neuer TLS-Handshake erforderlich. Wiederverwendung und neue Verbindungen müssen bei der Fehlersuche unterschieden werden.

HTTP/3 verwendet dagegen QUIC über UDP. QUIC integriert TLS 1.3 für Schlüsselvereinbarung und Authentifizierung; es verwendet nicht einfach zusätzlich einen klassischen TLS-Record-Kanal über TCP. TLS-Nachrichten werden in QUIC transportiert, und QUIC verwendet die abgeleiteten Geheimnisse für seinen eigenen Paketschutz. Die Zertifikats- und Namensprüfung bleibt dabei relevant. „UDP bedeutet unverschlüsselt“ wäre genauso falsch wie „HTTPS bedeutet immer TCP“.

Weitere Transportdetails erklärt TCP, UDP und QUIC. Für die Sicherheitsentscheidung bleibt die zentrale Frage in beiden Fällen gleich: Ist die erwartete Gegenstelle mit den richtigen Prüfungen authentifiziert, und schützt das tatsächlich verwendete Protokoll den gewünschten Wegabschnitt? Die unterschiedlichen Transporte dürfen im Diagramm nicht zu einer fiktiven Pflichtfolge vermischt werden.

Ein geschützter Kanal macht Inhalte nicht automatisch vertrauenswürdig.

Ein gültiges Zertifikat verhindert weder eine betrügerische Website noch schädliche Downloads. Es beseitigt keine Programmierfehler, falsch vergebenen Dateirechte oder gestohlenen Anwendungssitzungen. Nach dem Entschlüsseln entscheidet die Anwendung über Datenverarbeitung und Berechtigungen. Ein bereits kompromittiertes Endgerät kann Klartext vor dem Verschlüsseln beziehungsweise nach dem Entschlüsseln auslesen.

Praktischer Schutz besteht deshalb aus zusammenpassenden Maßnahmen: korrekte URL, aktuelle Software, funktionierende Zertifikatsverwaltung, sichere Endpunkte, angemessene Anmeldung und kontrollierte Berechtigungen. Passwörter, MFA und Passkeys beantworten die nächste Frage: Wie weist eine Person gegenüber der bereits authentifizierten Website ihre Berechtigung zur Anmeldung nach? Das Security-Lab hilft dabei, verdächtige Aufforderungen einzuordnen.

Begründe die Entscheidung vor dem Weiterklicken.

Aufgabe 1: Ein Zertifikat ist von einer bekannten CA signiert und zeitlich gültig. Im SAN steht ausschließlich shop.example.com; geöffnet wurde portal.example.com. Reicht die bekannte CA? Wäre das Entfernen der Namensprüfung eine sichere Reparatur?

Lösung: Eine gültige Kette ersetzt die passende Dienstidentität nicht.

Die CA-Kette kann stimmen, aber der erwartete Name wird nicht abgedeckt. Der Browser darf daraus keine erfolgreiche Authentifizierung von portal.example.com ableiten. Der Betreiber muss die Namenszuordnung beziehungsweise das ausgelieferte Zertifikat korrigieren. Die Namensprüfung abzuschalten würde gerade den Schutz entfernen, der eine andere gültig zertifizierte Gegenstelle vom erwarteten Dienst unterscheidet.

Aufgabe 2: Eine Skizze zeigt für TLS 1.3 zuerst die vollständige Zertifikatsprüfung, danach ServerHello und Schlüsselaushandlung. Dieselbe Skizze soll unverändert für HTTP/3 gelten. Welche zwei Korrekturen sind erforderlich?

Lösung: Schlüsselableitung beginnt früher; QUIC integriert TLS anders.

Im betrachteten neuen zertifikatsbasierten TLS-1.3-Handshake liefern ClientHello und ServerHello die Vereinbarungsbeiträge. Daraus entstehen Handshake-Schlüssel, mit denen die folgenden Servernachrichten einschließlich Certificate geschützt werden. Die Identitäts- und Handshake-Prüfung wird anschließend abgeschlossen. HTTP/3 verwendet QUIC über UDP mit integrierter TLS-1.3-Authentifizierung und eigenem Paketschutz; ein zusätzlicher klassischer TLS-over-TCP-Ablauf wäre falsch. Die Namens- und Vertrauensprüfung entfällt deshalb nicht.

Quellen und fachlicher Stand.

Geprüft am . Abläufe und Namen sind eigene vereinfachte Beispiele. Die Handshakegrafik zeigt einen neuen zertifikatsbasierten TLS-1.3-Aufbau ohne Wiederaufnahme, Clientzertifikat, HelloRetryRequest und 0-RTT. Browserregeln und CA-Angebote können sich ändern.