Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#1148 closed defect (invalid)

Respond to any domain\port is present on server and nginx config.

Reported by: ZeusF1@… Owned by:
Priority: minor Milestone:
Component: nginx-core Version: 1.10.x
Keywords: tls 443 80 any_domain Cc:
uname -a: Linux *** 3.10.0-327.36.3.el7.x86_64 #1 SMP Mon Oct 24 16:09:20 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

Linux *** 2.6.32-642.6.1.el6.x86_64 #1 SMP Wed Oct 5 00:36:12 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
nginx -V: nginx version: nginx/1.10.2

Description

Same issue found in google

http://superuser.com/questions/612560/why-a-listen-443-default-server-nginx-rule-override-already-configured-rule-ht

Easy way to reproduce:

  1. Create valid server_name on port 80 for domain1.com
  2. Create valid section to 443 port with valid certificate for domain2.com
  3. make curl https://domain1.com

Actual:
(51) SSL: certificate subject name 'domain2.com' does not match target host name 'domain1.com'
Random(first) domain picked with TLS cert and tryed to access site with it.

Expected:
Closed connection, or something, since not 443 default

server {
    listen 80;

    server_name domain1.com;
    root /home/domain1.com/;

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

    # certs sent to the client in SERVER HELLO are concatenated in ssl_certificate
    ssl_certificate /etc/letsencrypt/live/domain2.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/domain2.com/privkey.pem;
    ssl_session_timeout 1d;
    ssl_session_cache shared:SSL:50m;
    ssl_session_tickets off;


    server_name domain2.com;
    root /home/domain2/public;



    location ~ \.php$ {
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        fastcgi_pass unix:/var/run/php-fpm/test.sock;
        fastcgi_index index.php;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include fastcgi_params;
  }



    # HSTS (ngx_http_headers_module is required) (15768000 seconds = 6 months)
    add_header Strict-Transport-Security max-age=15768000;

    # OCSP Stapling ---
    # fetch OCSP records from URL in ssl_certificate and cache them
    ssl_stapling on;
    ssl_stapling_verify on;

    ## verify chain of trust of OCSP response using Root CA and Intermediate certs
    ssl_trusted_certificate /etc/letsencrypt/live/domain2.com/fullchain.pem;

    resolver 8.8.8.8;


}

Change History (3)

comment:1 by Maxim Dounin, 4 years ago

Resolution: invalid
Status: newclosed

Default server for a listening socket handles all the requests on the listening socket, see http://nginx.org/en/docs/http/request_processing.html.

in reply to:  1 ; comment:2 by ZeusF1@…, 4 years ago

Replying to mdounin:

Default server for a listening socket handles all the requests on the listening socket, see http://nginx.org/en/docs/http/request_processing.html.

Handle all request is ok.
But you need VALID TLS certs to answer on port 443, and if you are not have this section\config, nginx will just pick first - random, which I feel is wrong.

So nginx is responding invalid certificate(from another domain), for section, which should not have TLS certificate.

Browser check found mismatch, and you cant even do redirect from https to regular http, because certificate mismatch.

Or in your logic I should generate certificates for all server{} just to do redirect to http?

in reply to:  2 comment:3 by Valentin V. Bartenev, 4 years ago

Replying to ZeusF1@…:

But you need VALID TLS certs to answer on port 443, and if you are not have this section\config, nginx will just pick first - random, which I feel is wrong.

It's not random. It's what you have configured. There's always a default server block for each listening socket.

Browser check found mismatch, and you cant even do redirect from https to regular http, because certificate mismatch.
Or in your logic I should generate certificates for all server{} just to do redirect to http?

That's how HTTPS works. In order to do any HTTP redirect you need a request. Clients to be able to send requests have to finish TLS handshake first. That's it.

See also: #195.

Note: See TracTickets for help on using tickets.