it-swarm.com.de

Warum können Let's Encrypt Wildcard-Zertifikate nicht unterstützen?

Verschlüsseln wir behauptet :

Wir bieten keine Organisationsvalidierungs- (OV), erweiterten Validierungs- (EV) oder Platzhalterzertifikate an, hauptsächlich , weil wir Die Ausstellung für diese Zertifikatstypen kann nicht automatisiert werden.

Um ehrlich zu sein, glaube ich ihnen nicht. Warum genau sollte dies der Fall sein?

14
user541686

Let's Encrypt hat gerade angekündigt, dass sie 2018 Wildcard-Zertifikate anbieten werden:

Wildcard-Zertifikate werden kostenlos über unseren kommenden ACME v2 API-Endpunkt angeboten. Wir werden zunächst nur die Validierung der Basisdomäne über DNS für Platzhalterzertifikate unterstützen, können jedoch im Laufe der Zeit zusätzliche Validierungsoptionen untersuchen. Wir empfehlen unseren Nutzern, in unseren Community-Foren Fragen zur Unterstützung von Platzhalterzertifikaten zu stellen.

Quelle: https://letsencrypt.org/2017/07/06/wildcard-certificates-coming-jan-2018.html

Der Support für Wildcard-Support ist ab dem 13.03.2018 jetzt live ! Link für die erforderlichen Schritte https://community.letsencrypt.org/t/acme-v2-production-environment-wildcards/55578

17
Emil Stenström

Aufgrund einer Ankündigung von Let's Encrypt sind die Informationen in dieser Antwort nur noch von historischem Wert. Siehe die Informationen in Emil Stenström 's Antwort .

Das IETF-standardisierte ACME v2-Protokoll wird in Kürze verfügbar sein und Let's Encryptangekündigt am 14. Juni 2017 , dass sie im Januar 2018 einen neuen API-Endpunkt gegen diesen Standard haben werden Wie von Emil in seiner Antwort berichtet, geben Let's Encrypt heute (6. Juni 2017) bekannt, dass sie den neuen API-Endpunkt verwenden können, um den begehrten Platzhalter auszugeben Zertifikate. Guter Fang Emil.


Nach einem zu langen Austausch von Kommentaren habe ich beschlossen, sie zu einer Antwort zu sammeln und zu erweitern. Hoffentlich hilft das. Ich vermeide jede Diskussion über die OV- und EV-Zertifikate, da sie ein ganz anderes Szenario haben und der Titel der Frage eindeutig fragt: Warum können wir die Unterstützung nicht verschlüsseln Platzhalter Zertifikate?

Ganz oben auf der Liste der "Warum" steht, dass das Protokoll ACME , das die Grundlage für die Validierung von LE bildet, die Wildcard-Validierung noch nicht abdeckt. Ohne dies kann LE solche Zertifikate einfach nicht ausstellen, ob sie wollen oder nicht. Es gab jedoch Diskussionen über die IETF ACME-Mailingliste , so dass möglicherweise noch Hoffnung besteht, zumindest in das Protokoll aufgenommen zu werden. Außerdem erklärt die LE FAQ weiter, dass Wildcard-Zertifikate nicht auf unbestimmte Zeit ausgeschlossen sind. Obwohl sie diesen Status vielleicht trotzdem erreichen.

Wird Let's Encrypt Platzhalterzertifikate ausstellen?

Wir haben derzeit keine Pläne dazu, aber es ist eine Möglichkeit für die Zukunft. Hoffentlich sind für die überwiegende Mehrheit unserer potenziellen Abonnenten keine Platzhalter erforderlich, da es einfach sein sollte, Zertifikate für alle Subdomänen zu erhalten und zu verwalten.

Die Automatisierung des Ausstellungsprozesses ist ein Schlüsselprinzip hinter Let's Encrypt. Also, alles, was nicht automatisiert werden kann, wird nicht durch sie geschehen. Das ist ein Punkt, den sie wiederholt in Beiträgen auf ihrem Community-Forum betont haben.

Ein Teil des Problems bei der Automatisierung der Ausgabe für einen Platzhalter besteht darin, wie es gemacht wird. Der HTTP-Validierungsprozess besteht darin, dass der Zertifizierungsserver den anfordernden Agenten (ein Programm oder ein Skript) anweist, eine eindeutig benannte Datei mit signiertem Inhalt auf dem zu validierenden Host zu erstellen. Anschließend versucht der Zertifizierungsserver, auf diese Datei zuzugreifen und deren Inhalt zu überprüfen. Wenn die Datei abgerufen werden kann und der Inhalt korrekt ist, beweist dies, dass der anfordernde Agent die Berechtigung technisch hat, diesen Host zu steuern, und validiert für ein Zertifikat ist.

