Kurze Gültigkeit bei Zertifikaten

Früher konnte ich ein Zertifikat mit 3 Jahren Gültigkeit kaufen und CRL oder OCSP haben die Gültigkeit beschränkt. Seit Sep 2020 akzeptieren Browser nur noch Zertifikate mit maximal 13 Monaten und Let's Encrypt stellt schon immer Zertifikate für 90 Tage aus. Nun will Apple sogar auf bis zu 45 (vormals 10) Tage herunter. Ist das nun gut oder schlecht und was bedeutet so eine Änderung für Administratoren.

Gültigkeit

Wie lange ein Zertifikat gültig ist, hängt davon ab, welche Dauer die ausstellende Zertifizierungsstelle erlaubt und wie lange die Zertifizierungsstelle selbst überhaupt gültig ist. Denn auch das Stammzertifikat einer Zertifizierungsstelle ist nicht endlos gültig. Die lokalen Stamm-CAs können sie einfach in der MMC oder per PowerShell einsehen:

PS C:\> get-childitem Cert:\LocalMachine\Root\ | ft NotBefore,NotAfter, Subject

Die Gültigkeit kann ich einfach errechnen:

PS C:\> (get-childitem Cert:\LocalMachine\Root\ | foreach {$_.notafter - $_.NotBefore}).days | Measure-Object -Average -Maximum -Minimum

Count : 119
Average : 8779,71428571429
Maximum : 15922
Minimum : 820

Da sind natürlich ein paar Test-CAs drin, z.B. von Fiddler, die nur kurz gültig sind, aber es gibt so Peaks bei 7305, 9131, 10759, 10957 Tagen, also 20,25, 29 und 30 Jahren. Wobei einige Zertifikate selbst mit so langer Gültigkeit bereit abgelaufen sind:

Allerdings sollten Sie diese Zertifikate nicht löschen, denn es könnte ja sein, dass es lokale Treiber o.ä. gibt, die damals von Zertifizierungsstellen signiert wurden, die von diesen RootCAs abgeleitet sind. Auch könnte es ja sein, das Sie eine SMIME/PGP-verschlüsselte sehr alte Mail lesen wollen. Dabei handelt es sich dann aber um Zertifikate, die für "Bestandsdaten" genutzt werden. Eine TLS-Verschlüsselung von Verbindungen per HTTPS, SMTPS, POP3S, IMAP4, LDAPS etc. verschlüsseln ja nur die Daten während der Übertragung. Hier ist das Alter und das Vorliegen früherer Root-CAs nicht kritisch, denn das aktuell vom Server genutzte Zertifikat muss von einer aktuell noch gültigen und vertrauenswürdigen RootCA und IssuingCA abstammen.

Dauer - immer kürzer

Für diese Transportverschlüsselung, die überwiegend bei HTTPS zum Einsatz kommen, ist die Gültigkeit des Zertifikats essentiell. Wenn es einem Angreifer gelingt, ein Zertifikat zu stehlen oder sogar auch nur eine IssuingCA kapern kann, dann kann er mit dem Zertifikat viel Unfug anrichten. Der Schutz von länger gültigen Zertifikaten liegt dann nur in der Veröffentlichung der "Ungültigkeit" über eine CRL oder OCSP. Dazu ist es aber erforderlich, dass der Client die Gegenstelle der PKI erreichen kann, überhaupt prüft und die PKI die Zugangspunkte bereitstellt. Das sind viele "Wenn's" und "Aber" und selbst Exchange Administratoren kennen den Trick die CRL-Prüfung bei der Installation eines Exchange Updates temporär abzuschalten um die Installation zu beschleunigen.

Das Deaktivieren einer CRL/OCSP-Prüfung sehe ich sehr kritisch. Sie sollten es besser ermöglichen, dass alle Clients immer alle CRLs über einen Proxy oder direkt erreichen können.

Aber selbst mit einer funktionierenden CRL-Prüfung gibt es noch genug Fehlerfälle, die umso kritischer sind, je länger Zertifikate gültig sind, z.B.

  • Sperrungen fehlerhaft oder wirkungslos
    Es ist ja nett, wenn Sie ein Zertifikat zurückziehen lassen wollen, aber das kann nur der Besitzer machen und das kann etwas dauern. Aber auch dann ist der Faktor Mensch im Spiel, welcher diese Aktion prüft ud es soll schon Fehler gegeben haben, dass das falsche Zertifikat zurückgerufen wurde oder der Rückruf nicht in der CRL angekommen ist. Software kann Fehler haben
  • Fehler bei manueller Ausstellung
    Auch der Prozess einer Ausstellung eines Zertifikats kann fehlerbehaftet sein. Es gab in der Vergangenheit schon Fälle, dass jemand ein Zertifikat für einen fremden Namen erhalten hat. Das erschüttert natürlich das komplette Vertrauen in PKIs und einige Zwischenzertifizierungsstellen wurden durch solche Fehler letztlich ausgeschlossen.

