Von AH03099 zu AH01909

Man oh man :-(. Apache ist nach den letzten Post aus WordPress heraus wieder eingefroren, aber in der error.log stehen nicht mehr tausende von AH03099-Fehlermeldungen, sondern  „AH01909: default:443:0 server certificate does NOT include an ID which matches the server name“. Das deutet ziemlich klar auf Probleme mit meinen Zertifikaten hin. Ich habe jetzt mal mein Default-Zertifikat von Plesk gelöscht und lasse nur noch mein Lets Encrypt-Zertifikat aktiv. Dazu habe ich ein paar Einstellungen umgestellt. Das ist reines Try-and-Error. Hoffentlich zerschieße ich mir nichts.

V-Server-Upgrade des Betriebssystems mehr oder weniger geglückt

Ich bin wegen des Upgrades meines V-Servers seit über einem Jahr wie die Katze um den heißen Brei geschlichen. Es kann einfach zu viel schief gehen. Aber nachdem ich die Hardware durch den neuen Vertrag massiv aufgerüstet habe, wären ein Verweilen auf dem alten Ubuntu 12 LTS sowohl Blödsinn als auch langsam ein Sicherheitsrisiko gewesen. Nachdem ich gestern aus meiner Sicht alle relevanten Daten meiner bisherigen Installation gesichert hatte, habe ich den Sprung gewagt und über Nacht die Aktualisierung auf Ubuntu 18 LTS angestoßen. Die Nacht habe ich aber deshalb richtig schlecht geschlafen. Doch heute morgen war der Server auf dem neuen Stand – aber natürlich ohne alle meine bisherigen Daten und Einstellungen. Weder waren Webseiten da noch ging E-Mail. Was aber klar war. Und jetzt musste es sich zeigen, ob ich das Upgrade wirklich sorgfältig vorbereitet hatte und meine rudimentären Admin-Kenntnisse für das Wiederherstellen der Webseiten und der restlichen Dienste genügen.

Das Fehlen der E-Mail war erst einmal das größte Problem und ich habe versucht, meine gesicherten Einstellungen einfach zurückzuspielen, um möglichst schnell wieder per E-Mail erreichbar zu sein. Das ging gründlich schief und auch der 1. Versuch, meine gesicherten Webseiten wiederherzustellen, ebenso. 🙁

Also habe ich den Server gleich noch einmal vollkommen plattgemacht und ein 2. Mal neu installiert.

Wenn man es besonders eilig hat, sollte man langsamer gehen.

In dem zweiten Versuch habe ich nach der Neuinstallation erst meine Haupt-Domain rjs.de vollkommen neu und leer aufgesetzt und dann zuerst den E-Mail-Server neu konfiguriert und auch mein E-Mail-Konto komplett neu angelegt – natürlich mit den bisherigen Daten. Nach einigem Hin- und Her mit SMTP und Zertifikaten etc. ging das aber dann durch. Das ist schon mal das Wichtigste gewesen.

An die Wiederherstellung der Webseiten bin ich dann auch indirekt gegangen.

  1. Anlegen einer Datenbank mit den alten Zugangsdaten, die für die Webseite bisher eingerichtet waren.
  2. Einspielen des gesicherten Dumps.
  3. Kopieren alles gesicherten Dateien aus dem Sicherungsverzeichnis auf dem Server in das neu angelegte Verzeichnis

Das hat für meine zentrale Webseite und den Blog (offensichtlich) schon mal funktioniert und auf dem Weg werde ich wohl auch noch die anderen Seiten über den Tag reproduzieren können.

Aber es gibt diverse Kleinigkeiten wie FTP-Zugänge, Schreibrechte für die automatische Aktualisierung durch das CMS, Zertifikate (ich nutze Let’s Encrypt, aber da gibt es wohl auch im Vertrag eine Möglichkeit, ein anderes Zertifikat zu verwenden), Aktualisierungen etc., die noch einige Arbeit machen werden. Und ich will gar nicht wissen, was ich alles übersehen habe und/oder doch verloren gegangen ist.

Aber die wichtigsten Sachen sind wohl gutgegangen :-).

Zertifikatsprobleme

Da will ich doch gestern spät am Abend meinen Fliegerblog nach gefühlten Ewigkeiten – gegrounded wegen Corona – mit einem Beitrag füllen und bekomme eine Meldung, dass die Seite unsicher ist und kein gültiges Zertifikat hat. Nach einem anstrengenden Flugtag hatte ich gestern keine Lust mehr mich darum zu kümmern. Aber heute morgen kam die gleiche Meldung bei meinem normalen Blog, aber auch bei meiner Webseite  und anderen Subdomains samt meiner Plesk-Adminoberfläche. Also ganz offensichtlich ein grundsätzliches Problem.

Ich verwende ein Zertifikat von Let’s Encrypt, was eine nonprofit-Organisation mit freien Zertifikaten ist. Und das ist immer noch eine bestimmte Zeit gültig, verlängert sich aber eigentlich automatisch. Zumindest ist das bei mir eingestellt und so war es bisher. Aber dieses Mal hat die Verlängerung wohl nicht funktioniert. Egal – das Zertifikat halt heute morgen schnell für alle Domains/Subdomains von Hand verlängert und jetzt ist wieder alle gut.