Wenn ich ein Zertifikat für www.example.com Erhalten möchte, wird auf die erstellte Datei mit der URL like zugegriffen

http​://www.example.com/.well-known/acme-challenge/2BHlJs9Qdk_8m6yRNzqEvwiVejyBsa8zXPpORGMIEz4

Der Dateiname ist Teil eines signierten Blocks und für diese Anforderung eindeutig. Eine spätere Anforderung hat einen neuen Dateinamen mit neuem Inhalt, sodass die Challenge-Antwort bei dem Versuch, die Validierung zu umgehen, nicht vor dem Laden verwendet werden kann. Jedenfalls ist das alles gut und schön für einen bekannten Domainnamen. Was passiert, wenn wir versuchen, ein Zertifikat für *.mysub.example.com Zu erhalten? Der Zertifizierungsserver versucht, auf die URL von zuzugreifen

http​://*.mysub.example.com/.well-known/acme-challenge/2BHlJs9Qdk_8m6yRNzqEVWiVejyBsa8zXPpORGMIEz4

Das wird nicht funktionieren. Es wird nicht einmal im DNS-System nachgeschlagen, sowieso nicht wie erwartet. Wenn Sie versuchen, dies in DNS nachzuschlagen, erhalten Sie unter normalen Umständen eine Fehlermeldung NXDOMAIN, und wenn tut etwas zurückgibt, ist es wahrscheinlich nicht das, was beabsichtigt ist. Der Authentifizierungstest kann nicht nur eine Ebene auf mysub.example.com Zurücksetzen, da dies nicht durch das angeforderte Zertifikat abgedeckt ist und möglicherweise auch nicht unter der Kontrolle des anfordernden Agenten steht. Möglicherweise kann ich eine unbegrenzte Anzahl von Subdomains für eine Domain oder Subdomain erstellen, ohne dem übergeordneten Element selbst Dateien hinzufügen zu können.

Das Hinzufügen eines Platzhalterdatensatzes zum DNS funktioniert tatsächlich rückwärts gemäß den Erwartungen. Ein solcher Datensatz stimmt nur überein, wenn die Datensätze keine übereinstimmende Domäne enthalten. Wenn ich eine Subdomain von mysub.example.com Mit den richtigen DNS-Einträgen dafür erstelle, stimmt *.example.com nicht damit überein . Und es überträgt sich auch auf Datensatztypen. Ein CNAME-Datensatz für mysub.example.com Ohne übereinstimmenden MX-Datensatz stimmt also immer noch nicht mit einer Anforderung für einen MX-Datensatz mit mysub überein, obwohl is ein Platzhalter-MX-Datensatz vorhanden ist . RFC 1912 kann interessant und kompliziert sein. {Hier sind Drachen.}

Da ein Platzhalter im DNS dem widerspricht, was der Platzhalter im Zertifikat bedeutet, werden die Dinge für die Überprüfung noch interessanter. Mit Blick auf die Möglichkeit, dass ich mehrere Domains registrieren lassen könnte:

  • david.jones.name
  • james.jones.name
  • sarah.jones.name
  • mary.jones.name
  • angelica.jones.name

Ich versuche dann, ein Wildcard-Zertifikat für *.jones.name Zu erhalten. Als Validierung fordern sie 4 Domainnamen im Namespace .jones.name An. Ich kann 4 der 5 verfügbaren zur Verfügung stellen und diesen Test bestehen. Jetzt habe ich ein Zertifikat für *.jones.name. Was soll Jared Jones tun, wenn er jared.jones.name Erhält und ich mit meinem *.jones.name - Zertifikat einen MitM-Angriff durchführe?

Aus diesem Grund können sie die Überprüfung nicht automatisieren, dass die Anforderung für ein Platzhalterzertifikat von einer Quelle stammt, die für ALLE und VERANTWORTLICH IST ] ALLE Subdomains, die jetzt oder je in diesem Namespace vorhanden sein könnten. Sie können mithilfe automatisierter Tools überprüfen, ob jemand die Kontrolle über sub.example.com Hat, und solange sub durch etwas Bestimmtes ersetzt wird, das ebenfalls validiert werden kann. Sobald sub durch * Ersetzt ist, funktionieren die Tools zur Validierung nicht mehr. Die einzige Möglichkeit, die Berechtigung für einen Platzhalterdomänen-Namespace zu überprüfen, besteht darin, den Besitz der übergeordneten Domäne UND die Identität der anfordernden Partei zu überprüfen. Wenn ich Eigentümer der übergeordneten Domain example.com Bin, kann ich auf jeder von mir gewählten Ebene alles als Subdomain frei erstellen und steuern. Beachten Sie, dass sich "Besitz" hier von "Kontrolle" unterscheidet, was durch das ACME-Protokoll validiert wird.

