Webhosting 1000 (neu), Plesk, Lets Encrypt Zertifikat wird nicht angewendet/benutzt

  • Hallo zusammen,


    ich habe ein Problem das Lets Encrypt Zertifikat auf die Webseite einzubinden.

    Das Zertifikat wurde über das Plesk Panel (wie in der Anleitung) erstellt und in den Hosting-Einstellungen aktiviert.

    Die Webseite Zeigt allerdings ein Plesk Zertifikat an.


    Wo ist mein (Denk)-Fehler, irgendwelche Vorschläge ?


    Plesk -> Websites & Domains -> SSL/TLS ZertifikateZertInPanel.PNG


    Plesk -> Websites & Domains -> Hosting-Einstellungen (Sicherheit)

    HostingSicherheit.PNG

    HostingSicherheit2.PNG


    Ansicht Zertifikat Browser

    PleskZert.PNG


    Danke

  • Hay,


    das kann auch mit Browsercaching zusammenhängen. Probiere den Aufruf der Webseite mal im privaten Modus (Firefox) oder alternativ mit einem andern Browser.


    CU, Peter

    Peter Kleemann // https://www.pkleemann.de // +49 621 1806222-0 // Kann Programme, Internet, Netzwerke und Telefon.

  • Hay,


    das plesk Default Zertifikat wird da in der Kundenansicht auch nicht angezeigt. Das ist aber auch alles, was ich zum Webhosting sagen kann, habe selbst einen root-Server und ich sehe es natürlich als Administrator in den allgemeinen Einstellungen, aber nicht als Kunde.


    pasted-from-clipboard.png


    CU, Peter

    Peter Kleemann // https://www.pkleemann.de // +49 621 1806222-0 // Kann Programme, Internet, Netzwerke und Telefon.

  • SSL ist bei Plesk so bisschen eine Einstellungssache, schau mal bitte alle Menüs durch die du findest. Ich hab das mal vor Lichtjahren zuletzt gemacht und hatte das selbe Verhalten, irgendwo wird sich bei dir noch ein Haken verstecken.

  • Hay,


    hm, probiere mal, die Webseite ohne www vorne aufzurufen. Wenn dann das Lets Encrypt-Zertifikat kommt, dann hast Du vergessen "www-Subdomain" bei Beantragung des Zerts anzuklicken. Ist das einzige, was mir jetzt noch konkret einfällt.


    Wenn nicht und falls noch nicht geschehen, würde ich die Webseite

    - in den Hosting-Einstellungen absichtlich auf default stellen, dann wieder zurück und testen.

    - wieder auf default, das Lets Encrypt unter den SSL-Zertifkaten löschen und neu beantragen (einschließlich natürlich der "www" -Subdomain)


    Ich habe diese Schritte bei einer meiner Domains aus Kundensicht durchexerziert und es war jedesmal sofort im Browser der Wechsel des Zertifkats ersichtlich. Allerdings war die Installation des Lets Encrypt-Zeritifkates auch jedesmal beim ersten Mal erfolgreich...


    Ansonsten bin ich hier mit meinem Latein am Ende :)


    CU, Peter

    Peter Kleemann // https://www.pkleemann.de // +49 621 1806222-0 // Kann Programme, Internet, Netzwerke und Telefon.

  • Danke erstmal---


    Zitat

    dann hast Du vergessen "www-Subdomain" bei Beantragung des Zerts anzuklicken. Ist das einzige, was mir jetzt noch konkret einfällt.

    habe ich gemacht.


    Zitat


    in den Hosting-Einstellungen absichtlich auf default stellen, dann wieder zurück und testen.

    Auch schon getestet.


    Zitat


    wieder auf default, das Lets Encrypt unter den SSL-Zertifkaten löschen und neu beantragen (einschließlich natürlich der "www" -Subdomain)


    Auch schon gemacht.



    (Ich bin nicht einer der beim ersten Problem sofort im Forum postet.)

    Ich versuche schon seit 2 Tage es in den Griff zu bekommen.


    Gibt es ein Werks-Reset oder sowas ?


    @Skulduggery ich schaue nochmal alles durch.

  • Hallo nochmal,


    habe gerade nochmal nachgeschaut, und siehe da jetzt geht es.

    Ich habe seit gestern nichts geändert.

    Kann es sein das es etwas mit der neuen Domain zu tun hatte ?

    Diese war recht frisch, also ein halben Tag alt ...?


    Warum das jetzt funktioniert ist mir ein Rätsel.


    LG

  • Hay,

    Diese war recht frisch, also ein halben Tag alt ...?

    also in fast jedem Thread oder im ccp beim Beantragen von Domains steht, dass es bis zu 48h dauern kann, bis sich die DNS-Einstellungen weltweit herumgesprochen haben. Also ja natürlich.


    CU, Peter

    Peter Kleemann // https://www.pkleemann.de // +49 621 1806222-0 // Kann Programme, Internet, Netzwerke und Telefon.

  • Hallo,


    danke nochmal für die Hilfe und Sorry für den Thread.


    Da die Domain bereits erreichbar war, bin ich von der (falschen) Annahme ausgegangen das dies bereits durch war.

    Desweiteren habe ich gedacht: Domain erreichbar -> Lets Encrypt sollte funktionierren.


    Sorry nochmal und Danke !


    LG

  • Hay,

    Desweiteren habe ich gedacht: Domain erreichbar -> Lets Encrypt sollte funktionierren

    ja, das Mißverständnis liegt hier: Wenn Du die Domain erreichst, ist der für Deinen Internetanschluß zuständige DNS schon umgestellt. Insofern sieht für Dich alles funktionsfähig aus. Damit alles funktioniert muss aber auch der DNS von Lets Encrypt synchronisiert sein und letzlich auch der DNS, der Deinen Server versorgt (Netcup). Das ist selten zum gleichen Zeitpunkt so, da in der Regel unterschiedliche DNS-Server.


    Und dann kommt noch hinzu, dass z.B. die Fritzbox manchmal den (alten) DNS selbst dann noch cached, wenn Dein Provider längst schon die neue IP hat. Und wenn Du Pech hast und denkst, durch einen Start der Fritzbox behebt sich das, dann weist Dein Provider (Telekom ständig) beim neuen Verbindungsaufbau auch einen neuen DNS-Server für Dich zu, der noch die alte IP-Adresse der Domain hat...


    CU, Peter

    Peter Kleemann // https://www.pkleemann.de // +49 621 1806222-0 // Kann Programme, Internet, Netzwerke und Telefon.

  • Ich möchte hier nochmal nachhaken, da ich vor demselben Problem stehe und "einfach warten" mich nicht zufrieden stellt.

    Auch glaube ich irgendwie nicht, dass es am DNS liegt. Ich vermute eher, dass irgendein "Trigger" im Plesk noch fehlt oder ein Cronjob noch nicht gelaufen ist.


    Ich habe heute gegen 11:30 Uhr eine Domain von meinem alten Webhosting auf das neue Webhosting umgezogen. Mit /flushdns, Reboot der Fritzbox usw. konnte ich schon ab 12:00 Uhr den neuen Webspace erreichen und alles konfigurieren. Alle Zugriffe per HTTP funktionieren problemlos. nslookup liefert ebenfalls korrekte Ergebnisse zurück.


    Auch Let's Encrypt hat vollkommen problemlos funktioniert (an deren DNS kann es also auch nicht liegen). Es wurde ein korrektes Zertifikat beantragt und im Plesk hinterlegt. Auch ist jeweils genau das richtige Zertifikat für die betroffenen Domains / Subdomains im Plesk hinterlegt. Ich habe sogar den Text, der im Plesk als *.crt angezeigt wird, in eine Datei gegeben und mir von Windows interpretieren lassen. Ergebnis: Alles korrekt, zertifiziert von LE, DNS der Subdomain hinterlegt.


    Kurzum: Es ist alles da, HTTP läuft problemlos, nur mag der Webserver irgendwie nicht das im Plesk korrekt definierte SSL Zertifikat ausliefern.


    So. Und jetzt wird es komisch.

    Ich hatte gestern um 20:00 Uhr eine weitere Domain dem Webhosting zugewiesen. Gegen 01:30 Uhr habe ich für diese Domain im Plesk zwei Subdomains zum Testen angelegt. Auf beiden Domains hatte ich direkt beim Anlegen LE beantragt.

    Für diese Subdomains hat alles (HTTP und HTTPS) sofort funktioniert. Die Hauptdomain hatte ich unangetastet gelassen.

    Jetzt habe ich zum Test für diese weitere Domain selbst, auch ein LE Zertifikat beantragt. Und das Ergebnis? Der gleiche Mist wie mit der umgezogenen Domain. Dabei hat es für die Subdomains doch bereits funktioniert!?

    Auch das Verfahren von gestern (also Test Subdomain für diese weitere Domain) habe ich gerade wiederholt. Ebenfalls wird nur das Default-Zertifikat ausgeliefert. HTTP geht wie immer, komplett problemlos, weshalb ich DNS ausschließe.`

    Ich vermute, dass gestern irgendwas zwischen 20:00 und 01:30 Uhr passiert ist. Aber was?


    Die Frage ist also: Wie bringe ich den Webserver dazu, endlich meine Einstellungen aus dem Plesk anzuerkennen? Muss ich etwa wieder bis 01:30 Uhr warten?

  • Hay,


    schließt trotzdem ein DNS-Problem nicht aus (ohne den Server selbst zu sehen, kann ich aber auch nicht mehr dazu sagen). Einfach per ssh mit dem Server verbinden (sollte in jedem neuem Tarif drin sein) und mal auf dem Server selbst einen nslookup/dig auf die domain/subdomain machen.


    Meiner persönlichen Erfahrung nach ist es sehr häufig der für den Server zuständige Netcup-Nameserver selbst, der als letztes von Änderungen etwas mitbekommt. Hatte da schon Verzögerungen von 8-12 Stunden in Relation zu rest-of-world und ich bin zugegeben ungeduldig, wenn ich eine neue Domain habe und schnell mal was tun möchte, deswegen schaue ich da eigentlich immer als erstes drauf, wenn es nicht so läuft, wie ich will.


    Ich warte dann notfalls die 48h einfach ab und erst wenn es danach immer noch "irgendwie komisch" ist, dann melde ich mich beim Support.


    An dieser Stelle auch gleich mal ein Screenshot, den ich zufällig vor ein paar Tagen gemacht habe und das ganze Dilemma mit DNS aufzeigt:


    DNS_Telekom_Diff.jpg


    Es zeigt die Telekom-IP-Einstellungen der Fritzbox und ich habe beide meiner angebotenen DNS von der Telekom separat und direkt abgefragt. Der eine (aktive) hatte die neue ipv4-Adresse noch nicht, der andere hatte sie. Witzigerweise hatten beide schon die neue ipv6 Adresse. Nach Neuaufbau der DSL-Verbindung bekam ich dieselben DNS-Server und dasselbe Ergebnis. Irgendwann dann in der anschließenden Nacht hatte ich dann auch die korrekte ipv4 sofort.

    Peter Kleemann // https://www.pkleemann.de // +49 621 1806222-0 // Kann Programme, Internet, Netzwerke und Telefon.

  • Danke für die Hinweise. Da geht uns wohl ähnlich mit der Ungeduld :)

    Danke auch für die Erfahrungen, dass die Änderung bei Netcup selbst wohl am längsten dauert.


    Leider kann ich in der SSH chroot weder dig, noch ping oder sonst was nützliches finden, womit ich das testen kann. Auch openssl fehlt leider.

    Ein curl https://domain.tld -v liefert wenigstens die Info, dass die korrekte IPv6 Adresse geladen wird, aber auch dort kommt ein self signed certificate.


    Aber gut. Ich habe alles auf dem neuen Webspace fertig konfiguriert. Außer den Zertifikatswarnungen funktionieren auch alle Clients (Nextcloud und Co) wieder einwandfrei. Ich werde mich dann also zurücklehnen und auf morgen oder übermorgen warten.


    P.S.: Es ist einfach frustrierend, dass die einzige Lösung "bitte warten" ist :(

    Den Support hätte ich dafür aber auch nicht voreilig bemüht.

  • Hay,


    vielleicht würde ich - wenn es nach Zeitablauf noch nicht funktioniert - einfach mal alles zurückstellen auf "normal" und dann so vorgehen, als hätte ich Lets Encrypt noch nie beantragt...


    Leider kann ich in der SSH chroot weder dig, noch ping oder sonst was nützliches finden, womit ich das testen kann. Auch openssl fehlt leider.

    Ein curl https://domain.tld -v liefert wenigstens die Info, dass die korrekte IPv6 Adresse geladen wird, aber auch dort kommt ein self signed certificate.


    Die eine Hälfte iv6 hast Du ja schon....z.B. lässt sich wget auf ipv4 zwingen. curl auch, mit -ipv4 als parameter.

    Wäre mal interessant zu sehen, was curl so ausgibt...

    wget trick.jpg


    CU, Peter

    Peter Kleemann // https://www.pkleemann.de // +49 621 1806222-0 // Kann Programme, Internet, Netzwerke und Telefon.

  • Die eine Hälfte iv6 hast Du ja schon....z.B. lässt sich wget auf ipv4 zwingen. curl auch, mit -ipv4 als parameter.

    Wäre mal interessant zu sehen, was curl so ausgibt...

    Danke für die Befehle. Dort bekomme ich tatsächlich auf einzelnen Domains noch die alte IP. Auf diesen Domains wird auch korrekterweise noch das alte LE Zertifikat ausgeliefert vom Server. Auf den ganz neuen Domains kommt aber der korrekte Server und das Plesk self-signed Zertifikat :rolleyes:


    Hier mal ein Screenshot von der URL für die Nextcloud Instanz (leitet auf die alte Instanz weiter, mit HTTP 503 wegen Wartungsmodus):

    Nextcloud alt.PNG


    Und zum Vergleich die neue Domain (mit neuer IP):

    Neue Domain.PNG



    curl von meinem PC aus ergibt etwas ähnliches, aber eben auch auf der Nextcloud Instanz:

    Nextcloud Neu.PNG


    Edit: Vor lauter Screenshots meine letzte offene Frage vergessen:

    Wie kann es denn sein, dass der Webserver offensichtlich alles richtig ausliefert, aber das falsche Zertifikat nimmt? DNS hin oder her. Es kommt ja der korrekte Content (per HTTP). Nach meinem Verständnis macht das alles der Nginx auf der .132 oder etwa nicht?

  • Hay,

    Wie kann es denn sein, dass der Webserver offensichtlich alles richtig ausliefert, aber das falsche Zertifikat nimmt? DNS hin oder her. Es kommt ja der korrekte Content (per HTTP). Nach meinem Verständnis macht das alles der Nginx auf der .132 oder etwa nicht?

    das kann (so) nur sein, wenn das Zertifikat einfach nicht installiert ist, was wiederum vorkommen kann, wenn Du es zu früh versucht hast. Bei den Domains, die bereits auf der neuen IP laufen würde ich deswegen wie oben vorgeschlagen die Zertifikate wegnehmen und von neu starten.


    Außerdem musst Du natürlich achten, dass eine htaccess nicht auch noch den well-known ordner umleitet. Es kann ja sein, dass Du bei den neuen Domains beantragt hast, der Letsencrypt hat über htaccess auf den alten IPs "seinen" Ordner entdeckt und Dir die Zertifikate erstellt, plesk meint, dass er die dann installiert hat und dann fehlen sie trotzdem. Oder irgendwie so ein ähnliches gewusel :D wtf :D


    CU, Peter

    Peter Kleemann // https://www.pkleemann.de // +49 621 1806222-0 // Kann Programme, Internet, Netzwerke und Telefon.

  • So, ich möchte euch mein Feedback natürlich nicht schuldig bleiben. Nachdem ich es am Wochenende nicht mehr lösen konnte, hatte ich keine Zeit mehr mich drum zu kümmern. Ich habe also NICHTS GEÄNDERT.


    Seit Mittwoch morgen (also zwischen 48 und 72 Stunden nach der Änderung) liefert der Webserver das richtige Zertifikat aus. Warum? Ich habe keine Ahnung X/


    DNS ist natürlich inzwischen auch auf dem Webserver korrekt.

  • Hay,


    freut mich. Es freut mich allerdings auch, dass mein "GEDULD!!!" ein sehr erfolgreiches Troubleshooting ist :D (wenn auch nicht unbedingt befriedigend).


    CU, Peter

    Peter Kleemann // https://www.pkleemann.de // +49 621 1806222-0 // Kann Programme, Internet, Netzwerke und Telefon.