RE: Fallback default server sharing cert information about other domains than for the URL you visit ?
> With that config when I try to launch nginx it fails with these errors > > Aug 09 11:29:21 myhost nginx[10095]: nginx: [emerg] bind() to [::]:443 > failed (98: Address already in use) Try to remove the ipv6only=on option it should work just fine without. Imo the [FE80:...:0001]:443 conflicts with [::]:443 in linux since the ipv6only option forces nginx to try to create a separate listening socket while the port is in use (hence the error). rr ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
Re: Fallback default server sharing cert information about other domains than for the URL you visit ?
Thanks for the help.
I'm really feeling pretty stupid atm since I can't seem to find & understand a
how-to document to get this right :-/
So I have this config
server {
listen 80 http2 default_server;
listen [::]:80 http2 ipv6only=on default_server;
server_name _;
return 301 https://$host;
}
server {
listen 172.17.0.1:443 ssl http2 default_server;
listen [FE80:...:0001]:443 ssl http2 ipv6only=on default_server;
server_name _;
ssl_trusted_certificate"/etc/ssl/trusted.crt.pem";
ssl_certificate"/etc/ssl/dummy.crt.pem";
ssl_certificate_key"/etc/ssl/dummy.key.pem";
return 444;
}
server {
listen 443 ssl http2 default_server;
listen [::]:443ssl http2 ipv6only=on default_server;
server_name _;
ssl_trusted_certificate"/etc/ssl/trusted.crt.pem";
ssl_certificate"/etc/ssl/dummy.crt.pem";
ssl_certificate_key"/etc/ssl/dummy.key.pem";
return 444;
}
server {
listen 172.17.0.1:80 http2;
listen [FE80:...:0001]:80 http2;
server_name example.com www.example.com;
location / {
return 301 https://example.com$request_uri;
}
}
server {
listen 172.17.0.1:443 ssl http2;
listen [FE80:...:0001]:443 ssl http2 ipv6only=on default_server;
server_name example.com www.example.com;
ssl_trusted_certificate"/etc/ssl/trusted.crt.pem";
ssl_certificate"/etc/ssl/chain.crt.pem";
ssl_certificate_key"/etc/ssl/privkey.pem";
add_header Strict-Transport-Security "max-age=31536;
includeSubDomains; preload";
location / {...}
}
With that config when I try to launch nginx it fails with these errors
Aug 09 11:29:21 myhost nginx[10095]: nginx: [emerg] bind() to [::]:443
failed (98: Address already in use)
If I comment out the IP-less listener
# server {
# listen 443 ssl http2 default_server;
# listen [::]:443ssl http2 ipv6only=on
default_server;
# server_name _;
# ssl_trusted_certificate"/etc/ssl/trusted.crt.pem";
# ssl_certificate"/etc/ssl/dummy.crt.pem";
# ssl_certificate_key"/etc/ssl/dummy.key.pem";
# return 444;
# }
and try again, I do get a site fail with that "Websites prove their identity
via certificates. Firefox does not trust this site because it uses a
certificate that is not valid for ..." error again.
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
RE: Fallback default server sharing cert information about other domains than for the URL you visit ?
> "In versions prior to 0.8.21 this parameter is named simply default. " > > Was that a typo? Or is there a new or different usage now ? Not a typo just nginx being backwards compatible and me using it since 0.5.x or even earlier (and being lazy). As far as I remember the directive has been renamed to better convey the meaning. rr ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
Re: Fallback default server sharing cert information about other domains than for the URL you visit ?
I'll get a set up I can fool around with that more easily and see how that works here. I notice that you're not using 'default_server" in your listen directive, just 'default'. Reading here https://nginx.org/en/docs/http/ngx_http_core_module.html#listen It's not a listed option and it says "In versions prior to 0.8.21 this parameter is named simply default. " Was that a typo? Or is there a new or different usage now ? ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
RE: Fallback default server sharing cert information about other domains than for the URL you visit ?
> certificate (and also the test 403 response) for nondefined subdomain requests
> and the order of server {} block
Missed the ending of sentence - .. the order of server {} blocks doesn't matter
(in the test case).
rr
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
RE: Fallback default server sharing cert information about other domains than for the URL you visit ?
> > Just for testing purposes (if possible) you could either add the IP to
> > both listen directives or remove the ip part from the full-domain
> > server {} block to see if it changes anything.
>
> Hm. That doesn't really make sense to me.
>
> This server has multiple IPs. The hosted server needs to respond on a
> specific IP,
> so it needs the specific IP.
>
> The fallback is supposed to work for all "whenever it doesn't match" cases,
> so it
> doesn't get an IP, right?
Yes and no the 'default' fallback works for particular 'address:port' and
listen ip:443 seems to be different than just listen 443;
Out of personal interest I spun up an instance to replicate your setup and it
kind of confirms my suspicion:
If you have:
server {
listen 443 ssl http2;
ssl_certificate realdomain.crt;
ssl_certificate_key realdomain.key;
server_name realdomain;
return 403;
}
server {
listen 443 ssl http2 default;
ssl_certificate dummy.crt;
ssl_certificate_key dummy.key;
server_name _;
return 402;
}
Everything works as expected - you get first server for https://realdomain and
dummy cert for anything else.
The moment you change the first listen to listen real.ip:443 ssl http2; the
'default_server' doesn't work anymore and you always get the 'realdomain'
certificate (and also the test 403 response) for nondefined subdomain requests
and the order of server {} block
The workaround I found is then is to also define a dummy listen ip:port for the
catch server then the real certificate is not "leaked" in random requests:
server {
listen real.ip:443 ssl http2 default;
ssl_certificate dummy.crt;
.
}
Unless there are (old) clients which don't support SNI (server name indication)
in general specifying the IP only on dns-level and using just 'listen 443 will
make the configuration more simple.
rr
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Re: Fallback default server sharing cert information about other domains than for the URL you visit ?
Hi,
> you can't expect that they will get the return code.
Okay I guess that makes sense.
Is there any other way to get an attempt to connect to a un-hosted site to get
a "nobody home, go away" response?
Something other than the current "there's a problem with the cert" mis-message?
> I might be wrong (needs a clarification from nginx dev/support people)
No worry. Hope somebody that's sure will chime in eventually.
> Just for testing purposes (if possible) you could either add the IP to
> both listen directives or remove the ip part from the full-domain
> server {} block to see if it changes anything.
Hm. That doesn't really make sense to me.
This server has multiple IPs. The hosted server needs to respond on a specific
IP, so it needs the specific IP.
The fallback is supposed to work for all "whenever it doesn't match" cases, so
it doesn't get an IP, right?
Did I misunderstand your point?
> Other than that depending on the requirements the other options are
> just to make a matching server block with a valid certificate (with
> Lets Encrypt it's quite simple and free) or have an *.example.com
> wildcard SSL so the browsers are satisfied with
A subdomain wildcard like that assumes that ALL subdomains of example.com are
unhosted. That's not true here.
There are an infinite number of possible mismatches. I can't really set up a
"valid cert" for each one.
This is about the fallback. I thought that's what the fallback is supposed to
handle.
Let's see if a 'dev' has some other comments.
Thanks!
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
RE: Fallback default server sharing cert information about other domains than for the URL you visit ?
> I expect it to fail with a 444, and only have info about the failed subdomain.
The SSL handshake happens before the http status and since the browser doesn't
get a valid certificate it immediately throws an error and ignores the rest.
Unless the users override the error on the browser side (iirc with HSTS it's
not even possible as with invalid or expired certs) you can't expect that they
will get the return code.
> Why does it respond with cert info about the "example.com, www.example.com
> " certs at all? Those are only for the full-domain site.
I might be wrong (needs a clarification from nginx dev/support people) but if
the configuration is as you have included in the email it might be that the
default_server directive doesn't work as expected since you have different
listen blocks:
listen 172.17.0.1:443 ssl http2;
vs
listen 443 ssl http2 default_server;
Since nginx can have a different default_server for different 'address:port'
pairs depending on what 'listen 443' is actually expanded to (just a guess
0.0.0.0:443) it could be that the nginx decides that it has to use the
certificates from first server {} (in the order in configuration) rather than
the catch all fallback.
Just for testing purposes (if possible) you could either add the IP to both
listen directives or remove the ip part from the full-domain server {} block to
see if it changes anything.
Other than that depending on the requirements the other options are just to
make a matching server block with a valid certificate (with Lets Encrypt it's
quite simple and free) or have an *.example.com wildcard SSL so the browsers
are satisfied with whateversubdomain.example.com.
rr
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Fallback default server sharing cert information about other domains than for the URL you visit ?
Hi,
My own domain, let's say 'example.com', is registered in the HSTS preload
database (https://hstspreload.org).
I setup my domain as virtual host in Nginx,
/etc/nginx/sites-enabled/example.conf
server {
listen 172.17.0.1:80;
server_name example.com www.example.com;
location / {
return 301 https://example.com$request_uri;
}
}
server {
listen 172.17.0.1:443 ssl http2;
server_name example.com www.example.com;
ssl_trusted_certificate "/etc/ssl/trusted.crt.pem";
ssl_certificate "/etc/ssl/chain.crt.pem";
ssl_certificate_key "/etc/ssl/privkey.pem";
add_header Strict-Transport-Security
"max-age=31536; includeSubDomains; preload";
location / {...}
}
The cert is good for example.com + www.example.com.
When I go to
https://example.com
it works like you would expect.
I also set up a fallback, default server in my main nginx config
/etc/nginx/nginx.conf
...
server {
listen 80 default_server;
listen [::]:80 ipv6only=on default_server;
server_name _;
return 301 https://$host;
}
server {
listen 443 ssl http2 default_server;
listen [::]:443 ssl http2 ipv6only=on default_server;
server_name _;
ssl_trusted_certificate "/etc/ssl/trusted.crt.pem";
ssl_certificate "/etc/ssl/null.crt.pem";
ssl_certificate_key "/etc/ssl/nullkey.pem";
return 444;
}
include sites-enabled/*.conf;
If I go to a subdomain of my domain that has a DNS A-record pointing to the
same IP, but no Nginx virtual hosted site,
https://subdomain.example.com
in the browser I get this message
Did Not Connect: Potential Security Issue
Firefox detected a potential security threat and did not continue to
subdomain.example.com because this website requires a secure connection.
What can you do about it?
subdomain.example.com has a security policy called HTTP Strict
Transport Security (HSTS), which means that Firefox can only connect to it
securely. You can’t add an exception to visit this site.
The issue is most likely with the website, and there is nothing you
can do to resolve it. You can notify the website’s administrator about the
problem.
Learn more…
Websites prove their identity via certificates. Firefox does
not trust this site because it uses a certificate that is not valid for
subdomain.example.com. The certificate is only valid for the following names:
example.com, www.example.com
Error code: SSL_ERROR_BAD_CERT_DOMAIN
View Certificate
I expect it to fail with a 444, and only have info about the failed subdomain.
Why does it respond with cert info about the "example.com, www.example.com
" certs at all? Those are only for the full-domain site.
What do I need to set up to just get a fallback 444 response and NO information
about any other domain's certs etc, when I visit the un-hosted
subdomain.example.com?
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Static resource failed to pass through cookie
map $cookie_test_debug $forward_to_gray {
# forward to gray1
9cb88042edc55bf85c22e89cf880c63b 10.0.0.1;
}
location ~ ^/test/ {
root /data/www/project;
index index.html;
if ( $uri !~ (css|js)$ ) {
rewrite ^.*$ /test/index.html break;
}
if ( $forward_to_gray != '' ) {
proxy_pass http://$forward_to_gray$request_uri;
break;
}
}
location / {
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
try_files $uri $uri/ /index.php?$query_string;
if ( $forward_to_gray != '' ) {
proxy_pass http://$forward_to_gray$request_uri;
break;
}
}
According to the above configuration, my php request can be routed through a
cookie, but the static resource will report 404, I don't know if there is a
problem with my configuration.
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
