Der betroffene Webhost ist a2e5e und nach dem Bestellen einer neuen Domain oder Erstellung einer Subdomain wird nach dem Beantragen eines Let's Encrypt Zertifikats über das WCP nur das selbst signierte Plesk Zertifikat ausgeliefert. Anfrage beim Support wurde leider bis jetzt noch nicht bearbeitet.
Weil das in dem anderen Thread zum Problem bei der Verlängerung genannt wurde - das Problem tritt auch auf wenn die Option "Dauerhafte, für SEO geeignete 301-Weiterleitung von HTTP zu HTTPS" nicht ausgewählt wird.
LE SSL Zertifikat im WCP ausgewählt - Wird aber nicht ausgeliefert stattdessen plesk self-signed
- Copro
- Thread is marked as Resolved.
-
-
Nach der Antwort an den Support hat der Hostmaster das gestern Abend noch unkompliziert gelöst und die Beeinträchtigung bereinigt.
Das LE Zertifikat wird seit der Korrektur gestern Abend korrekt ausgeliefert und die statischen Dokumente liefert jetzt der nginx auch korrekt aus.
Solltet Ihr also auf eurem Webhost ähnliche Probleme haben und etwas Wartezeit das nicht lösen, am Besten freundlich beim Support nachfragen und das dringendste Problem - also am Besten das mit dem nicht korrekt ausgelieferten Zertifikat melden. -
Mich würde wirklich mal interessieren woran das liegt und warum es immer wieder auftritt.
Dieses Problem taucht ja regelmäßig hier im Forum auf, löst sich dann irgendwann entweder von selbst oder wird vom Support gelöst.
Eine Info, wodurch sowas ausgelöst wird und warum man die Ursache nicht generell beheben kann, habe ich aber noch nirgendwo gelesen... (Oder überlesen )
-
Also bei mir tritt das bei jeder neu registrierten Domain im Webhosting auf. Meine Vermutung geht in die Richtung, dass ich die Aufteilung der Stammverzeichnisse nicht aus dem httpdocs Ordner heraus nutze, sondern einen anderen Stammordner wie www verwende. Generell scheint es da irgendwo bei der Änderung der Stammverzeichnisse zu hapern, die z.B. nicht beim nginx ankommen.
-
Meine Vermutung geht in die Richtung, dass ich die Aufteilung der Stammverzeichnisse nicht aus dem httpdocs Ordner heraus nutze, sondern einen anderen Stammordner wie www verwende.
Genau so nutze ich es auch, alle Domains nutzen als DocRoot /www/domain.tld/subdomain usw. und trotzdem klappt LE bei mir problemlos. Ich vermute daher eher eine Fehlkonfiguration am Host oder eine andere Einstellung im Hosting, die zu diesem Fehler führt.
-
Genau so nutze ich es auch, alle Domains nutzen als DocRoot /www/domain.tld/subdomain usw. und trotzdem klappt LE bei mir problemlos. Ich vermute daher eher eine Fehlkonfiguration am Host oder eine andere Einstellung im Hosting, die zu diesem Fehler führt.
Sehe ich auch so. Eventuell kommen auch mehrere Faktoren zusammen. Z.B. Copro geht bei der Einrichtung der Zertifikate immer auf eine bestimmte Art und Weise vor, die zwar eigentlich funktionieren sollte aber eben nicht funktioniert. ALLES, was ein User im WCP einstellen kann, sollte prinzipiell funktionieren oder wenigstens nicht zu Zuständen führen, die der User nicht mehr selbst beheben kann. Von irgendwelchen Kamikaze-Aktionen wie dem Löschen sämtlicher Dateien/Datenbanken mal abgesehen. Obwohl selbst das der User eigenständig beheben kann, indem er die Daten aus seinem (hoffentlich vorhandenen ) Backup wiederherstellt.
Aber gerade bei den Einstellung für SSL konnte man die (Sub-)Domain offenbar in einen Zustand bringen, den man nicht mehr selbst beheben konnte. Ich denke es passierte, wenn man die dauerhafte Umleitung auf https aktiviert hat bevor ein Zertifikat vorhanden war. Bin mir da aber nicht mehr sicher, ob das derzeit noch so ist bzw wie man dahin kam. Jedenfalls liess sich die Umleitung nicht mehr deaktivieren, war also wirklich dauerhaft. ich bin bei solchen Dingen eher übervorsichtig und mache sowas Schritt für Schritt und nicht auf einmal, auch wenn das vom UI her möglich ist. Also erst Zertifikat erstellen und erst wenn das erstellt und zugewiesen ist dann die dauerhafte Weiterleitung. Insofern "finde" ich viele solcher Fehler im UI oder in der Serverkonfiguration erst gar nicht, wenn ich nicht explizit nach Fehlermöglichkeiten suche.
-
Wie gesagt, ich vermute auch dass es entweder ein Fehler am gesamten Host oder eben eine "andere" Bedienung/Userconfig im Hosting selbst ist. Bin aber gleichzeitig der Meinung, dass das nicht Aufgabe des Endbenutzers ist, rauszufinden welche der vielen Möglichkeiten denn fehlerfrei funktionieren. Hier hat einfach der Anbieter dafür zu sorgen, dass die Bedienung in jeder Konstellation erfolgreich verläuft, ansonsten eben ein Ticket bei Plesk erstellen oder selber fixen.
Ich habe das eben sogar testweise versucht absichtlich "falsch" zu forcieren:
1. neues Subdomain-Hosting angelegt
2. 302-Weiterleitung aktiviert, bevor(!) ich überhaupt LE aktiviert habe. Dadurch ließ sich hier natürlich auch nur das plesk-default Zertifikat auswählen, was wir ja eigentlich nicht wollen
3. danach erst habe ich das LE-Zertifikat aktiviert/eingerichtet, sogar mit der unnötigen www-Subdomain (-> www.sub.domain.de)
4. funzt! bei der 302-Weiterleitung wurde das eben frisch erzeugte Zertifikat automatisch hinterlegt und wird entsprechend korrekt ausgeliefert.
Bestärkt mein Gefühl, dass ggf. doch irgendeine Einstellung seitens Netcup an seinem Host anders ist als an meinem.
-
Bestärkt mein Gefühl, dass ggf. doch irgendeine Einstellung seitens Netcup an seinem Host anders ist als an meinem.
Das ist ohne weiteres denkbar, ist ja schon öfter der Fall gewesen. Insofern ist es sicher eine gute Idee, hierfür ein Support-Ticket zu erstellen.
Bin aber gleichzeitig der Meinung, dass das nicht Aufgabe des Endbenutzers ist, rauszufinden welche der vielen Möglichkeiten denn fehlerfrei funktionieren. Hier hat einfach der Anbieter dafür zu sorgen, dass die Bedienung in jeder Konstellation erfolgreich verläuft, ansonsten eben ein Ticket bei Plesk erstellen oder selber fixen.
Klar, Fehler können immer passieren. Auch (und ganz besonders) bei einem UI. Aber selbstverständlich kann es nicht Aufgabe des Users sein, für solche Fehler irgendwelche Workarounds zu finden. Seine Aufgabe beschränkt sich bestenfalls darauf, gefundene Fehler zu melden. Das meinte ich ja auch mit
ALLES, was ein User im WCP einstellen kann, sollte prinzipiell funktionieren oder wenigstens nicht zu Zuständen führen, die der User nicht mehr selbst beheben kann.
-
Mit einem Ticket beim Support konnte das Problem dann wieder einwandfrei bereinigt werden.
Ich wiederhole mal die Schritte von DerRené mit einer Subdomain, weil ich kann mir auch vorstellen kann, dass es nur die unglückliche Reihenfolge ist die das Problem auslöst.
1. Neues Subdomain-Hosting angelegt
2. 301-Weiterleitung aktivieren (Dauerhafte, für SEO geeignete 301-Weiterleitung von HTTP zu HTTPS )
3. Danach erst das LE-Zertifikat aktivieren mit der unnötigen www Subdomain (-> www.sub.domain.de)
4. Test und Prüfung erneut nach x Stunden (Direkt nach Anlage: Domain noch nicht zugewiesen / in Zuweisung)
Bisher hat das immer nicht geklappt:1. Neues Subdomain-Hosting angelegt
2. Zuerst das LE-Zertifikat aktivieren mit der unnötigen www Subdomain (-> www.sub.domain.de)
3. Dann die 301-Weiterleitung aktivieren (Dauerhafte, für SEO geeignete 301-Weiterleitung von HTTP zu HTTPS )4. Test und Prüfung erneut nach x Stunden
-
Neuer Versuch der ebenfalls nicht klappt - jetzt bleibt es bei der Anzeige des Standard index.html ohne LE Zertifikat:
Domain noch nicht zugewiesen / in Zuweisung0. Neues Unterverzeichnis im www Ordner angelegt mit frischer index.html und statischem Inhalt vorbefüllt.
1. Neues Subdomain-Hosting angelegt mit Zuweisung des angelegten Ordners
2. Zuerst das LE-Zertifikat aktivieren ohne www Subdomain
3. Dann die 301-Weiterleitung aktivieren (Dauerhafte, für SEO geeignete 301-Weiterleitung von HTTP zu HTTPS )
4. Test und Prüfung erneut nach 24 Stunden -> Anzeige ohne LE Zertifikat wie oben: Domain noch nicht zugewiesen / in Zuweisung
--> Ticket beim Support eröffnet
[UPDATE] Support konnte das Problem bereinigen.Zur Dokumentation der Zeiten bis zur Bereinigung:
07.03.2022 12:57 Ticket erstellt
08.03.2022 19:43 Weitergabe an Abteilung
10.03.2022 13:42 Bereinigung
-
Bei einer neuen Domain, (die aktuell mit Dokumentenstamm /domain.de/httpdocs angelegt wurde) und mit weiteren Subdomains testdomain.bestehendedomain.de habe wieder dieselben Problem ... Kontakt mit dem Support wurde schon aufgenommen und mittlerweile an Fachabteilung weiter gegeben.
[UPDATE] Das netcup Team konnte das Problem bereinigen. Es wird aus dem korrekten Dokumentenstamm Ordner ausgeliefert und das SSL Zertifikat ist ein gültiges von Let's Encrypt und nicht das abgelaufene von plesk.
Zur Dokumentation der Zeiten bis zur Bereinigung:
20.03.2022 20:41 Ticket erstellt
21.03.2022 15:24 Weitergabe an Abteilung
24.03.2022 13:57 Bereinigung
-
Den Support hat das ständige Bereinigen so genervt, dass das Problem jetzt bereinigt wurde ... zumindest bei mir am a2e5e tritt der Fehler jetzt nicht mehr auf.
Vielen Dank!