☰

Nginx und https - Die Angabe einer IP-Adresse als Servername ergibt die richtige Website, aber das falsche Zertifikat

tag-icon • tag-icon nginx ssl https sni
Nginx und https - Die Angabe einer IP-Adresse als Servername ergibt die richtige Website, aber das falsche Zertifikat

Ich möchte diese URL ausführen:https://192.168.1.254und erhalte eine Website mit dem richtigen Inhalt und Zertifikat in der Adressleiste. Ich erhalte die Website, aber in der Adressleiste wird ein ungültiges Zertifikat angezeigt, da das Zertifikat aus einem anderen Serverblock stammt: dem Standardserverblock000-default.conf.

Kann mir bitte jemand dieses Verhalten erklären?

Mein Client-Browser ist Google Chrome Version 87.0.4280.88 (Offizieller Build) (64-Bit)

Mein Nginx-Server ist:

root@OpenWrt:/etc/nginx/conf.d# nginx -V
nginx version: nginx/1.19.4 (x86_64-pc-linux-gnu)
built with OpenSSL 1.1.1h  22 Sep 2020
TLS SNI support enabled

Ich denke, das Problem hängt damit zusammen, dass SNI anscheinend nicht zulässt,a Literale IPv4- und IPv6-Adressen als „HostName“. Aber ist das wirklich der Fall?

Ich habe einen Standardserverblock000-default.confso was:

server {
    server_name _;
    listen 80 default_server;
    listen 443 ssl default_server;

    ## To also support IPv6, uncomment this block
    # listen [::]:80 default_server;
    # listen [::]:443 ssl default_server;

    ssl_certificate '/etc/nginx/conf.d/_lan.crt';
    ssl_certificate_key '/etc/nginx/conf.d/_lan.key';
    return 404; # or whatever
}

Und ein weiterer Server namens luci-http.conf wie folgt:

server {
        listen 80;
        listen [::]:80;
        server_name openwrt.lan 192.168.1.254;
        # access_log /proc/self/fd/1 openwrt; # use logd (init forwards stdout).
        include conf.d/*.locations;
}

Wenn ichhttp://192.168.1.254in der Adressleiste wird mir die richtige Webseite angezeigt.

Ich habe auch diesen https-Server: luci-https.conf

server {
        listen 443 ssl;
        listen [::]:443 ssl;

        server_name openwrt.lan 192.168.1.254;
        #include '/var/lib/nginx/lan_ssl.listen.default';
        ssl_certificate '/etc/nginx/conf.d/_lan.crt';
        ssl_certificate_key '/etc/nginx/conf.d/_lan.key';
        ssl_session_cache 'shared:SSL:32k';
        ssl_session_timeout '64m';
        # access_log /proc/self/fd/1 openwrt; # use logd (init forwards stdout).
        include conf.d/*.locations;
}

Wenn ichhttps://192.168.1.254in der Adressleiste wird mir die richtige Webseite und das Zertifikat angezeigt_lan.crt. Wie Sie sehen, habe ich in diesem und im Standardserverblock dasselbe Zertifikat/Schlüssel-Paar.

Wenn ich jedoch diese IP-Adresse als Servername entferne ausluci-https.confund fügen Sie es als Servernamen hinzu in:meinesite.lan.confIch sehe nicht dasselbe Verhalten.

server {
        listen 443 ssl;
        listen [::]:443 ssl;
        #listen 192.168.1.254 ssl;
        #include '/var/lib/nginx/lan_ssl.listen';

        server_name mysite.lan www.mysite.lan fun.mysite.lan 192.168.1.254;

        root /www/mysite;
        index index.html index.htm index.nginx-debian.html;

        ssl_certificate '/etc/nginx/conf.d/mysite.lan.crt';
        ssl_certificate_key '/etc/nginx/conf.d/mysite.lan.key';
        ssl_session_cache 'shared:SSL:32k';
        ssl_session_timeout '64m';

        location / {
                try_files $uri $uri/ =404;
        }

        access_log /var/log/nginx/mysite.lan.access.log;
        error_log /var/log/nginx/mysite.lan.error.log;
}

Wenn ich nunhttps://192.168.1.254in der Adressleiste wird mir die richtige Webseite angezeigt, aber wieder das Zertifikat in_lan.crtnicht das Zertifikat:meinesite.lan.crtausmeinesite.lan.confwie erwartet.

Wenn ich ...

ssl_certificate '/etc/nginx/conf.d/mysite.lan.crt';
ssl_certificate_key '/etc/nginx/conf.d/mysite.lan.key';

im Standardserverblock000-default.confdann bekomme ich stattdessen dieses Zertifikat, wenn ichhttps://192.168.1.254in der Adressleiste des Browsers, ob 192.168.1.254 als Servername angegeben ist inluci-https.confodermeinesite.lan.conf.

Es scheint also, dass SNI mit einem „Hostnamen“ übereinstimmt, der eine IP-Adresse ist, aber das Zertifikat aus dem Standardserverblock nimmt. Warum ist das so?

Antwort1

... SNI lässt offenbar keine wörtlichen IPv4- und IPv6-Adressen als „HostName“ zu. Aber ist das wirklich der Fall?

Die Idee hinter SNI ist, zwischen mehreren Domänen auf derselben IP-Adresse zu unterscheiden. Insofern macht die Verwendung von SNI mit einer IP-Adresse keinen wirklichen Sinn. Daher ist es auch auf tatsächliche Hostnamen beschränkt. Zitat ausRFC 6066:

"HostName" enthält den vollqualifiziertenDNS-Hostnamedes Servers, wie vom Client verstanden. ... Wörtliche IPv4- und IPv6-Adressen sind in „HostName“ nicht zulässig.

    server_name mysite.lan www.mysite.lan fun.mysite.lan 192.168.1.254;

...
Es scheint also, dass SNI mit einem „Hostnamen“ übereinstimmt, der eine IP-Adresse ist, aber es nimmt das Zertifikat aus dem Standardserverblock.

Da SNI nur für tatsächliche Hostnamen verwendet wird, gibt es im TLS-Handshake kein SNI und daher wird die Standard-HTTPS-Konfiguration verwendet. Innerhalb des HTTPS gibt es jedoch das HTTP-Protokoll, das den HostHeader enthält. Da der HostHeader die IP-Adresse angibt (weil dies bei der URL der Fall ist), wird er mit diesem spezifischen virtuellen Host übereinstimmen. Daher: falsches Zertifikat, richtiger Inhalt.

verwandte Informationen