SSL客户端证书和NginX

如果通过CA和Server中的“通用名称”certificate您的意思是整个主题名称，其中可以包含通用名称以外的其他项目，虽然大多数人这样做临时SSL证书不会打扰他们，是一样的 – 不要不这样做。 nginx和curl都使用的OpenSSL不能将子证书链接到同名的父项; 这在X.509中不是一个正常的情况，至less在其他软件中也不能处理。

• CA证书应该具有作为主体的名称（自动地也是颁发者，因为这是一个根，见下），该名称是CA的名称 – 这不需要是域名，但可以是喜欢。
• （SSL）服务器请求和证书应该具有作为Subject.CommonName服务器的域名，如果服务器有多个但密切相关的域名，可以是通配符，或者如果所有客户端将通过地址访问在实际工作中，只有当客户都是你非常亲密的同事或朋友）。 服务器证书中的颁发者名称将自动设置为CA名称 。
• 同样，/每个客户端请求和证书应该有一个与CA名称不同的主题名称，并且颁发者成为CA名称。 如果您希望客户端证书安全地识别客户端，这大概是这种行为的目的，那么每个客户端证书都应该有一个不同于其他客户端证书的名称，最好与服务器证书不同，以避免混淆。

与此我相信它应该工作。 一个更基本，也许更好的testing工具是openssl命令行：

 openssl s_client -connect $addr:$port -cert $clicert -key $clikey -CAfile $cacert 

这将输出关于（企图）SSL / TLS连接的详细信息。 如果相当接近结束，它说Acceptable client certificate CA names后面跟着您的CA的正确名称，服务器设置正确的客户端身份validation（以及基本的SSL）。 如果它有一些其他的名字，或者说No client certificate CA names sent ，有些是错误的。 当s_client等待input时，只需inputEOF（Unix通常为^ D，Windows ^ Z）。

另外：网站是错误的说，签署服务器请求与您自己创build特设CA密钥和证书是“自签名”。 自签名是专门签署了一个相同的密钥对，其公共一半在该证书 ; 在实践中，这只用于顶层CA，称为“根”。 您正在使用自己的CA签署您的服务器证书，但您不是自签名的。 如果你想处理来自陌生人的连接，用自己的CA签署你的服务器证书是不好的，因为它没有提供任何证据来信任你的服务器，像Verisign或GoDaddy这样的知名CA的“商业”服务器证书。 通常情况下，生产与testing不同，因为testing通常只能由开发人员和/或很less的betatesting人员使用，但是一些生产系统也可能只限于less数几个密切相关的客户。

编辑：获得由着名的CA签署的临时CA（对于客户证书）：这将是困难和昂贵的，没有必要。

如果一个知名的CA给你一个允许你颁发证书的“sub-CA”或“intermediate CA”证书，他们将把你的业务的未来押注在你的安全性上，所以你必须提供与他们相同的安全级别（定制硬件，专业build筑，全天候的武装警卫，经过多次专门培训和authentication的人员，定期的外部审计 – 所有这些都很昂贵），或者你必须买断他们的业务（所以他们不再有风险）。 除了您的https://security.stackexchange.com/questions/25551/help-understanding-client-certificate-verification之外， 请参阅：

• 获得中间的SSL证书
• https://security.stackexchange.com/questions/47267/can-i-buy-a-signing-valid-certificate-for-internal-use
• https://security.stackexchange.com/questions/61842/how-to-become-intermediate-certificate-authority

但是唯一需要信任颁发客户证书的系统是您自己的服务器; 只要你控制你自己的服务器，你只要configuration他们信任你自己的CA证书。

是的， 这是小牛 。

-E / – 证书选项也打破了。

如果我用brew安装curl并指定–openssl构build选项，它就可以工作。