Neue SSL-Zertifikate

TCM schrieb:
Stichwort reverse proxy: Da kann ich HAProxy nur wärmstens empfehlen, falls der noch nicht bekannt ist.
Zum Vergrößern anklicken....
Vielleicht ab 1.7 kann er dann auch HTTP/2. Das war der Grund, für unser aktuelles Projekt HAProxy erstmal nicht einzusetzen - wir wollen HTTP/2 verwenden.

Sorry, diese Diskussion ist eigentlich Off-topic. Ich hör schon auf.
 
Kurzes Googlen sagt, HAProxy kann auch TLS terminieren und dann TCP roh weiterleiten, ohne irgendwas von HTTP/2 verstehen zu müssen. Könnte aber u.U. nicht ausreichend sein, stimmt.
 
Mit dem offiziellen Client in der Version 0.4 (noch nicht in den Ports) kam übrigens der "renew" Befehl hinzu. Der aktualisiert bald ablaufende Zertifikate (ich glaube alles was noch <= 30 Tage Laufzeit hat) so wie sie geholt wurden. Das macht die Sache alles schon recht bequem.

Einfach alles nach der gewünschten Methode holen und dann per cron nur noch "letsencrypt renew" ausführen. Das war vorher noch komplizierter.
 
Mit dem Teil habe ich abgeschlossen. Das ist so fett und will jeden Spezialfall abhandeln und sich um völlig unbeteiligte Sachen kümmern, das sollte man eigtl. nur einsetzen, wenn man wirklich keine Ahnung hat oder haben will. Nur ob das eine gute Voraussetzung ist, wenn es um Sicherheit geht, ist die andere Frage. Macht das Ding nicht sogar auch den HSTS-Header? Oder hat zumindest ne Option dafür?

Aus meiner Sicht hat man entweder genug Ahnung, um einen simplen Client, der das API bedient, in eine eigene Infrastruktur zu integrieren oder man ist bei einem Hoster, der eben das für einen macht. Auf lange Sicht kann so eine eierlegende Wollmilchsau wegen der notwendigen Komplexität, damit alles einfach zu bedienen ist, nur nach hinten losgehen.
 
-Nuke- schrieb:
Ja, ist ja schon gut, alle Let's Encrypt Client Nutzer sind dumm...
Zum Vergrößern anklicken....

Hat keiner behauptet. Ich hab ja extra geschrieben, dass man auch keine Ahnung haben wollen kann. Es gibt viele Bereiche, wo man sich der blissful ignorance hingeben kann und der Scheiß einfach laufen soll. Ich bemeckere nur, dass krypto-nahe Sachen nicht dazugehören sollten.
 
Und ob ich mir nun die Zertifikate über ein Python Skript oder ein Bash-Skript oder manuell hole, macht was für einen Unterschied? Alles macht genau das Gleiche.

Und wenn ich letsencrypt certonly --webroot=..., passiert genau das Gleiche als wenn ich letsencrypt.sh bla aufrufe.

Keiner zwingt dich letsencrypt-auto --apache aufzurufen, genauso zwingt dich keiner über diesen Client zu nutzen.

Aber alleine aus der Tatsache heraus, dass alle Tools genau das gleiche machen, solltest du mit der Aussage: "Ist was für Leute die keine Ahnung haben" mal eben ganz vorsichtig sein oder sie besser gleich lassen.
 
Da hat aber der LE client Zugriff auf private keys. Das sollte idealerweise getrennt sein. Der Teil, der mit den LE-Servern redet, sollte nur Zugriff auf CSRs haben. Auf private keys sollte _nur_ der Webserver Zugriff haben (und root halt).
 
@TCM: Also du würdest quasi noch eine dritte Instanz dazwischen schalten?

  • Webserver User mit private key und public key chain
  • Let's Encrypt User mit Account Key und CSR für ACME/Netzkommunikation mit LE-Server
  • Let's Encrypt User mit Private Domain Key um den CSR zu erstellen
Ich denke dass bei Let's Encrypt eben dieser Account Key das eigentliche große Thema ist und da kann auch der Web Server im besten Fall nicht drauf zugreifen. Durch das automatische regelmäßige austauschen sind kompromittierte Keys auch schneller wieder weg. Das halte ich für einen großen Gewinn.


Zum Thema "Alle Clients machen im Endeffekt das Selbe": Ja, vor allem, wenn man sich nur das ACME-Protokoll ansieht. Das Shell Script finde ich recht gut weil ich es ziemlich komfortabel finde und ich weniger Abhängigkeiten haben, also gar kein Python, was vielleicht für denen einen oder anderen interessant ist.

Auch denke ich, dass es gut ist, dass es minimalistischere simplere Implementierungen gibt, weil man damit Code Reviews erleichtertet. Sowas wie acme_tiny kann auch jemand ohne große Programmierkenntnisse zumindest grundsätzlich verstehen. Der offizielle Client ist ja mehr für das Projekt-Ziel, dass wirklich jeder seine Website auf HTTPS umstellt, quasi ohne Aufwand zu haben. Auch wenn ich da sowas wie Caddy fast netter finde für Leute, die eigentlich keine Admins sind.

Ja, ich weiß. Vielleicht keine gute Idee, das als nicht-Admin zu machen, aber die Vorstellung, dass jeder und jede, der oder die einen Shop betreiben will oder ein Blog, etc. betrieben will einen kompetenten Admin hat ist geht einfach an der gegewärtigen Realität vorbei und rein persönlich finde ich es ganz gut, wenn das ganze Web nicht nur aus Facebook, eBay, YouTube, Cloud und Co. besteht.

Ich habe auch die Hoffnung, dass Let's Encrypt und ACME sich in positive Richtung weiter entwickeln.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben