proxy_ssl_verify error: 'upstream SSL certificate does not match "test.example.com" while SSL handshaking to upstream', for CN/SAN 'matched' client & server certs ?
francis at daoine.org
Thu Jun 4 15:19:15 UTC 2020
On Tue, Jun 02, 2020 at 10:22:06PM +0300, Maxim Dounin wrote:
> On Tue, Jun 02, 2020 at 04:27:28PM +0100, Francis Daly wrote:
Thanks for the extra information.
> > That suggests that if you choose to use "proxy_ssl_server_name on;",
> > then you almost certainly do not want to add your own "proxy_set_header
> > Host" value.
> Not exactly.
> The 421 Misdirected Request error is only returned
> when one tries to access a virtual server with SSL client
> certificate verification enabled, and used a different server name
> during the SSL handshake.
Is the "client certificate verification" part important there, in the
general case? The upstream server could be anything, so could be more
picky about matching SNI name and Host header, I guess.
So based on the other mails in the thread, I'll update my own notes to
say: if you use "proxy_ssl_server_name on;", then probably make sure
that "proxy_set_header Host" and "proxy_ssl_name" have the same value;
by default they do, but if you change only one there may be problems.
> Normally one can use Host header which
> is different from the SNI server name, and this is often happens
> in real life (e.g., connection reuse in HTTP/2 implies requests to
> multiple hostnames via one connection).
True; web searches do reveal some people reporting 421 error in normal
use cases, but they seem mainly down to badly configured servers.
> That's more about being careful when configuring things,
> especially when configuring SSL.
Since the cases where special consideration is needed are not trivial
to enumerate, adding a note for only one of them is not the most useful
thing to do.
Francis Daly francis at daoine.org
More information about the nginx