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