Warum sollte jede Organisation die wichtigsten Unterschiede zwischen HTTP und HTTPS kennen?

Wichtige Erkenntnisse

• HTTPS ist HTTP, das mit TLS/SSL-Verschlüsselung gesichert ist; HTTP sendet jede Anfrage und Antwort als Klartext, der im Original lesbar ist.
• Seit Chrome 68 im Juli 2018 kennzeichnen Browser unverschlüsselte HTTP-Seiten als „Nicht sicher“, und der Druck auf unverschlüsselte Seiten hat seither nur noch zugenommen.
• TLS 1.3 (RFC 8446, veröffentlicht im August 2018) ist die aktuelle Version des Protokolls; TLS 1.0 und 1.1 wurden im März 2021 mit RFC 8996 offiziell als veraltet erklärt.
• Mit dem Antrag SC081v3 des CA/Browser Forums wird die maximale Gültigkeitsdauer öffentlicher Zertifikate von 398 Tagen auf 47 Tage bis zum 15. März 2029 reduziert, und zwar in stufenweisen Schritten, die am 15. März 2026 beginnen.
• Die Abwicklung des Produktionsdatenverkehrs über HTTP birgt reale Geschäftsrisiken: Datenabfang, Abstrafungen im SEO-Ranking, Browserwarnungen beim Bezahlvorgang und beim Login sowie Compliance-Lücken.
• Die Automatisierung des Zertifikatslebenszyklus, nicht eine einmalige Migration, gewährleistet die Sicherheit einer Organisation angesichts immer kürzer werdender Gültigkeitsfenster.

Veröffentlicht: März 2022. Aktualisiert: August 2026. Geprüft vom PKI- und Sicherheitsteam von Encryption Consulting.

Was ist der Unterschied zwischen HTTP und HTTPS?

HTTP (Hypertext Transfer Protocol) ist das Regelwerk, das Browser und Server zum Anfordern und Bereitstellen von Webseiten verwenden. Dabei werden die Daten unverschlüsselt übertragen. HTTPS (Hypertext Transfer Protocol Secure) ist HTTP, das über eine TLS-Verbindung (Transport Layer Security), dem modernen Nachfolger von SSL (Secure Sockets Layer), übertragen wird. Dadurch werden Anfragen und Antworten während der Übertragung verschlüsselt. Der sichtbare Unterschied liegt in der URL und dem Schloss-Symbol: HTTP-Adressen beginnen mit . http:// und ein nicht entriegeltes oder fehlendes Vorhängeschloss anzeigen, während HTTPS-Adressen mit https:// und ein geschlossenes Vorhängeschloss neben der URL anzeigen.

Eine Zertifizierungsstelle (CA) wie DigiCert, Sectigo oder Let's Encrypt ist eine vertrauenswürdige Drittpartei, die die Identität eines Domaininhabers überprüft und das SSL/TLS-Zertifikat ausstellt, welches einen öffentlichen Schlüssel an diese Domain bindet. Während des TLS-Handshakes präsentiert der Server dieses Zertifikat, der Client verifiziert es anhand einer vertrauenswürdigen CA-Kette, und beide Seiten vereinbaren einen symmetrischen Sitzungsschlüssel mittels asymmetrischer Verschlüsselung. Alle anschließend gesendeten Daten werden mit diesem Sitzungsschlüssel verschlüsselt. Daher ist eine HTTPS-Verbindung resistent gegen Man-in-the-Middle-Angriffe, die bei unverschlüsseltem HTTP erfolgreich wären. Eine detailliertere Beschreibung der Handshake-Mechanismen finden Sie in unserem TLS-Handshake-Leitfaden ; die Grundlagen von Zertifikaten werden in unserem Schulungszentrum unter „Was ist HTTPS und wie unterscheidet es sich von HTTP“ erläutert.

Wann wurde HTTPS zum Webstandard?

HTTPS wurde nicht von heute auf morgen zum Standard. Es ist das Ergebnis jahrzehntelanger Bemühungen von Browserherstellern, der IETF und des CA/Browser Forums, und diese Bemühungen sind durch den unten beschriebenen Zertifikatsgültigkeitsplan bis heute aktiv.

