staging.inyokaproject.org

Ein Hoch auf das Webteam! Ich finde super, wie ihr den HTTPS-Weg beschreitet.

Sehr schön. Gibts auch Doku dazu?

@2: Was verstehst du unter Doku dazu?

Wir haben für die Server eine gewisse Dokumentation, und noch mehr nützliche Informationen im ansible falls das gemeint war 😉

mfg Stefan Betz

Ich finde es gut das Sicherheit für Euch kein Fremdwort ist !

@3: Naja werden die Certs automatisch erneuert oder manuell. Einfach mehr Infos.

Oder gibt es sowas schon für die "Öffentlichkeit"?

@5: Die Zertifikate werden von Icinga auf Aktualität geprüft, und später auch automatisch aktualisiert. Gegenwärtig machen wir das noch manuell bis wir ausreichend Erfahrung im Umgang mit Letsencrypt haben.

mfg Stefan Betz

@6: Alles klar. Danke

Der Artikel liest sich gut. Danke für eure Arbeit.

Als ich euren Beitrag gelesen habe fiel mir wieder auf, dass das ja auch auf meiner todo-Liste steht. Schon als Anfang Dezember Lets' Encrypt in Public Beta überging, wurde es drauf gesetzt. Also war es Samstag abend auch bei mir soweit. Auf einem Cubietruck mit Ubuntu-Core läuft eine owncloud schon seit längerem über SSL. Das selbsterstellte Zertifikat ist schon nervig. Aber immer noch besser als über http.

Lets' Encrypt 🇬🇧 finde ich einen guten Anfang und das Einbinden ging sehr schnell und unkompliziert. Der große Haufen namhafter Sponsoren zeigt, dass daran geglaubt wird. Die sollen nur so weiter machen. Bin mal gespannt, was noch aus der Zertifikatlaufzeit wird.

<Sarkasmus>Übrigens haben die sich ihr eigenes SSL-Zertifikat bei IdentTrust gemacht. Wohl kein Vertrauen in die eigene Arbeit 😊 </Sarkasmus>

Schönen Sonntag allen.

<OT> Außerdem sind alle herzlich zu den Chemnitzer Linuxtagen 🇩🇪 (19. und 20. März 2016) am Stand von der Ubuntu-Community - ubuntuusers.de willkommen. Es gibt zwar bei uns nichts zu gewinnen, aber ein feuchter Händedruck sei jedem gegönnt. 👍 </OT>

Ich habe meine Domains letztens auch auf Let's Encrypt umgestellt, und das verlief wirklich (fast) reibungslos. Ich hatte mir überlegt einen Wikiartikel dazu zu schreiben, aber finde momentan einfach die Zeit dafür nicht. Hat das Webteam die Doku so geschrieben, dass man diese ohne zu viel Aufwand in einen Wikiartikel übernehmen kann? Das würde einiges an Erstarbeit ersparen.

Fefe hat hier auch eine Meinung 😉

Inwieweit hat er hier Recht oder Unrecht?

@10: Fefe hat absolut unrecht. Der Python Client ist zwar der Standard Client - aber das Protokoll ist absolut offen - inzwischen gibt es unzählige Clients in unzähligen Sprachen die ein Zertifikat anfordern können - sogar ein Bash Script kann das. Wenn er den Python CLient nicht nutzen will muss er das ja nicht tun...

@9: Damit können wir nicht dienen. Eine neue Domain ist z.B. nur das ändern einer Variable und der Aufruf eines Befehls, den Rest macht ansible & Co automatisiert. Ist also schon sehr spezifisch von uns und keine allgemeine Dokumentation die Wiki tauglich wäre für extern.

mfg Stefan Betz

@11: Danke

@10, @11:

„Absolut unrecht“ ist höchstens absolut falsch…

Zum Thema (konstruktives, ehrlich): Das Problem das Fefe hat, und das auch ich sehe, ist, dass hier ein Python-Skript welches noch nicht annähernd ausgereift ist mit vollem Root-Zugriff an deinem Server herumspielt. Dabei werden, wenn man das Skript mit allen verfügbaren Optionen nutzt, automatisch Konfigurationsdateien editiert und Server neu gestartet. Ich seh da im Code auf die Schnelle auch nicht, dass da mal für die weniger brisanten Sachen die Privilegien gedroppt werden (gut, kann mich auch irren…), sondern das läuft anscheinend komplett mit Root-Rechten durch.

Anders formuliert: Im Moment würde ich das auf keinem produktiven System verwenden.

Klar, es gibt andere Clients, es gibt sogar dutzende Implementationen die wesentlich schlanker sind, keine Root-Rechte benötigen und auch nicht dazu in der Lage sind an Apache oder nginx herumzuspielen.

Aber das sind dann eben Drittanbieter und nicht der offizielle Let's Encrypt Client. Und da liegt das Problem. Der offizielle Client sollte schlank sein, ohne Root-Rechte auskommen und auch sonst, genauso wie jeder andere Prozess, möglichst abgeschottet laufen. Auch das mit der Verifikation ist nicht so ganz in Ordnung (die könnte man doch auch auf einem Port >1024 durchführen, dann bräuchte man auch keine Root-Rechte, zumal der eigentliche Webserver in der Zwischenzeit weiterlaufen könnte und erst dann neugestartet werden müsste, wenn das neue Zertifikat vorhanden ist…).

Ich hoffe das ist soweit verständlich. Dass Fefe (auch in meinen Augen) etwas übertreibt sei mal dahingestellt. Die Kritik ist trotzdem berechtigt.

@14: Verifikation über einen >1024 Port wäre fatal, denn jeder mit Shellzugang könnte so einfach ein Cert für die dort gerouteten Domains klicken. Das man Port 80 braucht ist also schon vollkommen richtig und erforderlich.

mfg Stefan Betz

@15: Stimmt, da war was ☺

Auf GitHub ist dazu auch irgendwo ein Issue, so wie es aussieht will man langfristig einen eigenen Port (<1024 😬 ) hierfür reservieren.

@10: Mit dem Kommentar zum Client hat er sicher recht. Deshalb muss aber das Konzept insgesamt nicht Mist sein...

Mittlerweile hat er auch selber umgestellt. http://blog.fefe.de/?ts=a88afde2

HSTS finde ich gut 👍

@16: Das wäre der hier: https://github.com/letsencrypt/acme-spec/issues/33