HTTPS mit .htaccess erzwingen

Um HTTPS für den gesamten Datenverkehr in Apache zu erzwingen, fügen Sie drei Zeilen in die .htaccess-Datei im Stammverzeichnis Ihrer Website ein: RewriteEngine On, RewriteCond %{HTTPS} off und RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301].

Wenn Sie jemals eine Weiterleitungsregel aus einem Forenbeitrag eingefügt haben und dann zusehen mussten, wie der Browser in einer Endlosschleife steckte, bis er aufgab, war die Regel selbst wahrscheinlich in Ordnung. Was sie in der Regel zum Scheitern bringt, ist das, was vor Ihrem Server sitzt.

Diese Regel erfasst jede Anfrage, die über einfaches HTTP eingeht, und gibt eine permanente Weiterleitung zur identischen URL über HTTPS aus. Sie funktioniert auf Apache mit aktiviertem mod_rewrite und einem bereits installierten SSL-Zertifikat – und schlägt auf vorhersehbare Weise fehl, wenn ein CDN oder Load Balancer vor Ihrem Origin-Server sitzt. Dieser Leitfaden liefert zunächst die kopierfertige Regel, dann die Domain-, Ordner- und www-Varianten, anschließend die Behebung von Redirect-Schleifen und schließlich die Vorgehensweise, wenn Sie gar nicht Apache verwenden.

Voraussetzungen: SSL-Zertifikat und mod_rewrite

Das Erzwingen von HTTPS funktioniert nur, wenn ein gültiges TLS/SSL-Zertifikat bereits auf der Domain installiert ist. Eine Weiterleitung auf HTTPS ohne Zertifikat sichert die Website nicht – sie macht sie hinter einer Browser-Sicherheitswarnung unerreichbar. („SSL-Zertifikat” ist der gängige Branchenbegriff; das eigentliche Protokoll ist TLS.) Überprüfen Sie, ob das Zertifikat aktiv ist, indem Sie https://yourdomain.com direkt im Browser aufrufen und das Schlosssymbol prüfen, bevor Sie die .htaccess bearbeiten.

Die nachstehende Regel setzt das mod_rewrite-Modul von Apache voraus, das auf den meisten Shared- und cPanel-Hosting-Umgebungen standardmäßig aktiviert ist. Die .htaccess-Datei befindet sich im Stammverzeichnis Ihrer Website, in der Regel public_html oder dem Document Root der Domain. Bearbeiten Sie sie über den cPanel File Manager (aktivieren Sie „Show Hidden Files”, um Dotfiles anzuzeigen), per FTP oder über SSH. Erstellen Sie vor der Bearbeitung eine Sicherungskopie der Datei, damit Sie sie bei einer fehlerhaften Regel wiederherstellen können.

Die .htaccess-Regel zum Erzwingen von HTTPS für den gesamten Datenverkehr

Fügen Sie Folgendes in die .htaccess-Datei im Stammverzeichnis Ihrer Website ein, um jede HTTP-Anfrage auf HTTPS umzuleiten:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Zeile für Zeile: RewriteEngine On aktiviert die Rewrite-Engine. RewriteCond %{HTTPS} off löst die Regel nur aus, wenn die Verbindung noch nicht verschlüsselt ist. RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} baut die URL auf HTTPS um, wobei die Variablen %{HTTP_HOST} und %{REQUEST_URI} die exakte Domain und den Pfad des Besuchers erhalten – die Regel funktioniert daher domainübergreifend und erzwingt niemals stillschweigend www.

In den Flags [L,R=301] gibt R=301 eine permanente Weiterleitung aus, und L stoppt die Rewrite-Verarbeitung bei dieser Regel. Verwenden Sie beim Testen zunächst nur R (eine temporäre 302), da Browser 301-Weiterleitungen hartnäckig cachen und eine fehlerhafte 301-Weiterleitung mühsam rückgängig zu machen ist. Wechseln Sie erst zu R=301, wenn Sie bestätigt haben, dass die Weiterleitung sauber aufgelöst wird.

Wiederholen Sie RewriteEngine On nicht. Wenn die Zeile bereits in der Datei vorhanden ist, fügen Sie nur RewriteCond und RewriteRule darunter ein.

Varianten: Spezifische Domain, Unterordner und www-Kanonisierung

Um HTTPS nur für eine Domain zu erzwingen, wenn mehrere auf denselben Document Root zeigen, fügen Sie eine Bedingung für HTTP_HOST hinzu:

RewriteEngine On
RewriteCond %{HTTP_HOST} ^yourdomain\.com [NC]
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

Das Flag NC macht den Host-Abgleich unabhängig von Groß- und Kleinschreibung. Um HTTPS mit der www/Non-www-Kanonisierung zu kombinieren, dokumentiert htaccessbook das Einbetten beider Weiterleitungen in einen mod_rewrite-Guard:

<IfModule mod_rewrite.c>
	RewriteEngine On

	RewriteCond %{HTTPS} off
	RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

	RewriteCond %{HTTP_HOST} !^www\. [NC]
	RewriteRule (.*) https://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</IfModule>

Die veröffentlichte Version dieses Blocks setzt voraus, dass RewriteEngine On bereits weiter oben in der Datei steht; es wurde daher oben hinzugefügt, damit der Ausschnitt eigenständig funktioniert. Die erste Regel leitet die Anfrage auf HTTPS um. Die zweite fügt www zu einem Host hinzu, dem es fehlt. Beachten Sie, dass [L] die Verarbeitung beendet, sobald eine Regel zutrifft – eine einfache HTTP-Anfrage ohne www verursacht daher zwei Weiterleitungen statt einer: zunächst zu HTTPS, dann zum www-Host. Das Einbetten der Regeln in <IfModule mod_rewrite.c> sorgt dafür, dass die Website bei nicht geladenem mod_rewrite offen ausfällt (d. h. über HTTP ausgeliefert wird), anstatt einen 500-Fehler zu werfen.

Das manuelle Kombinieren dieser Regeln wird schnell unübersichtlich, sobald Sie HTTPS, www-Kanonisierung, einige Weiterleitungen und einen Caching-Block in derselben Datei zusammenführen – ein falsches Flag oder eine Regel in der falschen Reihenfolge kann in der Produktionsumgebung Probleme verursachen. Der htaccess-Generator von OpenReplay stellt die Datei anhand einer Reihe von Schaltern zusammen: HTTPS erzwingen, www hinzufügen oder entfernen, 301- oder 302-Weiterleitungen hinzufügen, Gzip und Browser-Caching aktivieren, IPs sperren, benutzerdefinierte Fehlerseiten zuweisen. Die Ausgabe ist kommentiert, aktualisiert sich bei Änderungen der Optionen und läuft vollständig im Browser – Sie können sie kopieren oder herunterladen und mit Ihrer bestehenden Konfiguration vergleichen.

ERR_TOO_MANY_REDIRECTS hinter einem CDN oder Load Balancer beheben

Wenn Ihre Weiterleitung ERR_TOO_MANY_REDIRECTS verursacht, hat der Browser zu viele Hops verfolgt und aufgegeben. Die häufigste Ursache ist ein TLS-terminierender Proxy oder Load Balancer. Da TLS am Proxy endet, ist %{HTTPS} am Origin-Server niemals on, die Regel wird bei jeder Anfrage ausgelöst, und die Schleife bricht nie ab. Die Lösung besteht darin, stattdessen dem weitergeleiteten Schema zu vertrauen:

<IfModule mod_rewrite.c>
	RewriteEngine On
	RewriteCond %{HTTP:X-Forwarded-Proto} !https
	RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</IfModule>

Hier liest RewriteCond %{HTTP:X-Forwarded-Proto} !https den vom Proxy gesetzten X-Forwarded-Proto-Header, sodass die Regel nur ausgelöst wird, wenn die ursprüngliche Besucherverbindung HTTP war. Testen Sie mit R, bevor Sie auf R=301 wechseln.

Eine Cloudflare Flexible SSL-Schleife ist ein anderes Problem mit einer anderen Lösung. Bei der Flexible-Verschlüsselung ist die Verbindung zwischen Cloudflare und Ihrem Server unverschlüsselt – eine Origin-Regel, die auf HTTPS besteht, sendet die Anfrage daher immer wieder in die Schleife. Cloudflare bietet zwei Auswege: Entweder entfernen Sie die HTTPS-Weiterleitung am Origin, oder Sie stufen die Zone auf Full oder strenger hoch, was ein Zertifikat am Origin erfordert. Beide Änderungen erfolgen im Cloudflare-Dashboard, nicht in der .htaccess. Ein Besucher im Flexible-Modus surft weiterhin über HTTPS, und das von Cloudflare in X-Forwarded-Proto gemeldete Schema spiegelt die eigene Verbindung des Besuchers wider, sodass der oben genannte Header-Test hier nicht fehlschlägt. Die Korrektur des Verschlüsselungsmodus ist dennoch die eigentliche Lösung.

Leeren Sie nach jeder Änderung den Browser-Cache und die Cookies, bevor Sie erneut testen, da eine gecachte 301-Weiterleitung eine Korrektur verdecken kann. Eine bedingte Schleife, die nur Nutzer betrifft, die über einen bestimmten Proxy-Pfad ankommen, ist bei einem einzelnen manuellen Test aus dem eigenen Browser unsichtbar. Session-Replay einer nach einer Migration betriebenen Website kann diese sporadische Redirect-Schleife sowie Mixed-Content-Fehler als Endlos-Bounce-Muster sichtbar machen, das echte Nutzer treffen.

Wann .htaccess nicht das richtige Werkzeug ist

