[Technik] Let's Encrypt fuer Hostsharing

Purodha Blissenbach purodha at blissenbach.org
So Nov 15 11:26:58 CET 2015


hallo Michael und alle,

auch wenn ich nicht alles verstanden habe - das liest sich erst mal
recht gut, finde ich. Wer sie nicht brauch oder will, okay, aber ich
glaube, für viele von uns sind die Wildcard-Subdomain-Zertifikate ganz
genau das Richtige. Wenn wir sie nicht kriegen könnten, wär schade.

Purodha

On 14.11.2015 18:40, Michael Hierweck wrote:
> Hallo allerseits,
>
> das Team - insbesondere Peter und ich - machen sich Gedanken darüber,
> wie wir Let's Encrypt [1] für alle Domains automatisch verfügbar 
> machen
> können, ohne dass die Nutzer sich überhaupt darum kümmern müssen.
>
> Aktuell führen wir SNI [2] ein und alle Domains, die nicht von einem
> durch den Nutzer vorgegebenen Zertifikat abgedeckt sind, erhalten
> automatisch ein selbstsigniertes Wildcard-Zertfikat. Das Ausrollen
> erwarte ich noch in diesem Monat.
>
> Folgende Herausforderungen sich zu meistern:
>
> 1. Der Erneuerungsprozess für Zertifikate muss vollautomatisiert 
> sein,
> da die Zertifikate nur 90 Tage gültig [3] sind. Wir wollen dies in
> unsere Infrastraktur integrieren.
>
> Für die automatisierte Validierung soll es zwei Verfahren geben:
>
> - per Datei im Webspace [4]
>
> 	=> dieses Verfahren erscheint mir für uns ungeeignet,
> 	weil wir die Webserverkonfiguration überlagern müssten,
> 	um die Challenge mit der richtigen Response zu meistern
> 	(Das klingt komplex und hakelig.)
>
> - per DNS-Eintrag [4]
>
> 	=> dieses Verfahren erscheint mir für uns besser geeignet,
> 	denn wir müssen lediglich einen DNS-Eintrag hinzufügen.
> 	Dieser DNS-Eintrag sollte minimale Gültigkeitsdauer haben,
> 	damit er jederzeit mit sofortiger Wirkung aktualisierbar ist.
> 	(Dieses Verfahren scheint bei Let's Encrypt noch nicht
> 	implementiert zu sein [5]).
>
> 2. Unser heute realisierten Konzept von "leichtgewichtigen 
> Subdomains",
> bei denen es genügt, ein Verzeichnis anzulegen oder alle Subdomains 
> auf
> htdocs-ssl abgebildet werden können, um sie innerhalb eines CMS zu
> implementieren, steht der Let's Encrypt-Philosophie entgegen, da 
> Let's
> Encrypt die Auffassung vertritt, dass Wildcard-Zertfikate 
> problematisch
> und unnötig seien [6][7], obwohl sie im ACME-Standard [8] vorgesehen
> sind. Dieser Ansicht mag ich nicht folgen, da Multidomain-Zertifikate
> keinen Ersatz vollwertigen darstellen und spätestens dann an ihre
> Grenzen geraten, wenn häufig oder schnell Subdomains hinzukommen 
> sollen
> oder sehr viele Subdomains vorkommen. Einerseits soll der
> Beantragungsprozess ca. 20 bis 30 Sekunden benötigen, andererseits
> vergrößert jeder SubjectAltName das Zertifikat. Wer beispielsweise
> seinen Namespace aufteilt: <kunde>.example.com oder
> <keyword>.example.com sollte wissen, dass
>
> 	a) das nur für wenige Kunden oder Keywords per SubjectAltName
> 	implementierbar ist
>
> 	b) umgekehrt aber auch jeder Apache- oder Nginx-VHost Ressourcen
> 	verbraucht, d.h. auch die Anzahl der Zertifikate pro Server
> 	limitiert ist
>
> Für die Hostsharing-Nutzer hieße dies zunächst einmal, dass wir, wenn
> wir Let's Encrypt unterstützen wollen, ohne unser Subdomain-Konzept 
> über
> Bord werfen zu wollen, noch kreative Ideen brauchen. Unser Automat 
> wird
> jedenfalls die verwendeten Subdomains nicht erraten können.
>
> Ein Vorschlag lautet, Wildcard-Subdomains bei Hostsharing für neue 
> per
> Default zu deaktivieren. Dann müsste es aber sinnigerweise eine Liste
> von Subdomains in HSAdmin verwaltbar sein, also drei Optionen:
>
> DNS für example.com verwalten:
> (*) Wildcard für alle Subdomains *.example.com schalten
> ( ) keine Subdomains für example.com schalten
> ( ) folgende Subdomains für example.com schalten: <Liste>
>
> Der heutige Default "Wildcard" wäre mit Let's Encrypt dann nicht
> (vollautomatisiert) nutzbar.
>
>
> Grundsätzlich würde ich folgendes begrüßen:
>
> * Wir führen SNI jetzt - wie oben skizziert - ein.
>
> * Wir stellen die DNS-Verwaltung auf HSAdmin um, um die Infrastruktur 
> zu
> schaffen.
>
> * Wir schaffen eine Option, Keys und (Zwischen-)Zertifikate via 
> HSAdmin
> hochzuladen (write-only). (Implementieren könnte man sogar, dass 
> HSAdmin
> den Key und das CSR erzeugt.)
>
> In wenigen Monaten könnten wir das Vorgenannte umgesetzt haben und 
> dann
> die Lage neu beurteilen:
>
> * Wir hoffen, dass Let's Encrypt bis dahin DNS-Validierung 
> implementiert
> hat und doch noch Wildcard-Zertikate ausstellen wird.
>
>
> Meine persönliche Kritik an Let's Encrypt:
>
> Statt schlicht die Verwendung von Verschlüsselung zu fördern, legt 
> Let's
> Encrypt Anwendern - und das ist der Kritikpunkt - Steine in den Weg.
>
> 1) Nicht alle Serverdienste unterstützen SNI, HTTP-Server ja, andere
> sind mir nicht bekannt. Hostsharing könnte sein teueres(!)
> Wildcard-Zertfikat also nicht auf Multidomain-Zertifikate von Let's
> Encrypt umstellen, weil wir es auch für Mail-Dienste, FTP-SSL und 
> andere
> Services nutzen. Den Verweis auf DNSSEC und DANE halte ich persönlich
> für eine Ausrede, weil er CAs im klassischen Sinne - also auch Let's
> Encrypt - obsolet machen würde. DNSSEC und DANE implementieren eine
> Trust Chain über die DNS-Delegation, die Root-CAs entsprechen hier 
> den
> Root-Zonen.
>
> Insbesondere - oder verstehe ich etwas komplett falsch? - verweist 
> Let's
> Encrypt darauf, dass der ACME-Standard Wildcard-Zertifikate nicht
> unterstütze [7]. Ich verstehe aber den Standard so, dass es dem
> CA-Betreiber obliegt, zu entscheiden, ob er Wildcard-Zertfikate für
> *.example.com ausstellt, wenn er example.com erfolgreich validiert 
> hat [8].
>
> "It is up to the server's local policy to decide which names are
> acceptable in a certificate, given the authorizations that the server
> associates with the client's account key.  A server MAY consider a
> client authorized for a wildcard domain if it is authorized for the
> underlying domain name (without the "*" label)."
>
> Mit "server" ist hier der Server der CA gemeint, der der über die
> automatisierte Ausstellung des Zertfikats entscheidet.
>
> 2) Die kurze Zertifikatsgültigkeitsdauer erfordert Automatisierung.
> Automatisierung ist aber in vielen Fällen erst einmal ein Hindernis, 
> um
> nicht zu sagen, ein Show-Stopper. Beispiel: Eingebettete Geräte, z.B.
> unsere Remote Management-Karten oder auch Netzwerkgeräte wie Switches
> und Router mit Webinterface. Den Verweis auf den Aufbau einer eigenen 
> CA
> für diese Geräte halte ich nur eingeschränkt für akzeptabel, weil es
> nicht unerheblichen Aufwand bringt, eine eigene CA sicher zu 
> betreiben
> und deren Root-Zertifikat auf alle Endgeräte zu verteilen. Das 
> beginnt
> damit, dass man eigentlich ein HSM braucht.
>
> [1] https://letsencrypt.org/
> [2] https://de.wikipedia.org/wiki/Server_Name_Indication
> [3] https://letsencrypt.org/2015/11/09/why-90-days.html
> [4] https://letsencrypt.org/howitworks/technology/
> [5]
> 
> https://community.letsencrypt.org/t/shouldnt-verification-via-dns-record-be-a-priority/604/14
> [6]
> 
> https://community.letsencrypt.org/t/please-support-wildcard-certificates/258/71
> [7] 
> https://community.letsencrypt.org/t/support-wildcard-certificates/2917/6
> [8] https://tools.ietf.org/html/draft-ietf-acme-acme-01#section-6.6
>
> Beste Grüße
>
> Michael
>
> _______________________________________________
> Technik mailing list
> Technik at hostsharing.net
> https://lists.hostsharing.net/mailman/listinfo/technik



Mehr Informationen über die Mailingliste Technik

Hostsharing 3 Monate kostenlos und unverbindlich testen

Nutzen Sie und kostenloses Test- und Beratungsangebot.
Nehmen Sie jetzt Kontakt auf und lernen Sie den Hostsharing-Service kennen.

Jetzt Testsystem bestellen Mehr erfahren