Let's Encrypt startet die allgemeine Verfügbarkeit von 6-Tage- und IP-Adress-Zertifikaten

 (letsencrypt.org)
14 Punkte von GN⁺ 2026-01-17 | 1 Kommentare | Auf WhatsApp teilen
  • Let's Encrypt hat die offizielle Bereitstellung von Kurzzeit-Zertifikaten mit 6 Tagen Gültigkeit und IP-Adress-basierten Zertifikaten gestartet
  • Kurzzeit-Zertifikate sind 160 Stunden (ca. 6 Tage und 16 Stunden) gültig und können über den ACME-Client durch Auswahl des Profils shortlived ausgestellt werden
  • Diese Zertifikate sollen häufigere Erneuerungen fördern und so die Sicherheit erhöhen sowie die Abhängigkeit von wenig verlässlichen Widerrufsverfahren verringern
  • IP-Adress-Zertifikate unterstützen sowohl IPv4 als auch IPv6 und werden wegen der höheren Änderungsdynamik von IP-Adressen ausschließlich als Kurzzeit-Zertifikate ausgestellt
  • Diese Maßnahme wird als schrittweise Veränderung zur Verbreitung automatisierter Zertifikatserneuerung und zur Stärkung der Sicherheit bewertet

Bereitstellung von Kurzzeit-Zertifikaten (6 Tage)

  • Kurzzeit-Zertifikate (short-lived certificates) sind 160 Stunden gültig und haben damit eine deutlich kürzere Laufzeit als bisherige 90-Tage-Zertifikate
    • Sie können ausgestellt werden, wenn im ACME-Client das Zertifikatsprofil shortlived ausgewählt wird
  • Diese Zertifikate erhöhen die Sicherheit, indem sie häufigere Validierungen verlangen, und mildern Probleme durch die Unzuverlässigkeit von Widerrufssystemen
    • Bisher war bei einem Leak des privaten Schlüssels ein Zertifikatswiderruf nötig, doch da das Widerrufsverfahren nicht zuverlässig ist, konnte der verwundbare Zustand bis zum Ablauf bestehen bleiben
    • Mit Kurzzeit-Zertifikaten wird diese Verwundbarkeitsphase deutlich verkürzt
  • Kurzzeit-Zertifikate sind optional (Opt-in) und sollen nicht zum Standard werden
    • Nutzer mit vollständig eingerichteten automatischen Erneuerungsprozessen können leicht umstellen
    • Da jedoch nicht alle Nutzer an so kurze Laufzeiten gewöhnt sind, bleibt die Standardeinstellung unverändert
  • In den kommenden Jahren soll die Standard-Gültigkeitsdauer von Zertifikaten von 90 auf 45 Tage verkürzt werden
Anzeige

IP-Adress-Zertifikate

  • IP-Adress-Zertifikate (IP address certificates) ermöglichen es, TLS-Verbindungen über IP-Adressen statt über Domainnamen zu authentifizieren
    • IPv4 und IPv6 werden beide unterstützt
  • IP-Adress-Zertifikate werden zwingend nur in Form von Kurzzeit-Zertifikaten ausgestellt
    • Der Grund dafür ist, dass sich IP-Adressen häufiger ändern als Domains und daher häufigere Validierungen erforderlich sind
  • Weitere Details und Anwendungsfälle finden sich im ersten Beitrag zu IP-Zertifikaten vom Juli 2025

