301-Weiterleitung funktioniert nicht: SSL-Fehler bei ALL-INKL

Die Kurzfassung: Eine korrekt eingerichtete 301-Weiterleitung kann bei HTTPS trotzdem scheitern. Der Grund: Bevor der Webserver die Weiterleitung ausliefern kann, muss die sichere Verbindung zur Ausgangsdomain funktionieren. Fehlt dort ein gültiges SSL-Zertifikat oder wird es falsch bereitgestellt, kommt die Weiterleitung gar nicht erst beim Besucher an. Ein konkreter Fall aus unserem DJ-Domainprojekt zeigt das Problem bei ALL-INKL.

Praxisbeispiel: dj-in-arnstadt.de funktioniert, dj-arnstadt.de nicht

Bei der Erweiterung unseres DJ-Projekts wurden für Städte verschiedene Domains registriert. Die zusätzlichen Schreibweisen sollen per 301 (dauerhaft verschoben) auf die entsprechende Zielseite führen. Bei Arnstadt fiel am 10. November 2026 ein Unterschied auf:

Erreichbar: https://dj-in-arnstadt.de

Fehler beim HTTPS-Aufruf: https://dj-arnstadt.de

Gemeldeter Testbefund: Beim externen Abruf erschien HTTP 526 (ungültiges SSL-Zertifikat). Der genaue Fehler in der Host-/Zertifikatskonfiguration wurde damit noch nicht abschließend nachgewiesen.

Die 301-Weiterleitung der zweiten Domain war nach Angaben des Betreibers bereits bei ALL-INKL eingerichtet. Trotzdem öffnete sich die Zielseite im Browser nicht wie erwartet. Das Problem betrifft also zunächst die Erreichbarkeit der Weiterleitungsdomain über HTTPS und nicht zwingend die eingetragene Zieladresse.

Warum ein 301-Redirect das SSL-Problem nicht umgeht

Ein Browser, der https://dj-arnstadt.de aufruft, muss zuerst eine TLS-Verbindung zu genau diesem Hostnamen herstellen. Erst nach dem erfolgreichen Verbindungsaufbau kann der Server einen HTTP-Status 301 Moved Permanently und einen Location-Header mit der neuen URL zurückgeben.

Reihenfolge: HTTPS-Verbindung zur alten Domain → Zertifikatsprüfung → HTTP-Anfrage → 301-Antwort → Aufruf der Zieladresse. Misslingt die Zertifikatsprüfung, wird die nachgelagerte 301-Antwort möglicherweise nie erreicht.

Das erklärt, warum auch eine Domain, die gar keine eigene Website betreibt und nur weiterleiten soll, ein funktionierendes HTTPS-Setup benötigt. Das gilt ebenso für eine verwendete www-Variante.

Was bedeutet HTTP 526 genau?

Der Fehlercode 526 – Invalid SSL Certificate ist insbesondere aus Cloudflare-Umgebungen bekannt. Er wird dort ausgegeben, wenn Cloudflare im Modus Full (strict) das Zertifikat des Ursprungsservers nicht verifizieren kann. Typische Ursachen sind ein abgelaufenes Zertifikat, ein falscher Hostname im Zertifikat oder eine unvollständige Zertifikatskette. Aus dem Fehlercode allein folgt aber nicht, welche konkrete ALL-INKL-Einstellung falsch ist.

Die technische Erklärung steht in der offiziellen Cloudflare-Dokumentation zu Fehler 526. Ob eine vorgeschaltete Proxy-/CDN-Konfiguration beteiligt ist, muss man im konkreten Fall gesondert prüfen.

Fehler bei ALL-INKL beheben: SSL für die Weiterleitungsdomain prüfen

Schritt 1: Domain und DNS kontrollieren

Im ALL-INKL KAS prüfen, ob dj-arnstadt.de tatsächlich dem richtigen Hosting und dem vorgesehenen Redirect zugeordnet ist. Zusätzlich kontrollieren, wohin die DNS-Einträge zeigen. Wichtig: Die kostenlose Let’s-Encrypt-Einrichtung in der ALL-INKL-Anleitung setzt voraus, dass die Domain per DNS auf ALL-INKL verweist.

Schritt 2: SSL-Schutz für die Ausgangsdomain einschalten

Im KAS Domain → betreffende Domain → Bearbeiten → SSL-Schutz → Bearbeiten öffnen. Prüfen, ob ein gültiges Zertifikat für dj-arnstadt.de eingebunden ist. Fehlt es, kann man – sofern der Tarif und die DNS-Zuordnung das zulassen – das angebotene Let’s-Encrypt-Zertifikat beziehen und einbinden. Auch die Variante www.dj-arnstadt.de braucht eine passende Absicherung, falls sie verwendet wird.

Die genaue Klickfolge dokumentiert ALL-INKL in SSL-Zertifikat: Einbindung Let’s Encrypt Zertifikat. Wenn das Zertifikat laut KAS bereits aktiv ist, zusätzlich Hostname, Gültigkeit und Zertifikatskette prüfen lassen, statt blind neue Redirect-Regeln anzulegen.

Schritt 3: Die bestehende 301-Weiterleitung zunächst belassen

In der Domainverwaltung ist bei Ziel → Domainweiterleitung (Redirect) die gewünschte Zieladresse mit Status 301 Moved Permanently einzutragen. Wenn dies bereits erfolgt ist, die Einstellung zunächst nicht unnötig verändern: Eine neue 301-Regel behebt kein Zertifikatsproblem. Die offizielle ALL-INKL-Anleitung zur Weiterleitung beschreibt diesen Schritt.

Schritt 4: Nach der SSL-Reparatur erneut testen

Nacheinander http://dj-arnstadt.de/ und https://dj-arnstadt.de/ öffnen. Bei beiden Aufrufen muss die gewünschte Zieladresse erreicht werden. Für eine echte Statusprüfung unter Windows kann man in der Eingabeaufforderung curl.exe -I https://dj-arnstadt.de/ verwenden. Bei einer korrekt antwortenden ersten Weiterleitung sollte dann etwa HTTP/1.1 301 oder HTTP/2 301 sowie ein Location:-Header zur richtigen Zieladresse erscheinen.

Mit curl.exe -IL https://dj-arnstadt.de/ lässt sich die Weiterleitungskette verfolgen. Wenn curl dagegen einen Zertifikatsfehler meldet, diesen nicht durch dauerhaftes Abschalten der Zertifikatsprüfung „lösen“. Zuerst das Zertifikat beziehungsweise die TLS-Konfiguration reparieren.

Checkliste für größere Domainbestände

Wer viele regionale Domainvarianten besitzt, sollte jede einzeln kontrollieren. Eine funktionierende Hauptdomain sagt nichts darüber aus, ob auch die alternative Schreibweise über HTTPS erreichbar ist. Für jede Domain sind vier Punkte wichtig: HTTP-Aufruf, HTTPS-Aufruf, gültiges Zertifikat für den Hostnamen und korrekte 301-Zieladresse. Werden auch www-Hosts genutzt, gehören diese ebenfalls in den Test.

In unserem Projekt betrifft das nicht nur Arnstadt, sondern eine größere Gruppe von Stadt- und Alternativdomains. Der hier dokumentierte Befund ist eine Momentaufnahme vom 10. November 2026; die erfolgreiche Reparatur und der abschließende 301-Nachtest stehen für dj-arnstadt.de noch aus.