[Technik] Let's Encrypt fuer Hostsharing

Michael Hierweck michael.hierweck at hostsharing.net
Sa Nov 14 18:40:20 CET 2015


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



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