Fragen? Antworten! Siehe auch: Alternativlos
Einige meinten, aber Android macht das doch auch so. Das ist offensichtlich keine Ausrede für irgendwas. Google wollte halt nicht verklagt werden, weil sie keinen Support für alte Geräte machen, falls die dann gebrickt werden, weil die Zertifikate alle nicht mehr gültig sind. Das ist in meinen Augen ein Grund für eine Klage gegen Google, weil sie vorsätzlich defekte Software ausliefern.
Die andere Art Leserbrief zitiere ich hier mal:
Wie die verlinkte Archivseite erläutert, verwendet die Telematik-Infrastruktur das Kettenmodell als Gültigkeitsmodell für die Zertifikatskettenprüfung innerhalb dieser Infrastruktur (siehe das dort verlinkte Fact Sheet). Das Kettenmodell kommt aus dem Orkus des deutschen Signaturgesetzes, seiner Zeit vorangetrieben von der damaligen "Regulierungsbehörde für Telekommunikation und Post" (RegTP), heute Bundesnetzagentur.Lasst mich hier noch ergänzen: Und wir reden hier von TLS, nicht von digitalen Signaturen unter amtlichen Dokumenten oder Verträgen!Ohne jetzt ins Detail zu gehen ist es beim Kettenmodell völlig akzeptabel und normal, Zertifikate auszustellen, die über das notAfter-Datum des Ausstellerzertifikats hinausgehen. Die nachvollziehbare Grundidee dahinter ist, dass eine geleistete Signatur als Willenserklärung ja nicht plötzlich ungültig werden sollte, nur weil das Signaturzertifikat abgelaufen ist. Die Idee ist richtig, aber die Umsetzung in Form des Kettenmodells ist ein historischer Fehler, über den ich mit den Verantwortlichen bei der RegTP damals schon kontroverse Gespräche führen durfte - ohne Erfolg, versteht sich.
Das größte Problem des Kettenmodells ist, dass der Rest der Welt das Schalenmodell nach RFC5280 (Kapitel 6.1; "validation process", Punkt d) zur Gültigkeitsprüfung verwendet, bei dem erwartet wird, dass die Gültigkeit eines untergeordneten Zertifikats innerhalb der Gültigkeit des jeweiligen Ausstellerzertifikats liegt.
Nahezu die komplette Software in unserer Welt, die in irgendeiner Weise Zertifikatsprüfungen macht, verwendet das Schalenmodell, bis auf einige ranzige Spezialsoftware, die explizit für den Einsatz in der deutschen Behördenwelt geschrieben wurde und technisch gesehen RFC5280 verletzt.Oder alternativ könnte man auch einfach aufhören, die einschlägigen Standards zu verletzten, weil ein paar Sesselfurzer einer deutschen Behörde das mal irgendwann so zu Papier gefurzt haben.Der Grund für den Ausfall ist nun offenbar, dass die Telematik am Kettenmodell festhält - und zwar auch für Zertifikate die für TLS verwendet werden. Das Root-Zertifikat ist abgelaufen, aber die ausgestellten Zertifikate unter dieser CA sind laut Kettenmodell weiterhin gültig, nicht jedoch nach dem Schalenmodell. Das ist aus meiner Sicht ein heftiger Architekturfehler, sinnvollerweise wären da besser zwei PKIs zum Einsatz gekommen, eine nach Schalenmodell für den ganzen Technologiestack einschließlich TLS und von mir aus eine nach dem irrsinnigen Kettenmodell.
Das Problem dürfte nun sein, dass die verwendete Software der Teilnehmer offenbar auf Standard-Cryptobibliotheken wie OpenSSL, JCE oder der Windows Crypto API beruht und diese nun für den TLS-Handshake verwendet. Diese Software setzt aber wie erwähnt das Schalenmodell um. Und diese Software dreht nun erwartungsgemäß den Bauch nach oben, wenn in der Zertifikatskette zu einem noch gültigen Zertifikat ein abgelaufenes Zertifikat auftaucht. Das erklärt auch wiederum, warum in manchen Umgebungen dann die Zertifikatsprüfung komplett abgeschaltet wurde - weil es im normalen Betrieb vermutlich andauernd zu solchen Problemen kommt, die aufgrund der unterschiedlichen Interpretation des Gültigkeitsmodells auftreten.