How to disable access in NGINX to all non-existent third-level domains on the site via SSL (port 443)?

Question

PHP

Welcome all.
At first, I’ll say that I read the manual, searched for a solution in search engines, experimented on a working project, but I couldn’t do what was required, so I ask for help from the community.

So, the task seems to be banal, to prohibit access in NGINX to all non-existent third-level domains at site2.ru via SSL (there is a ban on port 80 at the moment). Those. now the browser does not show anything by a non-existent name, for example, t.site2.ru, because The ssl certificate is valid only for the main domain, but the search engine receives the site2.ru content, but should receive a 403 response code.

On the Internet, the vast majority of solutions are for port 80, but it seems to be the same with 443, as a result, the solution comes down to the following, you need to add an entry to the NGINX configuration file:

server {
listen 443 default_server;
server_name_;
access_log /dev/null;
error_log /dev/null;
return 403;
}

But if I add one, the main domain stops opening for me (in the example below it is site2.ru)!

As a result, my file looks like this in abbreviated form:

http {

server {
listen 80 default;
server_name site1.ru www.site1.ru;
error_log /dev/null;
access_log /dev/null;
return 444;
}

server {
listen 80;
server_name site2.ru www.site2.ru;
return 301 https://$host$request_uri ;
}

############## if you add what is advised on the Internet ##############

server {
listen 443 default_server;
server_name_;
access_log /dev/null;
error_log /dev/null;
return 403;
}

################################################# #######

server {
listen 443 ssl http2;
server_name site2.ru www.site2.ru;
...
}

}

How to solve the problem and deny access in NGINX to all non-existent third-level domains at site2.ru via SSL (port 443)?

Answer 1

And yet a paradoxical result came out of this story. The site rested with all its fibers or whatever. We managed to get a normal result only with the help of iconv and forced conversion to UTF-8. Only after that did all the functions work. Here you are, grandmother, and St. George's Day!

Answer 2

first open through one browser, and then close and open through another

Answer 3

Spared the site.

Where do you store? How do you get it? Precisely everything is in utf? Connection, charset in puff and Apache, tables in the database?

The encoding is iso-8859, but the conversion to utf-8 gives krakozyabry.

Perhaps by the fact that you are trying to recode? Since it is already in utf (since the subset is the same), nothing needs to be recoded.

Answer 4

It's all pretty banal.
https://nginx.ru/ru/docs/http/request_processing.html
Here is how Nginx processes requests. Now it’s immediately clear what you are stuck on, because if an unconfigured subdomain accesses port 80, it’s quite simple here, you can configure a default virtual host and, for example, redirect it to the main one or deny access, but in general, whatever. But if the call goes to 443 via ssl, then in order for the connection to take place, you need a certificate, which you do not have for each non-existing subdomain. There are several ways out.
1. Add a setting with a self-signed certificate to this configuration, the downside is that if a person goes over, he will see that the site is not safe and God knows what he might think about the main domain) Suddenly he is not educated enough to understand why this message is shown to him and will accept you for a scammer.

server {
listen 443 default_server;
server_name _;
access_log /dev/null;
error_log /dev/null;
return 403;
}

The question is, why send logs to zero ??? It's not easier to turn them off, what a wildness)
2. Buy a certificate that immediately protects both the domain itself and all its subdomains and fasten it there, in this case everything will be as smooth as in the case of port 80, unless of course someone decides to break into third-level domains)))
3. In the DNS, send to the server only those domains and subdomains that really exist, in this case, this will be shown to everyone else.
Read more documentation)

Answer 5

If the https request has already arrived at the server, then the server must have a valid certificate, otherwise a warning about an invalid certificate will be displayed in the browser.
Option 1: forget about the invalidity of the certificate, still give 403.
Option 2: get a *.site2.ru wildcard certificate
Option 3: explicitly register all subdomains in the NS records of the domain. The browser will not even send a request to a non-existent subdomain.