• 2012: HTTP Strict Transport Security (HSTS) wurde als RFC 6797 veröffentlicht und bietet Websites die Möglichkeit, Browsern mitzuteilen, dass Verbindungen ausschließlich über HTTPS hergestellt werden sollen.
• 2014: Google kündigte HTTPS als leichtes Ranking-Signal in der Suche an, wodurch verschlüsselte Seiten einen kleinen SEO-Vorteil erhalten.
• Juli 2018: Mit Chrome 68 wurde jede einfache HTTP-Seite in der Adressleiste als „Nicht sicher“ gekennzeichnet – ein Meilenstein, der die meisten verbleibenden öffentlichen Websites zum Umstieg veranlasste.
• August 2018: TLS 1.3 wurde als RFC 8446 veröffentlicht, die heute aktuell verwendete Version des Protokolls.
• 2021. März: Mit RFC 8996 wurden TLS 1.0 und TLS 1.1 offiziell als veraltet erklärt, ihre Verwendung in neuen Implementierungen untersagt und jeder Server, der sie noch anbietet, als nicht konform gekennzeichnet.
• 2025 zu 2029: Mit dem Antrag SC081v3 des CA/Browser Forums wird die maximale Gültigkeitsdauer öffentlicher Zertifikate bis zum 15. März 2029 von 398 Tagen auf 47 Tage reduziert, mit Zwischenschritten auf 200 Tage (März 2026) und 100 Tage (März 2027).

Welche Technologien und Systeme sind von der Umstellung von HTTP auf HTTPS betroffen?

Jedes System, das Webverkehr verarbeitet oder weiterleitet, benötigt ein gültiges Zertifikat und TLS-Unterstützung – nicht nur die öffentliche Marketing-Website. Dies umfasst Webserver und Reverse-Proxys, Load Balancer und CDNs, interne APIs und Microservices (oft mit Mutual TLS gesichert), IoT- und Geräteverwaltungs-Endpunkte, interne Admin-Panels und Dashboards, die Teams als „sicher“ betrachten, weil sie nicht öffentlich zugänglich sind, Backends für mobile Apps sowie Mail-Gateways, die auf STARTTLS basieren. Eine HTTP-zu-HTTPS-Migration, die lediglich die Hauptwebsite umfasst und interne Dienste, APIs oder IoT-Endpunkte weiterhin über HTTP betreibt, birgt nach wie vor ein Sicherheitsrisiko für das Unternehmen.

Was passiert mit Ihrer Organisation, wenn Sie HTTPS nicht verwenden?

Das Festhalten an unverschlüsseltem HTTP verursacht messbare Geschäftskosten und nicht nur eine theoretische Sicherheitslücke.

• SEO-Auswirkungen: HTTPS ist seit 2014 ein Rankingfaktor bei Google, und die Browserwarnung „Nicht sicher“, die jetzt auf einfachen HTTP-Seiten erscheint, reduziert die Klickrate und die Verweildauer, selbst wenn eine Seite noch gut rankt.
• Browserwarnungen: Chrome, Firefox und Edge kennzeichnen HTTP-Seiten und -Formulare alle als „Nicht sicher“, was das Vertrauen der Besucher genau in dem Moment untergräbt, in dem sie sich anmelden, zur Kasse gehen oder ein Lead-Formular absenden.
• Datenabfangen: Jede HTTP-Sitzung ist während der Übertragung lesbar und veränderbar, sodass Anmeldeinformationen, Zahlungsdetails und andere personenbezogene Daten (PII), die über HTTP gesendet werden, durch einen Man-in-the-Middle-Angriff abgefangen werden können.
• Compliance-Risiko: PCI DSS fordert starke Verschlüsselung für Karteninhaberdaten während der Übertragung, und Rahmenwerke wie die DSGVO setzen Verschlüsselung als grundlegende Sicherheitsmaßnahme für personenbezogene Daten voraus. Unverschlüsseltes HTTP auf einem Formular, das solche Daten erfasst, stellt eine direkte Compliance-Lücke dar.

Wie überprüft man den HTTP/HTTPS-Status und die Zertifikatsintegrität der eigenen Website?