.htaccess ist ausschließlich für Apache und wird nur auf Apache-basiertem Hosting ausgewertet. Auf Nginx gibt es keine .htaccess-Datei. HTTPS wird dort mit einem Server-Block erzwungen, der auf Port 80 lauscht und eine Weiterleitung zurückgibt:

server {
    listen 80;
    server_name yourdomain.com www.yourdomain.com;
    return 301 https://$host$request_uri;
}

Halten Sie return 301 nur im Port-80-Block; wird es in den 443-Block eingefügt, entsteht erneut eine Schleife. Bei modernen Stacks gehört die HTTPS-Durchsetzung oft auf die CDN-, Plattform- oder Load-Balancer-Ebene, anstatt in die Server-Konfiguration.

Sobald Ihre Weiterleitung funktioniert, härten Sie sie mit einem HSTS-Header ab, damit Browser automatisch über HTTPS verbinden und die unsichere HTTP-Anfrage vollständig überspringen. HSTS ist in RFC 6797 definiert; das OWASP HSTS Cheat Sheet empfiehlt Strict-Transport-Security: max-age=63072000; includeSubDomains; preload. Betrachten Sie preload als Einbahnstraße: Die Entfernung einer Domain aus der Preload-Liste dauert lange, und in der Zwischenzeit können Besucher von der Domain und allem darunter ausgesperrt werden, falls Sie jemals auf HTTP zurückfallen müssen.

Wählen Sie die Regel, die zu Ihrer Konfiguration passt, stellen Sie sie mit einer temporären 302 bereit, überprüfen Sie, dass die Weiterleitung in einem einzigen Hop aufgelöst wird, stufen Sie sie dann auf eine permanente 301 hoch, und ergänzen Sie HSTS obendrauf. Diese Vorgehensweise erzwingt HTTPS ohne die Redirect-Schleifen und gecachten Fehler, die aus einer Fünf-Minuten-Änderung einen Ausfall machen können.

Häufig gestellte Fragen

Was ist der Unterschied zwischen einer 301- und einer 302-Weiterleitung beim Erzwingen von HTTPS?

Eine 301-Weiterleitung ist permanent, eine 302 ist temporär. Browser cachen 301-Weiterleitungen aggressiv und halten sie lange vor, sodass eine fehlerhafte 301-Weiterleitung schwer rückgängig zu machen ist. Verwenden Sie beim Testen einer HTTPS-Weiterleitung zunächst R (eine 302) in den RewriteRule-Flags, bestätigen Sie, dass die Weiterleitung sauber in einem Hop aufgelöst wird, und wechseln Sie dann für die permanente Version zu R=301.

Wie überprüfe ich, ob meine HTTPS-Weiterleitung korrekt aufgelöst wird, anstatt nur den Browser-Cache zu leeren?

Führen Sie curl -IL http://yourdomain.com in der Kommandozeile aus. Das Flag -I fordert nur Header an, und -L folgt Weiterleitungen, sodass Sie die vollständige Kette sehen. Eine korrekte Konfiguration gibt eine einzelne 301-Weiterleitung mit einem Location-Header zurück, der auf die https-URL zeigt, gefolgt von einer 200-Antwort auf der sicheren Adresse. Wenn Sie mehrfache 301-Weiterleitungen oder eine Weiterleitung zurück zu http sehen, liegt eine Schleife vor. Dies ist deterministisch, anders als die Inspektion eines gecachten Browser-Tabs.

Warum wirft meine HTTPS-Weiterleitung einen 500-Fehler statt umzuleiten?

Ein 500-Fehler bedeutet in der Regel, dass mod_rewrite nicht geladen ist, Ihre Regel aber direkt RewriteEngine oder RewriteRule aufruft. Betten Sie die Regeln in einen IfModule mod_rewrite.c-Guard ein, damit Apache sie überspringt und über HTTP ausliefert, anstatt bei fehlendem Modul einen Fehler zu werfen. Auf den meisten Shared- und cPanel-Hosting-Umgebungen ist mod_rewrite standardmäßig aktiviert, aber der Guard ist das sichere Muster, wenn Sie dies nicht bestätigen können.

Funktioniert die .htaccess-HTTPS-Regel mit AWS Application Load Balancer oder anderen TLS-terminierenden Proxys?

Nicht die Standardregel mit %{HTTPS} off. Wenn ein AWS ALB oder ein ähnlicher Load Balancer TLS terminiert, endet die verschlüsselte Verbindung am Proxy, und Ihr Apache-Origin-Server sieht immer einfaches HTTP – %{HTTPS} ist daher niemals on, und die Regel gerät mit ERR_TOO_MANY_REDIRECTS in eine Schleife. Testen Sie stattdessen RewriteCond %{HTTP:X-Forwarded-Proto} !https, das den vom Proxy gesetzten Header liest, der das ursprüngliche Besucherprotokoll meldet.