SSL Probleme mit SNI über NGINX

Hallo!

Ich habe eine Domain von Apache auf NGINX umgestellt. DNS Einträge sind selbstverständlich geändert. In der IP-Gruppe von NGINX wurde auch der SSL-Support aktiviert.
Ich habe also die entsprechende Domain und Sub-Domains mit der neuen IP-Gruppe von NGINX versehen und diese Änderung greift auch.
Bis auf die Domain, auf die auch per HTTPS zugegriffen werden soll. Das Zertifikat wurde entsprechend gewählt und funktionierte unter Apache einwandfrei!

Nun erhalte ich beim Zugriff per Chrome oder Safari nur die Fehlermeldung:

Fehler 107 (net::ERR_SSL_PROTOCOL_ERROR): SSL-Protokollfehler

Die error.log gibt nichts her und in der access.log tauchen nur solche Einträge auf:

"\x16\x03\x01\x00?\x01\x00\x00?\x03\x02P??_n3s?????}`??o\x08??1?8@?\x06X?$?/?\x00\x00H?" 400 173 "-" "-"

Mache ich da was falsch?

(Die Dienste habe ich bereits neu gestartet...)

Gruß

Martin

Ich habe die Themen mal zusammengeführt.

Wir haben das eben getestet und das Problem reproduzieren können. Leider verhält sich NGINX nicht ganz so wie er es laut seiner eigenen Dokumentation sollte.
Kurz gesagt muss für die Verwendung von SNI immer noch ein "Default-Host" (mit eigenem SSL-Zertifikat) eingerichtet werden.
Als kurzfristigen Workaround machen Sie bitte folgendes:
- fügen Sie in die Datei /etc/nginx/sites-available/default nach den "Listen"-Anweisungen noch die Option "default" und beim Port 443-Eintrag noch "ssl" ein:

listen          192.168.141.199:80[B] default[/B];
listen          192.168.141.199:443[B] default ssl[/B];

- kopieren Sie aus der erstbesten vHost-Konfiguration mit SSL noch die SSL-Anweisungen heraus und fügen Sie diese in der "default"-Datei z.B. nach den listen-Anweidungen mit ein, z.B.:

ssl_protocols   SSLv3 TLSv1;
ssl_ciphers     AES128-SHA:AES256-SHA:RC4-SHA:DES-CBC3-SHA:RC4-MD5;
ssl_certificate /etc/ssl/certs/fe385bfc5d088e1c-combined.crt;
ssl_certificate_key     /etc/ssl/private/fe385bfc5d088e1c.key;

Danach sollte mit einem "/etc/init.d/nginx restart" erst mal alles funktionieren; die default-Datei wird aber bei jeder Änderung an IP-Einstellungen/IP-Gruppen überschrieben.
Ich mache gleich ein Ticket hierzu auf, wir werden das in den nächsten Tagen sauber lösen. Das wird voraussichtlich darauf hinauslaufen, dass LiveConfig bei SNI ein "eigenes" SSL-Zertifikat erzeugt und damit eine Standard-Seite anzeigt, die den Benutzer darüber informiert dass sein Browser kein SNI unterstützt...

Viele Grüße

-Klaus Keppler

Ebenso vielen Dank!

Wird in der nächsten Version - wie geplant - diese Konfiguration automatisch vorgenommen?

Guten Tag,

das Problem ist in der aktuellen Preview scheinbar nicht behoben!! Auf einem Testsystem wird kein SNI genutzt, dh. die IP ist exklusiv. SSL Zertifikat ist hinterlegt. Nur nach Anpassung der /etc/nginx/vhosts.d/default wie oben beschrieben, läuft das SSL Zertifikat.

Dh. im Endeffekt wird man über folgenden Sachverhalt stolpern:

Zitat

Danach sollte mit einem "/etc/init.d/nginx restart" erst mal alles funktionieren; die default-Datei wird aber bei jeder Änderung an IP-Einstellungen/IP-Gruppen überschrieben.

