4 comments on “Buchclub: Handbuch für Fachinformatiker (Teil 6: Webserver und -anwendungen) – Anwendungsentwickler-Podcast #66”

1. Robin `ypid` Schneider sagt:

   12. Juli 2016 um 16:41:19 Uhr

   Hi Stefan,

   Let’s Encrypt ist ja nicht gerade ungeschoren davon gekommen in Deinem Podcast 😉
   Kannst du das noch ein bisschen ausführen, warum das kein „vernünftiges SSL-Zertifikat“ (bei Minute 16) ist?
   Geht es dir darum, dass man bei Let’s Encrypt eventuell nicht mehr lernt, wie das mit CSR und formate Konvertieren und ablaufenden Zertifikaten so ist? SSL ist übrigens eine alte Bezeichnung. TLS ist der Nachfolger.

   Für das Thema Webserver konfigurieren habe ich noch eine kleine Vortagsempfehlung: Zeitgemäße Webserver-Konfiguration — Ein Serviervorschlag

   Danke übrigens für die Hosting Empfehlung. Ich bin selbst gerade etwas am suchen.

   Gruß Robin

2. Stefan Macke sagt:

   13. Juli 2016 um 6:54:34 Uhr

   Hallo Robin,

   ich habe nichts gegen let’s encrypt und setze es auch selbst ein. Es ist nur nervig, dass die Laufzeit der Zertifikate so kurz ist. Und irgendwie habe ich immer noch Bedenken, dass sie nicht überall akzeptiert werden. Aber das ist wohl unbegründet 🙂

   SSL/TLS kenne ich. Ist nur die alte Gewohnheit…

   Das Video werde ich mir mal anschauen. Ich suche immer gute Tutorials für meine Studenten. Danke!

   Viele Grüße!
   Stefan

3. Robin `ypid` Schneider sagt:

   13. Juli 2016 um 12:38:28 Uhr

   Hallo Stefan,

   die Gültigkeit eines Zertifikats ist so eine Sache.

   Pro (kurze Gültigkeit):

   Weniger Probleme mit dem zurückziehen von Zertifikaten. Beispiel certificate revocation list (CRL) und Heartbleed. Aber das kann man mit OCSP und OCSP stapling in den Griff bekommen.
   Erhöhte Sicherheit. Kontrolle über den privaten Schlüssel wird öfter geprüft.
   Admins werden zur Automatisierung erzogen 😉

   Contra (kurze Gültigkeit):

   Das einzige Problem was ich hier sehe ist bei embedded systems. Denn Falle hatte ich vor kurzem mit einer alten IP-Kamera. Die kann (noch) kein ACME. Da müsste man das Zertifikat also entweder alle 90 Tage manuell erneuern, sich ein Skript dafür schreiben oder ein Zertifikat mit längerer Gültigkeit beschaffen. Aber bei Servern über die man die Kontrolle hat spielt das keine Rolle. Hierfür gibt es genug gute Möglichkeiten, die Zertifikats Erneuerung zu automatisieren (ich arbeite selbst an so einer Möglichkeit mit Ansible, siehe debops.pki).

   „Und irgendwie habe ich immer noch Bedenken, dass sie nicht überall akzeptiert werden.“

   Meines Wissens wird es von jedem Endgerät anerkannt das halbwegs vernünftige Krypto unterstützt. Ich meine mich zu erinnern, dass sogar für Windows XP SP3 noch Anstrengungen unternommen wurden und es jetzt selbst da noch funktioniert (falls das noch jemand benutzt → keine gute Idee).

   Zum Vortag: Gerne geschehen 🙂

   Gruß Robin

4. Stefan Macke sagt:

   13. Juli 2016 um 19:15:11 Uhr

   Hallo Robin,

   schöne Diskussion der Vor- und Nachteile! Danke dafür.

   Die Automatisierung sollte für keinen halbwegs kompetenten Admin ein Problem sein. Und wenn sogar Uraltsysteme damit laufen, nehme ich meine Bedenken hiermit zurück 🙂

   Viele Grüße!
   Stefan

    This will be displayed in a monospaced font. The first four 
    spaces will be stripped off, but all other whitespace
    will be preserved.
    
    Markdown is turned off in code blocks:
     [This is not a link](http://example.com)

Here is some inline `code`.