Wenn vor einer Webadresse https:// steht, wird die Verbindung zwischen Browser und Website verschlüsselt übertragen. Dadurch können Daten auf ihrem Weg durch das Internet nicht einfach im Klartext mitgelesen werden.
Das ist allerdings nur ein Teil der Geschichte.
HTTPS soll zusätzlich sicherstellen, dass der Browser tatsächlich mit dem Server kommuniziert, der für die aufgerufene Domain legitimiert wurde. Dafür kommen digitale Zertifikate, kryptografische Schlüssel und ein Protokoll namens TLS zum Einsatz.
Im Alltag wird trotzdem häufig von einem „SSL-Zertifikat“ gesprochen. Technisch ist diese Bezeichnung heute nicht mehr besonders präzise. Die früher verwendeten SSL-Protokolle wurden längst durch TLS ersetzt.
Wenn ein Hoster also mit einem kostenlosen SSL-Zertifikat wirbt, bedeutet das heute in aller Regel:
Die Website erhält ein Zertifikat für HTTPS und kommuniziert über TLS.
Was bedeutet HTTPS?
HTTPS steht für:
Hypertext Transfer Protocol Secure
Grundlage ist HTTP, also das Protokoll, über das Browser und Webserver miteinander kommunizieren.
Ohne Verschlüsselung könnte eine Verbindung vereinfacht so aussehen:
Browser
↓
HTTP
↓
Webserver
Mit HTTPS kommt eine abgesicherte Transportverbindung hinzu:
Browser
↓
HTTPS über TLS
↓
Webserver
HTTP beschreibt weiterhin, welche Webseite oder Ressource angefordert wird.
TLS schützt die Übertragung.
HTTPS ist deshalb vereinfacht gesagt:
HTTP innerhalb einer verschlüsselten und authentifizierten Verbindung.
Was bedeutet SSL?
SSL steht für Secure Sockets Layer.
Dabei handelt es sich um den historischen Vorgänger von TLS.
SSL wurde in verschiedenen Versionen entwickelt, ist heute aber technisch überholt.
Das moderne Verfahren heißt:
TLS – Transport Layer Security.
Trotzdem haben sich Begriffe wie:
SSL-Zertifikat,
SSL-Verschlüsselung,
SSL aktivieren
im allgemeinen Sprachgebrauch gehalten.
Wenn jemand heute von einem SSL-Zertifikat für seine Website spricht, meint er normalerweise ein TLS-Zertifikat für HTTPS.
Für den Alltag ist das nicht dramatisch.
Technisch sauberer wäre jedoch:
TLS-Zertifikat beziehungsweise HTTPS-Zertifikat.
Warum braucht eine Website überhaupt Verschlüsselung?
Stell dir vor, du meldest dich bei einer Website an.
Du sendest:
Benutzername,
Passwort.
Ohne Transportverschlüsselung könnten solche Informationen theoretisch an Stellen mitgelesen werden, über die der Datenverkehr läuft.
Das können beispielsweise beteiligte Netzwerke oder kompromittierte Zwischenstationen sein.
HTTPS sorgt dafür, dass der Inhalt der Kommunikation zwischen Browser und Gegenstelle verschlüsselt übertragen wird.
Ein Beobachter sieht dann nicht einfach:
Benutzername: anna
Passwort: geheim123
sondern verschlüsselte Daten.
Das ist besonders wichtig bei:
Logins,
Formularen,
Online-Shops,
Zahlungsinformationen,
persönlichen Daten.
Aber auch eine reine Informationsseite sollte heute über HTTPS bereitgestellt werden.
HTTPS schützt nicht nur Passwörter
Eine häufige Vorstellung lautet:
Meine Website besitzt kein Login und keinen Shop. Also brauche ich kein HTTPS.
Das greift zu kurz.
Auch bei einer normalen Informationsseite verhindert HTTPS, dass Inhalte während der Übertragung unbemerkt manipuliert werden können.
Ohne verschlüsselte und authentifizierte Verbindung könnte theoretisch ein System zwischen Besucher und Website Inhalte verändern.
Zum Beispiel:
Werbung einfügen,
Links austauschen,
Schadcode ergänzen.
HTTPS schützt deshalb nicht nur Geheimnisse.
Es schützt auch die Integrität der übertragenen Daten.
HTTPS erfüllt drei zentrale Aufgaben
Vereinfacht kann man HTTPS auf drei Sicherheitsziele reduzieren.
Vertraulichkeit:
Andere sollen den übertragenen Inhalt nicht einfach mitlesen können.
Integrität:
Daten sollen unterwegs nicht unbemerkt verändert werden.
Authentifizierung:
Der Browser soll prüfen können, ob die Gegenstelle für die aufgerufene Domain ein gültiges Zertifikat besitzt.
Diese drei Funktionen bilden die eigentliche Grundlage von HTTPS.
Das Zertifikat verschlüsselt nicht einfach die ganze Website
Der Satz:
Das SSL-Zertifikat verschlüsselt meine Website.
ist zwar verständlich, technisch aber ungenau.
Die Dateien auf dem Server werden durch das Zertifikat nicht automatisch verschlüsselt.
Die WordPress-Datenbank wird dadurch ebenfalls nicht verschlüsselt.
Ein Angreifer mit vollständigem Serverzugriff kann die Website weiterhin lesen.
Das Zertifikat wird vielmehr beim Aufbau der sicheren Verbindung verwendet.
Es hilft dem Browser dabei:
die Gegenstelle zu authentifizieren
und
eine sichere TLS-Verbindung aufzubauen.
Die eigentliche laufende Kommunikation wird anschließend mit für die Verbindung ausgehandelten kryptografischen Schlüsseln geschützt.
HTTPS ist Transportverschlüsselung
Dieser Begriff hilft bei der Einordnung.
HTTPS schützt den Transportweg.
Vereinfacht:
Browser
⇄ verschlüsselte Verbindung ⇄
Server
Die Daten können auf beiden Endpunkten natürlich wieder lesbar sein.
Der Browser muss die Webseite schließlich darstellen können.
Der Server muss beispielsweise Formulardaten verarbeiten können.
HTTPS bedeutet deshalb nicht:
Niemand kann diese Daten lesen.
Sondern:
Die Daten werden auf dem Übertragungsweg zwischen den beteiligten Endpunkten geschützt.
Was ist ein TLS-Zertifikat?
Ein TLS-Zertifikat ist ein digital signiertes Dokument mit Informationen über eine Website beziehungsweise deren kryptografische Identität.
Es enthält unter anderem einen öffentlichen Schlüssel und Informationen darüber, für welche Domainnamen es gültig ist.
Ein Zertifikat könnte beispielsweise gelten für:
example.de
oder:
www.example.de
oder mehrere Namen gleichzeitig.
Der Browser erhält das Zertifikat beim Aufbau der Verbindung und kann überprüfen, ob es zur angeforderten Domain passt und innerhalb einer vertrauenswürdigen Zertifikatskette liegt.
Das Zertifikat gehört zum Domainnamen
Ein Zertifikat ist nicht einfach pauschal „für den Server“ gültig.
Der Browser erwartet, dass der aufgerufene Hostname vom Zertifikat abgedeckt wird.
Wenn du aufrufst:
muss das Zertifikat entsprechend für example.de gültig sein.
Ein Zertifikat ausschließlich für:
anderedomain.de
würde nicht passen.
Genau deshalb kann ein Webserver zahlreiche Websites mit jeweils unterschiedlichen Zertifikaten betreiben.
www und Hauptdomain sind unterschiedliche Hostnamen
Wie bereits in Was ist eine Domain? erklärt, sind:
example.de
und
www.example.de
technisch unterschiedliche Hostnamen.
Ein Zertifikat sollte deshalb alle Varianten abdecken, unter denen die Website tatsächlich erreichbar sein soll.
Häufig enthält es beispielsweise beide:
example.de
www.example.de
Danach wird eine Variante als Hauptadresse verwendet und die andere dorthin weitergeleitet.
Was bedeutet SAN?
Moderne Zertifikate können für mehrere Domainnamen gültig sein.
Diese zusätzlichen Namen werden über sogenannte Subject Alternative Names, kurz SAN, angegeben.
Ein Zertifikat könnte beispielsweise abdecken:
example.de
www.example.de
shop.example.de
Der Browser kann dann für jeden dieser Namen prüfen, ob er im Zertifikat enthalten ist.
Das ermöglicht es, mehrere Hostnamen mit demselben Zertifikat zu verwenden.
Was ist ein Wildcard-Zertifikat?
Ein Wildcard-Zertifikat kann verschiedene Subdomains einer Domain abdecken.
Beispielsweise:
*.example.de
Das könnte unter anderem verwendet werden für:
shop.example.de
blog.example.de
mail.example.de
Dabei gibt es jedoch technische Grenzen.
Ein Wildcard-Zertifikat sollte deshalb nicht einfach als universelles Zertifikat für sämtliche denkbaren Domain-Ebenen verstanden werden.
Für viele Infrastrukturen ist es trotzdem ausgesprochen praktisch.
Wer stellt TLS-Zertifikate aus?
Zertifikate werden typischerweise von sogenannten Certification Authorities, kurz CA, ausgestellt.
Auf Deutsch wird häufig von Zertifizierungsstellen gesprochen.
Browser und Betriebssysteme besitzen Vertrauensspeicher mit Root-Zertifikaten anerkannter Stellen.
Die Vertrauenskette sieht vereinfacht so aus:
Browser vertraut
↓
Root-Zertifizierungsstelle
↓
Zwischenzertifikat
↓
Zertifikat der Website
Wenn diese Kette korrekt aufgebaut ist, kann der Browser die Signaturen überprüfen.
Warum vertraut der Browser einem Zertifikat?
Nicht weil die Website behauptet:
Ich bin wirklich example.de.
Das wäre wertlos.
Stattdessen wurde das Zertifikat von einer Stelle signiert, deren Vertrauenskette der Browser überprüfen kann.
Vereinfacht sagt die Zertifizierungsstelle:
Für diesen Domainnamen wurde die vorgeschriebene Kontrolle nachgewiesen, und dieses Zertifikat gehört zu dem entsprechenden öffentlichen Schlüssel.
Der Browser überprüft anschließend unter anderem, ob:
das Zertifikat zeitlich gültig ist,
der Hostname passt
und
die Zertifikatskette vertrauenswürdig ist.
Was prüft eine Zertifizierungsstelle?
Für normale automatisierte Website-Zertifikate wird typischerweise geprüft, ob der Antragsteller Kontrolle über die betreffende Domain besitzt.
Das kann beispielsweise nachgewiesen werden über:
eine bestimmte Datei auf dem Webserver,
eine DNS-Antwort
oder
einen anderen automatisierten Validierungsmechanismus.
Die Zertifizierungsstelle überprüft damit nicht automatisch:
Ist dieses Unternehmen seriös?
Sind die Inhalte wahr?
Ist der Shop vertrauenswürdig?
Sie prüft für diesen Zertifikatstyp im Wesentlichen die Kontrolle über den Domainnamen.
Das Schloss bedeutet nicht „Diese Website ist seriös“
Das ist eine der wichtigsten Missverständnisse rund um HTTPS.
Auch ein betrügerischer Shop kann ein gültiges Zertifikat besitzen.
Auch eine Phishing-Seite kann über HTTPS erreichbar sein.
Das Zertifikat beweist nicht:
Diese Person ist ehrlich.
Es zeigt im Wesentlichen:
Die Verbindung zu diesem Host wird mit einem für diesen Host gültigen Zertifikat geschützt.
Deshalb darf HTTPS niemals mit einer inhaltlichen Vertrauensprüfung verwechselt werden.
Auch Betrüger brauchen heute HTTPS
Kostenlose automatisierte Zertifikate haben HTTPS für praktisch jede Website zugänglich gemacht.
Das ist sehr positiv für die Sicherheit des Webs.
Es bedeutet aber gleichzeitig, dass das Vorhandensein von HTTPS kein Qualitätsmerkmal mehr ist.
Die richtige Frage lautet nicht:
Hat die Website ein Schloss?
Sondern:
Zeigt der Browser eine sichere Verbindung ohne Zertifikatsfehler – und vertraue ich unabhängig davon dem Betreiber und Inhalt?
Das sind zwei verschiedene Ebenen.
Was ist Let’s Encrypt?
Let’s Encrypt ist eine Zertifizierungsstelle, die kostenlose automatisierbare TLS-Zertifikate bereitstellt.
Das hat wesentlich dazu beigetragen, dass HTTPS heute auch bei kleinen Websites zum Standard geworden ist.
Hostinganbieter können Zertifikate automatisiert anfordern, installieren und erneuern.
Für den Website-Betreiber bedeutet das häufig:
Domain anlegen.
HTTPS aktivieren.
Fertig.
Im Hintergrund laufen trotzdem Zertifikatsanforderung, Validierung, Installation und spätere Erneuerung.
Warum laufen Zertifikate überhaupt ab?
TLS-Zertifikate besitzen einen begrenzten Gültigkeitszeitraum.
Nach Ablauf akzeptiert der Browser sie nicht einfach dauerhaft weiter.
Das sorgt unter anderem dafür, dass Zertifikate regelmäßig erneuert werden müssen und alte kryptografische Identitäten nicht unbegrenzt gültig bleiben.
Für Betreiber bedeutet das:
Zertifikatserneuerung muss funktionieren.
Moderne Hostingplattformen automatisieren diesen Prozess weitgehend.
Zertifikate sollten automatisch erneuert werden
Manuell alle paar Monate an Zertifikate denken zu müssen wäre fehleranfällig.
Deshalb sollten moderne Websites eine automatisierte Erneuerung verwenden.
Der Prozess kann ungefähr so aussehen:
Zertifikat läuft bald ab
↓
System fordert neues Zertifikat an
↓
Domainkontrolle wird bestätigt
↓
neues Zertifikat installiert
↓
Webserver verwendet neue Version
Im Idealfall bemerkt der Betreiber davon überhaupt nichts.
Nur wenn die Erneuerung fehlschlägt, sollte eine Warnung entstehen.
Ein abgelaufenes Zertifikat kann die Website praktisch unbenutzbar machen
Wenn ein Browser dem Zertifikat nicht mehr vertraut, zeigt er eine deutliche Sicherheitswarnung.
Für normale Besucher wirkt das alarmierend – zu Recht.
Ein abgelaufenes Zertifikat kann deshalb eine technisch funktionierende Website praktisch vom normalen Zugriff abschneiden.
Monitoring sollte daher nicht nur prüfen:
Ist der Server online?
Sondern bei wichtigen Websites auch:
Ist das Zertifikat weiterhin gültig?
Wie entsteht eine verschlüsselte Verbindung?
Beim Aufbau einer HTTPS-Verbindung führen Browser und Server einen sogenannten TLS-Handshake durch.
Vereinfacht passiert dabei:
Der Browser verbindet sich mit dem Server.
Der Server präsentiert sein Zertifikat.
Der Browser überprüft das Zertifikat.
Beide Seiten einigen sich auf kryptografische Parameter und erzeugen beziehungsweise leiten gemeinsame Sitzungsschlüssel ab.
Danach können die eigentlichen HTTP-Daten verschlüsselt übertragen werden.
Die reale Kryptografie ist komplexer.
Für das Grundverständnis reicht aber:
Identität prüfen
↓
sichere Schlüssel vereinbaren
↓
verschlüsselt kommunizieren
Warum wird nicht einfach alles mit dem öffentlichen Schlüssel verschlüsselt?
Asymmetrische Kryptografie ist für bestimmte Aufgaben hervorragend geeignet, aber vergleichsweise aufwendig.
Für große laufende Datenmengen wird deshalb typischerweise symmetrische Verschlüsselung eingesetzt.
Der TLS-Handshake sorgt dafür, dass beide Seiten sicher gemeinsames Schlüsselmaterial für die Sitzung erhalten.
Die anschließende Datenübertragung kann dann effizient mit symmetrischen Verfahren geschützt werden.
Das bedeutet:
Die komplexere Kryptografie hilft beim sicheren Verbindungsaufbau.
Die eigentliche laufende Übertragung verwendet anschließend effiziente Sitzungsschlüssel.
Was ist ein privater Schlüssel?
Zu einem Zertifikat gehört kryptografisch ein Schlüsselpaar.
Ein Teil davon ist öffentlich.
Der private Schlüssel muss geheim bleiben.
Er befindet sich normalerweise auf dem System, das die entsprechende TLS-Verbindung bedient.
Gerät dieser Schlüssel in falsche Hände, kann das die Sicherheit der entsprechenden Identität gefährden.
Deshalb sollten private Schlüssel:
nicht öffentlich gespeichert,
nicht versehentlich in Backups veröffentlicht,
nicht in Git-Repositories eingecheckt
und nur den notwendigen Systemen zugänglich gemacht werden.
Der private Schlüssel gehört nicht in das Webverzeichnis
Eine Datei mit einem privaten TLS-Schlüssel darf keinesfalls einfach öffentlich herunterladbar sein.
Sie gehört in einen geschützten Bereich des Servers.
Hosting-Control-Panels übernehmen diese Verwaltung normalerweise automatisch.
Wer einen Server selbst betreibt, trägt dafür eigene Verantwortung.
Das ist ein weiteres Beispiel dafür, warum ein eigener VPS mehr Kontrolle, aber auch mehr Sicherheitsaufgaben mit sich bringt.
Zertifikat und privater Schlüssel müssen zusammenpassen
Der öffentliche Schlüssel im Zertifikat gehört zu einem bestimmten privaten Schlüssel.
Der Webserver benötigt den passenden privaten Schlüssel, um die entsprechende kryptografische Identität verwenden zu können.
Wird ein falscher Schlüssel eingebunden, funktioniert die TLS-Konfiguration nicht korrekt.
Bei automatisierten Hostingplattformen sieht der Benutzer diese Details meistens nicht.
Bei manueller Serveradministration werden sie dagegen relevant.
Was ist die Zertifikatskette?
Der Browser erhält häufig nicht nur das eigentliche Website-Zertifikat.
Es existiert eine Kette von Zertifikaten.
Vereinfacht:
Root CA
↓
Intermediate CA
↓
Website-Zertifikat
Die Root-Zertifizierungsstelle befindet sich bereits im Vertrauensspeicher des Browsers beziehungsweise Betriebssystems.
Das Website-Zertifikat wird typischerweise über eine oder mehrere Zwischenzertifizierungsstellen mit dieser vertrauenswürdigen Wurzel verbunden.
Fehlt ein notwendiges Zwischenzertifikat, kann es bei Clients zu Zertifikatsproblemen kommen.
Warum verwenden Zertifizierungsstellen Zwischenzertifikate?
Eine Root-Zertifizierungsstelle ist besonders sensibel.
Ihr privater Schlüssel sollte möglichst stark geschützt und selten direkt verwendet werden.
Deshalb arbeiten Zertifizierungsstellen mit Intermediate-Zertifikaten.
Damit lässt sich eine Hierarchie aufbauen, ohne den besonders kritischen Root-Schlüssel für jede einzelne Website-Zertifizierung einsetzen zu müssen.
Für normale Website-Betreiber läuft diese Architektur im Hintergrund.
Was ist ein selbstsigniertes Zertifikat?
Technisch kann man ein Zertifikat selbst erzeugen und selbst signieren.
Die Verbindung kann damit ebenfalls verschlüsselt werden.
Der Browser vertraut dem Zertifikat aber normalerweise nicht automatisch.
Er kennt keine vertrauenswürdige Zertifikatskette dazu.
Deshalb erscheint eine Sicherheitswarnung.
Selbstsignierte Zertifikate können in internen Testumgebungen sinnvoll sein.
Für öffentlich zugängliche Websites sind Zertifikate einer vertrauenswürdigen CA normalerweise die richtige Lösung.
Eine Browserwarnung sollte nicht einfach weggeklickt werden
Wenn ein Browser meldet, dass ein Zertifikat ungültig ist, kann die Ursache banal sein.
Zum Beispiel:
Zertifikat abgelaufen.
Falsche Domain.
Fehlende Zertifikatskette.
Aber genau diese Prüfungen schützen vor manipulierten oder falsch konfigurierten Verbindungen.
Die richtige Reaktion bei einer eigenen Website lautet deshalb:
Fehler beheben.
Nicht:
Besuchern erklären, sie sollen die Warnung ignorieren.
Was bedeutet Mixed Content?
Eine Website kann selbst über HTTPS geladen werden und anschließend einzelne Ressourcen noch über unsicheres HTTP anfordern.
Zum Beispiel:
https://example.de
lädt ein Bild von:
http://example.de/bild.jpg
Das wird als Mixed Content bezeichnet.
Die Seite mischt also sichere und unsichere Ressourcen.
Browser können solche Inhalte warnen oder teilweise blockieren.
Eine korrekt migrierte HTTPS-Website sollte deshalb sämtliche notwendigen Ressourcen ebenfalls über sichere Verbindungen beziehen.
Mixed Content tritt häufig nach einer HTTPS-Umstellung auf
Besonders ältere WordPress-Seiten besitzen manchmal fest gespeicherte HTTP-URLs.
Nach der Umstellung auf HTTPS bleibt beispielsweise in einem alten Artikel:
http://example.de/wp-content/uploads/bild.jpg
stehen.
Dann muss nicht zwingend das Zertifikat falsch sein.
Die Seite selbst fordert schlicht noch eine unsichere Ressource an.
Solche Fälle sollten bereinigt werden.
Relative und interne URLs können Umstellungen erleichtern
Wie URLs in einer Website gespeichert werden, beeinflusst Migrationen.
WordPress besitzt allerdings zahlreiche Stellen, an denen vollständige URLs gespeichert werden können.
Bei einer HTTPS-Umstellung sollte deshalb kontrolliert werden, ob weiterhin interne HTTP-Verweise vorhanden sind.
Ein blindes Suchen-und-Ersetzen in einer WordPress-Datenbank kann gefährlich sein, weil manche Daten serialisiert oder strukturiert gespeichert werden.
Dafür sollten geeignete WordPress-Werkzeuge verwendet werden.
HTTP sollte auf HTTPS weiterleiten
Wenn eine Website auf HTTPS umgestellt wurde, sollte die alte HTTP-Adresse normalerweise nicht als eigenständige zweite Version bestehen bleiben.
Ein Aufruf von:
http://example.de
sollte auf:
weitergeleitet werden.
Typischerweise wird dafür eine permanente Weiterleitung eingesetzt.
Vereinfacht:
http://example.de
↓
301
https://example.de
Damit landen Besucher zuverlässig auf der sicheren Variante.
Auch www und non-www sollten konsistent behandelt werden
Eine Website könnte theoretisch unter vier Varianten erreichbar sein:
http://example.de
http://www.example.de
https://example.de
https://www.example.de
Für eine klare Architektur sollte eine Hauptvariante definiert werden.
Beispielsweise:
Die anderen Varianten leiten anschließend dorthin weiter.
Dadurch existiert für Besucher und Suchmaschinen eine eindeutige Hauptadresse.
HTTPS ändert die Domain nicht
Beim Wechsel von:
http://example.de
zu:
bleibt example.de dieselbe Domain.
Geändert wird das verwendete Protokoll.
Das ist technisch etwas anderes als ein Domainumzug von:
alte-domain.de
zu:
neue-domain.de.
Trotzdem ändern sich vollständige URLs.
Deshalb müssen Weiterleitungen und interne Konfiguration korrekt sein.
HTTPS läuft typischerweise über einen anderen Port als HTTP
Webserver unterscheiden Netzwerkdienste unter anderem über Ports.
Klassisches HTTP verwendet standardmäßig Port 80.
HTTPS verwendet standardmäßig Port 443.
Im Browser müssen diese Ports normalerweise nicht angegeben werden.
Bei:
weiß der Browser automatisch, welcher Standarddienst gemeint ist.
Bei eigener Serveradministration werden Firewall- und Webserverkonfigurationen dafür jedoch relevant.
Was ist SNI?
Ein einzelner Server kann viele HTTPS-Websites mit unterschiedlichen Zertifikaten betreiben.
Beim Verbindungsaufbau muss der Server wissen, für welchen Hostnamen der Besucher ein Zertifikat benötigt.
Dafür wird unter anderem Server Name Indication, kurz SNI, verwendet.
Der Client teilt dabei während des Verbindungsaufbaus mit, welchen Hostnamen er erreichen möchte.
Dadurch kann der Server das passende Zertifikat auswählen.
Das ist eine wichtige Grundlage modernen Shared Hostings.
Eine IP-Adresse kann deshalb viele HTTPS-Websites bedienen
Früher wurde teilweise angenommen, jede HTTPS-Website benötige zwingend eine eigene öffentliche IP-Adresse.
Für moderne Standardumgebungen stimmt das nicht.
Mit SNI können sehr viele Domains dieselbe IP-Adresse verwenden und trotzdem unterschiedliche Zertifikate besitzen.
Das ist besonders für Shared Hosting und Server mit zahlreichen Websites wichtig.
Eine gemeinsame IP-Adresse verhindert also grundsätzlich keine saubere HTTPS-Konfiguration.
HTTPS und DNS erfüllen unterschiedliche Aufgaben
DNS beantwortet vereinfacht:
Welches technische Ziel gehört zu diesem Hostnamen?
HTTPS beantwortet anschließend:
Wie kommunizieren Browser und dieses Ziel sicher miteinander und passt das Zertifikat zum angeforderten Hostnamen?
Der Ablauf sieht vereinfacht so aus:
example.de
↓
DNS
↓
IP-Adresse
↓
TLS-Verbindung
↓
Zertifikat prüfen
↓
HTTPS
↓
Website
Ein funktionierendes Zertifikat repariert deshalb kein falsches DNS.
Und korrektes DNS ersetzt kein TLS-Zertifikat.
Die Grundlagen des ersten Schrittes findest du in Was ist DNS?.
HTTPS und Hosting hängen zusammen
Das Zertifikat muss dort bereitstehen, wo die TLS-Verbindung tatsächlich angenommen wird.
Bei einfachem Hosting ist das der Webserver des Hosters.
Bei einer CDN- oder Proxy-Architektur kann die öffentliche TLS-Verbindung bereits am vorgeschalteten Dienst enden.
Danach existiert möglicherweise eine zweite TLS-Verbindung zum Origin.
Vereinfacht:
Browser
⇄ HTTPS ⇄
CDN
⇄ HTTPS ⇄
Origin
Genau deshalb kann ein CDN seine eigenen Zertifikate für die öffentliche Domain verwalten.
Mehr dazu findest du unter Was ist ein CDN?.
Auch die Verbindung vom CDN zum Origin sollte geschützt sein
Ein häufiger Denkfehler lautet:
Der Besucher sieht HTTPS, also ist alles sicher.
Wenn ein CDN vorgeschaltet ist, besteht die Übertragung jedoch aus mehreren Abschnitten.
Browser → CDN.
CDN → Origin.
Auch der zweite Abschnitt sollte sicher und korrekt authentifiziert werden.
Sonst wäre nur ein Teil des Transportweges angemessen geschützt.
Was ist HSTS?
HSTS steht für HTTP Strict Transport Security.
Damit kann eine Website dem Browser mitteilen, dass sie zukünftig ausschließlich über HTTPS aufgerufen werden soll.
Der Browser merkt sich diese Vorgabe für eine bestimmte Zeit.
Ein späterer Versuch, die Website über HTTP aufzurufen, kann dann unmittelbar auf HTTPS umgestellt werden, ohne zunächst eine normale unverschlüsselte HTTP-Nutzung zuzulassen.
Das kann die HTTPS-Konfiguration weiter absichern.
HSTS sollte nicht unüberlegt aktiviert werden
HSTS ist wirkungsvoll.
Genau deshalb sollte man wissen, was man tut.
Wenn der Browser gelernt hat:
Diese Domain ausschließlich über HTTPS verwenden.
muss HTTPS zuverlässig funktionieren.
Besonders weitreichende HSTS-Konfigurationen können auch Subdomains betreffen.
Eine falsche Einstellung kann dadurch mehrere Dienste beeinflussen.
HSTS gehört deshalb eher in eine bewusst geplante Konfiguration als in eine Sammlung zufällig aktivierter „Security Header“.
Was ist HSTS Preload?
Für besonders konsequente HTTPS-Nutzung existiert zusätzlich das Konzept von HSTS-Preload-Listen.
Dabei können Domains bereits in Browsern beziehungsweise deren zugrunde liegenden Listen als ausschließlich per HTTPS nutzbar bekannt sein.
Das verhindert selbst beim ersten Kontakt bestimmte HTTP-Szenarien.
Die Aufnahme sollte allerdings nur erfolgen, wenn die gesamte betroffene Domainstruktur dauerhaft und zuverlässig HTTPS unterstützt.
Ein späterer Rückweg ist deutlich umständlicher als das Entfernen eines normalen HTTP-Headers.
Für normale kleine Websites ist Preloading deshalb kein Pflichtprogramm.
HTTPS macht WordPress nicht automatisch sicher
HTTPS schützt den Netzwerktransport.
Eine unsichere WordPress-Installation bleibt trotzdem unsicher.
Zum Beispiel können weiterhin Probleme bestehen durch:
veraltete Plugins,
schwache Passwörter,
kompromittierte Administratoren,
unsichere Dateiberechtigungen,
fehlende Updates,
Schadcode.
HTTPS ist eine Sicherheitskomponente.
Nicht die gesamte Sicherheitsstrategie.
Ein HTTPS-Schloss schützt nicht vor einem gehackten Server
Angenommen, ein Angreifer besitzt vollständige Kontrolle über den Webserver.
Dann kann der Server selbst schädliche Inhalte über eine perfekt verschlüsselte HTTPS-Verbindung ausliefern.
Der Browser bekommt:
eine technisch sichere Verbindung
zu
einem kompromittierten Server.
Die Verschlüsselung funktioniert korrekt.
Das Problem liegt auf einer anderen Ebene.
Deshalb sollte Sicherheit immer schichtweise betrachtet werden.
HTTPS schützt auch nicht automatisch gespeicherte Daten
Ein Kontaktformular sendet Daten verschlüsselt an den Server.
Dort speichert WordPress die Nachricht möglicherweise in seiner Datenbank.
HTTPS schützt die Übertragung.
Wie die Daten anschließend gespeichert werden, ist eine andere Frage.
Dasselbe gilt für:
Backups,
Datenbanken,
Serverdateien.
Transportverschlüsselung und Verschlüsselung gespeicherter Daten sind unterschiedliche Konzepte.
HTTPS und Datenschutz sind deshalb nicht dasselbe
Eine Website kann sämtliche Verbindungen hervorragend verschlüsseln und trotzdem Datenschutzprobleme besitzen.
Beispielsweise weil sie unnötig viele persönliche Daten sammelt.
Oder Daten an zahlreiche Drittanbieter überträgt.
HTTPS verhindert nicht, dass ein berechtigter Empfänger Daten erhält.
Es schützt lediglich die Übertragung gegen bestimmte Risiken.
Datenschutz beginnt deshalb nicht und endet nicht beim Schloss im Browser.
Warum Browser HTTP-Seiten deutlich kritischer behandeln
Unverschlüsselte Verbindungen entsprechen heute nicht mehr dem erwarteten Sicherheitsstandard des Webs.
Browser kennzeichnen HTTP-Seiten deshalb zunehmend als nicht sicher beziehungsweise behandeln bestimmte Funktionen eingeschränkt.
Das ist sinnvoll.
Ein Besucher sollte erkennen können, wenn die Verbindung nicht gegen einfaches Mitlesen und Manipulieren geschützt ist.
Für neue Websites gibt es praktisch keinen guten Grund mehr, öffentliches normales HTTP als Hauptvariante zu betreiben.
HTTPS beeinflusst auch moderne Browserfunktionen
Einige Web-Plattformfunktionen stehen aus Sicherheitsgründen nur in sogenannten sicheren Kontexten zur Verfügung.
Das erhöht den praktischen Druck zusätzlich, Websites über HTTPS auszuliefern.
HTTPS ist deshalb heute keine Sonderfunktion für Banken oder Shops mehr.
Es gehört zur normalen technischen Basis einer Website.
Kostet HTTPS Performance?
Kryptografische Verfahren benötigen selbstverständlich Rechenleistung.
Auch der TLS-Handshake erzeugt zusätzliche Arbeit.
Auf modernen Systemen ist das jedoch normalerweise kein vernünftiger Grund, HTTPS zu vermeiden.
Moderne Webprotokolle und Server sind genau für diesen Einsatz konzipiert.
Zusätzlich können bestehende Verbindungen und moderne Transportmechanismen dafür sorgen, dass sich die Kosten über mehrere Anfragen verteilen.
In der Praxis gehört HTTPS zu einer modernen performanten Webarchitektur.
Ein schneller Server sollte HTTPS selbstverständlich bewältigen
Wenn ein normaler Webserver bereits durch TLS-Verschlüsselung überfordert wäre, liegt ein grundlegenderes Kapazitätsproblem vor.
Für typische WordPress-Websites ist die Kryptografie selbst selten der entscheidende Performanceengpass.
Viel häufiger sind:
PHP,
Datenbank,
Bilder,
JavaScript,
externe Dienste.
Die Performancegrundlagen behandeln wir unter Warum Websites langsam werden.
Zertifikatstypen sagen nicht automatisch etwas über Verschlüsselungsstärke aus
Früher wurde beim Marketing stark zwischen verschiedenen Zertifikatstypen unterschieden.
Dabei kann leicht der Eindruck entstehen:
Ein teures Zertifikat verschlüsselt stärker als ein kostenloses Domain-Zertifikat.
Das ist so pauschal falsch.
Die Stärke der tatsächlichen TLS-Verbindung hängt von verwendeten kryptografischen Protokollen und Algorithmen ab.
Ein kostenlos ausgestelltes Zertifikat kann eine ebenso moderne verschlüsselte Verbindung ermöglichen wie ein kostenpflichtiges Zertifikat.
Unterschiede liegen eher bei Validierung, Support, Vertragsleistungen oder organisatorischen Anforderungen.
Was ist Domain Validation?
Bei Domain Validation, kurz DV, wird im Wesentlichen geprüft, ob der Antragsteller Kontrolle über die Domain besitzt.
Das ist der übliche Ansatz für sehr viele moderne Website-Zertifikate.
Für einen Blog, eine Unternehmenswebsite oder ein Wissensportal reicht diese technische Domainvalidierung für HTTPS in aller Regel völlig aus.
Der Browser erhält dadurch eine vertrauenswürdige Zertifikatskette für den Hostnamen.
Teurer bedeutet nicht automatisch sicherer
Ein Unternehmen kann selbstverständlich aus organisatorischen oder vertraglichen Gründen einen bestimmten Zertifikatsanbieter wählen.
Aber die Vorstellung:
200-Euro-Zertifikat = starke Verschlüsselung
und:
kostenloses Zertifikat = schwache Verschlüsselung
ist falsch.
Für normale Websites ist eine korrekt konfigurierte aktuelle TLS-Verbindung mit zuverlässig erneuertem Zertifikat wesentlich wichtiger als der Preis des Zertifikats.
Zertifikatsfehler haben häufig ganz banale Ursachen
Wenn HTTPS nicht funktioniert, muss nicht sofort ein kryptografisches Problem vorliegen.
Typische Ursachen können sein:
Zertifikat abgelaufen,
falscher Domainname,
DNS zeigt auf falschen Server,
www-Version fehlt im Zertifikat,
Zertifikatskette unvollständig,
Webserver verwendet falsches Zertifikat,
CDN und Origin sind nicht richtig abgestimmt.
Die Kunst besteht darin, die betroffene Ebene zu erkennen.
Nach einem Serverumzug ist HTTPS besonders zu prüfen
Ein Hostingumzug kann beispielsweise so ablaufen:
Alter Server besitzt Zertifikat.
Website wird auf neuen Server kopiert.
DNS wird umgestellt.
Der neue Server besitzt aber noch kein korrektes Zertifikat.
Dann erreichen Besucher zwar den richtigen neuen Server, bekommen dort jedoch einen TLS-Fehler.
Deshalb sollte vor einer DNS-Umstellung geklärt sein, wie HTTPS auf dem Zielsystem bereitgestellt wird.
Die Grundlagen des Umzugs haben wir bereits bei Was ist Webhosting? behandelt.
DNS-basierte Zertifikatsvalidierung kann vor dem Umzug hilfreich sein
Bei manchen Zertifikatsverfahren lässt sich Domainkontrolle über DNS nachweisen.
Das kann insbesondere bei bestimmten Infrastrukturen praktisch sein, weil der neue Webserver dafür nicht zwingend bereits öffentlich die Website ausliefern muss.
Solche Verfahren werden auch für Wildcard-Zertifikate verwendet.
Für normale Shared-Hosting-Nutzer geschieht die Auswahl der Validierung meist automatisch im Hintergrund.
HTTP-basierte Validierung braucht den richtigen Server
Bei einer webbasierten Domainprüfung muss die Zertifizierungsstelle eine bestimmte Information unter der Domain erreichen können.
Zeigt DNS noch auf einen anderen Server, kann die Prüfung entsprechend dort landen.
Das erklärt, warum Zertifikatsausstellung bei Umzügen manchmal scheitert.
Domain, DNS, Webserver und Zertifikat hängen technisch zusammen, obwohl sie unterschiedliche Aufgaben besitzen.
Mehrere Websites brauchen saubere Zertifikatsverwaltung
Auf einem Hostingserver mit vielen Domains können entsprechend viele Zertifikate existieren.
Ein Control Panel kann deren Ausstellung und Erneuerung automatisieren.
Das ist deutlich angenehmer, als jede Domain manuell zu pflegen.
Bei größeren Installationen sollte trotzdem überwacht werden, ob automatische Verlängerungen fehlschlagen.
Ein einziger nicht erneuerter Domainname kann sonst überraschend einen Zertifikatsfehler produzieren.
Zertifikate gehören zur Betriebsüberwachung
Bei wichtigen Websites sollte Monitoring idealerweise prüfen:
Website erreichbar?
HTTPS funktioniert?
Zertifikat passt zum Hostnamen?
Zertifikat läuft nicht unmittelbar ab?
So kann ein Problem erkannt werden, bevor Besucher eine Warnmeldung sehen.
Viele Systeme bieten solche Prüfungen automatisch an.
HTTPS-Fehler sollten nach Ebenen untersucht werden
Eine sinnvolle Denkweise ist:
Domain korrekt?
↓
DNS korrekt?
↓
richtiger Server?
↓
Zertifikat vorhanden?
↓
Hostname im Zertifikat?
↓
Zertifikatskette korrekt?
↓
Webserver liefert richtiges Zertifikat?
↓
HTTPS-Seite selbst fehlerfrei?
↓
Mixed Content?
Damit wird aus „SSL geht nicht“ eine nachvollziehbare technische Fehlersuche.
WordPress muss seine HTTPS-Adresse kennen
WordPress arbeitet mit Website-URLs.
Nach einer HTTPS-Umstellung sollten diese Einstellungen zur tatsächlichen Hauptadresse passen.
Sonst können beispielsweise:
interne Links,
Weiterleitungen,
Loginvorgänge,
Assets
unerwartet auf HTTP verweisen.
Bei Proxy- und CDN-Umgebungen muss WordPress außerdem korrekt erkennen können, dass die ursprüngliche Besucheranfrage über HTTPS erfolgte.
Falsche Proxy-Konfigurationen können sonst Weiterleitungsschleifen erzeugen.
Was ist eine Redirect Loop?
Eine Weiterleitungsschleife entsteht beispielsweise, wenn zwei Systeme widersprüchliche Annahmen besitzen.
CDN:
Besucher ist bereits über HTTPS hier.
WordPress:
Anfrage sieht für mich nach HTTP aus, also weiter zu HTTPS.
Die Anfrage läuft erneut durch den Proxy.
WordPress sieht wiederum HTTP.
Und so weiter.
Der Browser meldet schließlich zu viele Weiterleitungen.
Solche Fehler sind keine Zertifikatsprobleme im engeren Sinn, sondern Architekturprobleme zwischen Proxy, Webserver und Anwendung.
Deshalb müssen Reverse Proxy und WordPress zusammenpassen
Ein CDN oder Reverse Proxy kann die öffentliche HTTPS-Verbindung terminieren.
WordPress läuft dahinter möglicherweise auf einer anderen Verbindungsebene.
Dann muss der Webserver beziehungsweise WordPress über geeignete Informationen erkennen, welches ursprüngliche Protokoll der Besucher verwendet hat.
Managed-Plattformen konfigurieren das automatisch.
Bei eigener Serverarchitektur sollte diese Ebene bewusst eingerichtet werden.
Ist HTTPS heute für SEO wichtig?
HTTPS gehört zum normalen technischen Standard einer modernen Website.
Man sollte es aber nicht als SEO-Trick betrachten.
Eine Website wird nicht deshalb hervorragend ranken, weil sie ein Zertifikat besitzt.
Der größere Punkt ist:
Eine öffentlich betriebene Website sollte Besuchern eine sichere und technisch saubere Verbindung anbieten.
SEO ist nur ein Teil der Gesamtbetrachtung.
Nicht wegen SEO auf HTTPS wechseln – sondern weil HTTP nicht mehr sinnvoll ist
Diese Unterscheidung klingt klein, ist aber wichtig.
Wer HTTPS ausschließlich als Rankingmaßnahme betrachtet, fragt:
Wie viele Positionen bringt mir das?
Die sinnvollere Frage lautet:
Warum sollte ich meinen Besuchern heute überhaupt noch eine unverschlüsselte Verbindung anbieten?
Die Antwort ist für die meisten öffentlichen Websites:
Es gibt keinen guten Grund.
Muss jede Subdomain ein Zertifikat besitzen?
Nur wenn über diese Subdomain ein TLS-Dienst angeboten werden soll.
Beispielsweise:
shop.example.de
benötigt für HTTPS ein passendes Zertifikat.
Dass example.de bereits eines besitzt, deckt shop.example.de nicht automatisch in jedem Fall ab.
Das hängt davon ab, welche Namen im Zertifikat enthalten sind beziehungsweise ob ein entsprechendes Wildcard-Zertifikat verwendet wird.
E-Mail verwendet eigene TLS-Verbindungen
Das Website-Zertifikat und die Absicherung von E-Mail sind nicht automatisch dasselbe Thema.
Mailserver verwenden ebenfalls TLS, aber über andere Dienste und Hostnamen.
Eine Website unter:
www.example.de
und ein Mailserver unter:
mail.example.de
können unterschiedliche Zertifikate und Konfigurationen besitzen.
Die Domain verbindet diese Systeme organisatorisch.
Technisch bleiben sie eigenständige Dienste.
Ein Zertifikat ist kein Backup
Klingt offensichtlich, wird aber bei Sicherheitsbegriffen manchmal alles in einen Topf geworfen.
HTTPS schützt:
die Kommunikation.
Ein Backup schützt:
die Wiederherstellbarkeit von Daten.
Eine Firewall kontrolliert:
bestimmte Netzwerkzugriffe.
Mehrfaktor-Authentifizierung schützt:
Kontozugänge.
Updates beseitigen:
bekannte Softwareprobleme.
Keine einzelne Maßnahme ersetzt die anderen.
Sicherheit entsteht aus mehreren Schichten.
Das Schloss im Browser ist nur die sichtbare Spitze
Der Besucher sieht vielleicht nur:
https://
und ein Symbol in der Browseroberfläche.
Dahinter steckt eine ganze Kette:
Domain
↓
DNS
↓
Server oder CDN
↓
TLS-Zertifikat
↓
Zertifikatskette
↓
Handshake
↓
Sitzungsschlüssel
↓
verschlüsselte HTTP-Kommunikation
Dass all das im Alltag praktisch unsichtbar funktioniert, ist eine der großen Leistungen moderner Webinfrastruktur.
HTTPS sollte langweilig sein
Für einen Website-Betreiber ist die beste HTTPS-Konfiguration diejenige, über die er kaum nachdenken muss.
Zertifikat wird automatisch ausgestellt.
Es wird automatisch erneuert.
HTTP leitet korrekt weiter.
Alle Ressourcen werden sicher geladen.
Monitoring meldet Fehler.
Fertig.
HTTPS sollte keine monatliche Wartungsaufgabe sein.
Es sollte eine zuverlässige Basisschicht der Website sein.
Was du dir über SSL, TLS und HTTPS merken solltest
HTTPS schützt die Kommunikation zwischen Browser und Website.
Technisch kommt dafür heute TLS zum Einsatz. Der Begriff SSL wird zwar weiterhin häufig verwendet, bezeichnet aber die historische Vorgängertechnologie.
Ein TLS-Zertifikat hilft dem Browser zu überprüfen, dass der Server ein gültiges Zertifikat für den angeforderten Hostnamen präsentiert.
Die laufende Verbindung wird anschließend verschlüsselt.
HTTPS bietet damit drei zentrale Eigenschaften:
Vertraulichkeit gegen einfaches Mitlesen,
Integrität gegen unbemerkte Veränderung
und
Authentifizierung der Gegenstelle innerhalb des Zertifikatssystems.
Das Zertifikat beweist jedoch nicht, dass eine Website seriös ist.
Es macht WordPress nicht automatisch sicher.
Es verschlüsselt nicht die Datenbank.
Und es ersetzt keine Backups.
HTTPS schützt eine ganz bestimmte Ebene:
den Transport der Daten.
Gerade deshalb ist es ein unverzichtbarer Bestandteil einer sauber aufgebauten Website.