Die Überprüfung der HTTPS-Abdeckung bedeutet, jeden erreichbaren Hostnamen zu prüfen, nicht nur die Homepage.

1. Durchsuche die gesamte Domain und jede bekannte Subdomain nach URLs, die noch über [URL-Adresse] bereitgestellt werden. http://.
2. Prüfen Sie für jedes gefundene Zertifikat die Gültigkeit, die ausstellende Zertifizierungsstelle, die Schlüsselstärke (mindestens RSA 2048 Bit oder ECC) und das Ablaufdatum.
3. Prüfen Sie, ob HSTS aktiviert ist und gegebenenfalls Subdomains einschließt und in die HSTS-Vorladeliste aufgenommen wurde.
4. Testen Sie auf gemischte Inhalte, d. h. HTTPS-Seiten, die noch HTTP-Bilder, Skripte oder iFrames laden.
5. Prüfen Sie, ob HTTP-zu-HTTPS-Weiterleitungen eine einzelne 301-Weiterleitung und keine mehrstufige Weiterleitungskette verwenden.
6. Überprüfen Sie, wie Zertifikate derzeit ausgestellt und erneuert werden. Manuell verwaltete Zertifikate sind die Hauptursache für ungeplante Ausfälle, und dieses Risiko steigt rapide an, wenn sich die Gültigkeitsdauer auf 47 Tage verkürzt.

Wie migriert man von HTTP zu HTTPS?

1. Erstellen Sie eine Liste aller Domains, Subdomains und internen Dienste, die aktuell über HTTP erreichbar sind.
2. Besorgen Sie sich für jedes Gerät ein gültiges SSL/TLS-Zertifikat von einer vertrauenswürdigen Zertifizierungsstelle; ein kostenloses CSR-Generator kann die für den Start dieses Prozesses erforderliche Zertifikatsignierungsanforderung erzeugen.
3. Installieren und konfigurieren Sie TLS 1.3, wobei TLS 1.2 nur als Fallback verwendet wird, und deaktivieren Sie TLS 1.0 und TLS 1.1.
4. Leite alle HTTP-Anfragen mit 301-Weiterleitungen auf HTTPS um.
5. Aktivieren Sie HSTS, um Versuche zur Herabstufung des Protokolls zu verhindern.
6. Finden und beheben Sie gemischte Inhaltsreferenzen, sodass keine HTTPS-Seite eine HTTP-Unterressource lädt.
7. Aktualisieren Sie interne Links, Sitemaps und Canonical-Tags, sodass sie auf die HTTPS-Versionen aller Seiten verweisen.
8. Automatisieren Sie die Zertifikatserkennung, -ausstellung und -erneuerung, anstatt Ablaufdaten manuell zu überwachen. Bei einer Gültigkeitsdauer von 47 Tagen ist eine manuelle Überwachung in nennenswertem Umfang nicht praktikabel.

Update-Protokoll

• August 2026: Aktualisiert mit dem 47-tägigen Gültigkeitszyklus des Zertifikats des CA/Browser Forums, dem aktuellen Status von TLS 1.3 und RFC 8996, einer Checkliste zur Erkennung, einer Checkliste zur Migration, einer Vergleichstabelle, einem Abschnitt zu den Einschränkungen und einem FAQ.
• 2022. März: Originalveröffentlichung.

HTTP vs. HTTPS: Ein direkter Vergleich

Attribut	HTTP	HTTPS
Verschlüsselung	Keine; Daten wurden als Klartext gesendet	TLS-Verschlüsselung (aktuell TLS 1.3), verifiziert durch ein SSL/TLS-Zertifikat
Standardport	Port 80	Port 443
Zertifikat erforderlich	Nein	Ja, ausgestellt von einer vertrauenswürdigen Zertifizierungsstelle
SEO-Auswirkungen	Kein Rankingvorteil; „Nicht sicher“-Warnungen können die Klickrate verringern	Ranking-Signal seit 2014; keine Browser-Sicherheitswarnung
Browserbehandlung	„Nicht sicher“-Kennzeichnung in Chrome, Firefox und Edge	Geschlossenes Vorhängeschloss-Symbol, standardmäßig als vertrauenswürdig eingestuft
Datenintegrität	Anfällig für Abfangen und Veränderung während des Transports	Ende-zu-Ende verschlüsselt und authentifiziert

