toheine.net

Aktuelles zu Let's Encrypt

4 min read toheine Lets Encrypt Security

Ich bin diese Woche über die Podcast-Episode News PKI-Neuerungen, Tor-Umbau und React2Shell von Passwort gestolpert, die sich mit den Neuerungen von Let’s Encrypt sowie dem Thema PKI insgesammt angenommen hat. Die komplette Episode geht dabei auf einige weitere interessante Themen ein. Für mich wertvoll waren insbesondere die im Folgenden beschriebenen Infos.

Laufzeit von Let’s-Encrypt-Zertifikaten wird angepasst

Am 02.12.2025 veröffentlichte Let’s Encrypt einen Blog-Post , in dem eine Änderung der Zertifikats-Laufzeiten bekannt gegeben wurde. Die Umsetzung wird in folgenden Schritten geschehen:

  • 13.05.2026: Reduzierung der Laufzeit von Zertifikaten auf 45 Tagen im ACME-Profil tlsserver.
    Das Default-Profil classic ist davon nicht betroffen.
  • 10.02.2027: Reduzierung der Laufzeit von Zertifikaten im Default-Profil classic auf 64 Tage.
  • 16.02.2028: Reduzierung der Laufzeit von Zertifikaten im Default-Profil classic auf 45 Tage.

Damit die ACME-Clients ordentlich mitbekommen, wann sie das Zeritifkat erneuern müssen, sollten diese das Feature ACME Renewal Information (ARI) unterstützen. Ich präferiere bisher dehydrated als ACME-Client. Dieser unterstützt (soweit ich das sehe) derzeit noch kein ARI. Aber ein entsprechender Pull-Request liegt bereits vor. Ich gehe davon aus, dass das rechtzeitig umgesetzt wird.

Mit der Anpassung der Laufzeiten kommt Let’s Encrypt den Basline Requirements (s.u.) nach die u. a. die maximale Dauer von Zertifikats-Laufzeiten für CAs vorgibt. Dort heißt es aktuell:

Subscriber Certificates issued on or after 15 March 2029 SHOULD NOT have a Validity Period greater than 46 days and MUST NOT have a Validity Period greater than 47 days.

Das muss man aktiv weiter verfolgen. Es ist zu erwarten, dass die Laufzeiten in Zukunft weiter reduziert werden. Das ist zumindest der Wunsch der Browserhersteller.

DNS-PERSIST-01 in Planung

Im gleichen Blog-Post von Let’s Encrypt wird ein neuer DNS-Challenge-Typ namens DNS-PERSIST-01 angekündigt. Dieser soll die Automatisierung zur Ausstellung von Zertifikaten vereinfachen. Geplant ist, dass der DNS-Ressource-Record vom Typ TXT, der bei der (bisherigen) DNS-01-Challgenge dynamisch gesetzt werden musste, einmalig und dauerhaft eingetragen wird. Hier darf man gespannt sein, wie schnell das kommt, da es hier Absprachen mit der IETF und dem CA/Browser-Forum gibt/geben muss. Ein erster Entwurf liegt bei der IETF bereits vor.

Baseline Requirements

Nicht neu … aber ich hatte das bisher einfach noch nicht hinterfragt: Wie kann es funktionieren, dass verschiedene die Certificate Authorities (CAs) die ausgestellten Zertifikate einheitlich und nach bestimmten Qualitätskriterien/Richtlinien ausstellen? Hier kommen die eben erwähnten Baseline Requirements ins Spiel. Verfasser ist ein Zusammenschluss verschiedener Browser-Hersteller und Zertifizierungsstellen, der unter dem namen CA/Browser-Fourm auftritt.

Certificate Transparency (CT) Logs

Die Logs über die bisher ausgestellten Zertifikate wechseln von RFC 6962 API zu Static CT API . Der eigentlich neue RFC 9162 fand keine praktische Anwendung. Durch Static CT wird der Aufwand für das Vorhalten der Logs und die Beantwortung von Anfragen deutlich reduziert. Eine Beschreibung, wie das funktioniert, ist im Let’s-Encrypt-Blogbeitrag End of Life Plan for RFC 6962 Certificate Transparency Logs vom 14.08.2025 und im Heise-Artikel Static-CT verbessert Zertifikatsprotokolle vom 18.07.25 gut nachzulesen.

Um die CT Logs einzusehen gibt es Tools wie z. B. crt.sh . Das war mir auch komplett neu. Hier sind pro Domain alle bisher ausgestellten Zeritifikate hinterlegt. Ich bin fasst vom Stuhl gefallen, als ich gesehen hab, was man hier alles ablesen kann:

Gekürzte Ausgabe von crt.sh am Beispiel toheine.net
Gekürzte Ausgabe von crt.sh am Beispiel toheine.net

Natürlich sind die ausgestellten und produktive Zertifikate im Internet und damit für alle Welt einsehbar. Aber mir war nicht klar, dass jede Erzeugung auch offen im Netz steht (auch wenn ich das Zertifikat nicht nutze). In Zukunft werde ich wohl in meinen Fortbildungen keine exemplarischen Zertifikate auf den Namen <name>-is-doof.meine-domain.tld erzeugen 😉 .

Fazit

Die erwähnte Podcast-Episode mit dem Titel News PKI-Neuerungen, Tor-Umbau und React2Shell war mit zahlreichen wichtigen Infos für mich gespickt. Nicht nur zu den aktuellen News von Let’s Encrypt … auch die weiteren Themen waren super aufbereitet. Ich muss peinlich berührt zugeben, dass ich entsprechende SSL-/TLS-Zertifikate schon seit vielen Jahren fröhlich ausstelle, aber mir hat gleichzeitig einiges an Hintergrundwissen gefehlt. Wieder was gelernt! Danke an @christopherkunz und @syst für die Aufbereitung. Euren Podcast werde ich in Zukunft aktiv verfolgen und weiter empfehlen.

Quellen