SSL Probleme mit SNI über NGINX

  • Guten Tag,


    ich habe nun einen Kunden über den NGINX Webserver mit SSL über SNI laufen. Doch leider kommt dann keine Webseite beim aufruf per HTTPS. Wenn ich dem Kunden eine Exklusive IP auf dem NGINX zuweise geht es alles.


    Laut --DIAG ist der NGINX aber mit SNI Support compiliert.


    Wo kann noch der Fehler liegen ?


    Gruß


    Björn Strausmann

  • 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:

    Code
    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:

    Code
    "\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:

    Code
    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.:

    Code
    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

  • 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...


    Bitte halten Sie es offen, welche Domain und Zertifikat hier für den Fallback verwendet werden.


    Gruß


    Björn Strausmann

  • Hallo Herr Keppler,


    ich möchte dieses wichtige Thema hiermit nochmal hervor heben. Scheinbar wurde dieses Problem noch immer nicht behoben und auch kein Ticket, wie damals von Ihnen gesagt, erstellt.


    Ich möchte Sie bitten dies in den nächsten Previews mit aufzunehmen.

  • 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.

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



    Oder als Kurzform:

    Code
    $ 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..

  • 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

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!