HTTPS und TLS-Grundlagen

HTTP + TLS = HTTPS

HTTP bleibt das Anwendungsprotokoll für Requests und Responses. Bei HTTPS wird diese HTTP-Kommunikation durch TLS geschützt. Die Formel ist ein Denkmodell, keine wörtliche Paketsyntax:

HTTP/1.1 und HTTP/2 über HTTPS verwenden gewöhnlich TCP-Port 443. HTTP/3 nutzt QUIC über UDP, ebenfalls gewöhnlich Port 443. Ein Port allein beweist weder das Protokoll noch TLS.

Drei Schutzziele von TLS

Typisches HTTPS authentifiziert den Server, nicht automatisch auch den Client. Clientzertifikate beziehungsweise mTLS existieren, sind für gewöhnliches HTTPS aber nicht erforderlich.

Was ein Serverzertifikat aussagt

Ein X.509-Serverzertifikat bindet Identitätsnamen und öffentliches Schlüsselmaterial nach einem Vertrauensmodell zusammen. Relevant sind konzeptionell: Namen, insbesondere Subject Alternative Names (SAN), öffentlicher Schlüssel, Aussteller, Gültigkeitszeitraum und Signaturbeziehung. Einzelne Felder musst du nicht auswendig lernen.

Das Zertifikat ist nicht selbst „der Verschlüsselungsalgorithmus“. TLS übernimmt den kryptografischen Schutz; das Zertifikat hilft vor allem bei Identität, Schlüsselzuordnung und Vertrauen.

Hostname-Validierung

Beim Aufruf https://web01.firma.test prüft der Client, ob eine passende Zertifikatsidentität – modern insbesondere ein SAN – für web01.firma.test enthalten ist. Ein Zertifikat nur für mail.firma.test passt nicht automatisch. Ein Wildcard-Name wie *.firma.test kann je nach Regeln geeignete einteilige Hostnamen abdecken; Details sind hier nachrangig.

Vertrauenskette und CA

Eine Certificate Authority (CA) bestätigt Zertifikatsbindungen durch Signaturen. Typisch ist die Kette Serverzertifikat → Intermediate CA → vertrauenswürdige Root CA. Der Browser beziehungsweise das Betriebssystem besitzt einen Trust Store mit vertrauten Root-Zertifikaten. Der Server liefert gewöhnlich sein Zertifikat und benötigte Intermediate-Zertifikate; das Root-Zertifikat muss er normalerweise nicht mitsenden.

Der Client baut und validiert einen Zertifizierungspfad zur vertrauten Wurzel. Verschlüsselung und Identitätsprüfung sind unterschiedliche Konzepte: Verschlüsselter Verkehr zu einem nicht verlässlich identifizierten Gegenüber löst das Identitätsproblem nicht.

Selbstsigniert und interne CA

Ein selbstsigniertes Zertifikat signiert sich selbst, statt zu einem anderen vertrauenswürdigen Aussteller zu verketten. Das macht Verschlüsselung nicht unmöglich und beweist keine Böswilligkeit. Clients vertrauen der behaupteten Identität jedoch normalerweise erst, wenn dieses Zertifikat oder der passende Trust Anchor ausdrücklich vertraut wird.

Organisationen können eine interne CA betreiben. Geräte, die deren Root CA kontrolliert vertrauen, können damit ausgestellte interne Zertifikate validieren. Das ist in Labor- und Firmennetzen üblich – Zertifikatswarnungen sollten trotzdem untersucht und nicht blind umgangen werden.

Gültigkeit und typische Zertifikatsfehler

Ablauf bedeutet eine Validierungs- beziehungsweise Vertrauensstörung, nicht dass Verschlüsselung mathematisch unmöglich wäre. Browser formulieren Fehler unterschiedlich.

Was vor geschützten HTTP-Daten geschieht

1. Der Client verbindet sich.
2. Client und Server handeln unterstützte TLS-Parameter aus.
3. Der Server stellt Zertifikatsinformationen bereit.
4. Der Client validiert Identität, Namen, Zeit und Vertrauenskette.
5. Kryptografische Schlüssel werden etabliert.
6. Erst danach werden geschützte HTTP-Anwendungsdaten ausgetauscht.

Dies ist bewusst ein modernes, vereinfachtes Modell ohne Cipher-Mathematik oder veraltete RSA-Key-Exchange-Vereinfachung.

Praxis: Zertifikat im Browser untersuchen

Öffne in einer verfügbaren Browseroberfläche die Verbindungs- oder Zertifikatsinformationen. Finde unabhängig von exakten Menübezeichnungen: angefragten Hostnamen, Aussteller, Gültigkeitszeitraum, Zertifikatsnamen/SAN und Vertrauensstatus. Optional ist curl -I https://… ein HTTP-Client-Test; externe Internetverbindung ist nicht erforderlich.