Außerhalb von LE wird meistens ein Zertifikat über den Host oder den Registrar erhalten, sodass die "Identität" bereits bestätigt ist und der Besitz bekannt ist. Wenn ich mich bei GoDaddy und Host bei DigitalOcean registriere, "wissen" beide, wer ich bin, und haben ein angemessenes Maß an Vertrauen, dass ich die Domain besitze. Selbst wenn sie das Zertifikat nicht selbst ausstellen, können sie die Anforderung verarbeiten und bei der Zertifizierungsstelle überprüfen, ob Identität und Eigentum gültig sind. Auf diese Weise kann die Zertifizierungsstelle ein Platzhalterzertifikat für die angeforderte Ebene ausstellen, auch wenn es sich um ein oder zwei Ebenen der Domäne handelt, die ich besitze, da der gesamte Baum in meinen Besitz fällt.

Es reicht oft aus, nur im whois nach der Domain zu suchen und die Regeln für diesen Namespace zu kennen, um den Besitz zu bestimmen. Es ist jedoch ein menschenzentrierter Prozess, der nicht mit angemessenem Aufwand und Zuverlässigkeit automatisiert werden kann. Um die Sache zu komplizieren, sind Namespace-Regeln bestenfalls inkonsistent. Beispielsweise sind für die .name gTLD einige Namen der 2. Ebene registrierbar, während andere reserviert sind und die Namen der 3. Ebene registrierbar sind. Dies gilt auch für viele ccTLDs. Und einige gTLDs sind immer Registrierungen der 3. Ebene, .pro Ist ein Beispiel, denke ich. Wie kann ein automatisierter Prozess "wissen", ob *.smyther.name Rechtmäßig ist und nicht *.david.smyther.name?

smith.name Ist reserviert und die Leute müssen sich auf der dritten Ebene registrieren, daher wäre ein *.smith.name Ein schlechtes Zertifikat. OTOH smyther.name Ist nicht reserviert, daher wäre ein *.smyther.name Ein gutes Zertifikat. Sie können dies mithilfe des whois-Systems herausfinden. Ein Programm müsste die Ausgabe analysieren, die sich immer ändern kann und daher für die Automatisierung unzuverlässig ist. Ich kenne die .name GTTD, aber ich bin auch auf andere gestoßen, die seltsame und veränderbare Regeln haben, die die Automatisierung machen, vielleicht nicht nmöglich, sondern npraktisch. LE ist kostenlos, so dass sie nicht jede Glocke und Pfeife machen können, nur weil es schön ist.

Auch in Bezug auf die Ausstellung von Wildcard-Zertifikaten durch LE kommt es auf die "Automatisierung" an. Sie könnten Bedingungen für einen Fall von this und für einen anderen Fall von that einbauen. Aber wo hören sie auf, die Regeln zu "twittern"? Je mehr Zweige sie in den Entscheidungsbaum einbauen, desto mehr Fehlerquellen führen sie ein. Da der Platzhalter kostenlos und automatisch ist, hat er weniger Wert. Sie können ein Zertifikat erhalten, das 100 Domain-Namen in einem einzigen Schuss abdeckt (iirc). Warum also einen Platzhalter verwenden? Ihre Zeit und Mühe wird besser für Dinge aufgewendet, die für das "Allgemeinwohl" wertvoller sind, als Ausnahmen zu schaffen und sich ändernde Bedingungen zu überwachen.

Ja, ich weiß, dass es Anwendungsfälle gibt, in denen ein Platzhalterzertifikat unverzichtbar ist. Eine mobile App, die für jede Verbindung eine neue, zufällige und eindeutige Subdomain erhält, kann keine LE-Zertifikate verwenden. Die Anzahl der Zertifikate, die Sie pro Woche anfordern können, ist begrenzt, sodass sie nicht jedes Mal ein neues Zertifikat erhalten können, wenn ein Client eine Verbindung herstellt. Technisch möglich, wird aber mit LE nicht passieren. Für die meisten dieser Edge-Fälle gibt es jedoch andere Optionen. Eine davon ist, ein Wildcard-Zertifikat woanders zu kaufen. In vielen Fällen mit mobilen Apps (oder sogar Desktop-Anwendungen) ist es auch möglich, eine interne Zertifizierungsstelle zu erstellen und diese zur Vertrauensdatenbank der App hinzuzufügen. Anschließend werden die neuen kurzlebigen Zertifikate erstellt, die bei Bedarf intern signiert werden.

21
user135823