Let's Encrypt bereitet die Ausstellung von Zertifikaten für IP-Adressen vor

• Let's Encrypt wird bald die Ausstellung von Zertifikaten unterstützen, die IP-Adress-SANs enthalten; anfangs werden sie nur im kurzlebigen (shortlived) Profil mit 6 Tagen Laufzeit angeboten und für eine gewisse Zeit per Whitelist eingeschränkt bereitgestellt
• Bis zur offiziellen Freigabe laufen interne Tests und Vorbereitungen weiter; einen konkreten Zeitplan oder Hinweise zur Antragstellung gibt es noch nicht
• In der Staging-Umgebung wurden Beispielzertifikate mit IPv6-Adressen sowie eine Site, die diese verwendet, veröffentlicht; die Community wird gebeten, Auffälligkeiten oder Feedback zu teilen
• In Firefox wurde ein Bug zur Anzeige von IP-SANs entdeckt (BZ #1973855), daher werden die Tests fortgesetzt
• Praktische Tests haben gezeigt, dass es bei gemischten DNS-SAN- und IP-SAN-Fällen zu Verwirrung kommen kann; demonstriert wurde, dass TLDs und die Schreibweise von IPv6-Adressen ähnlich wirken können

---

Let's Encrypt, Getting ready to issue IP address certificates

Stand der Vorbereitung für die Unterstützung von IP-Adress-SANs

• Let's Encrypt plant, bald in der Produktionsumgebung die Ausstellung von Zertifikaten mit IP-Adress-SANs zu unterstützen
• Diese Zertifikate werden nur im shortlived-Profil mit 6 Tagen Gültigkeit ausgestellt und für eine gewisse Zeit über eine Allowlist eingeschränkt betrieben
• Ein offizieller Starttermin sowie das Verfahren zur Aufnahme in die Allowlist stehen noch nicht fest, da weitere interne Vorbereitungen nötig sind

Tests und Beispielzertifikate

• In der Staging-Umgebung wurden Beispielzertifikate mit IP-SANs sowie ein real eingesetztes Beispiel auf einer Site (IPv6-Adresse) veröffentlicht
• Die Community wird gebeten, Auffälligkeiten, interessante Beobachtungen oder entdeckte Probleme zu teilen

Mischfälle von IP-SAN und DNS-SAN

• Im Test wurde demonstriert, dass Zertifikate mit gleichzeitig enthaltenen DNS-SANs und IP-SANs ausgestellt werden können und dabei Verwechslungsfälle in der Darstellung auftreten können
• Bestimmte TLDs wie .cafe und die Schreibweise von IPv6-Adressen können sich ähneln, was zu Verwirrung führen kann
• In Firefox wurde außerdem ein Bug bei der Anzeige von IP-Adress-SANs (BZ #1973855) festgestellt

Zusammenfassung

• Die Unterstützung von IP-Adress-Zertifikaten bei Let's Encrypt wird zunächst eingeschränkt über Whitelist und Kurzläufer-Zertifikate eingeführt
• Vor dem Einsatz in realen Services sollen durch Tests verschiedenster Fälle und Community-Feedback Stabilität und Kompatibilität geprüft werden
• Auch Browser-Anzeigeprobleme bei gemischter Verwendung von SANs für DNS-Namen und IP-Adressen werden mitdiskutiert

[GN⁺]

Hacker-News-Kommentare

• Ich denke, Zertifikate für IP-Adressen sind ebenfalls nützlich.
  Aber ich denke, Let’s Encrypt könnte eine viel größere Wirkung haben, wenn es S/MIME-Zertifikate unterstützen würde.
  Rund um E-Mail-Verschlüsselung gibt es seit Jahren eine fast schon absurde Situation.
  Inzwischen unterstützen die meisten großen E-Mail-Clients S/MIME-Verschlüsselung direkt, aber wie im Web braucht man für eine reibungslose User Experience Zertifikate von einer CA.
  Vertrauenswürdige, kostenlose S/MIME-Zertifikate mit einer Gültigkeit von mehr als einem Jahr gibt es inzwischen gar nicht mehr.
  Das Ergebnis ist, dass Privatnutzer E-Mail-Verschlüsselung praktisch überhaupt nicht verwenden.
  PGP ist zu umständlich und wird außerhalb von Technik-Enthusiasten kaum genutzt.
  Ich denke, wir sollten inzwischen auch unsere E-Mails verschlüsseln.
  Nebenbei: Wenn eine CA den privaten Schlüssel stellvertretend erzeugt, halte ich dieses Zertifikat nicht für vertrauenswürdig.
  Außerdem muss man bei S/MIME alte Zertifikate weiterhin aufbewahren, um alte E-Mails zu entschlüsseln, daher sind häufig wechselnde Zertifikate unpraktisch.

  • Zu der Aussage, dass man bei S/MIME alte Zertifikate braucht, um alte E-Mails zu entschlüsseln: Der Entschlüsselungsschlüssel selbst kann auch in neuen Zertifikaten weiterverwendet werden, weil man das neue Zertifikat mit dem bestehenden Schlüssel erstellen kann, z. B. mit der Option --reuse-key von certbot.
    Ob das eine gute Praxis ist, ist allerdings eine andere Frage.
    Was wirklich gebraucht wird, ist meiner Meinung nach eine automatische Zertifikatsausstellung im ACME-Stil.
    Im Moment wird es kaum genutzt, weil der Erneuerungsprozess unbequem ist.

  • Für PGP gibt es inzwischen WKD (Web Key Directory) Link, womit sich das Vertrauensmodell von TLS auf E-Mail anwenden lässt.
    TLS-Zertifikate sind deutlich einfacher zu bekommen als S/MIME-Zertifikate.
    Es kann zwar helfen, wenn die Identitätsverwaltung von Dritten übernommen wird, aber die meisten Menschen arbeiten eher nicht in Firmen, für die so ein Modell gut passt.
    Wenn es um Unternehmen geht, halte ich eine interne Identitätsverwaltung für sinnvoller.
    Die jüngste Signalgate-1.0-Episode Link war in Bezug auf das Versagen der Identitätsverwaltung bei Ende-zu-Ende-Verschlüsselung sehr lehrreich.
    Deshalb denke ich, dass S/MIME-Zertifikate oder WKD auch für Regierungen nützlich sein könnten, wenn sie als tatsächlich brauchbares System eingeführt würden.

  • Persönlich sehe ich die Perspektiven für S/MIME-basierte E-Mail-Verschlüsselung eher positiv, halte die Umsetzbarkeit aber für gering.
    Viele normale Nutzer haben schon Schwierigkeiten mit der Verwaltung privater Schlüssel, und in der Realität fällt es ihnen oft sogar schwer, ihre E-Mail-Passwörter ordentlich zu verwalten.
    Am Ende läuft es darauf hinaus, dass entweder pro Domain zentral Zertifikate ausgestellt werden müssen oder Nutzer gar keine Zertifikate bekommen, während Cyberkriminelle gleichzeitig S/MIME-signierte E-Mails versenden.
    Wenn Passkeys in Zukunft allgemein üblich werden und ein Generationswechsel stattgefunden hat, ist dann vielleicht der richtige Zeitpunkt, Menschen direkt mit Schlüsselpaaren umgehen zu lassen.

  • Ich finde, E-Mail-Verschlüsselung sollte einfach verschwinden.
    Siehe: Stop using encrypted email

  • Ich kenne mich mit S/MIME-Verschlüsselung nicht gut aus und habe deshalb eine Frage.
    Warum muss man alte E-Mails mit demselben Protokoll entschlüsseln?
    Ich persönlich hatte Zertifikate immer als etwas für den Transportweg verstanden, während für gespeicherte Daten ohnehin separate Verschlüsselung auf Server- oder Host-Ebene existieren sollte. Deshalb erscheint es mir logisch, beim Transport kurzlebige Zertifikate zu verwenden und für die Speicherung beliebige andere Verschlüsselung – vielleicht übersehe ich hier aber etwas.

• Ich frage mich, ob alle Stellen, die Adressen verwalten, etwa ISPs und Cloud-Anbieter, bei diesem Modell mitziehen.
  Diese rotieren IPs teils extrem schnell, manchmal sogar schneller als in 6 Tagen.
  Ich könnte verstehen, wenn Cloud-Anbieter vor der Neuvergabe einer IP eine Cooldown-Zeit für die Analyse einplanen oder Zertifikate für die betreffende IP nachschlagen und widerrufen. Falls nicht, entsteht die zusätzliche Komplexität, dass Nutzer per Host-Header validieren, unerwünschte IP-basierte Verbindungen ablehnen oder warten müssen, bis alte Zertifikate vollständig verschwunden sind.
  Ich frage mich auch, wie viele IP-Zertifikate man bei den einzelnen Cloud-Anbietern bekommen kann und was sie kosten.

  • Eigentlich unterscheidet sich dieses Problem meiner Meinung nach kaum davon, wie Cloud-Anbieter Custom-/Vanity-Domains handhaben.
    Bei Azure kann man zum Beispiel DNS-Namen wie myapp.westus.cloudapp.azure.com an eine VM binden, und jeder kann sich bei einer CA ein Zertifikat für diese Domain ausstellen lassen Beispiel.
    Auch hier kann jemand direkt nach dem Löschen einer VM ohne gesonderte Cooldown-Phase diese Domain übernehmen.

  • HTTPS-Zertifikate können einen Tag vor Ablauf der Domain als 90-Tage-Zertifikate erneuert werden, und eine CA kennt auch nicht das Limit einer Kreditkarte.
    Die Leute, die IP-Zertifikate nutzen würden, sind vermutlich meist nicht dieselben, die eine IP nach kurzer Zeit wieder verwerfen und verschwinden.
    Die nützlichsten Anwendungsfälle wären sehr spezielle Legacy-Software oder Fälle, in denen wie bei Cloudflare ECH (Encrypted Client Hello) oder ESNI (Encrypted SNI) ohne Shared IP unterstützt werden muss.
    Im ersten Fall, also Legacy, wird man die IP kaum leichtfertig aufgeben, und im zweiten Fall mit ECH/ESNI halte ich es ohnehin für schwierig, erfolgreich die eigentliche Domain zu erreichen.

  • Auf die Frage, ob ISPs mitziehen müssen: Ich sehe es eher umgekehrt.
    Die Aufgabe von ISPs ist nicht, IPs auf eine Weise zuzuteilen, die dem TLS-Standard entspricht, sondern die Identitätsprüfung sollte von TLS-Zertifikatsanbietern anhand der Verknüpfung im jeweiligen Ökosystem zwischen Identität und Ressource – Domain, IP usw. – erfolgen.
    Es wurde diesmal nicht im Detail erklärt, wie das umgesetzt werden soll, aber mein Bauchgefühl sagt mir, dass Let’s Encrypt eine Liste mit IP-Bereichen erstellen wird, die über ASN-Grenzen hinweg langfristig übertragen werden, möglicherweise als gemeinsam gepflegte öffentliche Datenbank ähnlich der Mozilla Public Suffix List, und nur für die dort enthaltenen IPs Zertifikate ausstellt. Wenn eine IP zu einem anderen ASN wechselt, würde dann entsprechend der Umgang mit der Ungültigkeit geregelt.
    Ich hoffe, dass so etwas auch mit anderen ACME-Ausstellern geteilt wird.

  • Wenn es darum geht, wie viele IP-Zertifikate man in verschiedenen Clouds bekommen kann und was sie kosten, frage ich mich auch, ob es künftig Wildcard-Zertifikate dafür geben könnte.

  • In meiner Situation wäre schon ein IP-Zertifikat für nur einen einzigen Tag sehr willkommen, weil ich damit https-URLs testen könnte.

• Technisch verstehe ich ungefähr, wie es funktioniert, aber ich frage mich, wofür es in der Praxis eigentlich gedacht ist.

  • Allein die Unterstützung für ECH (Encrypted Client Hello) oder ESNI (Encrypted SNI) ist meiner Meinung nach schon sehr bedeutend.
    In der Anfangszeit von ESNI konnten das nur große HTTPS-Proxys wie Cloudflare einsetzen, daher wirkte die Idee von IP-Zertifikaten wie ein unerreichbarer Traum. Jetzt können alle Server an ESNI/ECH teilnehmen.
    Wenn Clients anfangen, bei allen Servern standardmäßig von vorhandenen IP-Zertifikaten auszugehen und ESNI zu versuchen, könnte das einen großen Beitrag zur Verbesserung der Privatsphäre im gesamten Internet leisten.

  • In mehreren Antworten wurden schon gute Beispiele genannt, aber auch NTS (Network Time Security) ist erwähnenswert.
    Ohne IP-Zertifikate braucht auch NTS DNS, und wenn DNS ausfällt, ist authentifizierte Zeitsynchronisation überhaupt nicht mehr möglich.
    DNSSEC schlägt ohne korrekte Uhrzeit bei der Validierung fehl, und mit einer Abhängigkeit von DNS + NTS wäre eine Wiederherstellung unmöglich.
    Wenn sich mit Zertifikaten, die eine IP enthalten, authentifizierte Zeit ohne DNS verteilen ließe, könnte das dieses Problem lösen.

  • Man könnte es nutzen, wenn ein gültiges Zertifikat trotz größerer DNS-Änderungen erhalten bleiben muss, etwa um die Erreichbarkeit eines Dashboards sicherzustellen oder zu verhindern, dass alte Automatisierungen wegen DNS-Fehlern stoppen.
    Ein anderer Anwendungsfall wäre, Testumgebungen ohne DNS schneller und einfacher aufzusetzen oder Dinge wie Cockpit kurzfristig nach außen freizugeben.
    Im Grunde eröffnet das jede Menge Einsatzmöglichkeiten, soweit die Vorstellungskraft reicht.

  • Auch für „opportunistisches“ DoTLS, also DNS-Abfragen über TLS gegenüber authdns-Servern, könnte das interessant sein.
    Ein autoritativer DNS-Server könnte auf dem DoTLS-Port mit einem Zertifikat arbeiten, das die öffentliche IP als SAN (Subject Alternative Name) enthält.
    Das geht heute zwar schon über Hostnamen, aber auf einer einzelnen öffentlichen IP können sehr unterschiedliche Namen liegen, sodass ein IP-basiertes SAN die Zuordnung klarer macht.

  • Ich denke, das ist passend für Leute, die aus Hobbygründen oder für einmalige Zwecke lieber direkt eine IP statt eines Hostnamens an ein Projekt binden und dafür keine Domain verwenden möchten.

• Ich frage mich, warum nicht Internet Regional Registries (RIRs) oder Local Internet Registries (LIRs) Zertifikate ausstellen.
  Warum muss ein Dritter Registranten bei RIRs oder LIRs validieren? Ist es so, dass Domain-Registrare ohnehin schon zu viel auf dem Tisch haben?
  Ich frage mich, ob der Grund am Ende derselbe ist.

• Ich habe das Gefühl, hier wird einfach eine weitere Möglichkeit geschaffen, TLS neu zu missbrauchen.
  Bisher ging es um Zertifikate für Domains, die jemand gar nicht besitzt, und jetzt könnten auch Zertifikate für IPs möglich werden, die jemand nicht besitzt.
  Blackhat-Hacker dürften auf Telegram begeistert darüber reden.

  • Eigentlich gibt es IP-Zertifikate schon lange, neu ist nur, dass Let’s Encrypt sie nun ebenfalls anbietet.

• Ich frage mich, ob man dadurch die Verwaltungsoberfläche des lokalen Routers, z. B. 192.168.0.1, per https ohne Self-Signed-Fehler aufrufen kann.

  • Nein, aber vielleicht irgendwann doch.
    Lokale Adressen werden nicht allgemein zugewiesen und sind auch nicht global geroutet, daher gibt es prinzipiell keine Möglichkeit, sie zu validieren.
    Wenn der Router-Hersteller es aber wirklich wollte, könnte bei Geräten ohne CG-NAT und mit zugewiesener öffentlicher IPv4-Adresse immerhin ein Zertifikat für diese öffentliche Adresse beantragt werden.
    Mit IPv6 wäre das noch einfacher, weil es meist global geroutet wird.

  • Nein, und das sollte auch nicht so sein.
    Praktisch lässt sich das aber gut mit einem Proxy, einer echten Domain, einem echten Zertifikat und DNS-Rewriting lösen.
    Zum Beispiel mit einer nginx-Manager-UI und adguard als DNS.
    Man beschränkt den DNS des Routers auf adguard, schreibt die eigene Domain auf den Proxy um, registriert die Domain und lässt ein echtes Zertifikat ausstellen – und damit ist das Problem gelöst.
    Ich nutze inzwischen alle meine lokalen Dienste per https.

  • Für private IPs werden keine Zertifikate ausgestellt.
    Dieselbe private IP kann in einem anderen Netzwerk jederzeit einem völlig anderen Gerät gehören, deshalb ist exklusiver Besitz nicht garantiert.

  • Eher das Gegenteil.
    Ohne öffentliche IP kann kein gültiges Zertifikat ausgestellt werden.
    Schon heute kann man ein Domain-Zertifikat bekommen und die betreffende Domain auf 192.168.0.1 weiterleiten.

  • Um ein Zertifikat zu bekommen, muss man die betreffende IP, also eine öffentliche IP, tatsächlich besitzen.

• Ich frage mich, ob Zertifikate auch für internes IPv4 (192.168.x.x, 172.16.x.x, 10.x.x.x) möglich wären oder ob Browser solche Adressen bewusst ignorieren sollten. Und falls nicht: Könnte man dann wenigstens Wildcard-Zertifikate für interne Netze bekommen?

  • Im Kontext von Zertifikaten, die von öffentlichen CAs ausgestellt werden, ergibt diese Frage meiner Meinung nach keinen Sinn.
    Anders als Domains werden private IPs wie 10.10.10.10 gleichzeitig von zahllosen Menschen „besessen“.
    Für interne Entwicklung gibt es Tools wie mkcert, und für gemeinsam genutzte Ressourcen innerhalb eines Unternehmens sind domainbasierte TLS-Zertifikate deutlich einfacher.

  • Wenn man beweisen könnte, dass der private Schlüssel eines Geräts absolut niemals nach außen gelangt, könnte man es theoretisch auch mit bestehenden CAs versuchen.
    Bei Zertifikaten für interne Adressen ist aber schon der Erwerb des Geräts und das Auslesen des privaten Schlüssels ein unmittelbares Problem für die Sperrung des Zertifikatsschlüssels.
    Daher ist es in der Praxis sinnvoller, auf vertrauenswürdigen Geräten Zertifikate manuell zu importieren, um fehlerfreien Zugriff zu ermöglichen, oder bei mehreren Geräten eine eigene CA aufzubauen und die Zertifikate zentral zu verteilen.
    Mit einem Open-Source-ACME-Server kann man auch intern dieselbe Art von automatisierter Ausstellung wie bei Let’s Encrypt umsetzen.

  • Man kann DNS zunächst auf einen öffentlichen Server zeigen lassen, um das Zertifikat ausstellen zu lassen, und danach DNS auf interne 192.168…-Adressen umbiegen und Zertifikat samt Schlüssel kopieren.
    Man sollte nur beachten, dass manche Router DNS-Antworten, die auf interne Adressen zeigen, verschlucken können, daher sollte man das vorher testen.

  • Ich finde nicht, dass Browser private Netzwerke ignorieren sollten.
    Für mich ist ein privates Netzwerk vielleicht nur mein lokaler Router, für andere kann es aber ein Netz sein, das die ganze Welt umspannt.

• Ich finde es interessant, dass im Beispielzertifikat kein subject-Feld vorhanden ist.
  Liegt das daran, dass die Anfrage per IP erfolgt und im SAN DNS eingetragen ist?

  • Laut dem Team von Let’s Encrypt ist geplant, künftig nur noch subject alternative names statt des subject common name zu verwenden.
    Im Kurzzeitprofil mit 6 Tagen Laufzeit wird das bereits so gemacht, im „klassischen“ 90-Tage-Profil aber noch nicht.

• Jemand erwähnte scherzhaft, ob jetzt der richtige Zeitpunkt sei, CVE-2010-3170 wieder hervorzuholen.

  • Wenn man die X.509-Validierungslogik selbst implementiert, kann so eine Schwachstelle natürlich noch vorhanden sein. Aber um das real auszunutzen, müsste auch noch eine fehlerhaft arbeitende CA das entsprechende Zertifikat ausstellen, daher halte ich das für eher unwahrscheinlich.

• Schade ist nur, dass sich Zertifikate für IP-Adressen nicht per DNS-Challenge ausstellen lassen.
  Aber ich verstehe auch, warum das so ist.