我被告知使用双向身份验证连接到客户的服务器。服务器身份验证工作正常,但我们遇到了很大的麻烦,使客户端身份验证到位。让我试着解释一下我们的麻烦。
不久前,我的公司在GeoTrust购买了一张证书,该证书完全有效,可用作我们的客户证书。显然,客户没有设法将此GeoTrust证书适当地添加到他们的信任库,因此我们每次尝试连接到他们的服务器时都会在SSL握手日志中看到错误 unknown_ca 。
相反,客户要求我们向他们发送证书签名请求(csr),我们收到了根证书以及应该用作我们客户证书的证书。相应地更新了我们的密钥库之后,我们现在在SSL握手日志中看到错误 unsupported_certificate 。仔细查看客户签名的客户端证书可以发现新证书明确具有服务器身份验证扩展名,但没有客户端身份验证扩展名。我发现 unsupported_certificate 与缺少的客户端身份验证扩展名之间的关联非常明显,但客户拒绝接受缺少的客户端身份验证作为有效解释(因此拒绝为我们创建一个新的和适当扩展的客户端证书)。这就是客户所说的:
客户从我的日志中向我发送了一张没有退回证书的屏幕截图,并声称此日志条目意味着我通过网络以错误的格式传递客户端证书:
为了加强他关于我以错误格式提交客户端证书的断言,客户向我发送了以下TCP转储屏幕截图,其中 pkcs 被圈起来:
我认为, pkcs-9-at-emailAddress 只是在证书中包含电子邮件地址信息的标准方式,与以错误格式提交的证书无关。此外,我在Google中找到了一个地方,其中提到在客户端证书缺少客户端身份验证扩展名的情况下,无证书返回日志条目可能会发生。
为了排除我们的Java代码使用的 keystore.jks 和 truststore.jks 格式不正确,我试图连接到他们的仅使用OpenSSL命令的服务器:
openssl s_client -CAfile caroot.cer -cert client.cer -key client.key -connect <host>:<port>
执行此OpenSSL命令会导致完全相同的 unsupported_certificate 错误。
如果有人能帮助我了解我们是对的还是客户是对的,我将不胜感激。非常感谢。
答案 0 :(得分:4)
当然,OpenSSL s_client
将以正确的格式传输证书(否则在连接到服务器之前会失败)。让我们检查为TLS 1.2 (RFC 5246)定义的错误警报。
bad_certificate
A certificate was corrupt, contained signatures that did not
verify correctly, etc.
unsupported_certificate
A certificate was of an unsupported type.
还有几个警报,但这些是最有趣的两个。据此,我们可能会推断无法解析证书,例如由于格式不正确会导致bad_certificate
,并且在不合适的密钥用法信息等情况下可能会返回unsupported certificate
。
如果您的客户需要进一步的证据,您可以将s_server(1)
程序与s_client
一起使用,以表明在此设置中客户端证书会以同样的方式被拒绝。
答案 1 :(得分:2)
客户向我发送了一张没有从他的日志返回的证书的屏幕截图,并声称此日志条目意味着我通过电汇以错误的格式传递客户端证书。
错误。这正是它所说的。
未返回任何证书。当错误,您没有返回证书时,就会发生这种情况。之所以发生这种情况,是因为您的SSL软件没有找到由CertificateRequest
消息中服务器指定的证书类型或可信签署者签名的证书。
这反过来意味着两件事之一:
-trustcacerts
选项,进入密钥库,以及(2)使用相同的方式安装签名证书生成密钥对和CSR时使用的别名。 OR
CertificateRequest
消息中将自己的根CA作为可信签名者发送,或者没有包含其类型。 我的钱都在(1)和(2)上,但是签署证书的客户的整个业务都是荒谬的。如果他的信任商店不认识一个公认的CA,那就是他们需要解决的问题,而不是改为不同的签名者,这只会解决问题。例如,你相信他们的签名者吗?我不是在信任库的意义上,而是在企业安全意义上的意思吗?
如果是(2)这意味着客户的软件没有认出他自己发行的证书,所以我不明白为什么你需要参与其中。< / p>
对客户关于提交的格式错误的客户端证书的声明有何评论?
我的评论是,这并没有激发信心。
我在谷歌找到了一个地方,提到在客户端证书缺少客户端身份验证扩展的情况下,无证书返回日志条目。
换句话说,他们没有正确签名。
我对以下TCP转储屏幕截图没有任何信心,其中pkcs被圈起来&#39;或者,除非在上面有第一个CertificateRequest
然后是Certificate
消息。如果一切正常,则客户似乎发出了不正确的证书。
任何关于你已经破坏它的指控都可以打折扣,因为两端的验证都会失败。同样地,任何关于您的软件在传输过程中损坏它的指控也可以打折扣,因为您使用Java而不是您自己的代码来执行此操作。
所有这些只会更加强烈地表明您应该忘记客户签署证书并让他们使用GeoTrust根CA证书解决原始问题。它更简单,并且不会涉及到你。