Hallo, ich stehe auch vor diesem Problem, wollt ihr das mal updaten ? Es wäre ja nicht als würde das Problem seit 1 Jahr bestehen ?!

Gibt es hier schon Neuigkeiten?

Da sich hier nichts tut, habe ich hier (zumindest für die Debian User) einen kleinen Patch, der den Workaround von Herrn Keppler implementiert.

(ve10601) echelon ~ $ diff -ruN /usr/lib/liveconfig/lua/nginx.lua*   
--- /usr/lib/liveconfig/lua/nginx.lua	2014-08-20 23:01:58.452847822 +0200
+++ /usr/lib/liveconfig/lua/nginx.lua.patched	2014-08-20 23:18:09.258017691 +0200
@@ -497,12 +497,12 @@
     -- SSL configuration
     if opts.interfaces ~= nil then
       for i=1, #opts.interfaces do
-        fh:write("\tlisten\t\t", opts.interfaces[i], ";\n")
+        fh:write("\tlisten\t\t", opts.interfaces[i], " default;\n")
       end
     end
     if opts.ssl_interfaces ~= nil then
       for i=1, #opts.ssl_interfaces do
-        fh:write("\tlisten\t\t", opts.ssl_interfaces[i], ";\n")
+        fh:write("\tlisten\t\t", opts.ssl_interfaces[i], " default ssl;\n")
       end
       fh:write("\tssl_prefer_server_ciphers on;\n")
       if opts.ssl_pci then
@@ -510,6 +510,8 @@
       else
         fh:write("\tssl_ciphers ", LC.liveconfig.DEFAULT_SSL_CIPHERS, ";\n")
       end
+      fh:write("\tssl_certificate /etc/ssl/certs/ssl-cert-snakeoil.pem;\n")
+      fh:write("\tssl_certificate_key /etc/ssl/private/ssl-cert-snakeoil.key;\n");
     end
 
     if v_major == 0 and (v_minor < 8 or (v_minor == 8 and v_patch < 21)) then

Oder als Kurzform:

$ wget -O- http://paste.tamcore.eu/20cbbb0ecf.txt | patch -p0

Sollte /etc/ssl/certs/ssl-cert-snakeoil.pem nicht existieren, muss das Paket ssl-cert installiert werden.

Jetz mal ernsthaft. Wäre es so schwer gewesen, obigen Workaround zusammen mit Version 1.7.4 auszurollen? Das Problem ist jetzt lang genug bekannt und trotzdem tut sich hier absolut nichts. Ist langsam echt nicht mehr feierlich..

Zitat von TamCore

Jetz mal ernsthaft. Wäre es so schwer gewesen, obigen Workaround zusammen mit Version 1.7.4 auszurollen? Das Problem ist jetzt lang genug bekannt und trotzdem tut sich hier absolut nichts. Ist langsam echt nicht mehr feierlich..

Ich frage mich schon länger warum der Workaround nicht eingebaut wird. Wäre schön, wenn es da endlich mal eine Lösung zu gäbe. Ich meine wir zahlen dafür schließlich monatlich Geld und da finde ich das man das dann auch erwarten kann.

Ja, finden wir auch sehr nervig.
Wir haben inzwischen mehrere Kunden die NGINX einsetzen und jedes mal muss man da bei Updates aufpassen.

Ich hatte dazu auch noch ein paar Fragen:
Ist es möglich, dass Ihr die Dateien in /usr/lib/liveconfig/lua als conffiles markiert (Debian Paket)? Dann wird man wenigstens vor dem überschreiben gewarnt. Alternativ, ist es möglich mit einer eigenen LUA File die originale nginx.lua zu überlagern?

Derzeitige conffiles:
/etc/cron.d/liveconfig
/etc/liveconfig/liveconfig.conf
/etc/liveconfig/liveconfig.key
/etc/liveconfig/mailquota.txt
/var/lib/liveconfig/liveconfig.db

Spontan würde ich sagen, dass Du mittels custom.lua die Funktion LC.web.nginx.configure überschreiben musst.