upstream SSL certificate does not match "x.x.x.x"

[Francis Daly]

On Wed, Oct 28, 2020 at 12:28:04AM -0400, bouvierh wrote:

Hi there,

it looks to me like you've come across a case that the current nginx
code does not handle in the way that you want it to.

Maybe the nginx code could be changed to handle this case; or maybe it
will be decided that what nginx does is correct.

Either way -- until a code change is made on the nginx side, you will
have to either use something other than nginx, or change something on
your side to work within the current nginx implementation.

>         location / {
>             proxy_http_version 1.1;
>             resolver 127.0.0.11;
>             proxy_ssl_trusted_certificate trustedCA.crt;
>             proxy_ssl_verify_depth 7;
>             proxy_ssl_verify       on;
>             proxy_pass          https://13.78.229.75:443;
>         }

> However when I try to curl my "NGINX_SERVER":
> curl https://"NGINX_SERVER
> I get:
>  *110 upstream SSL certificate does not match "13.78.229.75" while SSL
> handshaking to upstream, client: 13.78.128.54, server: , request: 
> 
> Looking at the server certificate, everything looks ok:
>         Subject: CN = 13.78.229.75
>             X509v3 Subject Alternative Name:
>                 IP Address:13.78.229.75, DNS:iotedgeapiproxy
> 
> I am at loss. How can curl/openssl tell me my server cert is valid while
> nginx telling me it is wrong. What am I doing wrong?

What nginx currently does (at least: looking at the 1.17.2 code, which
I happen to have to hand), is:

* if there is a Subject Alternative Name defined, then it is looked at
and Subject is ignored.
* within Subject Alternative Name, only DNS values are looked at (not
IP Address values).

And your certificate happens to mean that nginx-as-implemented-today
will not accept it as valid for the IP address.


Possibly adding

  proxy_ssl_name iotedgeapiproxy;

to your config will make things Just Work.

Alternatively, changing the proxy_pass to refer to
https://iotedgeapiproxy, and making sure that that resolves to the IP
address (by using an "upstream" definition, or by having your system
resolver respond appropriately at nginx startup) should work, but that
might have consequences for returned Location: headers and the like.

The other options would involve not verifying the certificate (bad!),
or re-issuing the certificate either with no Subject Alternative Name,
or with an extra value in the "DNS" part of the Subject Alternative Name
that is the IP address, just to work around the nginx implementation.


Hopefully the "proxy_ssl_name" addition will be enough.

Good luck with it,

	f
-- 
Francis Daly        francis at daoine.org