Firefox, die Fritz!box & der SEC_ERROR_INADEQUATE_KEY_USAGE Fehler

Was hatten wir schon lange nicht mehr? Das der Firefox seltsame Fehlermeldungen ausspuckt. Seit es Firefox 69 gibt, kann man statt der Adminoberfläche seiner Fritz!box nur noch einen mysteriösen, bis Dato unbekannten, „SEC_ERROR_INADEQUATE_KEY_USAGE“ Fehler sehen:

Fehler: Gesicherte Verbindung fehlgeschlagen

Beim Verbinden mit fritz.box trat ein Fehler auf. Eine Verwendung des Zertifikatschlüssels ist für den versuchten Arbeitsschritt unpassend. Fehlercode: SEC_ERROR_INADEQUATE_KEY_USAGE

Die Website kann nicht angezeigt werden, da die Authentizität der erhaltenen Daten nicht verifiziert werden konnte.
Kontaktieren Sie bitte den Inhaber der Website, um ihn über dieses Problem zu informieren.

Wer ist da der Schuldige?

Ihr kennt den Fehler auch nicht? Da seid Ihr in guter Gesellschaft. Ein so unbekannter Fehler ist es dann allerdings auch nicht, wie meine Nachforschungen ergeben haben. Leider nutzt dies alles nichts, da man den Bug nicht selbst beheben kann. Das Ihr eine Fritzbox, einen Firefox und Linux habt, ist übrigens keine Garantie auch eine Fehlermeldung zu bekommen.

Der Fehler wird von Firefox seit 69 für die Fritzboxen gezeigt, d.b. Firefox hat offensichtlich einen Check verändert, der vorher durchgelaufen ist.
Moniert wird, daß der Key gar nicht für ein Cert zugelassen wäre: „A certificate has a key usage extension that does not assert a required usage“

Wenn man sich das Cert mit openssl x509 -text -purpose ansieht, kommt das raus:

Certificate purposes:
SSL client : Yes
SSL client CA : Yes
SSL server : Yes
SSL server CA : Yes
Netscape SSL server : Yes
Netscape SSL server CA : Yes
S/MIME signing : Yes
S/MIME signing CA : Yes
S/MIME encryption : Yes
S/MIME encryption CA : Yes
CRL signing : Yes
CRL signing CA : Yes
Any Purpose : Yes
Any Purpose CA : Yes
OCSP helper : Yes
OCSP helper CA : Yes
Time Stamp signing : No
Time Stamp signing CA : Yes

Also alles korrekt? Mitnichten!

Die Zwecke für die das Zert eingesetzt werden darf, sind ok. Was aber ins Auge fällt ist:

X509v3 Subject Alternative Name: critical
DNS:benderirc.de, DNS:fritz.box, DNS:www.fritz.box, DNS:myfritz.box, DNS:www.myfritz.box, DNS:fritz.nas, DNS:www.fritz.nas

Ihr seht richtig. In dem Cert der Fritzbox taucht ein Domainname auf, der da gar nichts zu suchen hat und von dem Firefox bereits ein gültiges Zertifikat kennt.

Issuer: CN = benderirc.de
Validity
Not Before: Dec 24 15:25:01 2017 GMT
Not After : Jan 15 15:25:01 2038 GMT

Schauen wir weiter nach der Gültigkeit, finden wir raus, daß es bereits im Jahr 2017 erzeugt wurde, so also schon seit Jahren dem Firefox vorliegt und der das bislang noch nie moniert hat.

AVM gegen Mozilla

Die Frage zu klären wird sicher spannend und nervig werden. Primär würde ich jetzt erstmal AVM beschuldigen, weil der Domainname hat da nun so gar nichts zu suchen. Was geht bitte meine Fritzbox eine meiner Domains an? Auf der anderen Seite, ist das kein neuer Zustand, also wieso meckert FireFox jetzt da drüber?

Ich werde also beide anmailen müssen, damit jeder seinen Teil an dem Desaster behebt. Im Bugzilla von Mozilla ist zu dem Fehler bereits vor 6 Jahren mal ein Patch geschrieben worden, ich wette da hat bei Version 68->69 einer dran rumgespielt.

 

FIXED: Apache 2.4.41-4

Für Euch frisch aus der Werkstatt: Apache httpd 2.4.41-4 löst das Problem „Apache httpd 2.4.41 mit defektem PIPE support

Fedora User können schon updaten

und zwar mit folgendem Befehl für FC29:

dnf -y update https://kojipkgs.fedoraproject.org//packages/httpd/2.4.41/4.fc29/x86_64/httpd-2.4.41-4.fc29.x86_64.rpm https://kojipkgs.fedoraproject.org//packages/httpd/2.4.41/4.fc29/noarch/httpd-filesystem-2.4.41-4.fc29.noarch.rpm https://kojipkgs.fedoraproject.org//packages/httpd/2.4.41/4.fc29/x86_64/mod_ssl-2.4.41-4.fc29.x86_64.rpm https://kojipkgs.fedoraproject.org//packages/httpd/2.4.41/4.fc29/x86_64/httpd-tools-2.4.41-4.fc29.x86_64.rpm

