Besucher von shop.example.comerhalten ein Zertifikat, das nur für example.comgilt. Eine Weiterleitung zur Hauptdomain hilft nicht, denn der Browser prüft die Zertifikatsidentität, bevor überhaupt eine HTTP-Anfrage gesendet wird.
Ein Namensfehler lässt sich nur beheben, indem Zertifikat, SNI-Bindung und öffentlicher Host zusammenpassen. Dieser Artikel zeigt, wie Sie alle erreichbaren Namen erfassen und falsche Standardzertifikate an CDN, Proxy oder Webserver finden.
- Was das Thema bedeutet
- Ein realistisches WordPress-Beispiel
- Warum es wichtig ist und wann es eingesetzt wird
- Der einfache Weg für Einsteiger
- Der technische Weg
- Risiken, häufige Fehler, Backup und Rollback
- Wie AIOWS unterstützt: AIOWS SSL Manager
- Passende AIOWS-Artikel
- Fazit und empfohlener Weg
- Offizielle Quellen
Was ein Zertifikats-Namensfehler ist
Das Zertifikat muss den angefragten Hostnamen in den Subject Alternative Names (SANs) enthalten. Der ältere Common Name ist dafür heute nicht die maßgebliche Grundlage. Ein Wildcard-Zertifikat für *.example.comdeckt Namen wie shop.example.comab, jedoch weder example.comselbst noch a.b.example.com.
Zusätzlich muss der richtige TLS-Endpunkt dieses Zertifikat für den per SNI gesendeten Hostnamen ausliefern. Ein passender SAN-Eintrag nützt nichts, wenn CDN oder Virtual Host eine andere Bindung verwendet.
Ein realistisches WordPress-Beispiel
Für einen Shop wurde shop.example.comals CDN-Alias angelegt. Das Zertifikat am CDN enthält den Namen, der Alias wurde aber keinem konkreten Dienst zugeordnet und landet deshalb am Standard-Host. Dieser präsentiert ein Zertifikat für eine fremde Domain.
Das Team korrigiert die Alias- und Zertifikatsbindung, prüft jede aufgelöste IPv4- und IPv6-Adresse mit dem richtigen SNI-Wert und testet erst danach die Weiterleitung auf die kanonische URL. WordPress selbst benötigt keine Änderung.
Warum der Fehler vor WordPress behoben werden muss
Ein Browser kann einer Verbindung mit falscher Identität nicht vertrauen. Daher erreichen Login, REST, OAuth-Callbacks und Webhooks WordPress möglicherweise gar nicht. Eine Weiterleitung oder ein Plugin kann die Prüfung nicht nachträglich reparieren.
Der Ablauf gilt für Hauptdomain, www, Subdomains, Staging-Namen und externe Host-Aliase. Entfernen Sie Namen, die nicht öffentlich erreichbar sein sollen, statt sie ungeprüft in jedes Zertifikat aufzunehmen.
Der einfache Weg für Einsteiger
- Notieren Sie die exakte URL aus der Browserwarnung.
- Prüfen Sie, welche Namen das ausgelieferte Zertifikat tatsächlich abdeckt.
- Listen Sie Hauptdomain,
wwwund alle benötigten Subdomains vollständig auf. - Stellen Sie ein passendes Zertifikat aus und binden Sie es am öffentlichen Endpunkt ein.
- Testen Sie jeden Host in einem privaten Fenster und aus einem zweiten Netz.
- Richten Sie erst danach die gewünschte kanonische Weiterleitung ein.
Der technische Weg
Erstellen Sie eine Matrix aus Hostname, DNS-Ziel, IP-Adresse, SNI-Wert, erwarteter Seriennummer, SAN-Treffer, CDN- oder Virtual-Host-Bindung und späterem Redirect-Ziel. Prüfen Sie jede aktive Adresse einzeln, damit Round-Robin-DNS keinen fehlerhaften Knoten verdeckt.
- Vergleichen Sie Antworten mit korrektem SNI und – als Diagnose – ohne SNI.
- Beachten Sie, dass ein CNAME die Zertifikatsidentität seines Ziels nicht automatisch übernimmt.
- Testen Sie einen unbekannten Host als negative Kontrolle; er darf keine fremde Website ausliefern.
- Entfernen Sie alte Staging- und Aliasnamen aus DNS und Infrastruktur, wenn sie nicht mehr gebraucht werden.
Risiken, häufige Fehler, Backup und Rollback
Häufig wird nur die Hauptdomain geprüft oder fälschlich angenommen, ein Wildcard-Zertifikat decke jede Tiefe ab. Auch die Installation am richtigen Server, aber am falschen Listener, erzeugt weiterhin einen Namensfehler.
- Deaktivieren Sie niemals die Hostnamenprüfung.
- Bewahren Sie die bisherige Zertifikats- und Host-Bindung bis zur Abnahme auf.
- Ändern Sie Redirects nicht gleichzeitig mit der TLS-Bindung.
- Rollen Sie zurück, wenn zuvor funktionierende Hosts ein falsches Zertifikat erhalten.
Wie AIOWS unterstützt:
AIOWS SSL Manager
AIOWS SSL Manager hilft bei der WordPress-seitigen Kontrolle, nachdem das richtige Zertifikat am öffentlichen Endpunkt bereitsteht. Sie können damit prüfen, ob WordPress den vorgesehenen HTTPS-Host verwendet und ob Website-Adresse, Login und andere Anwendungswege konsistent auf die sichere Domain zeigen.
Vorher muss jedoch die Infrastruktur stimmen. Vergleichen Sie den fehlerhaften Host mit der SAN-Liste und ermitteln Sie, ob CDN, Proxy oder Webserver das falsche Zertifikat auswählt. Erst nach der Korrektur dieser Bindung prüfen Sie in WordPress die kanonischen Adressen und testen Navigation, Login, REST, Formulare und externe Callbacks. So vermeiden Sie, einen TLS-Identitätsfehler mit zusätzlichen Redirects zu überdecken.
Der SSL Manager kann keine externen Zertifikate an ein CDN binden, kein SNI-Routing eines Load Balancers ändern und keine fehlenden DNS-Namen ergänzen. Bewahren Sie deshalb die vorherige Endpunktkonfiguration separat auf. Falls ein neu gebundenes Zertifikat andere Hosts beeinträchtigt, stellen Sie die alte Bindung wieder her und korrigieren die Host-Matrix. Ist die Zertifikatsidentität für alle vorgesehenen Namen belegt, unterstützt AIOWS die anschließende Prüfung des WordPress-HTTPS-Zustands. Nicht vorgesehene Hostnamen sollten abgewiesen werden, statt still auf die Website umzuleiten.
Passende AIOWS-Artikel
- SSL auf einer WordPress-Website richtig einrichten
- SSL-Handshake bei WordPress fehlgeschlagen: Ursachen und Lösungen
- WWW- oder Non-WWW-HTTPS-Weiterleitung in WordPress
Fazit und empfohlener Weg
Bringen Sie DNS, SAN-Abdeckung und SNI-Bindung für jeden akzeptierten Host in Übereinstimmung. Erst danach folgen HTTP-Weiterleitung und WordPress-Konfiguration; fremde oder nicht mehr benötigte Hostnamen sollten klar zurückgewiesen werden.
