微信公众号搜"智元新知"关注
微信扫一扫可直接关注哦!

ssl – 具有多个客户端证书的nginx客户端身份验证

我正在尝试设置Nginx来对多个客户端执行客户端身份验证.我遇到的问题是那些客户端将拥有不同的证书,基本上是不同的根CA:

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

我查看了Nginx文档,我注意到了ssl_client_certificate指令.但是,单独该属性本身似乎不起作用,例如,如果我现在将其配置为仅为clientA工作:

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

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

解决方法:

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

如上所述,请注意ssl_verify_depth基本上控制了进入系统的容易程度 – 如果将其设置为足够高的值,并且某人能够获得您信任的CA之一的证书,或者通过他们信任的中间人之一,他们可以生成自己的证书,然后他们就可以通过你的Nginx进行身份验证,无论这是否是你的愿望.

因此,通常情况下,用于基于客户端的身份验证的所有证书都是由私人认可的CA生成的,因此,通常,链的长度不应太长.如果要平衡两个CA之间的深度编号,为了从ssl_verify_depth获得最佳保护,那么可以想象创建一个额外的CA来添加深度,然后将CA添加到可信列表而不是现在的实际中介. (请注意,一旦涉及一些中介,它会变得复杂,浏览器需要知道它们的存在,这通常是缓存的,并且在非缓存时可能会导致许多鬼问题.)

另外,请注意,实际上您不必在指定文件中包含单个CA – 它可以包含多个不相关的“根”CA,因此,如果要添加多个独立CA,则实际上不必打扰创建另一个CA来证明它们 – 您可以按原样包含此类独立CA.

版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。

相关推荐