SSL-Fehler nach Domainumzug
ssl fehler nach domainumzug · domain migration https · dns umzug zertifikat
Domainumzug und HTTPS: DNS, alte IPs, CDN, Zertifikatsausstellung, Redirects und Timing sauber prüfen.
Von DN01 Netzwerk-Team
Nach Domainumzügen überlagern sich DNS-Propagation, alte Server, neue Zertifikate und Redirect-Regeln. Für Besucher sieht das Ergebnis oft nur wie "Diese Verbindung ist nicht privat" aus, während Betreiber mehrere Schichten auseinanderhalten müssen: DNS-Ziel, Server Name Indication, Zertifikatskette, Gültigkeit, SAN-Namen, Protokollversion und Browser-Cache.
Der praktische Startpunkt ist der DN01 SSL Certificate Checker unter /de/ssl-certificate-checker. Er zeigt die öffentlich sichtbare TLS-Antwort einer Domain und hilft, Panel-Angaben, Load-Balancer-Konfiguration und Browserfehler gegen Live-Daten zu prüfen.
Dieser Leitfaden ist bewusst operativ geschrieben: erst eingrenzen, dann ändern, danach erneut messen. Verlinken Sie die relevanten SSL-Guides im Change-Ticket, damit Support, Hosting-Team und Entwickler nicht mit unterschiedlichen Annahmen arbeiten.
Wann dieser Check wichtig ist
Nutzen Sie den Guide bei Registrarwechsel, Nameserverwechsel, Hosting-Migration, CDN-Onboarding oder Relaunch mit neuer Domainstruktur.
Besonders kritisch sind Änderungen, die nicht überall gleichzeitig sichtbar werden: DNS-Umzüge, neue CDN-Zonen, Ingress-Regeln in Kubernetes, Zertifikatswechsel auf mehreren Nodes oder parallele IPv4/IPv6-Pfade. Prüfen Sie deshalb nicht nur die Hauptdomain, sondern auch www, api, mail, staging und jede öffentlich verlinkte Subdomain.
Öffnen Sie /de/ssl-certificate-checker, testen Sie den Hostnamen ohne Pfad und dokumentieren Sie Zeitpunkt, IP-Ziel, Ablaufdatum, Aussteller und Kette. Bei DNS-Fragen ergänzt /de/dns-checker die Sicht auf A-, AAAA- und CNAME-Ziele; bei Security-Headern hilft /de/http-header-checker.
Schritt-für-Schritt prüfen
1. Domain im SSL Checker testen und zuerst den Hostnamen im Zertifikat mit der geprüften Domain vergleichen. 2. notBefore und notAfter lesen. 3. Intermediate-Zertifikate und Reihenfolge prüfen. 4. Ergebnis mit Browserfehler, Server-Config und Deploy-Zeitpunkt abgleichen.
Prüfen Sie zuerst mit /de/dns-checker, wohin die Domain zeigt, und danach mit dem SSL Checker, welches Zertifikat dieser Pfad liefert. Wiederholen Sie nach TTL-Ablauf.
Wenn ein Ergebnis unerwartet ist, wiederholen Sie die Prüfung mit exakt demselben Hostnamen nach einem TTL-Zyklus und zusätzlich über den alternativen Namen, zum Beispiel example.com und www.example.com. Unterschiedliche Resultate deuten meist auf SNI, CDN, IPv6 oder einen nicht aktualisierten Backend-Knoten hin.
Häufige Fehler in der Praxis
Neue Zertifikate werden auf dem Zielserver installiert, während ein Teil der Nutzer noch den alten Server erreicht. Redirects werden vor gültigem HTTPS eingerichtet.
Ein weiterer Klassiker ist die Verwechslung von Zertifikat und HTTPS-Weiterleitung: Ein Redirect auf https://www.example.com hilft nicht, wenn https://example.com bereits vor dem Redirect mit falschem Zertifikat antwortet. Der TLS-Handshake passiert zuerst, die HTTP-Weiterleitung danach.
Verlassen Sie sich nicht nur auf Hosting-Panels. Panels zeigen oft das gespeicherte Zertifikat, nicht zwingend das Zertifikat, das der öffentliche Edge, Proxy oder Mail-Server gerade ausliefert.
Nützliche Querprüfungen
Lesen Sie im selben Cluster weiter: /de/guides/ssl/ssl-redirect-http-zu-https, /de/guides/ssl/ssl-ipv6-aaaa-probleme, /de/guides/ssl/ssl-zertifikat-erneuern-checkliste. Diese Guides decken angrenzende Ursachen ab und verhindern, dass ein Chain-Problem als DNS-Problem oder ein HSTS-Problem als Zertifikatsproblem behandelt wird.
Für Migrationen lohnt sich ein kleines Prüfprotokoll: alte IP, neue IP, geprüfter Hostname, Zertifikatsfingerprint, Ablaufdatum, Chain-Status, Browserfehler und verantwortlicher Dienst. Dieses Protokoll beschleunigt Eskalationen, weil Provider konkrete Live-Werte statt Screenshots aus lokalen Browsern bekommen.
Nach der Korrektur erneut mit dem SSL Checker prüfen und erst dann Caches, CDN-Purge oder HSTS-Änderungen ausrollen. So bleibt klar, welche Änderung den Fehler wirklich beseitigt hat.
| Beobachtung | Wahrscheinliche Ursache | Nächster Schritt |
|---|---|---|
| Browserfehler nur auf einer Subdomain | SAN-Name fehlt oder falscher vHost | Subdomain separat im SSL Checker prüfen |
| Mobil funktioniert, Desktop nicht | Kette oder Trust Store unterscheidet sich | Intermediate-Reihenfolge vergleichen |
| IPv6 liefert anderes Zertifikat | AAAA-Pfad zeigt auf alten Edge | DNS und Load Balancer gemeinsam prüfen |
| Fehler nach Renewal | Neues Zertifikat nicht auf allen Nodes aktiv | Fingerprint pro Edge/Backend vergleichen |
Häufig gestellte Fragen
- Wie lange können Fehler nach Umzug auftreten?
Mindestens bis relevante DNS-TTLs abgelaufen sind; manche Resolver cachen länger.
- Soll der alte Server HTTPS behalten?
Ja, während der Übergangsphase sollte auch der alte Pfad ein gültiges Zertifikat ausliefern.