Y
Y
Yan Vetrov2019-08-02 00:45:22
Nginx
Yan Vetrov, 2019-08-02 00:45:22

The site works on the HTTPS version of the IP. How to fix?

I'm not strong in NGINX, I have to figure it out myself. I had a problem, tried to restrict access by IP to the site using:

server {
listen 80;
server_name _;
return 444;
}

However, I found that when you open the HTTPS version of the site - you can access the site by IP. What to do? Here is my config:
server {
   root /var/www/birppl.ru/html;
   index index.html index.htm index.nginx-debian.html;
   server_name birppl.ru www.birppl.ru;
   location / {
   proxy_pass http://localhost:9000;
   proxy_http_version 1.1;
   proxy_set_header Upgrade $http_upgrade;
   proxy_set_header Connection 'upgrade';
   proxy_set_header Host $host;
   proxy_cache_bypass $http_upgrade;
}

    listen [::]:443 ssl ipv6only=on; # managed by Certbot
    listen 443 ssl http2; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/birppl.ru/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/birppl.ru/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

}

server {
     if ($host = birppl.ru) {
         return 301 https://$host$request_uri;
     } # managed by Certbot

     listen 80; 
     listen [::]:80; 
     server_name birppl.ru www.birppl.ru;
     return 404; # managed by Certbot
}

Answer the question

In order to leave comments, you need to log in

1 answer(s)
V
Viktor Taran, 2019-08-02
@id_pripyat

Gentlemen, do not invent a bicycle
Work HTTPS is fundamentally different from HTTP
When accessing http, you first get the site name from the server's response, based on this name, the config is substituted.
BUT with HTTPS, you first get the keys, and only after that you multiply to get at least a byte of information from the channel.
As a consequence of this, there are two postulates:
1. If you have at least one site with https, it appears automatically for all the others, whether you like it or not, since the config parsing mechanism comes after the channel is established, this is fundamental!
So when accessing by IP, you will get the https keys anyway, since this is a stupid daemon on the port.
2. If there is no key pair for this particular domain, in particular, IP will be considered as a domain that does not have explicit keys for itself. THEN, from hopelessness, the web server takes the NEAREST keys sorting them by name, that is, as a rule, it is 000-default.conf
In which you have default keys, maybe even self-signed ones, BUT only after that you may receive an http reffer.
well, all that remains is to lead an unnecessary comrade into a dead end
, for example, like this.
server {

listen 443 ssl;
       server_name default_server ;
       ssl_certificate        /etc/ssl/certs/ssl-cert-snakeoil.pem;
       ssl_certificate_key    /etc/ssl/private/ssl-cert-snakeoil.key;
       root /var/www/html;
       return 444;
}

But don't try to limit the site by name before getting the keys, it's simply impossible. It's
much easier to make a separate config for this IP and lead it into a trap. than to catch something through default_server

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question