使用多个客户端证书的Nginx客户端身份验证 [英] nginx client authentication with multiple client certificates

问题描述

我正在尝试设置NGINX以对多个客户端执行客户端身份验证.我的问题是这些客户端将具有不同的证书，基本上是不同的根CA:

I am trying to set up a NGINX to perform client authentication against multiple clients. The problem I have is that those clients will have different certificates, basically different Root CAs:

[clientA.crt] ClientA > IntermediateA > RootA
[clientB.crt] ClientB > IntermediateB1 > IntermediateB2 > RootB

我查看了NGINX文档，并注意到了ssl_client_certificate指令.但是，例如，如果我现在仅将该属性配置为仅对clientA起作用，则该属性本身似乎无法单独起作用:

I looked at the NGINX documentation and I noticed the ssl_client_certificate directive. However, that property alone seems not work by itself, for example, if I configure it for only work for clientA for now:

ssl_client_certificate /etc/nginx/ssl/clientA.crt;   
ssl_verify_client on;

然后我收到了400错误代码.通过查看其他问题，我发现我还必须使用ssl_verify_depth: 3.因此，如果我想在捆绑的PEM中同时连接clientA和clientB以允许两个客户端，我是否需要使用较高的值?该指令的目的是什么?将捆绑的PEM设置为高数值意味着什么?

Then I received a 400 error code back. By looking at other questions, I figured out that I also have to also use ssl_verify_depth: 3. Therefore, if I want concatenate both clientA and clientB in a bundle PEM to allow both clients, will I need use a high value? What's the purpose of this directive and what are the implications of setting to a high number with a bundled PEM?

推荐答案

http://nginx.org/r /ssl_client_certificate 指令用于指定您信任用于基于客户端的身份验证的证书.请注意，基本上每次尝试进行连接时都会发送整个列表(如果不需要，请按docs使用ssl_trusted_certificate.)

The http://nginx.org/r/ssl_client_certificate directive is used to specify which certificates you trust for client-based authentication. Note that the whole list is basically sent every time a connection is attempted (use ssl_trusted_certificate as per the docs if that's not desired).

如上所述，请注意ssl_verify_depth基本上控制进入系统的难易程度-如果将其设置为足够高的值，并且某人能够通过其中一个CA获得证书您信任，或者通过他们信任的中介机构之一生成自己的证书，那么无论您是否愿意，他们都可以向您的nginx进行身份验证.

As per above, note that ssl_verify_depth basically controls how easy would it be to get into your system — if you set it at a high-enough value, and someone is able to obtain a certificate with one of the CAs that you trust, or through one of their intermediaries which they trust to generate their own certificates, then they'd be able to authenticate with your nginx, whether or not that's your desire.

因此，通常的做法是，用于基于客户端的身份验证的所有证书都是由私有批准的CA生成的，因此，通常，链的长度不应太大.如果要均衡两个CA之间的深度数，以从ssl_verify_depth中获得最佳保护，则可以想到创建一个额外的CA以添加到深度中，然后将该CA添加到受信任列表中，而不是现在的实际中介. (请注意，一旦涉及到一些中介，它将变得很复杂，浏览器将需要知道它们的存在，通常会缓存这些中介，并且在不缓存时可能会导致许多幻影问题.)

As such, it'd normally be the practice that all certificates that are used for client-based authentication are generated by a privately sanctioned CA, hence, normally, there shouldn't be much of a length to the chain. If you want to equalise the depth number between the two CAs, to get the best protection from ssl_verify_depth, then it's conceivable to create an extra CA to add to the depth, then that CA to the trusted list instead of what's now an actual intermediary. (Note that it gets complicated once you involve a few intermediaries, the browser would need to know of their existence, which is usually cached, and can result in a number of ghost issues when non-cached.)

此外，请注意，您实际上不必在指定文件中具有单个CA-它可以包含多个不相关的根" CA，因此，如果要添加多个独立的CA，则实际上没有麻烦创建另一个CA进行认证-您可以按原样包括这样的独立CA.

Also, note that you don't actually have to have a single CA in the specified file — it can include multiple unrelated "root" CAs, so, if you want to add multiple independent CAs, you don't actually have to bother creating another CA to certify them — you can just include such independent CAs as-is.

这篇关于使用多个客户端证书的Nginx客户端身份验证的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！