Denken Sie auch daran, dass eine PKI die Thumbprints alle zurückgezogenen Zertifikate in der CRL solange vorhalten muss, bis das Zertifikat abgelaufen ist. Eine CRL kann also durchaus größer werden weswegen auch OCSP als Alternative entwickelt wurde. OCSP hat aber auch Einschränkungen. Mittlerweile gehe schon die Browser-Hersteller dazu über, eigene "Verbotslisten" zu führen.

Es spricht also schon einiges dafür, dass Zertifikat auch kürzer als ein Jahr oder sogar deutlich kürzer gültig sind und der Enrollment-Prozess entsprechend automatisiert wird. Das spiegelt sich auch in der Geschichte wieder:

Zeitraum

Maximale Gültigkeit

2012-2015

Let's Encrypt wird gegründet und 2015 die Version 1.0 des ACME-Protokolls als, welches als RFC Vorschlag eingereicht wurde. zu der Zeit waren Zertifikate zwar schon bekannt und in Gebraucht aber nicht weit verbreitet. Das wollte Let's Encrypt ändern.

Vor 2015

Bis zu 5 Jahre lang waren die meisten kommerziell ausgestellten Zertifikate gültig. Das war so etwas die Dauer, die ein normaler Server in gebrauch ist. Im Idelfall musste ein Administrator also nur einmal bei der Einrichtung ein Zertifikate anfordern und installieren.

2015-2018

3 Jahre war dann die erste Reduzierung durch die PKIs. Vermutlich wurde einfach die CRL zu lang, wenn Zertifikate bis zu 5 Jahre in der CRL mitgeschleppt werden müssen.

2018-2019

In dem Zeitraum wurde eine Umfrage im CA Forum gestartet, ob man nicht auf 1 Jahr heruntergehen sollte. Dies wurde aber von den Mitgliedern mehrheitlich abgelehnt.

2020

Dafür hat Apple dann ein Jahr später einfach Fakten geschaffen, indem Safari und MacOS keine Zertifikate mehr akzeptiert haben, deren verbleibende Gültigkeitsdauer über einem Jahr (genauer 398 Tage) war. Damit waren zumindest die großen Webhoster gezwungen, ihre Zertifikate früher zu erneuern.

März 2023

Drei Jahre später hat Google einen neuen Vorstoß gewagt und 90 Tage vorgeschlagen aber nicht aktiv weiter verfolgt.

The Baseline Requirements describe domain validation and authorization data may be reused so long as it was verified within the last 398 days. In reality, this represents a 795-day reuse period (i.e., assume a 398-day certificate is issued on the 397th day after domain validation was last completed). More timely domain validation will better protect domain owners while also reducing the potential for a CA to mistakenly rely on stale, outdated, or otherwise invalid information resulting in certificate mis-issuance and potential abuse. Currently, we want to study the impact of reducing domain validation reuse periods to 90 days or less.
Quelle: https://www.chromium.org/Home/chromium-security/root-ca-policy/moving-forward-together/

15. Sep 2025

Apple Vorschlag: 200 Tage

15. Sep 2026

Apple Vorschlag: 100 Tage

15. Apr 2027

Apple Vorschlag: 45 Tage

15. Sep 2027

Apple Vorschlag: 10 Tage
Diese letzte Stufe ist wohl mittlerweile nicht mehr gültig, so dass Apple gerne auf 45 Tage reduziert hätte.

Ob die von Apple vorgeschlagene Reduzierung kommt, ist noch nicht sicher. So kurze Zeiträume können nicht mehr manuell konfiguriert werden. Produkte und Prozesse müssen daher umgestellt werden, damit Sie z.B. per ACME automatisch neue Zertifikate anfordern aber auch in den Produkten verwenden. Die Verbreitung von Apple Clients ist durch das IPhone sicher groß, während MacOS im Vergleich zu Windows natürlich eher klein ist und Safari gibt es nicht mehr für Windows. Google wollte ja erst einmal auf die 90 Tage, die auch Let's Encrypt nutzt und hat über viele Jahre mit Millionen von ausgestellten Zertifikaten die Funktionsfähigkeit bewiesen.

Rolle der PKI und Autoenrollment ACME

