Springe zum Inhalt

... beziehungsweise wie bei Jules Verne in 80 Tagen, plus 10 Tage Karenzzeit.

Oberhaus und Unterhaus

Schon 2017 bei der Abstimmung im CA/Browser-Forum (oder wie ich gerne sage: "im Kartell"), als es darum ging, die maximale Gültigkeitsdauer öffentlich anerkannter TLS-Serverzertifikate von 39 Monaten (drei Jahre plus drei Monate Karenz) auf 398 Tage (ein Schaltjahr plus ein aufgerundeter Monat Karenz) herunter zu setzen, haben die Browser-Hersteller ("das Oberhaus") letztlich die Nein-Stimmen der Trust-Center-Betreiber ("das Unterhaus") nicht auf sich beruhen lassen, sondern über den Zwischenschritt von 825 Tagen (zwei Jahre plus gute drei Monate Karenz) die 398 Tage in ihren Browsern implementiert und im August 2020 unter dem Stichwort "Browser-Alignment" vom Kart... äh... CA/-Browser-Forum absegnen lassen.

Von Let's Encrypt lernen

Am 03.03.2023 ist das Chromium-Projekt von Google nun erneut vorgeprescht und schlägt eine weitere drastische Verringerung der Zertifikatsgültigkeiten vor (man könnte auch sagen "fordert", denn es wird mit der Keule gewunken, das einfach im Chrome-Root-Programm zu verankern, anstatt es über die Baseline-Requirements des CA/Browser-Forums einzustielen):

Root-CA-Zertifikate sollen nur noch maximal sieben Jahre genutzt werden (selbst wenn die Zertifikate nominell länger gültig sind) und CA-Zertifikate untergeordneter CAs nur noch drei Jahre gültig sein. Vor allem aber sollen öffentlich gültige TLS-Sever-Zertifikate nur noch maximal 90 Tage gültig sein, wie dies bei Let's Encrypt schon lange die Praxis ist.

Zusätzlich wird verlangt, dass PKI-Hierarchien unter öffentlich gültigen Root-CAs nur noch einen Typ von Endzertifikaten ausstellen - d. h. für den Browser: nur TLS-Server-Zertifikate und nicht bspw. Code-Signing-Zertifikate unter derselben Root-CA.

Warum nur, warum

Mit den Einschränkungen für die Nutzungszeit von CA-Zertifikaten will man erreichen dass ca. alle fünf Jahre die CAs auf den Stand der Technik gebracht werden. Und damit auch für den Fall vorbeugen, dass doch der ominöse Quanten-Computer gebaut werden kann, der den Shor-Algorithmus ausführen und 4096-Bit-RSA und mehr brechen kann, so dass "das Web" auf Post-Quanten-Kryptoalgorithmen wechseln muss. (Was letzteres betrifft stehen meine zwei Kasten Bier bei der Wette darauf, dass die Menschheit vorher wirtschaftlich nutzbare Kernfusions-Kraftwerke haben wird.)

Dagegen ist wenig einzuwenden: Über den Online-Update von Chrome kann Google regelmäßig neue Root-Zertifikate der teilnehmenden Trust-Center ausspielen. Und wer Browser ohne Online-Update im Internet nutzt, dem ist ohnehin nicht mehr recht zu helfen.

Interessanter ist die Funktionstrennung für die PKI-Hierarchien. Hier ist ein Ziel, dass bspw. eine kompromittierte Code-Signing-CA nicht zugleich das Fälschen von TLS-Serverzertifikaten erlaubt. Leider hätte auch das 2011/2012 nicht gegen die Comodo- und DigiNotar-Hacks  geholfen - dort haben die Angreifer einfach Zugang zu allen CAs des betreffenden Betreibers bekommen. Wenn ein Einbrecher einmal die Mauer von der Straße aufs Grundstück überklommen hat, ist es über den Jägerzaun zum Nachbargarten meist nur ein Katzensprung.
Allenfalls können damit unerwünschte und unbemerkte Quer-Wirkungen zwischen gänzlich unterschiedlichen Registrierungsprozessen innerhalb einer CA vermieden werden.

Noch mehr von Let's Encrypt lernen

Und die Verringerung der Laufzeit von Serverzertifikaten auf die (für diesen Blogbeitrag) namensgebenden 90 Tage schließlich soll zwei Ziele befördern.

