nginx ssl_trusted_certificate directive not working - nginx

Question

When I try to start the nginx server with this configuration I get an error
nginx: [emerg] no ssl_client_certificate for ssl_client_verify
My Configuration looks like
# HTTPS server
server {
listen 4443;
server_name localhost;
ssl on;
ssl_certificate /home/user/conf/ssl/server.pem;
ssl_certificate_key /home/user/conf/ssl/server.pem;
ssl_protocols TLSv1.2;
ssl_verify_client optional;
ssl_trusted_certificate /home/user/ssl/certs/certificate_bundle.pem;
include conf.d/api_proxy.conf;
}
As per the error, I should use ssl_client_certificate directive but as per the documentation if I don't want to send the list of certificates to clients I should use ssl_trusted_certificate.
http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_client_certificate
Can someone help me figure out what am I missing?

Answer 1

The answer is in the error message itself:
nginx: [emerg] no ssl_client_certificate for ssl_client_verify
If you disable ssl_client_verify in your configuration, the error will disappear upon the next start of nginx. It appears that the semantics of ssl_trusted_certificate only pertain to its exclusive use and is subject to "logical override" when other configuration directives are in play.
I would personally prefer enabling ssl_client_verify to mean: "client certificates are verified if presented; clients are given no information regarding what client certificates or authorities are trusted by the web server". But, I can also see advantage in troubleshooting TLS handshakes when this information is available. From a security perspective, I only see metadata presented to the client via openssl s_client; there is no public key or other "signature-critical" information that a malicious client could use to, for example, attempt to clone/reconstruct the CA.
For example, running the following against a local instance of nginx with your configuration:
openssl s_client -key client.key -cert client.crt -connect localhost:443
... would show data similar in structure to the following in the response:
Acceptable client certificate CA names
/CN=user/OU=Clients/O=Company/C=Location
Client Certificate Types: RSA sign, DSA sign, ECDSA sign
Requested Signature Algorithms: RSA+SHA512:DSA+SHA512:ECDSA+SHA512:RSA+SHA384:DSA+SHA384:ECDSA+SHA384:RSA+SHA256:DSA+SHA256:ECDSA+SHA256:RSA+SHA224:DSA+SHA224:ECDSA+SHA224:RSA+SHA1:DSA+SHA1:ECDSA+SHA1
Shared Requested Signature Algorithms: RSA+SHA512:DSA+SHA512:ECDSA+SHA512:RSA+SHA384:DSA+SHA384:ECDSA+SHA384:RSA+SHA256:DSA+SHA256:ECDSA+SHA256:RSA+SHA224:DSA+SHA224:ECDSA+SHA224:RSA+SHA1:DSA+SHA1:ECDSA+SHA1
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
In my opinion, the value of the above is confined in value to troubleshooting.
Your DN structures are (ideally) not "security relevant" (especially if the context is an Internet-facing web service).