Durch den Start von Lets Encrypt haben sich gleich mehrere Dinge zum Vorteil verändert:

  • ACME-Protokoll und 90 Tage
    Alle von Let's Encrypt ausgestellten Zertifikate sind maximal 90 Tage gültig. Damit dies funktioniert, muss die Generierung, Anforderung, Installation und Aktivierung eines Zertifikats automatisiert werden. Dazu gibt es das ACME-Protokoll, welches mittlerweile von vielen Produkten aber auch Providern unterstützt wird
  • HTTPS für alle
    Die Nutzung von verschlüsselten Verbindungen ist massentauglich geworden. Quasi jede Webseite kann heute per HTTPS erreicht und damit die Übertragung verschlüsselt werden. Es sind nicht mehr nur die Banken und Warenhäuser, sondern quasi alle Dienste.
  • Preisverfall
    Let's Encrypt-Zertifikate kosten bei der CA nichts aber sie müssen natürlich bei sich die Infrastruktur betreiben. Das ist aber einfach und machen viele Hosting-Provider für sie, so dass generell die Preise für Webserver-Zertifikate gefallen sind und es kaum mehr Webhosting-Angebote gibt, die nicht mindestens ein HTTPS-Zertifikat enthalten. Nicht alle nutzen aber dazu auch Let's Encrypt, d.h. auch kommerzielle PKIs haben ihre Preise gesenkt

Wenn nun die Gültigkeit weiter reduziert, wird das AutoEnrollment aber auch die Autokonfiguration der betroffenen Applikation immer wichtiger. Mit einer Gültigkeit von 1 Jahre konnte ein Administrator oder auch ein Dienstleister einfach einmal im Jahr die erforderlichen Änderungen manuell durchführen. Schon mit 90 Tagen (Let's Encrypt) ist dies nicht mehr handhabbar und mit 10 Tagen (Apple Vorschlag) definitiv keine Lösung mehr. Mittlerweile gibt es sogar weitere PKIs, die kostenfreie Serverzertifikate über ACME bereitstellen

Da stellt sich dann schon die Frage, warum es überhaupt noch einen Markt für kommerzielle PKIs mit entsprechenden Preisen gibt. Zumal der Support für ACME schon sehr weit verbreitet und diverse Webhoster nutzen ebenfalls Let's Encrypt.

Allerdings liefern Let's Encrypt und andere nur "Webserver-Zertifikate. Für SMIME, CodeSigning und andere Spezialfälle müssen Sie ihre eigene interne RootCA oder kommerzielle PKI nutzen.

Alternative SelfSSL und DNS-Eintrag?

Vom SMTP-Protokoll kennen wir DKIM-Einträge im DNS, die den öffentlichen Schlüssel für eine DKIM-Signature bereitstellen. Genauso könnten Sie ja auf die Idee kommen, einfach ein selbst oder einer privaten PKI signiertes Zertifikat einzusetzen und die Informationen dazu im DNS zu veröffentlichen. Ein Browser könnte dann per HTTPS auf ihren Server gehen und z.B. den Thumbprint mit einer DNS-Antwort abgleichen. Das Problem dabei ist aber, dass z.B. in einem fremden Netzwerk ein Angreifer oder Provider sowohl ihren HTTPS-Verkehr über einen Proxy leiten kann und zugleich die DNS-Anfrage sieht und die Antwort verändert. DNS ist unverschlüsselter und nicht signierter Verkehr über Port 53/UDP oder 53/TCP.

Das würde sich erst ändern, wenn die DNS-Abfragen z.B. über DNSSEC signiert erfolgen würden oder der Browser per DoH - DNS over HTTPS. Für SMTP gibt es mit DANE - DNS-Based Authentication of Named Entities sogar schon eine entsprechende Beschreibung. Für Webserver und HTTPS-Zugriffe wäre dies auch denkbar aber sowohl Chrome als auch Firefox planen wohl keinen DANE-Support im Browser (Stand Okt 2024)

Einschätzung

Die Echos auf Apples Vorschlag sind sehr gemischt von generelle Ablehnung bis absoluter Zustimmung. Sicher gibt es immer das Problem, dass Zertifikate gestohlen und zum Aufbrechen von Verbindungen genutzt werden. Auf der anderen Seite sind 10 Tage natürlich schon sehr kurz und funktionieren nur mit einem automatischen Enrollment samt Konfiguration. Ob dies in 3 Jahren bis 2027 zu schaffen ist, glaube ich nicht. Sicher könnte eine Firewall oder Reverse Proxy vor einem untauglichen System eine Kompatibilität herstellen aber was passiert, wenn das Limit auch für SMTP-Server und andere Dienste kommt, die kein HTTP auf Port 80 für das ACME-Protokoll bereitstellen?

Das größere Problem sehe ich aber im Wissen und Schulungsaufwand, denn schon heute gibt es ein riesiges Defizit um das Thema Zertifikate und PKI. Viele Administratoren aber auch Dienstleister haben hier nur rudimentäres Wissen und können gar nicht einschätzen, was Sie wann tun müssen. Ich wäre froh, wenn ich nicht mehr bei Kunden alle Jahre bei dem Wechsel von Zertifikaten helfen müsste. Ich bin verhalte vorsichtig und beobachte die Weiterentwicklung aufmerksam. Mit Let's Encrypt und ACME können sich aber neugierige Administratoren gerne schon einmal beschäftigen.

Weitere Links