Einerseits sollen die Server-Betreiber mit mehr oder weniger sanftem Druck dazu gedrängt werden, anstatt der herkömmlichen, "barocken, zeitaufwändigen und fehleranfälligen" manuellen Zertifikatsbeantragung automatisierte Protokolle, namentlich das von Let's Encrypt eingeführte ACME zu verwenden.

Dem Ansatz folge ich seit längerer Zeit auch. Das hauptsächliche verbleibende Problem bei ACME ist, dass es für Plattformen abseits der etablierten Betriebssysteme und Webserver, d. h. für Systeme wie Hypervisor, Appliances, Lights-Out-Schnittstellen usw., oft keine verfügbaren ACME-Clients gibt. Da derartige Systeme aber (aus Gründen 😉 ) selten über Internet erreichbar sind, ist dieser Nachteil für öffentlich gültige Zertifikate weniger relevant. ACME ist der Weg.

Allein als kommerzieller Trust-Center-Betreiber müsste man sich die Frage stellen, warum die Kunden dann weiterhin TLS-Serverzertifikate kaufen wollen, anstatt sie kostenlos von Let's Encrypt & Co. zu beziehen.

Der andere Grund für 90 Tage Gültigkeit ist das mangelnde Vertrauen in die etablierten Sperrmechanismen und die Hoffnung, dass sperrens-würdige Zertifikate dann zumindest schnell ablaufen.

Diesen Punkt sehe ich nicht ganz so gewichtig. Zum einen gibt es mit OCSP-Stapling seit Jahren einen probaten Sperr-/Prüfmechanismus, den die Browser-Hersteller implementieren und promoten können. Zum anderen muss man sich fragen, wie viele der System-Administratoren, die keine Zeit dafür haben, einen Sperrantrag für das Zertifikat ihres nicht mehr benötigten und/oder möglicherweise kompromittierten Servers zu stellen, stattdessen die Zeit finden, den Automatismus, der alle 80 Tage ein neues Zertifikat holt, zu unterbrechen.

Im einen oder anderen kommenden Blog-Beitrag werde ich nicht umhin kommen, das CA/Browser-Forum zu erwähnen. Daher sollte ich wohl zunächst ein paar Worte darüber sagen.

In den Urzeiten des World Wide Web, als HTTPS noch eine neue Technologie war, wurde es von den Browsern (die damals Netscape Navigator oder Internet Explorer 3 hießen) recht hemdsärmelig gehandhabt, wessen Serverzertifikate dabei akzeptiert wurden. Erst gab es nur das eine öffentliche Trustcenter, dessen Root-Zertifikat mit ausgeliefert wurde. Dann war man froh, dass sich ein Mitbewerber fand, um keinen Ärger mit den Anti-Kartell-Behörden zu riskieren. Im Detail festgelegte und auditierte Voraussetzungen, um mitspielen und an Zertifikaten mitverdienen zu können, gab es nicht wirklich.

Das änderte sich im Laufe der Zeit, als immer mehr Aspiranten sich meldeten, und so fand sich 2005 das CA/Browser-Forum (oder kurz: CABForum) zusammen. Wer mich schon einmal zu diesem Themenbereich referieren gehört hat, weiß, dass ich meist einfach "das Kartell" sage - ein informeller Zusammenschluss (laut Satzung "voluntary gathering") marktbeherrschender Unternehmen mit dem Zweck, Spielregeln für diesen Markt festzulegen und durchzusetzen.

Mitglieder sind auf der einen Seite die führenden und einige noch nicht oder nicht mehr so führenden Betriebssystem- und Browser-Hersteller: Apple (macOS, iOS, Safari), Google (Android, Chrome), Microsoft (Windows, Internet Explorer, Edge), Mozilla Foundation (Firefox), Opera und ein chinesischer Browser-Hersteller. Auf der anderen Seite sind ca. 70 bis 80 öffentliche Trustcenter dort vertreten, deren Zusammensetzung gelegentlich aufgrund von Marktbewegungen etwas variiert.

Interessanterweise stimmen diese beiden Teilnehmergruppen bei den allfälligen Änderungen der Spielregeln (insbesondere der Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates) getrennt ab. Aus aktuellem politischen Anlass könnte man das ein Bisschen mit den Rollen des Europäischen Rats und des Europaparlaments vergleichen - nur das beim Kartell wohl noch deutlicher ist, wer im Endeffekt das Sagen hat.

