HTTPS-Umstellung: Zertifikat, Weiterleitung, Mixed Content

Warum lohnt die Umstellung?

Bei HTTPS ist die Verbindung zwischen Browser und Server verschlüsselt. Sie ist damit gegen Mitlesen und gegen Veränderung durch Dritte auf dem Weg geschützt. Für Suchmaschinen kommt ein zweiter Grund hinzu: Google bevorzugt bei gleichwertigen Seiten die https-Version als kanonische Adresse, solange es mit ihr keine Probleme gibt. Wie diese Auswahl funktioniert, beschreibt der Beitrag zum Canonical-Tag.

Eine Umstellung ist technisch ein Umzug aller Adressen. Google behandelt sie in der Dokumentation zum Website-Umzug mit URL-Änderungen, gemeinsam mit dem Wechsel der Domain oder der Pfade.

Wie komme ich an ein Zertifikat?

Ein TLS-Zertifikat stellt eine Zertifizierungsstelle (CA) aus. Wer den Server selbst betreibt, erzeugt dafür ein Schlüsselpaar und eine Zertifikatsanforderung (CSR). Google nennt in seiner Anleitung ein RSA-Schlüsselpaar mit 2.048 Bit: Kürzere Schlüssel lassen sich per Brute Force knacken, längere kosten unnötig Rechenzeit. Auf Shared Hosting läuft das häufig über das Kundenmenü des Hosters. Fragen Sie dort nach, wie Sie ein Zertifikat für Ihre Domain aktivieren.

Zwei Dinge sind wichtig, damit das Zertifikat später nicht zum Problem wird:

• Es muss zur Adresse passen. Das Zertifikat gilt für die vollständige Adresse oder als Platzhalter für mehrere Subdomains. Ein Zertifikat für example.com deckt sub.example.com nicht ab. Prüfen Sie also, dass Ihre Variante mit und ohne www abgedeckt ist.
• Es muss erneuert werden. Kostenlose Zertifikate von Let's Encrypt sind laut deren FAQ 90 Tage gültig, ohne Ausnahme. Empfohlen ist eine automatische Erneuerung alle 60 Tage. Wer von Hand erneuert, vergisst es irgendwann.

Ein ungültiges Zertifikat ist auch für die Suche relevant: Google nennt es als einen Grund, warum es statt der https- die http-Seite als kanonisch wählen kann.

Wie leite ich http auf https um?

Der Server muss jede http-Adresse mit einer permanenten Weiterleitung (301) auf dieselbe https-Adresse schicken, Pfad inklusive. Google gibt hier die Richtung vor: Einen Weg wählen und von allen anderen Adressen dorthin umleiten. Auf einem Apache-Server geht das in der .htaccess:

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://ihre-domain.de%{REQUEST_URI} [R=301,L,NE]

So löst diese Website es, mit der Domain ohne www als Ziel. Für die Variante mit www ersetzen Sie das Ziel entsprechend. Wichtig ist, dass am Ende genau eine Adresse steht. Läuft zuerst eine Weiterleitung von http auf https und danach eine zweite auf www, erzeugt das eine Kette. Besser ist eine einzige Weiterleitung, die beides erledigt. Welche Möglichkeiten es für Weiterleitungen auf Domain-Ebene gibt, steht im Beitrag zur Domain-Weiterleitung.

Was ist Mixed Content?

Mixed Content liegt vor, wenn eine über HTTPS geladene Seite einzelne Ressourcen über http nachlädt. Die Ressource ist nicht geschützt: Was unverschlüsselt kommt, lässt sich mitlesen oder verändern. Skripte sind besonders heikel, weil sie jeden Teil der Seite ändern können. Aber auch Bilder lassen sich manipulieren, etwa um die Wirkung eines Buttons zu verfälschen.

Browser gehen in zwei Stufen vor:

Eine Ausnahme: Steht in der Adresse eine IP statt eines Domainnamens, wird auch ein Bild nicht aufgerüstet, sondern blockiert. Bei Bildern in srcset oder picture gilt dasselbe. Auch Downloads über http von einer https-Seite gelten als unsicher und werden von Browsern in der Regel blockiert oder mit Warnung gezeigt.

So beseitigen Sie Mixed Content:

1. FindenDie Entwicklerkonsole des Browsers meldet, welche Ressourcen aufgerüstet oder blockiert wurden. Rufen Sie wichtige Seiten damit auf.
2. Adressen ändernDie Ressource per https einbinden. Gibt es sie nicht über https, besser selbst hosten oder entfernen.
3. Datenbank beachtenBei CMS-Websites stehen alte http-Adressen oft in Beiträgen, Widgets und Einstellungen. Einmal durchsuchen und ersetzen.
4. StichprobeTypische Orte sind Bilder in alten Beiträgen, eingebettete Karten und Videos, Schriften und Skripte von Drittanbietern.

