nginx ssl_trusted_certificate directive not working

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?

mxmader · Answer 1 · 2020-12-28T16:24:44.700

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).

Nginx' documentation is misleading, OP's question is valid and this answer, to be honest, didn't clarify anything for me. So I don't want to provide metadata to the client, and there is directive for it. How to use it? — EugZol, Jun 13 '22 at 21:32
@EugZol It seems like the documentation is misleading and this is not possible. Have a look at this: https://serverfault.com/questions/938269/nginx-client-cert-verification-ssl-client-certificate-vs-ssl-trusted-certificat — beld, Jul 14 '23 at 13:40

nginx ssl_trusted_certificate directive not working

1 Answers1