Schlagwort: nginx

nginx mit TLS 1.3 und der alert number 70

kero Schreib einen Kommentar

Da habe ich nun ein bisschen für gebraucht, bis TLS 1.3 endlich auf einer bestimmten Maschine lief. Ich nutze nginx als Reverse Proxy und terminiere dabei ssl dort. Es werden die Repositories von nginx genutzt. Aktuell ist dort zur Zeit Version 1.19.10 von nginx. Das System ist ein Ubuntu 18.04. Wollte ich nun für eine bestimmte Seite TLS 1.3 aktivieren, kam beim Test immer nur folgendes:

$ openssl s_client -connect dieseitemittls1_3.de:443 -tls1_3
CONNECTED(00000005)
140426905970496:error:1409442E:SSL routines:ssl3_read_bytes:tlsv1 alert protocol version:../ssl/record/rec_layer_s3.c:1528:SSL alert number 70
…

OpenSSL 1.1.1 wird genutzt und die Nginx Version kann auch TLS 1.3.

Funktioniert hat es letztendlich nachdem ich für die default site auch TLS 1.3 aktiviert habe. Wobei diese eigentlich nichts mit der anderen Seite zu tun haben sollte. Durch das aktivieren in der default site ist nun TLS 1.3 für alle Seiten aktiviert, auch wenn dort nur TLS 1.2 eingetragen ist.

Ein bisschen würde mich schon interessieren, ob das Verhalten auch auftritt, wenn man die Ubuntu Repositories für nginx nutzt.

Drauf gekommen bin ich via eines Beitrags bei askubuntu.

nginx

kero Schreib einen Kommentar

Ich bin ja neulich von pound zu nginx gewechselt. Erst war ich natuerlich skeptisch, weil pound sehr einfach in der Konfiguration ist und nginx doch eher in die Richtung eigener Webserver geht und dementsprechend die Konfiguration etwas mehr Zeit erfordert hat. Nginx laeuft nun seit gut einem Monat und ich bin sehr zufrieden. Die Last ist gering und die Performance sehr gut. Bei ein paar 100000 Requests am Tag, eine gute Leistung. Ach ja, vor pound hatten wir eine LB Appliance (keine F5), im Vergleich dazu faehrt man meiner Meinung nach mit Nginx besser, da man viel flexibler in der Konfiguration ist.

links:
nagios plugin fuer nginx
cacti zeugs fuer nginx

pound -> nginx

kero Ein Kommentar

Umzug von pound nach nginx. Nginx ist schon ein bisschen…maechtiger. Aber nginx braucht laenger um den Ausfall eines backends zu bemerken (trotz proxy_connect_timeout 60, falls das der Alive Option von pound gleichkommt), bzw. bei komplett Ausfall der backends eine Fehlerseite zu liefern, das ging bei pound besser. Die Tage mal die Parameter genauer anschauen. Das access.log schaltet man uebrigens einfach mit access_log off ab.