Einschränkungen

• HTTPS verschlüsselt Daten während der Übertragung. Es schützt jedoch keine ruhenden Daten auf dem Server, in einer Datenbank oder in einem Backup.
• Ein gültiges Zertifikat ist kein Beweis für Legitimität. Phishing-Websites beschaffen sich routinemäßig ein gültiges, kostenloses SSL/TLS-Zertifikat. Ein Schloss-Symbol bestätigt also lediglich, dass die Verbindung verschlüsselt ist, nicht aber, dass die Website vertrauenswürdig ist.
• Fehlkonfiguriertes TLS, wie beispielsweise schwache Verschlüsselungssammlungen oder ein abgelaufenes Zertifikat, das ein Browser stillschweigend durch eine Überschreibung akzeptiert hat, kann ein falsches Vertrauen erzeugen, das schlimmer ist als gar keine Verschlüsselung.
• Die Gültigkeitsdauer von Zertifikaten verkürzt sich ständig (47 Tage bis März 2029), wodurch die Zertifikatsverwaltung von einer gelegentlichen manuellen Aufgabe zu einer Automatisierungsanforderung wird.
• HTTPS erfüllt eine von vielen Kontrollanforderungen. Es genügt allein nicht vollständig den Anforderungen von PCI DSS, DSGVO oder ähnlichen Compliance-Rahmenwerken, die jeweils zusätzliche Sicherheitsvorkehrungen über die Transportverschlüsselung hinaus erfordern.

Was würde Encryption Consulting empfehlen?

Betrachten Sie die Umstellung auf HTTPS als Startpunkt, nicht als Ziel. Das eigentliche Risiko für die meisten Unternehmen besteht heute nicht darin, dass „eine Seite noch über HTTP erreichbar ist“, sondern darin, dass „kein zuverlässiges Verzeichnis aller benötigten Zertifikate vorliegt und die Gültigkeitsdauer bald auf 47 Tage verkürzt wird“. CertSecure Manager automatisiert die Zertifikatserkennung, -ausstellung, -erneuerung und -sperrung in Ihrer gesamten Umgebung, sodass Zertifikate planmäßig erneuert werden, anstatt in Tabellenkalkulationen verwaltet zu werden. Für Unternehmen, die eine verwaltete, cloudbasierte PKI anstelle einer eigenen Zertifizierungsstelle benötigen, übernimmt PKI as a Service die Ausstellung und das Lebenszyklusmanagement direkt. Wenn Sie gerade erst beginnen, erstellt unser kostenloses CSR-Generator- Tool innerhalb weniger Minuten eine korrekt formatierte Zertifikatsignierungsanforderung. Encryption Consulting ist nach ISO/IEC 27001:2022 und SOC 2 zertifiziert. Daher wenden wir selbst dieselben Kontrollen an, die wir für Ihren Zertifikatslebenszyklus empfehlen.

Fazit

HTTP und HTTPS unterscheiden sich zwar nur durch einen Buchstaben, doch dieser Buchstabe steht für die gesamte Vertrauensschicht des modernen Webs: Verschlüsselung, Authentifizierung und Integrität für jede Anfrage und Antwort. Jedes Unternehmen, unabhängig von seiner Größe, hat ein direktes Interesse daran, HTTPS flächendeckend einzusetzen und die Zertifikatsverwaltung als fortlaufende Aufgabe und nicht als einmalige Einrichtung zu betrachten. Dies gilt insbesondere, da die Gültigkeitsdauer von Zertifikaten laut dem CA/Browser Forum bis 2029 auf 47 Tage sinken soll. Die Verwendung von Verschlüsselung und digitalen Zertifikaten ist sowohl für Verbindungen über das Internet als auch innerhalb des internen Netzwerks eines Unternehmens von entscheidender Bedeutung. Sicherheitssysteme wie die Public-Key-Infrastruktur (PKI) stellen Benutzern und Geräten in einem Unternehmen die benötigten Zertifikate zur Verfügung, um sich zu identifizieren und sicher zu kommunizieren. Erfahren Sie unter www.encryptionconsulting.com , wie Encryption Consulting Sie bei der Einrichtung und Automatisierung Ihrer PKI unterstützen kann.