Und ehe das jetzt so klingt, als wäre ich ein ausgemachter Kritiker des CA/Browser-Forums: Wir haben dem Kartell einige wirklich gute Dinge zu verdanken, z. B. den Umstieg von SHA-1 auf SHA-2 als Hashalgorithmus, Certificate Transparency und generell ein strengeres Regime der Aufsicht über die öffentlichen Trustcenter.

... wo sind sie geblieben?

Wenn man den Zertifikatsspeicher eines neu installierten Windows-Rechners anschaut, dann wird man feststellen, dass nur noch ein gutes Dutzend Root-CA-Zertifikate (microsoftisch-deutsch: "vertrauenswürdige Stammzertifikate") enthalten sind.
Das geht übrigens seit Windows 8 sehr schnell über den folgenden Kommandozeilen-Aufruf:

certlm.msc

Und das, obwohl Stand heute Hunderte öffentlicher Trustcenter mit ca. 391 Root-Zertifikaten am Microsoft Trusted Root Certificate Programm teilnehmen.

Der Nebel lichtet sich ein wenig, wenn man den Rechner eine Weile in Betrieb hat und feststellt, dass nach dem Besuch von Webseiten, Installation von signierten Programmen usw. unvermutet weitere Root-CAs im Store auftauchen.

Es gibt also einen in Windows eingebauten Nachlade-Mechanismus für Root-Zertifikate. Warum Microsoft nicht gleich alle Root-Zertifikate installiert, darüber kann man trefflich spekulieren. Neben der überschaubareren Optik, die dem Betrachter ein besseres Gefühl suggeriert, wem er da eigentlich alles vertraut, könnte es daran liegen, dass einige Komponenten des Betriebssystems vielleicht mit soooo vielen Root-Zertifikaten gar nicht zurecht kommen.

Der Nachlade-Mechanismus funktioniert grob wie folgt:

  • Wenn ein Zertifikat (bspw. das Serverzertifikat einer Webseite) validiert wird, versucht Windows, eine Zertifikatskette bis zu einer vertrauenswürdigen Root zu finden.
  • Falls die Zertifikatskette bis zu einem der installierten Root-Zertifikate geschlossen werden kann, dann wird sie nach Gültigkeit und Sperrstatus validiert.
  • Falls nicht, dann wird geprüft, ob der Hashwert des Issuer-Namens im letzten Zertifikat, zu dem kein vertrauenswürdiger Aussteller mehr im lokalen Store gefunden werden kann, in einer Liste hinterlegter Hashwerte von Issuern aus dem Root Certificate Program auftaucht.
  • Wenn ja, dann wird das betreffende Root-Zertifikat von einem Server aus dem Window Update System nachgeladen. (Notabene: Obwohl Windows Update Server mit verwendet werden, ist der Mechanismus selbst davon unabhängig, ob Windows Update aktiviert ist oder nicht.)

Aus Sicherheitssicht ist dieses Nachladen von Root-Zertifikaten wenig bedenklich, weil alle Trustcenter, deren Root-CAs am Programm teilnehmen gleichermaßen streng geprüft wurden. Allenfalls einem unbedarften Anwender, der unter diesen Trustcentern eine eigene Auswahl treffen will, spuckt Microsoft damit in die Suppe.

Es gibt jedoch einen (seltenen) Fall, in dem dieser Mechanismus versagt: Wenn in einem Firmen-Netzwerk - oder künftig vielleicht verstärkt in einem Industrie-4.0 OT-Netzwerk?! - die Firewall so dicht ist, dass sie den Windows-Clients jegliche Kommunikation mit Servern im Internet verwehrt.
Damit die Administratoren solcher Systeme einen eigenen, internen Download-Server für die Root-Zertifikate aufsetzen können, dessen Adresse sie dann - wie sollte es anders sein - per Group Policy intern verteilen, gibt es einen Weg, um alle Root-Zertifikate von Windows Update manuell herunterzuladen.
Das kommt natürlich auch all denen entgegen, die ähnlich neugierig sind wie ich:

certutil -syncWithWU <Directory>

In dem angegebenen Directory finden sich nach erfolgreichem Abschluss des Kommandos nicht nur alle für Microsoft Windows gültigen Root-Zertifikate, sondern auch eine Certificate-Store-Datei mit all jenen Zertifikaten, denen Windows auf gar keinen Fall vertraut. Aber das ist wahrscheinlich ein Thema für einen anderen Blogbeitrag...