Webseiten, die auf T-Online gehostet sind, lassen sich seit der der Nacht von 26. auf den 27. Juni 2022 nicht mehr per https abrufen. Es kommt eine Meldung, dass die Seite unsicher ist (Dies ist keine sichere Verbindung) und der Google Chrome verweigert die Anzeige. Man kann maximal die Inhalte über http anzeigen lassen. Hintergrund ist ein abgelaufenes Zertifikat bei t-online.de. Hier einige Informationen – im Netz scheint es noch wenig an Meldungen zu geben.
Anzeige
Ich habe wenig mitbekommen, da am gestrigen Sonntag, den 26. Juni 2022 mein Multisite-Blog (englischer IT-Blog, Senioren-Blog, Japan-Blog) am Abend aus dem Internet geschossen wurde. Da ging nichts mehr, selbst ins WordPress-Dashboard kam ich nicht mehr herein (Object nicht gefunden). Hintergrund war wohl, dass ein Update von Sprachdateien (Themes, Plugin) in Kombination mit einem wild gewordenen Plugin eine Reihe wichtiger Daten gelöscht hatte. Ich konnte diese aus einem Backup manuell restaurieren und so die Blogs schrittweise reparieren – ohne ein altes Backup komplette zurückschreiben zu müssen. Aber am Ende des Tages war noch eine Reparaturinstallation durch erneute Aktualisierung von WordPress 6.0 erforderlich, bis alles wieder lief. Nur der IT-Blog hier arbeitete weiter, da er eine separate Installation verwendet (dafür hatte ich die letzte Woche dort Ärger, siehe Probleme mit dem Blog (21. Juni 2022), aktuell läuft alles, aber ich weiß nicht, woran es letztendlich lag, vermute aber Speicherlimits beim Arbeitsspeicher des Web-Pakets). IT ist Teufelszeug – merken auch T-Online-Kunden, die deren Hosting-Angebot nutzten.
Eine Lesermeldung
Stefan Kanthak, der seine Webseite bei t-online hostet, hat mich gestern (26.06.2022, 17:50 Uhr) per Mail kontaktiert, um auf das Problem hinzuweisen – wegen der obigen Probleme habe ich das Ganze erst jetzt (27.6.) abgerufen. Stefan schreibt:
Moin Guenter,
versuch doch mal, IRGENDEINE Web-Seite unter homepage.t-online.de per
HTTPS aufzurufen, beispielsweise <*https://skanthak.homepage.t-online.de>,
alternativ auch gar nicht existierende wie <*https://[name]homepage.t-online.de/>:Diese PROFIS haben das heute Nacht abgelaufene X.509-Zertifikat NICHT
erneuert.mfg
Stefan
Der Platzhalter [name] steht für einen beliebigen Namen – denn es ist ein Wild-Card-Zertifikat für *homepage.t-online.de. Ich habe dann mal im Browser die Seite von Kanthak zum 27. Juni 2022 um 11:00 Uhr im Browser abgerufen und bekommen folgende Meldung:
Anzeige
Bisher hat T-Online das Zertifikat noch nicht aktualisiert. Inzwischen habe ich diese Meldung von gestern dazu gefunden – eine Antwort des Telekom-Teams steht noch aus. Noch jemand betroffen?
Das ist nicht das erste Zertifikatsproblem für 2022. Zum 30. Januar 2022 ist ein Zertifikat für die Mail-Server von T-Online ausgelaufen, so dass der Mailversand gestört war. Ich hatte im Beitrag Mail-Probleme: Telekom-Zertifikat zum 30.1.2022 abgelaufen berichtet.
Anzeige
Finde ich ja immer wieder geil zu sehen, dass selbst große Firmen kein funktionierendes Zertifikatsmanagement haben
Ja, "geil" kann man auch dazu sagen … ;-)
"schockierend" und " irgendwie unglaublich", geht aber auch … ;-)
Ach so, ja: "peinlich" passt auch noch ganz gut, wenn man bedenkt, wie sich die Telekom immer selbst sieht und nach außen so darstellt …
Und noch immer sind die Fehlermeldungen irreführend. Denn nur weil das Zertifikat abgelaufen ist, ist die Verbindung nicht unsicher.
Sag das deinen Browser, der das so anzeigt.
Wenn man bei FF auf "Advanced" bekommt man die Seite trotzdem auf.
Das ist natürlich nicht der Sinn der Übung…
Aber wie kann so etwas passieren?
Warum dauert es solange das zu beheben?
Sind alle Bedenkenträger im Urlaub?
Also seltsam:
Validity
Not Before: Mon, 21 Jun 2021 07:13:13 GMT
Not After: Sat, 25 Jun 2022 23:59:59 GMT
Das Zertificat lief eh nur ein Jahr und 1 Woche 370 Tage.
Wie kann man das "vergessen"?
(Und es zum Sonntag auslauen zu lasesn? Ist das ne Gute Idee?)
Scheinbar ist das eins dieser Low-Budget-Zertifikate, die man auch anderweitig bei Webhostern kostenlos kriegt, dafür aber jedes Jahr manuell verlängern muss.
Webspace à la xyz.providername.de ist als Gratiszugabe zum Internetanschluss eben mehr denn je ein Stiefkind. Wer dort seine private Homepage parkt, muss schon dankbar sein, wenn er überhaupt https nutzen darf.
Das hat mit Low-Budget-Zertifikat nichts zu tun. Alle halbwegs aktuellen Web-Browers akzeptieren keine Zertifikate mehr, deren Laufzeit viel mehr als ein Jahr beträgt.
Chrome / Firefox liefern ein ERR_CERT_VALIDITY_TOO_LONG wenn ein Zertifikat nach dem 1. September 2020 ausgestellt wurde und länger als 398 Tage gültig ist.
Gruß Singlethreaded
Is doch super simpel.
Das ist offensichtlich ein manueller Prozess.
Der mega teure alteingesessene Kollege Herbert Müller (der den ganzen Tag eh nix schafft!111) wurde mit einem Frührente-Auslöse-Angebot von einem Controller finanziell wegoptimiert.
Ergo…macht das keiner mehr.
Und bevor ein ankommt: es ist die Telekom, als ob da was automatisiert gesichert funktionieren würde 😂
"Der mega teure alteingesessene Kollege Herbert Müller (der den ganzen Tag eh nix schafft!111) wurde mit einem Frührente-Auslöse-Angebot von einem Controller finanziell wegoptimiert."
😂 👌 😂 👍 😂
Genial (und durchaus im Möglichen) auf den Punkt gebracht!
Selbst vor einiger Zeit erst wieder erlebt, was passieren kann, wenn "zu teure Alte" mal eben wegoptimiert werden. Und dann bekommt man noch den Frust der Geschäftsleitung ab, "warum denn dies und jenes plötzlich nicht mehr funktionieren würde …?" Darauf hin dann bekommt man (nach Aufklärung) als Antwort: "Ach so – ja, – nun, dann machen sie dies eben ab sofort alleinverantwortlich-administrativ mit …!"
Danke für die Ehre … 😒
Unfassbar, da es durchaus kostenlose Zertifikate gibt, die sich automatisch erneuern…
Besonders peinlich:
Inhabername: Deutsche Telekom AG
Ausstellername: T-Systems International GmbH
Also praktisch der selbe Laden. Vermutlich erschwert aber gerade diese Tatsache ein schnelles Handeln. Jeder, der mit der Telekom mal zu tun hatte, weiß, wovon ich rede.
Ist ja aber auch nicht gerade so, als hätte der "rosa Riese" solcherlei Pannen exklusiv – da gibt's ja überall verteilt ebenso auffallende "Experten". 🤷♂️
Vielleicht gab es ja mal einen Plan, das Wild-Card-Zertifikat für *.homepage.t-online.de einzustampfen und Zertifikate jeweils nur noch direkt für die Subsubdomains auszustellen und dieses Projekt wurde dann aus irgendwelchen Gründen doch nichts oder läuft seit Jahr und Tag fleissig irgendwo zwischen Entscheidern und Umsetzern hin und her.
Warum man sowas machen wollen könnte? Beispielsweise um bei Bedarf einzelne dieser Subsubdomain Auftritte leichter nicht verlängern aka revoken zu können. Mit der Gültigkeit eines SSL-Zertifikats steht und fällt jede Sichtbarkeit und auch Erreichbarkeit im Netz, Zertifikat weg = Inhalt weg.
Als ich vorletzte Woche für alle manuell zu bestückenden Server das wildcard konvertiert und überall hinterlegt habe, hatte ich kurz die Idee, dass man dafür eine Zertifizierung aus dem Boden stampfen und einen neuen Beauftragen küren sollte:
Zertifikatbeauftragte(r)
Dann noch ein Zertifikats-Management-System in die ISO/Grundschutz schummeln und schon läuft es.
Montags trifft sich die Arbeitsgruppe Datenschutz, dienstags die Arbeitsgruppe Informationssicherheit, mittwochs die Arbeitsgruppe für Zertifikatsdienste, donnerstags die Arbeitsgruppe zur Auslegung von Management-Vorgaben und freitags die Arbeitsgruppe Windows Update Forschung.
Am Wochenende kann man dann von einer Zukunft mit sinnvoller Technikgestaltung träumen.
Klingt gut. :-)
Zumindest für Telekom…
Und das setzt ja :
Achtung Trigger!
Achtung Trigger!
"Dokumentation" vorraus.
Kann man das nicht outsourcen?
In die Cloud schieben?
Nein, ich habe es:
Per script in block chain!
Das ist sicher!
Es ist jetzt 18:17 Uhr. Ich habe soeben das Telekom Kundencenter und Magenta Sport aufgerufen. Beide kann ich unter https aufrufen, und es kommen keinerlei Fehlermeldungen.
Werder das Kundencenter noch Magenta Sport liegen unter der Subdomain *.homepage.t-online.de
Wenn man sich jetzt das Zertifikat ansieht:
Allgemeiner Name *.homepage.t-online.de
Gültigkeit:
Beginn: Mon, 20 Jun 2022 13:22:44 GMT
Ende: Sat, 24 Jun 2023 23:59:59 GMT
Das Zertifikat wurde rechtzeitig ausgestellt, aber das wars dann. :)
Wieder auf den Sonntag morgen zu Ende?
Hoffen die, das, wenn sie es wieder vergessen haben, das irgendwem schon am Sonntag auffallen wird, so daß der Schaden bei den privaten Homepages schon nicht so groß werden wird? Und sie on Ruhe das Cert erneuern können?
Oder wieder Zufall?
Sonntag in der Nacht, kurz vor Montag endet die Laufzeit des neuen Zertifikates. Das Ende der Laufzeit richtet sich übrigens immer am Ausstellungszeitraum. Solange man am Montag ein Zertifikat ausstellt, hat man gute Chance dass es an einem Sonntag ausläuft. ;)
Achso, thanks. ich dachte man könnte die Anzahl der Tage vorgeben.
Dennoch hätte man doch schon letzte Woche das erneuern können, oder auf 398 Tage setzen und hätte noch einen ganzen Monat zeigt, es zu vergessen… :-)
Aber vermutlich ist das wirklich nicht automatisiert….
Ah.. ja. Telekom arbeitet ja auch mit Outlook, und da hat Kollege das scheduled. Nun ist er im Urlaub (eMails im Urlaub von der firma sind ja verboten) und Peng.
Paßt…
Fehler vom Outlook-Kalender. Der hätte warnen müssen :-)
Softwarefehler!