Ich erinnere mich an die Diskussion über das Spielen unter Linux. Gerade das Video gesehen und ich war echt begeistert,wie weit es schon gekommen ist:
Wie kann man sich den Typen denn freiwillig geben? Ist sein Server-Raum noch nicht abgefackelt?
Ich mag Linus. Wenn man seinen Hass auf YouTube Influencer zur Seite schiebt, hat man sehr unterhaltsame Minuten. Oft ist es aber eher sicheres Auftreten als wirklicher Skill. 
Wie kann man sich den Typen denn freiwillig geben? Ist sein Server-Raum noch nicht abgefackelt?
Warum sollte der abfackeln? Er hat doch extra in einem Video gezeigt das sein "Dämm-Material" nicht brennbar ist, war glaub sein Aprilscherz 
Finde ihn ansonsten auch ganz unterhaltsam.
Hast Du ein Smartphone um die Fire TV App zu installieren? Wenn ich mich richtig erinnere konnte man dort Copy&Paste vom Passwortmanager machen.
Hast recht, das geht ja auch...
Aber ansonsten hat YouTube das auch ganz gut gelöst. Zum Koppeln mit dem Fernseher muss man in der App nur einen 8 (?) Zeichen Code aus Buchstaben eingeben und dann war's das. Möchte man sich mit dem Konto selbst anmelden, bekommt man auch so einen Code und kann sich auf youtube.com/activate mitsamt Code und Konto anmelden und am firetv selber muss man gar nichts machen!
Warum sollte der abfackeln? Er hat doch extra in einem Video gezeigt das sein "Dämm-Material" nicht brennbar ist, war glaub sein Aprilscherz
Weniger Luftvolumen + keine Wärmebrücke über die Wände + Luftauslass wurde reduziert = das könnten Server nicht so dolle finden. Warum rauchen dem ständig nochmal die NAS / SAN Systeme ab? Was erwartet man denn da, wenn der Raum ganze 2m³ Luft hat?
Die einzigen nützlichen Videos kommen von seinen Mitarbeitern. Ansonsten muss ich bei den Videos immer nur den Kopf schütteln.
Was ich auch nicht verstehe, wenn er einen Computer baut, warum er ständig alle Teile 4free bekommt.
Ich experimentiere gerade zum ersten Mal mit certbot. Es soll bei diesem Szenario absichtlich kein alternativer Client genutzt werden.
Sehe ich das richtig, dass man bei gleichzeitiger Nutzung von RSA und ECDSA Zertifikaten noch immer möglichst viel selbst erledigen muss, wenn sich der Publickey nicht andauernd ändern soll? (Stichwort TLSA-Record)
D.h. den Key und CSR für beide Varianten erstellen und nachher das Zertifikat mit certbot certonly anfordern. Um die Verlängerung bzw. den Speicherort kümmert man sich besser selbst mit einem kleinen Script.
Oder habe ich irgendeinen supertollen modernen Weg übersehen? Genutzt wird übrigens Debian Buster, die eingesetzten Versionen sollten somit aktuell sein.
Edit, wenn man schon mal am Testen ist: Mit OpenSSL 1.1.1 aus Experimental klappt dann auch schon TLSv1.3 über Nginx 
tls13-summary.png tls13-configuration.png
(Let's Encrypt Staging; deshalb nicht vertrauenswürdig)
bei gleichzeitiger Nutzung von RSA und ECDSA Zertifikaten
was meinst Du damit, daß der Browser freie Wahl hat, welches er nimmt? und vor allem wie würdest Du das in Apache einbauen?
Weniger Luftvolumen + keine Wärmebrücke über die Wände + Luftauslass wurde reduziert = das könnten Server nicht so dolle finden. Warum rauchen dem ständig nochmal die NAS / SAN Systeme ab? Was erwartet man denn da, wenn der Raum ganze 2m³ Luft hat?
Die einzigen nützlichen Videos kommen von seinen Mitarbeitern. Ansonsten muss ich bei den Videos immer nur den Kopf schütteln.
Was ich auch nicht verstehe, wenn er einen Computer baut, warum er ständig alle Teile 4free bekommt.
Es gab tatsächlich noch ein paar Anpassungen an dem Raum, weil sie selber festgestellt haben, dass es zu wenig Luft ist
[U]nd vor allem wie würdest Du das in Apache einbauen?
Beispielsweise so (kann man bspw. über hardenize.com bequem verifizieren):
# [...]
SSLCertificateKeyFile /mirrored/gluster/mounts/shared/certificates/letsencrypt/dns-live/pz_rsa_key.pem
SSLCertificateFile /mirrored/gluster/mounts/shared/certificates/letsencrypt/dns-live/pz_rsa_cert.pem
SSLCertificateKeyFile /mirrored/gluster/mounts/shared/certificates/letsencrypt/dns-live/pz_ecdsa_key.pem
SSLCertificateFile /mirrored/gluster/mounts/shared/certificates/letsencrypt/dns-live/pz_ecdsa_cert.pem
SSLCertificateChainFile /mirrored/gluster/mounts/shared/certificates/letsencrypt/dns-live/letsencrypt_chain.pem
# [...]Sehe ich das richtig, dass man bei gleichzeitiger Nutzung von RSA und ECDSA Zertifikaten noch immer möglichst viel selbst erledigen muss, wenn sich der Publickey nicht andauernd ändern soll? (Stichwort TLSA-Record)
D.h. den Key und CSR für beide Varianten erstellen und nachher das Zertifikat mit certbot certonly anfordern. Um die Verlängerung bzw. den Speicherort kümmert man sich besser selbst mit einem kleinen Script.
Oder habe ich irgendeinen supertollen modernen Weg übersehen? Genutzt wird übrigens Debian Buster, die eingesetzten Versionen sollten somit aktuell sein.
Bei ECDSA Zertifikaten, nein (nichts übersehen). Bei RSA Zertifikaten kannst du die Option --reuse-key nutzten, um zu verhindern, dass sich der Key dauernd ändert.
Ich hoffe ja, dass es die OpenSSL 1.1.1. noch nach Buster schafft.
Zertifikate... Erwähnt doch mal bei den managed private Server, dass man dort überhaupt und mehr als 1 LetsEncrypt Zertifikat nutzen darf. 
Edit, wenn man schon mal am Testen ist: Mit OpenSSL 1.1.1 aus Experimental klappt dann auch schon TLSv1.3 über Nginx
Mal so ne dämliche Frage, muss ich nginx neu kompilieren, wenn ich openssl 1.1.1 installiert habe? Manche Seiten sagen ja, manche nein.
QuoteDie Standardisierung des Protokolls TLS 1.3 ist schon so weit fortgeschritten, dass immer mehr Software die Vorabversionen des kommenden Standards unterstützt. Dazu gehört auch der freie Webserver Nginx in der nun verfügbaren Version 1.13. Der Nachteil daran ist zurzeit aber noch, dass OpenSSL TLS 1.3 offiziell erst in Version 1.1.1 unterstützen wird, die noch nicht erschienen ist.
Nginx-Nutzer, die TLS 1.3 testen möchten, müssen also gegen eine instabile Version von OpenSSL kompilieren. Darüber hinaus ist darauf zu achten, die Draft-18-Version von TLS 1.3 in OpenSSL zu verwenden, da etwa die Browser Firefox und Chrome bisher nur diese Version unterstützen.
Quelle: https://www.golem.de/news/webs…-support-1704-127503.html
denke mal Golem ist vertrauenswürdiger als manche Blogs
ob TLS1.3 dann so kommt und vor allem auch Verbreitung findet, ist aber fragwürdig;
weil was die HTTP WG bei der IETF schon pfuscht, dafür reicht kein Bärenfell;
da waren allen ernstes Diskussionen,
- die Geolocation des Clients
- die Ausstattung (Auflsg. und Bits/Pixel) des Clients
in den HTTP-Request-Header zu packen ...
Mal so ne dämliche Frage, muss ich nginx neu kompilieren, wenn ich openssl 1.1.1 installiert habe? Manche Seiten sagen ja, manche nein.
Unter Buster nicht. Einfach OpenSSL (und libssl1.1) aus Experimental installieren, TLS1.3 in ssl_protocols aufnehmen und das Ding neustarten. Das ist alles, danach läuft es. Es ist halt experimentell, nichts für den Produktiveinsatz.
Vorsicht: OpenSSL 1.1 unterstützt in Debian derzeit per Default nur noch TLS >= 1.2! Wenn Du ältere Versionen brauchst, musst Du Deine openssl.cnf anpassen: https://lists.debian.org/debia…nce/2018/05/msg00000.html
Dual RSA/ECDSA funktioniert übrigens auch bei Nginx einwandfrei. Dort reicht es, wenn man die cert/key Konfiguration fürs zweite Schlüssel/Chain Paar dupliziert.
florian2833z Bei einem stabilen Debian Release würde ich lieber nicht an grundlegenden Dingen wie OpenSSL herumpfuschen. Das kann, fast wie mit der libc, schnell ins Auge gehen.
Die genauen Parameter habe ich gerade nicht. Schau mal in die Source-Pakete bei Debian und vergleiche den debian-Ordner zwischen den Versionen. Was OpenSSL angeht, stecke ich zu wenig drinnen, um das beurteilen zu können.
ob TLS1.3 dann so kommt und vor allem auch Verbreitung findet, ist aber fragwürdig;
Da TLS1.3 aktuell Geschwindigkeitsvorteile bietet, wird das schon Verbreitung finden. Sind ja alle Performancegeil heutzutage
Zurück zu Testing – bye, bye Experimental 
# apt-get install openssl=1.1.0h-4 libssl1.1=1.1.0h-4
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen.... Fertig
Die folgenden Pakete werden durch eine ÄLTERE VERSION ERSETZT (Downgrade):
libssl1.1 openssl
0 aktualisiert, 0 neu installiert, 2 durch eine ältere Version ersetzt, 0 zu entfernen und 0 nicht aktualisiert.Ich hoffe, dass OpenSSL 1.1.1 bald offiziell erscheint und dann schnell den Weg nach Buster findet. Wäre schade, wenn es erst in Bullseye enthalten wäre.