Häufig gestellte Fragen

Ist HTTPS einfach nur HTTP mit einem installierten Zertifikat? Nicht ganz. HTTPS ist HTTP, das über eine TLS-verschlüsselte Verbindung läuft. Das Zertifikat ermöglicht es dem Browser, die Identität des Servers zu überprüfen und diese verschlüsselte Verbindung herzustellen. Die Verschlüsselung, der Handshake und der Austausch des Sitzungsschlüssels sorgen jedoch erst für die Sicherheit des Datenverkehrs – nicht die Zertifikatsdatei allein.

Verlangsamt HTTPS eine Website? Der TLS-Handshake führt bei der ersten Verbindung zu einer geringen Latenz, typischerweise einigen Millisekunden mit TLS 1.3 und moderner Hardware. Diese Verzögerung wird bei nachfolgenden Anfragen durch die Wiederaufnahme der Sitzung wiederverwendet. In der Praxis überwiegen die Vorteile von HTTPS hinsichtlich SEO und Vertrauen diesen vernachlässigbaren Mehraufwand. HTTP/2, das von den meisten Browsern als Voraussetzung für HTTPS verwendet wird, macht eine HTTPS-Website oft insgesamt schneller als ihr HTTP-Pendant.

Kann eine Phishing-Seite auch HTTPS verwenden? Ja. Eine Zertifizierungsstelle überprüft, ob der Zertifikatsantragsteller die Domain kontrolliert, nicht aber, ob die Domain selbst vertrauenswürdig ist oder die dahinterstehende Organisation legitim ist. Ein geschlossenes Vorhängeschloss bestätigt die verschlüsselte Verbindung; es sagt nichts darüber aus, wer sich am anderen Ende befindet. Deshalb sollte HTTPS niemals als alleiniges Vertrauenssignal betrachtet werden.

Was passiert, wenn ein Zertifikat abläuft? Browser blockieren den Zugriff mit einer Warnmeldung, verbundene APIs und Dienste fallen komplett aus, und der Ausfall dauert an, bis ein neues Zertifikat ausgestellt und bereitgestellt wird. Da die Gültigkeitsdauer von Zertifikaten gemäß dem Zeitplan des CA/Browser-Forums auf etwa 47 Tage sinkt, wird die manuelle Nachverfolgung von Zertifikatserneuerungen zu einer Hauptursache für vermeidbare Ausfälle. Deshalb gewinnt die automatisierte Verwaltung des Zertifikatslebenszyklus jedes Jahr mehr an Bedeutung.

Benötigen interne, nicht-öffentliche Systeme auch HTTPS? Ja. Interne Administrationsbereiche, APIs und der Datenverkehr zwischen Diensten sind häufige Ziele, sobald ein Angreifer Zugriff auf das Netzwerk erlangt hat. Unverschlüsseltes HTTP bedeutet, dass Anmeldeinformationen und Sitzungstoken unverschlüsselt über das interne Netzwerk übertragen werden. Interne Systeme sollten daher denselben Zertifikats- und TLS-Anforderungen unterliegen wie alle öffentlich zugänglichen Systeme.

Referenzen

• CA/Browser Forum. Abstimmung SC081v3: Einführung eines Zeitplans zur Reduzierung der Gültigkeitsdauer und der Datenwiederverwendungszeiträume (11. April 2025). cabforum.org
• IETF. RFC 8446: Das Transport Layer Security (TLS) Protokoll Version 1.3 (August 2018). datatracker.ietf.org
• IETF. RFC 8996: Abschaffung von TLS 1.0 und TLS 1.1 (März 2021). ietf.org
• IETF. RFC 6797: HTTP Strict Transport Security (HSTS) (November 2012). datatracker.ietf.org
• Google. Ein Meilenstein für die Chrome-Sicherheit: Kennzeichnung von HTTP als „nicht sicher“ (2018). blog.google