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.
- Disable CRL Check for Exchange Servers Without Internet Access
https://learn.microsoft.com/en-us/archive/msdn-technet-forums/1a89fff4-da6e-4055-be04-2e52af3ee76e
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. |
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 |
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
- https://letsencrypt.org/
- https://pki.goog/ - Google Trust Services
- https://zerossl.com/
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.
- ACME Client Implementations
https://letsencrypt.org/docs/client-options/ - IIS tools for ACME: https://letsencrypt.org/docs/client-options/#clients-windows-/-iis
- Apache https://letsencrypt.org/2017/10/17/acme-support-in-apache-httpd/
- nginx https://github.com/nginx-proxy/acme-companion
- Fortinet: https://docs.fortinet.com/document/fortigate/7.6.0/administration-guide/822087/automatically-provision-a-certificate
- Juniper: https://www.juniper.net/documentation/us/en/software/junos/vpn-ipsec/topics/topic-map/security-ipsec-vpn-acme-protocol.html
- F5/BigIp: https://community.f5.com/kb/technicalarticles/automating-acmev2-certificate-management-on-big-ip/328935
- Cisco: https://acme.cisco.com/acme/
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
- OCSP - Online Certificate Status Protocol
- CRL - Certificate Revocation List
- DNSSEC
- DoH - DNS over HTTPS
- DANE - DNS-Based Authentication of Named Entities
- Let's Encrypt
- RFC 8555 - Automatic Certificate Management Environment (ACME)
https://datatracker.ietf.org/doc/html/rfc8555 - Wikipedia Let's encrypt
https://en.wikipedia.org/wiki/Let%27s_Encrypt - Automated Certificate Management Environment (ACME) protocol
https://en.wikipedia.org/wiki/Automatic_Certificate_Management_Environment - The Chromium Project - Moving Forward, Together
https://www.chromium.org/Home/chromium-security/root-ca-policy/moving-forward-together/ - TLS certificates: Apple proposes a maximum term of 10 days
https://www.heise.de/en/news/TLS-certificates-Apple-proposes-a-maximum-term-of-10-days-9991943.html - Google möchte Laufzeiten für TLS-Zertifikate verkürzen
https://www.heise.de/news/Google-moechte-Laufzeiten-fuer-TLS-Zertifikate-verkuerzen-8151372.html - How long can digital certificates be valid?
https://www.sectigo.com/resource-library/how-long-are-digital-certificates-valid - How businesses should prepare for shorter SSL/TLS certificate validity
periods
https://www.sectigo.com/resource-library/preparing-for-shorter-certificate-validity-periods