Verlassen Sie sich nicht darauf, dass der Browser Bilder automatisch aufrüstet. Das ist ein Notbehelf, und er greift nicht überall.

Was muss ich bei Google nachziehen?

Für den Umzug gelten Googles allgemeine Regeln. Die wichtigsten für eine HTTPS-Umstellung:

• Nicht alles gleichzeitig. Google empfiehlt, Änderungen nacheinander vorzunehmen, also nicht im selben Schritt CMS, Layout und Protokoll zu wechseln.
• Search Console. Bestätigen Sie die Inhaberschaft für alle Varianten: http und https, mit und ohne www. Das Tool „Adressänderung“ ist für die reine Umstellung nicht nötig.
• robots.txt prüfen. Auf der https-Fassung dürfen keine Sperren stehen, die nur für den Umzug oder die Testphase gedacht waren. Gibt es keine Datei, muss der Server 404 liefern. Mehr zu den Regeln steht im Beitrag über robots.txt und Sitemap.
• Sitemap aktualisieren. Die Sitemap enthält die https-Adressen. Google rät ausdrücklich davon ab, die http-Fassung der Seiten in die Sitemap aufzunehmen.
• Canonical anpassen. Ein Canonical von einer https-Seite auf die http-Seite ist einer der Gründe, warum Google doch die http-Adresse wählt.
• Interne Links. Verlinken Sie direkt auf die https-Adressen, nicht über die Weiterleitung. Mehr dazu im Beitrag über interne Verlinkung.
• Serverlast. Nach dem Umzug crawlt Google verstärkt, weil es alte und neue Adressen abruft. Der Server sollte das verkraften.

Die Weiterleitungen kosten laut Google keinen Link-Wert, 301-Weiterleitungen haben keine negativen Auswirkungen auf den PageRank. Dennoch sind vorübergehende Schwankungen normal. Der Umzug ist erst abgeschlossen, wenn Google jede alte und neue Adresse mindestens einmal abgerufen hat. Das richtet sich nach der Größe der Website. Das Vorgehen bei einem größeren Umbau beschreibt der Beitrag Relaunch ohne Rankingverlust.

Wann lohnt HSTS?

HSTS, die HTTP Strict Transport Security, ist ein Antwortheader. Er sagt dem Browser, dass die Website künftig nur noch über https aufgerufen werden darf. Der Browser rüstet dann jede http-Adresse dieser Domain selbst auf, bevor er sie anfragt. Zusätzlich lässt er bei Zertifikatsfehlern kein Weiterklicken mehr zu.

Strict-Transport-Security: max-age=31536000; includeSubDomains

Die Angaben bedeuten:

• max-age ist die Zeit in Sekunden, die sich der Browser die Vorgabe merkt. 31536000 entspricht einem Jahr.
• includeSubDomains dehnt die Regel auf alle Subdomains aus. Jede Subdomain muss dann über https erreichbar sein.
• preload ist für die Aufnahme in die Preload-Listen der Browser gedacht und verlangt mindestens ein Jahr bei max-age und zusätzlich includeSubDomains.

Drei Regeln aus der MDN-Dokumentation:

1. Nur über https sendenDer Header wird über http ignoriert, damit ein Angreifer ihn nicht verändern kann. Die Weiterleitung von http auf https enthält ihn deshalb nicht.
2. Erst am Ende einschaltenWeil HSTS nicht über http zurückgenommen werden kann, sondern nur mit max-age=0 über eine https-Antwort. Wer es zu früh setzt und danach ein ungültiges Zertifikat hat, kann Besucher nicht mehr über die Warnung hinweglassen.
3. Die erste Anfrage bleibt ungeschütztHSTS wirkt erst, nachdem der Browser einmal über https mit der Domain Kontakt hatte. Dagegen hilft nur das Preloading.

Diese Website sendet den Header mit max-age=31536000; includeSubDomains und leitet http per 301 auf https weiter.

Wie prüfe ich die Umstellung?

1. Alle Varianten aufrufenhttp und https, mit und ohne www, jeweils mit einer Unterseite. Jede muss nach einer einzigen Weiterleitung bei derselben https-Adresse landen.
2. Statuscode prüfenGoogle empfiehlt dauerhafte Weiterleitungen. Der Statuscode sollte also 301 sein, nicht eine vorläufige Weiterleitung.
3. Konsole öffnenAuf wichtigen Seiten keine Mixed-Content-Meldungen.
4. Zertifikat prüfenGültig für die aufgerufene Adresse, Ablaufdatum notieren oder automatische Erneuerung bestätigen.
5. Search Console beobachtenDer Bericht zur Seitenindexierung zeigt, ob Fehler oder Ausschlüsse zunehmen. Die Sitemap zeigt, wie viele https-Adressen erkannt wurden.

Häufige Fragen