Die Version ist jetzt erst einige Minuten alt und wurde extra für uns gebaut \o/

Die FC30 Version gibt dann hier: https://koji.fedoraproject.org/koji/buildinfo?buildID=1393459

Alle Tests sind positiv, also könnt Ihr die erst einmal bedenkenlos installieren, solange die noch nicht im Fedora Updates Repo ist. Das sollte zwar heute noch der Fall sein, aber wem das CGI-Problem jetzt schon wie ein Furunkel am Hintern klebt, der kann sich jetzt vorzeitig entlasten 😉

Fokus fällt 5 Jahre lang offensichtlicher Fehler nicht auf

FOCUS-Online-Autorin verfasste 2014  einen Beitrag über das allseits bekannte Periodensystem der Elemente, darin heißt es:

Jedes Element wird durch bestimmte Buchstaben abgekürzt. In der Regel gehen die Abkürzungen auf den lateinischen Namen zurück. So leitet sich das O für Wasserstoff von der lateinischen Bezeichnung Oxygenium ab, das H für Wasserstoff geht auf den Namen Hydrogenium zurück.“ (Zitatquelle s.u.)

Das ist dann doch schon peinlich, oder? Geht aber noch weiter, weil bereits 2014 ein Kommentator schrieb:

Zink liegt als Kupfer vor?
Sie schreiben: „Zink liegt üblicherweise als Cu2+ oder Cu+ vor, gibt also ein oder zwei Elektronen ab“. Cu ist aber Kupfer und kein Zink.
“ (Zitatquelle s.u.)

Das wurde allerdings zwischenzeitlich behoben. Das schlimme daran ist aber, daß der Fokusartikel bei Google auch noch in den Top 5 der Suche nach Informationen zum Periodensystem steht. Mal sehen, was der Fokus dazu schreiben wird.

Quelle: https://m.focus.de/wissen/periodensystem-der-elemente-was-das-periodensystem-ueber-die-elemente-verraet_id_4172935.html

WordPress 5.1.1 Multisites mit DB-Updateproblem

Nächste Warnung: Wer eine WordPress Multisite betreibt und von 5.0 auf 5.1.1 aktualisiert wird, der könnte ein Problem haben, ohne es zu wissen.

Datenbankupdate nicht ausgeführt

Die Fehler reichen von Logmeldungen wie dieser:

WordPress-Datenbank-Fehler Table ‚db466398.wp_blogmeta‘ doesn’t exist für Abfrage SELECT blog_id, meta_key, meta_value FROM wp_blogmeta WHERE blog_id IN (6) ORDER BY meta_id ASC von include(‚wp-load.php‘), require_once(‚wp-config.php‘), require_once(‚wp-settings.php‘), require(‚wp-includes/ms-settings.php‘), ms_load_current_site_and_network, get_site_by_path, get_sites, WP_Site_Query->query, WP_Site_Query->get_sites, _prime_site_caches, update_site_cache, update_sitemeta_cache, update_meta_cache

bis hin zu 500er Fehlern, wenn man die Webseiten aufruft.

Das Problem wurde vor 4 Wochen bereits bekannt, konnte aber nicht zuverlässig reproduziert werden von den Devs, tritt aber so oft auf, daß es kein Zufall mehr ist, ich habs ja auch gehabt 😉

Lösung:

Einloggen in die Datenbank und das hier ausführen:

CREATE TABLE `wp_blogmeta` (
`meta_id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
`blog_id` bigint(20) NOT NULL DEFAULT 0,
`meta_key` varchar(255) DEFAULT NULL,
`meta_value` longtext DEFAULT NULL,
PRIMARY KEY (`meta_id`),
KEY `meta_key` (`meta_key`),
KEY `blog_id` (`blog_id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8

Dann hören die Meldungen im Errorlog des Apachen auf. Ob das auch den 500er behebt, kann ich nicht sagen, da er mir nicht passiert ist. Wer sich jetzt fragt wo ich die Struktur her habe, es gibt in WP eine Datei, in der die DB Schemata drinstehen, da bekommt man das her.

 

QMMP & MP3 & Fedora 24

Na, auf Fedora 24 aktualisiert und der MP3 Sound ist weg ?

Kein Problem. Alles was wir brauchen sind Nerven aus Stahl und eine Rootkonsole 😀

Zunächst mal ladet Ihr Euch alle Pakete zu Eurer Prozessorversion von dieser Seite runter :

http://koji.fedoraproject.org/koji/buildinfo?buildID=710733

Debug und Infomodule braucht man nicht und Ja, das sind die Pakete für Fedora 23.. das macht nichts.

Dann ladet Ihr die alten QMMP Packs von RPMFusion runter, die beim Update gelöscht wurden:

http://download1.rpmfusion.org/free/fedora/releases/23/Everything/x86_64/os/Packages/q/


dnf erase qmmp*

cd ~/Downloads
rpm -i -nodeps qmmp*

VORHER prüfen, ob auch nur die RPMs in dem Verzeichnis sind, die man installieren will, ansonsten installiert rpm nämlich alles durcheinander.

Das wars schon. MP3 Wiedergabe geht wieder.