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 ?

[Maxim Dounin]

Hello!

On Tue, Jun 02, 2020 at 01:01:18PM -0700, PGNet Dev wrote:

> On 6/2/20 12:34 PM, Maxim Dounin wrote:
> > The mis-match comes from trying to redefine the name in some parts
> > of the configuration but not others.  Hope the above explanation
> > helps.
> 
> I've reread your comment
> 
> 	That is, the name you've written in the proxy_pass directive is 
> 	the actual hostname, and it will be used in the Host header when 
> 	creating requests to upstream server.  And it is also used in the 
> 	proxy_ssl_name, so it will be used during SSL handshake for SNI 
> 	and certificate verification.
> 
> 	It's not just "an upstream name".  If you want it to be only an 
> 	upstream name, you'll have to redefine at least proxy_ssl_name and 
> 	"proxy_set_header Host".  (Well, not really, since $proxy_host is 
> 	also used at least in the proxy_cache_key, but this is probably 
> 	not that important.)
> 
> a bunch of times.  Still can't grasp it clearly.  Which is the source of the pebkac :-/

Read: if you want to use an internal upstream name in proxy_pass, 
consider using _both_ "proxy_ssl_name" and "proxy_set_header 
Host", for example:

    proxy_pass https://test-upstream;
    proxy_set_header Host test.example.com;
    proxy_ssl_name test.example.com;

There are few other places where the hostname from the proxy_pass 
directive is used, but the probably aren't that important.

> Otoh, simply _doing_
> 
> 	Alternatively, you may want to use the real name, and define an 
> 	upstream{} block with that name.  This way you won't need to 
> 	redefine anything.
> 
> i.e., changing to EITHER

[...]

> now, in _either_ case, access to
> 
> 	https://example.com/app1
> 	https://example.com/app1/
> 
> _does_ return my 'test' app correctly

So everything is fine, as expected.

> i _do_ see in logs
> 
> in case (2), a single error instance,
> 
> 		2020/06/02 12:51:11 [debug] 6140#6140: *3 reusable connection: 1
> 		2020/06/02 12:51:11 [debug] 6140#6140: *3 http wait request handler
> 		2020/06/02 12:51:11 [debug] 6140#6140: *3 malloc: 0000563CDA76DF10:1024
> 		2020/06/02 12:51:11 [debug] 6140#6140: *3 SSL_read: 345
> 		2020/06/02 12:51:11 [debug] 6140#6140: *3 SSL_read: -1
> ???		2020/06/02 12:51:11 [debug] 6140#6140: *3 SSL_get_error: 2
> 		2020/06/02 12:51:11 [debug] 6140#6140: *3 reusable connection: 0
> 		2020/06/02 12:51:11 [debug] 6140#6140: *3 posix_memalign: 0000563CDA2963A0:4096 @16
> 		2020/06/02 12:51:11 [debug] 6140#6140: *3 posix_memalign: 0000563CDA650060:4096 @16
> 
> & 
> 
> in case (1), a double error instance
> 
> 		2020/06/02 12:53:46 [debug] 6267#6267: *6 SSL_read_early_data: 2, 0
> 		2020/06/02 12:53:46 [debug] 6267#6267: *6 SSL_do_handshake: 1
> 		2020/06/02 12:53:46 [debug] 6267#6267: *6 SSL: TLSv1.2, cipher: "ECDHE-ECDSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=ECDSA Enc=CHACHA20/POLY1305(256) Mac=AEAD"
> 		2020/06/02 12:53:46 [debug] 6267#6267: *6 reusable connection: 1
> 		2020/06/02 12:53:46 [debug] 6267#6267: *6 http wait request handler
> 		2020/06/02 12:53:46 [debug] 6267#6267: *6 malloc: 0000563C0F2ADAB0:1024
> 		2020/06/02 12:53:46 [debug] 6267#6267: *6 SSL_read: -1
> ???		2020/06/02 12:53:46 [debug] 6267#6267: *6 SSL_get_error: 2
> 		2020/06/02 12:53:46 [debug] 6267#6267: *6 free: 0000563C0F2ADAB0
> 		2020/06/02 12:53:46 [debug] 6267#6267: *6 http wait request handler
> 		2020/06/02 12:53:46 [debug] 6267#6267: *6 malloc: 0000563C0F2ADAB0:1024
> 		2020/06/02 12:53:46 [debug] 6267#6267: *6 SSL_read: 339
> 		2020/06/02 12:53:46 [debug] 6267#6267: *6 SSL_read: -1
> ???		2020/06/02 12:53:46 [debug] 6267#6267: *6 SSL_get_error: 2
> 		2020/06/02 12:53:46 [debug] 6267#6267: *6 reusable connection: 0
> 		2020/06/02 12:53:46 [debug] 6267#6267: *6 posix_memalign: 0000563C0F18FA60:4096 @16
> 		2020/06/02 12:53:46 [debug] 6267#6267: *6 posix_memalign: 0000563C0EDD4B10:4096 @16
> 		2020/06/02 12:53:46 [debug] 6267#6267: *6 http process request line
> 
> 
> but that error doesn't seem to be fatal.
> 
> any idea what's causing those^^ errors?

These aren't errors, these are debug messages.  The 
SSL_get_error() return code 2 means SSL_ERROR_WANT_READ, that is, 
SSL_read() consumed all the data from the socket and needs more 
data to read further.  These messages are perfectly normal and 
expected.

-- 
Maxim Dounin
http://mdounin.ru/