SSL error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca:SSL alert

[Maxim Dounin]

Hello!

On Fri, Nov 06, 2020 at 04:35:43AM -0500, meniem wrote:

> Thanks Sergey for your quick reply.
> 
> I have checked the debug logs for the SNI (upstream SSL server name), and it
> seems to be correct.I also used the "proxy_ssl_name" directive that set to
> the proxied_server_name. Below is the debug output when I hit the endpoint:

[...]

> 2020/11/06 09:14:36 [debug] 30370#30370: *113140 connect to 1.2.3.4:443, fd:13 #11343

[...]

> 2020/11/06 09:14:36 [debug] 30370#30370: *113140 upstream SSL server name: "targetapp.com"

[...]

> 2020/11/06 09:14:37 [error] 30370#30370: *113140 SSL_do_handshake() failed (SSL: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca:SSL alert$

The error is clear enough: the upstream server sent the "unknown 
CA" alert.  It is defined as follows
(https://tools.ietf.org/html/rfc5246#section-7.2.2):

   unknown_ca
      A valid certificate chain or partial chain was received, but the
      certificate was not accepted because the CA certificate could not
      be located or couldn't be matched with a known, trusted CA.  This
      message is always fatal.

That is, the upstream server got the certificate, but it does no 
know the Certificate Authority used to sign the certificate.

As long as the IP address of the server and the SNI name are 
correct, and the same certificate works with curl, this might 
happen due to lack of some intermediate certificates.  These 
certificates are added by curl automatically (as long as present 
in the available list CA certificates as provided to curl).  In 
contrast, nginx does not add any certificates automatically.

If intermediate certs are indeed required by your upstream server, 
you can provide them by placing them into the 
proxy_ssl_certificate file following the certificate itself, much 
like additional intermediate certificates for the server 
certificate in the ssl_certificate file.

Alternatively, consider reconfiguring your upstream server to do 
not require intermediate certs from the client.  Providing all 
required intermediate certificates on the server rather than 
asking clients to send them along with their client certificates is 
believed to be a better practice.

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