Unterstützung und Förderung

  • Diese Entwicklung wurde durch Open Technology Fund, Sovereign Tech Agency sowie Förderer und Spender unterstützt
  • Let's Encrypt ist eine von der Non-Profit-Organisation Internet Security Research Group (ISRG) betriebene kostenlose, automatisierte und öffentliche Zertifizierungsstelle (CA)
  • Im Jahresbericht 2025 der ISRG finden sich Informationen über die gesamte Non-Profit-Arbeit

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2026-01-17
Hacker-News-Kommentare

  • Stand heute konnte man mit certbot keine IP-Adresszertifikate bekommen
    Stattdessen habe ich lego verwendet, aber es hat ziemlich lange gedauert, den richtigen Befehl zu finden
    Der Befehl, der gestern funktioniert hat, war:
    lego --domains 206.189.27.68 --accept-tos --http --disable-cn run --profile shortlived

    • Ich habe mich gefragt, ob Caddy das auch unterstützt
      Scheint noch in Arbeit zu sein (GitHub-Issue)

  • IP-Adresszertifikate sind besonders für iOS-Nutzer interessant, die ihren eigenen DoH-Server betreiben
    Unter iOS funktionierte es nur, wenn sowohl für den FQDN als auch für die IP ein korrektes Zertifikat vorhanden war
    Deshalb funktionieren Profile großer Dienste wie dns4eu oder nextdns gut, aber selbst betriebene DoH-Server scheiterten

    • OpenSSL verlangt bei TLS-Verbindungen strikt, dass die IP-Adresse im SAN-Feld des Zertifikats enthalten ist
      Wahrscheinlich wurde das nicht explizit von einem iOS-Ingenieur ergänzt, sondern ist eher ein Nebeneffekt der verwendeten Kryptobibliothek
    • Ich nutze täglich DoH mit einer persönlichen Domain hinter einem Reverse Proxy und habe überhaupt keine Probleme

  • Ich habe mich gefragt, warum es Zertifikate mit 6 Tagen Laufzeit sind
    8 Tage wären praktisch für eine wöchentliche Erneuerung, und 8 ist eine Potenz von 2 und außerdem eine Glückszahl
    Aber 6 fühlt sich einfach nicht richtig an

    • Mit einem 6-Tage-Zyklus verteilt sich die Last langfristig gleichmäßig über die Wochentage
      Bei 8 Tagen könnte sich der Traffic auf bestimmte Wochentage konzentrieren
    • Tatsächlich sind es nicht 6 Tage, sondern ungefähr 160 Stunden (6,6 Tage)
      160 ist die Summe der ersten 11 Primzahlen und auch die Summe der Kuben der ersten drei Primzahlen
    • 6 steht auch symbolisch dafür, dass Gott 6 Tage arbeitete und am 7. ruhte
    • 6 ist die kleinste vollkommene Zahl (perfect number) und damit ein Symbol für Perfektion

  • Als Nächstes sollten sie sich bitte auf die Ausstellung von Zertifikaten für .onion-Adressen konzentrieren
    .onion hat bereits ein Schlüsselpaar, daher ist der Eigentumsnachweis vertrauenswürdiger als bei DNS

  • Wenn man IP-Zertifikate möchte, unterstützt certbot das noch nicht
    Es gibt dazu einen offenen PR (#10495)
    acme.sh scheint es dagegen bereits zu unterstützen

    • ACME-Clients mit aktueller Unterstützung für IP-Adressen sind acme.sh, lego, traefik, acmez, caddy, cert-manager
      Ich gehe davon aus, dass certbot bald nachzieht

  • Ich hatte mit einem Erneuerungszyklus von 2 Wochen getestet und war dann überrascht, dass die Zertifikate jetzt nur noch 6 Tage gültig sind
    Wenn die Pipeline fehlschlägt, bleibt zu wenig Zeit zum Debuggen
    Ich finde die Begründung schwer nachvollziehbar, dass IPs volatiler als Domains seien
    Die feste IP eines VPS ändert sich nicht so oft

    • Bei AWS kann man eine Elastic IP allerdings sofort freigeben
      Wenn man ein 45-Tage-Zertifikat ausstellen lässt und die IP direkt danach zurückgibt, kann ein anderer Nutzer diese IP bekommen
      Dann hätte man ein gültiges Zertifikat für die IP eines anderen, was riskant wäre
    • In Cloud-Umgebungen werden IPs schnell neu zugewiesen, daher sind selbst 6 Tage eher lang
    • Eine zu kurze Zertifikatslaufzeit passt nicht gut zu realen Betriebsabläufen
      Solche Richtlinien wirken wie ein Ansatz, der die praktische Arbeit vor Ort nicht gut versteht
    • Entscheidend ist die Kontrolle über den Besitz der IP
      Die meisten Betreiber von Diensten kontrollieren die IP selbst nicht direkt, daher ist das eine Maßnahme zur Risikoreduzierung für die CA
    • Wenn man an eine EC2-Instanz keine EIP bindet, bekommt sie nach einem Neustart fast immer eine andere IP
      Missbrauch ist zwar schwierig, aber aus Sicherheitssicht bleibt es relevant

  • Ich frage mich, ob IP-Adresszertifikate dazu führen könnten, dass der IPsec-Transportmodus wieder mehr Aufmerksamkeit bekommt
    Das von mir verfasste RFC 5660 hat ebenfalls damit zu tun

    • In der Praxis sind SDN oder Site-to-Site-VPNs aber bereits weit verbreitet
      Zertifikate in IPsec-Tunneln zu verwenden, ist weiterhin umständlich
      Manche Firewall-Geräte haben sogar seltsame Bugs, bei denen die Zertifikatsprüfung fehlschlägt, wenn die Zertifikatskette zu lang ist
    • Der IPSec-Standard ist zu groß und komplex, und selbst die Unternehmen, die ihn entwickelt haben, haben über Jahrzehnte hinweg immer wieder CVEs kassiert

  • Da IP-Zertifikate nur für im Internet erreichbare Adressen möglich sind, bleibt TLS für LAN-Geräte weiterhin schwierig

    • Mit IPv6 wäre das auch ohne externe Exponierung möglich
      Man könnte den Traffic am Edge per DNAT an eine VM zur Zertifikatserneuerung weiterleiten und ihn dann an interne Geräte verteilen
    • Ich verwende in meinem Heimnetz ein Wildcard-Zertifikat (*.home.example.com)
      Dafür braucht man einen öffentlichen DNS-Anbieter, bei dem sich TXT-Records per API setzen lassen, aber legos DNS-Plugins unterstützen viele Anbieter
    • In solchen Fällen kann auch eine private CA eine Lösung sein
    • Für interne Netzadressen kann man den Besitz von außen nicht nachweisen, daher ist es meiner Meinung nach besser, einfach Domains zu verwenden

  • Diese Ankündigung freut mich wirklich sehr
    IP-Zertifikate lösen das anfängliche Bootstrap-Problem bei self-hosted Software
    Zum Beispiel könnte die Instant-Subdomains-Funktion von TakingNames dadurch überflüssig werden

  • IP-Adresszertifikate sind nützlich, wenn kurzlebige Dienste (ephemeral services) per TLS kommunizieren sollen
    Man muss keine DNS-Records extra anlegen, was praktisch ist, wenn man Hunderte temporäre Instanzen startet

    • Sie könnten auch für Encrypted Client Hello (ECH) nützlich sein
      Wenn man statt eines im Klartext sichtbaren SNI ein IP-Zertifikat verwendet, können Außenstehende den tatsächlichen Hostnamen nicht sehen
      So könnten auch kleinere Websites ohne Proxy ECH nutzen, nicht nur große Cloud-Anbieter
    • In der offiziellen Ankündigung von Let's Encrypt sind verschiedene Anwendungsfälle zusammengefasst
    • Die Unabhängigkeit von Registraren ist attraktiv
      Das erhöht die Anonymität
    • Für Dienste, die sich nicht an Menschen richten, ist es besonders nützlich, die Abhängigkeit von Nameservern zu entfernen
    • Das lässt sich auch auf Protokolle wie DNS over TLS oder DNS over HTTPS anwenden