[EN]Kurze Information für Administratoren. Browserhersteller und Certificate Authorities (CAs) haben die Verkürzung der Lebensdauer von TLS-Server-Zertifikaten von 13 Monaten auf 47 Tage beschlossen. Es gibt aber eine Übergangsfrist für diese Änderung bis zum Jahr 2029, während der die Gültigkeitsdauer eines TLS-Zertifikats schrittweise reduziert wird.
Anzeige
Vor einiger Zeit gab es von Apple einen Vorschlag, die Lebensdauer von TLS-Server-Zertifikaten von 398 Tagen auf 47 Tage zu verkürzen. Dieser Vorschlag wurde von den Mitgliedern im CA/Browser Forum zum 13. April 2025 angenommen. Der Zeitplan für die Verkürzung sieht folgende Übergangsfristen vor:
- 15. März 2026: Neu ausgestellte Zertifikate, einschließlich ihrer Domain Control Validation (DCV), müssen alle 200 Tage erneuert werden.
- 15. März 2027: Die Lebensdauer wird auf 100 Tage gesenkt.
- 15. März 2029: Neue SSL/TLS-Zertifikate werden auf 47 Tage und DCVs (Domain Control Verification) auf 10 Tage begrenzt.
Sowohl The Register, als auch Bleeping Computer als auch heise haben das Thema in Artikeln aufgegriffen.
Anzeige
So kann man dann unliebsamen Content und Dienste ohne Gerichtsprozesse und Sperren einfach aus dem Web bekommen, Server Zertifikat Verlängerung schlägt fehl, leider, leider, kann man nichts machen.
Vor vielen Jahren gab es mal eine chinesische CA namens WoSign. Die hat im Prinzip das gleiche gemacht wie Let's Encrypt, auch kostenlos. Die wurde unter zumindest fragwürdigen Umständen aus dem Internet "gebombt".
Kann mir mal einer erklären, was das bringen soll..? ERNSTHAFT!!
Ausserden, wer will sich denn schon an einen Ami-Dienst wie Let's Encrypt hängen, wenn da mal wieder schnell irgendwelche "Förder-Gelder" gekürzt werden? Alles mal wieder nicht durchdacht. Ausserdem "Viel Spass!" an die Exchange-Admins, wenn sich mal wieder die Cmds. zum Import ändern (gab's ja alles schon einmal).
Viel wichtiger wäre eine verpflichtende Sperrprüfung per CRL oder OCSP.
Aber es stimmt schon, in 365 Tagen kann eine Domain vielfach den Besitzer wechseln und nichts hält den neuen davon ab, das Zertifikat des alten weiter zu benutzen.
Mehr Geld für die CAs und mehr Arbeit für die Administratoren
wenn die CAs dann nur 47/365x€ kosten nicht
Aufwand ist es trotzdem. Wir haben längerfristig laufende Verträge z.B. bei Digicert für Wildcard-Domains. Da bezahlt man nur einmal für 3 Jahre, das Zertifikat wird aber trotzdem öfters (aktuell jedes Jahr) ohne Zusatzkosten erneuert.
naja dann häng dich halt nicht an die Ami Dienste… Let´s Encrypt nutzt man ja nur wenn man zu geizig ist ;-P
Ich BIN geizig und dankbar für diesen Dienst. Mit diesem habe ich seit zig Jahren nur gute Erfahrungen gemacht. Also was soll's… meine Zertifikate rotiere ich eh alle 30 Tage. Manueller Eingriff? Was ist das? Das merke ich alles gar nicht.
Finde ich sehr gut! ACME und Automatisierung sei dank! Heißt das im Gegenzug, dass diese unsäglichen CRLs der Vergangenheit gehören?
Und wer seine eigene PKI hat kann ja weiterhin Certs auf 5 Jahre oder länger laufen lassen.
Nicht so ganz. Google Chrome mag auch Zertifikate meiner CA nicht, wenn sie nach dem Stichtag ausgestellt sind und "zu lange" gelten. Ähnlich auch wenn sie verpflichtende Erweiterungen (SAN) nicht haben.
Ebenso die Apple Systeme, die mögen Zertifikate länger 20 Monate auch nicht. Egal ob du die als Vertrauenswürdig einstufst.
Über Zertifikate werden in Zukunft die Daumenschrauben weiter angezogen. Dann sind eines Tages private und KMU Homepages weg, unliebsame Dienste weg usw. und Zertifikate bekommen nur noch zugelassene und genehme Anbieter, praktisch zurück zu AOL Zeiten mit allen Diensten zentral gebündelt und Nutzung nur mit persönlicher digitaler Identität. Wartet es ab.
Private Homepages sind nicht weg, nur weil die maximale Zertifikatsdauer verringert wird. Ohnehin haben private Homepages in der Regel ein Let's-Encrypt-Zertifikat, welches bereits auf 90 Tage beschränkt ist (also deutlich geringer als die bisherige Maximaldauer).
Es geht hier darum, einerseits Diensteanbieter zur automatischen Zertifikatserneuerung zu bewegen und andererseits die Auswirkungen von gestohlenen Zertifikaten zu verringern. Da muss man sich nicht gleich den Aluhut aufziehen und solchen Unsinn beschwören.
Nein natürlich steckt da absolut gar kein kommerzielles Interesse hinter ;-)
Weitergehen, es gibt nichts zu sehen!
Lassen wir es einfach so stehen – die spekulative Antwort auf die spekulative Antwort, warum, weshalb, wieso bringt uns nicht weiter. Für Admins wird am Ende des Tages nur die Frage relevant: Was hat das für Folgen für mein Arbeitsumfeld und was muss ich wann tun.
"Und wer seine eigene PKI hat kann ja weiterhin Certs auf 5 Jahre oder länger laufen lassen."
Ist praktisch für Unternehmen oder kleine Bastler daheim. Aber ansonsten… die eigene PKI wird nirgends unterstützt und bewege andere Leute mal dazu, CAs zu installieren. Es scheitert bereits am Lesen von FAQs und HowTo's…
Die Regeln solleten nur für die CAs im Truststore der Browser gelten. Sollten! Apple hat sich schon in der Vergangenheit nicht darum geschert und mit Safari Extrawürste gebraten. Google schert sich auch wenig um Standards. Google ist ein massiver Verfechter davon, keine Zertifikatsprüfung, sei es mit CRLs, OCSP oder OCSP stapling zu machen. Das alles kostet Bandbreite, die man lieber zum Ausspielen von Werbung nutzen möchte. Die CAs sind sowieso begeistert, denn dann brummt das Geschäft umso mehr. Die Einwendungen von mir und anderen, daß dies sehr viele embedded Anwendungen in der IoT beeinträchtigt, wurden einfach ignoriert. Übrigens all, die Kritik geäußert haben, wurden einfach ignoriert. Es gab keine Diskussionen in der Workgroup. Es wird m. W. im Standard auch nicht festgeschrieben, daß "private" CAs ausgenommen werden. Wieder einmal diktieren mächtige Tech Giganten, wie das Internet zu funktionieren hat. Insgesamt eine hirnrissige Entscheidung um zu kaschieren, daß die Google und Apple zertifikatvalidierung nicht im Griff haben bzw daß sie das einen feuchten Kehrricht interessiert. Die Folge: Ich muß für meine Techniker jetzt auch noch einen Browser bauen und ausrollen, der diesen Mist nicht unterstützt. Bleibt nur die Hoffung, daß man das bei FF wenigstens durch about:config ausschalten kann.
BTW: sicherer wird dadurch rein gar nichts. Nur das Zeitfenster für Angriffe wird etwas kleiner. Die Wahrscheinlichkeit wird marginal sinken. Sicher wird es nach dieser Methode, wenn das Zertifikat bereits nicht mehr gültig ist, wenn es ausgestellt wird.
Du bist im Rahmen der Workgroup in die Sache "involviert", weil du von irgendeiner "Certification Authority" bist?
Wenn es irgendwelche nennenswerten Sicherheitsgründe dafür gibt, OK. Ansonsten steigen ja nur wieder die Kosten für die Allgemeinheit, weil "Betriebskosten" immer an die Kunden weitergegeben werden.
Angenommen es gibt keinen ernsthaften Gründe für die Änderung…. Ich weiß nicht, ob man so was dann irgendwie beeinflussen kann? Wird dann ja nicht die letzte "schlechte" Entscheidung gewesen sein. Weiß nicht ob man sowas, auch als Ottonormalbürger, irgendwie in die Presse pushen kann oder Lobbyarbeit betreiben kann.
Bei den Entscheidern dürfte die rektale Apertur signifikant außerhalb der Spezifikation liegen.
Das kannst Du so nicht sagen. Wie ich bereits dargelegt habe, hatten die Stimmberechtigten in der workgroup eben andere, kommerzielle Interessen. Die Sicherheit hingegen geht denen am A. vorbei.
Wie sieht das den mit Internen CAs aus. Fallen die da auch drunter oder gibts ausnahmen für interne Wikis die CA aus ner internen Windows CA haben wo die Clients das gegenstück haben und es als gültig ansehen.
Der Text des Vorschlages (https://groups.google.com/a/groups.cabforum.org/g/servercert-wg/c/bvWh5RN6tYI) spricht von "Public CA", also die, mit denen die Branche ihr Geld verdient.
Aber letztendlich ist diese Unterscheidung nicht "gottgegeben", sondern muß von den Browserherstellern (in der Disussion waren Apple, Google, Microsoft und Mozilla beteiligt) auch so umgesetzt werden.
Meine Erfahrung aus den letzten Verkürzungen zeigt leider, daß die Branche sich selbst kein Auge aushackt (es gibt ältere Wurzelzertifikate großer CAs mit vielen "Mängeln" wie nur 1024bit Schlüssellänge, SHA1-Signatur, fehlenden Extensions und endlosen Laufzeiten, die man offensichtlich als "systemrelevant" betrachtet und weiterlaufen läßt), man an eigene CAs, aber eben gleich die strengeren Maßstäbe anlegt.
Ich durfte letztes Jahr ein ganzes Bündel interner Zertifikate für Netzwerkdrucker, Switche u.ä. ersetzen – nicht weil sie abgelaufen waren, sondern weil der Name im "Subject" nicht mehr als vertrauenswürdig zählt, inzwischen ist die V3-Erweiterung "Subject Alternate Name" zwingend erforderlich.
Leider haben die Geräte, welche selbst einen CSR (Certificate Signing Request) erzeugen können, davon noch nichts gehört, so daß ich die CSRs erst mal in OpenSSL umarbeiten mußte, damit sie regelkonform sind.
Wenn man eine eigene CA einsetzt (in einer Firma mit mehreren hundert Leuten und Geräten m.E. zwingend notwendig) tut man inzwischen gut daran, auch die Infrastruktur drum herum (einen weltweit erreichbaren CRL und OCSP-Server und intern einen Certbot zum sicheren Enrollment) mit aufzusetzen. Die Microsoft-CA-Dienste bieten all das.
Theoretisch ja. Das war zumindest die Absicht der workgroup. Apple und Google halten sich schon jetzt nicht dran. Gottseidank gibt es diese Prüfung (noch) nicht im Webserver und Clientzertifikate für mTLS sind (noch) nicht betroffen.
es wird Zeit, die Branche zu wechseln.
Das ist doch nur der Bückling vor den Cloudbetreibern, noch mehr Argumente für die Datensammler und Zollstationen.
Das ist doch Wegelagerei! Da muss ich mir extra einen Einstellen, der nur die öffentlichen Zertifikate unseres Unternehmens in sämtliche Webserver einpflegt!
Will nicht sagen, dass mein Job stressig ist, aber wenn ich jetzt schon 2 mal im Jahr BC Waves einspielen darf, die ungewollten Phänomene beseitigen darf, dann noch diverse Konsolidierungen und Aktualisierungen durchführen muss dann habe ich effektiv 3 Wochen im Monat wo ich unter 55 Stunden nicht ausm Geschäft komme…
Wir haben am Hauptstandort ca. 15 Zertifikate bei diversen Webservices die wir in der DMZ hosten… Wehe da funktioniert einer nicht, dann können wir n
An der Stelle kann ich nur dringend zur Automatisierung raten.
SCEP und den entsprechenden Dienst von Microsoft gibt es seit Jahrzehnten und lassen sich (im Windows-Umfeld) gut mit GPOs steuern.
Das Ausrollen von Zertifikaten für Benutzer, Computer, andere Geräte (iPhone), Netzwerk (802.1x), Mail, RDP, VPN, WLAN u.ä. ist recht schmerzfrei und Verlängerungen i.d.R vollautomatisch. Inzwischen unterstützen auch viele Geräte im IoT Umfeld, Netzwerkdrucker, Switche u.ä. automatisches Enrolment.
Let'sEncrypt und ACME dagegen ist Krampf und eigentlich nur in der Kombination Linux-/Windows-Webserver, Dehydrated und DNS-01-Challange halbwegs brauchbar. Selbst dann hängt der Dienst alle naselang, weil sich irgendeine EULA geändert hat und ein Administrator dieser Änderung manuell zustimmen muß, das darf nicht automatisch geschehen.
Auch tut er gerne dumm, wenn man 10 oder mehr Zertifikate haben will, dann muß man Pausen einlegen oder mehrere ausgehende IPs verwenden.
Außerdem unterstützen längst nicht alle Geräte ACME, selbst bei der Fritz!BOX hat es Jahre gedauert, bis die Entwickler die Notwendigkeit eingesehen haben, bei den meisten Firewall-Herstellern (z.B. Sophos) ähnlich.
also das Microsoft zeug ist aber auch nicht zu gebrauchen. Erstelle mal eine neuerer Zertifikats Vorlage und schau was dein Autoentrollement macht. Das fällt auf die Nase. Ein Bug den Microsoft seit Jahren nicht fixen will. Was beleibt vorlagen bis maximal Win8 bzw. WinServer2012…
Das nenne ich nicht Fortschritt!
Ist ein bisschen OT, aber passt von der politischen Großwetterlage gut:
Wenn ich das richtig sehe, sind _alle_ Zertifikathändler bzw. -aussteller amerikanische Unternehmen.
Wir kaufen einmal pro Jahr ein EV-Zertifikat für unsere Installer. Das ist ein verdammter Alptraum jedesmal: Unsere Kreditkarten werden bei US-Unternehmen oft nicht akzeptiert, die Bezahldienste sind immer wieder down, die Anbieter schicken mir leere Sticks – die digitale Übertragung gibt es nicht mehr für EV…
Wirklich mühsam, zeitaufwändig und kaum kontrollierbar sind auch die Unternehmensprüfungen für das EV-Zertifikat: Mal wollen sie angerufen werden, mal wollen sie anrufen; sie melden sich unter anderen Firmennamen… und das ändern die auch mal im Prozess. Tipp- bzw. Schreibfehler von denen gehen in die EV-Daten – was dazu führt, dass der gesamte Prozess wiederholt werden muss…
Ich hab' mittlerweile den Eindruck, dass das Geschäft von irgendwelchen Banden betrieben wird, die gemerkt haben, dass man mit wenig Aufwand eine Menge Geld verdienen kann.
Man kann sich vorstellen, wie einfach es für die US-Administration ist, per security letter außeramerikanische Softwareanbieter zu behindern.
Und es gibt keinen europäischen Anbieter! Wie kann denn das sein?
Letztes Jahr bin ich auf einen Holländer (ich weiß nicht mehr wie der hieß) gestossen und hab' mich schon gefreut – zu früh, ein paar Wochen danach ist der Sectigo gekauft worden. Wieder ein Ami….
Automatisierung ist das Zauberwort. Wir machen das schon seit Jahren und auch im Abstand von 30 Tagen. Bei etwas über 600 Zertifikaten, die wir verteilen, geht das auch gar nicht anders. Selbst, wenn die einmal im Jahr getauscht werden würden.