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
Nutzen Sie und kostenloses Test- und Beratungsangebot.
Nehmen Sie jetzt Kontakt auf und lernen Sie den Hostsharing-Service kennen.