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/
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
