Springe zum Inhalt

Nachdem Google 2023 mit einem ähnlichen Vor­haben scheiterte, brachte Apple am 08.10.2024 einen neuen Vorschlag im CA/Browser-Forum ein. Ziel ist es, die maximale Gültigkeitsdauer von öffent­lich gültigen TLS-Serverzertifikaten schrittweise auf 45 Tage zu begrenzen.

Primär soll dadurch die Relevanz von Sperrmechanis­men, denen Browser-Hersteller ohnehin skeptisch gegenüberstehen, verringert werden. Dies senkt das Risiko durch überflüssige oder gar kompromittierte, aber nicht gesperrte Ser­verzertifikate.

Gleichzeitig soll die „Cache“-Zeit für eine einmal er­folgte Validierung von OV/EV-Angaben auf 366 Tage reduziert werden. Für DNS-Namen oder IP-Adressen soll diese Zeit sogar auf 10 Tage verkürzt werden. Bisher dürfen Trustcenter einmal validierte Unter­lagen wie Handelsregisterauszüge bis zu 825 Tage lang wiederverwenden und sich so die aufwändige erneute Prüfung bei einer Verlängerung ersparen.

Technisch würde dadurch das ACME-Protokoll weiter an Bedeutung gewinnen, mit dem Zertifikats­ver­längerungen alle 30 bis 40 Tage auto­matisiert und dabei stets die DNS-Namen validiert werden können.

Der Vorschlag würde zudem die Position der Brow­ser-Hersteller gegenüber problematischen Trustcen­tern stärken. Nach einem Ver­trauensentzug stünden deren Kunden noch schneller ohne gültige Zertifikate da. Wer Dutzende öffentlich gültiger Serverzertifikate nutzt, ist gut beraten, einen Zweitlieferanten in petto zu haben.

Darüber hinaus könnte die kürzere Gültigkeit den Übergang zu PQC-Zertifikaten erleichtern, der ab etwa 2030 zu erwarten ist.

 

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

Nachdem ich im vorigen Beitrag mehmals das Wort „Karenz“ benutzt habe, möchte ich noch eine Bemerkung hinterherschicken:

Zertifikate, die vor dem Ablauf stehen (und tun sie das nicht alle?), aber weiterhin benötigt werden, müssen rechtzeitig erneuert werden, um Betriebsstörungen zu vermeiden. Häufig –sicherlich auch motiviert durch das klassische Gebührenmodell öffentlicher Trustcenter, bei dem jedes TLS-Serverzertifikat einzeln berechnet wurde– wird „rechtzeitig“ interpretiert als „so kurz wie vertretbar von dem Ablauftermin“.

Zuverlässiger ist es allerdings, so frühzeitig zu erneuern, dass ein umbeabsichtigter Ablauf mit hoher Sicherheit vermieden wird. Also längere Karenzzeiten einplanen, die man vielleicht eher in Monaten zählt als in Wochen. Zumal die Serverzertifikate einer internen PKI in der Regel gar nicht separat berechnet werden und auch viele kommerzielle Trustcenter inzwischen einen Zeitraum für die Versorgung mit Zertifikaten und nicht ein einzelnes Zertifikat als Abrechnungsgrundlage anbieten.

Und letztlich verbieten weder PKI-Standards noch Best-Practice-Anforderungen, Zertifikate lange vor ihrem Ablauftermin - man könnte also sagen vorzeitig - zu erneuern. Wer in puncto Verfügbarkeit auf der sicheren Seite bleiben will, sollte das Zertifikat seines Servers während des jährlichen geplanten Wartungsfensters erneuern, selbst wenn das vorhandene Serverzertifikat noch über ein Jahr gültig wäre.
Natürlich sollte man das nicht länger benötigte, vorherige Zertifikat anschließend sperren. Genau für diesen Fall sieht X.509 seit über 20 Jahren den Sperrgrund superseded vor.

Merke: PKI ist eines der wenigen(?) Themen, bei denen die Vokabel „vorzeitig“ positiv besetzt sein sollte.