尝试使用客户端证书时解决 sslv3 警报握手失败 [英] Solving sslv3 alert handshake failure when trying to use a client certificate

问题描述

我正在尝试连接到需要证书进行授权的服务.过程是我向服务发送 CSR 文件.该服务签署 CSR 并向我发送我用于连接的证书.

I'm trying to connect to a service that requires a certificate for authorization. The process is that I send the service a CSR file. The service signs the CSR and sends me a certificate that I use for connection.

1. 我通过以下命令行生成了 CSR:

1. I generated the CSR by the following command line:

openssl req -new -nodes -newkey rsa:2048 -keyout cert.key -out cert.csr

我把cert.csr的内容发给了他们.他们生成客户端证书，我得到了一个 PEM 文件.

I took the content of the cert.csr and sent to them. They generate the client certificate and I got a PEM file back.

我现在尝试使用 SSLCERT 中的证书文件连接 curl() 并提供来自 cert.key 的私钥作为 CURLOPT_SSLKEY -(我在第 1 步得到).

I now try to connect using their certificate file in SSLCERT for curl() and providing the private key from cert.key as CURLOPT_SSLKEY - (which I got at step 1).

失败:error:14094410:SSLroutines:SSL3_READ_BYTES:sslv3 警报握手失败

我在这个过程中做错了什么?

What am I doing wrong in this process?

当我尝试使用收到的包含来自服务的私钥的测试证书(自签名证书)时，它可以工作.但是当我使用他们从我的 CSR 生成的证书然后使用我的私钥作为密钥时，它会因握手失败而出错.

It works when I try with a received a test certificate including a private key from the service (self signed certificate). But when I use a certificate they generated from my CSR and then use my private key as key, it errors with handshake failure.

所以我知道这与 openssl/curl 不支持 v3/TLS 等无关，而其他人在研究解决方案时发现他们的问题是.

So I know it does not have something to do with that openssl / curl doesn't support v3/TLS etc. that others when researching for a solution found out their problem was.

这是我运行的:

  curl -i -v --request POST https://service.com/ --cert clientcert.pem --key private_key.pem --cert-type pem --tlsv1.1 --insecure
* Connected to service.com (1xx.xxx.xxx.xx) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Request CERT (13):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS handshake, CERT verify (15):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS alert, Server hello (2):
* error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure
* Closing connection 0

运行以下版本:curl 7.35.0 (x86_64-pc-linux-gnu) libcurl/7.35.0 OpenSSL/1.0.1f zlib/1.2.8 libidn/1.28 librtmp/2.3

Running following versions: curl 7.35.0 (x86_64-pc-linux-gnu) libcurl/7.35.0 OpenSSL/1.0.1f zlib/1.2.8 libidn/1.28 librtmp/2.3

推荐答案

不是一个明确的答案，但在评论中太多了:

Not a definite answer but too much to fit in comments:

我假设他们给你的证书要么有错误的颁发者(尽管他们的服务器可以为此使用更具体的警报代码)或错误的主题.我们知道证书与您的私钥匹配——因为 curl 和 openssl client 都将它们配对，而不会抱怨不匹配；但我们实际上并不知道它与他们想要的 CA 相匹配——因为您的 curl 使用 openssl，而 openssl SSL 客户端不会强制配置的客户端证书与 certreq.CA 相匹配.

I hypothesize they gave you a cert that either has a wrong issuer (although their server could use a more specific alert code for that) or a wrong subject. We know the cert matches your privatekey -- because both curl and openssl client paired them without complaining about a mismatch; but we don't actually know it matches their desired CA(s) -- because your curl uses openssl and openssl SSL client does NOT enforce that a configured client cert matches certreq.CAs.

Do openssl x509 <clientcert.pem -noout -subject -issuer 并且在来自测试 P12 的证书上同样有效.执行openssl s_client(或检查您所做的)并查看Acceptable client certificate CA names；那里的名称或其中之一应该与您的证书的颁发者(完全相同！)匹配.如果不是，那很可能是您的问题，您需要与他们核实您是否以正确的方式将 CSR 提交到了正确的位置.也许他们在不同的地区、不同的业务线、或测试与生产、或活动与待定等有不同的制度.

Do openssl x509 <clientcert.pem -noout -subject -issuer and the same on the cert from the test P12 that works. Do openssl s_client (or check the one you did) and look under Acceptable client certificate CA names; the name there or one of them should match (exactly!) the issuer(s) of your certs. If not, that's most likely your problem and you need to check with them you submitted your CSR to the correct place and in the correct way. Perhaps they have different regimes in different regions, or business lines, or test vs prod, or active vs pending, etc.

如果您的证书的颁发者确实与所需的 CA 匹配，请将其主题与工作 (test-P12) 主题进行比较:它们的格式是否相似?工作组件中是否有任何组件不存在于您的组件中?如果他们允许，请尝试生成并提交一个新的 CSR，其主题名称与 test-P12 的主题名称完全相同，或者尽可能接近，看看是否会产生一个效果更好的证书.(您不必生成新的密钥来执行此操作，但如果您选择这样做，请跟踪哪些证书与哪些密钥匹配，以免混淆.)如果没有对于可能与主题授权合理相关的任何差异(例如 KeyUsage、ExtendedKeyUsage、也许是 Policy、也许是 Constraints)，我们无法帮助查看带有 openssl x509 <cert -noout -text 的证书扩展，甚至可能是非标准的东西.

If the issuer of your cert does match desiredCAs, compare its subject to the working (test-P12) one: are they in similar format? are there any components in the working one not present in yours? If they allow it, try generating and submitting a new CSR with a subject name exactly the same as the test-P12 one, or as close as you can get, and see if that produces a cert that works better. (You don't have to generate a new key to do this, but if you choose to, keep track of which certs match which keys so you don't get them mixed up.) If that doesn't help look at the certificate extensions with openssl x509 <cert -noout -text for any difference(s) that might reasonably be related to subject authorization, like KeyUsage, ExtendedKeyUsage, maybe Policy, maybe Constraints, maybe even something nonstandard.

如果所有其他方法都失败了，请询问服务器操作员他们的日志对问题的描述，或者您是否有权查看日志.

If all else fails, ask the server operator(s) what their logs say about the problem, or if you have access look at the logs yourself.

这篇关于尝试使用客户端证书时解决 sslv3 警报握手失败的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！