Springe zum Inhalt

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...