解决尝试使用客户端证书时sslv3警报握手失败的问题

Question

我正在尝试连接到一个需要证书才能获得授权的服务。这个过程是我向服务发送一个CSR文件。该服务对CSR进行签名，并向我发送用于连接的证书。

1. 我通过以下命令行生成CSR： openssl req -new -nodes -newkey rsa:2048 -keyout cert.key -out cert.csr
2. 我把cert.csr的内容发给了他们。他们生成客户端证书，我得到了一个PEM文件。
3. 现在，我尝试使用SSLCERT中的证书文件来连接curl()，并将来自cert.key的私钥作为CURLOPT_SSLKEY -(我在步骤1中得到)。
4. 失败：error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure

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

当我尝试使用接收到的测试证书(包括来自服务的私钥)(自签名证书)时，工作。但是，当我使用他们从我的CSR生成的证书，然后使用我的私钥作为密钥时，就会出现握手失败的错误。

因此，我知道这与openssl / curl不支持v3/TLS等无关，其他人在研究解决方案时发现了他们的问题。

下面是我运行的内容：

  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

Answer 1

不是一个明确的答案，而是太多的不适合于评论：

我假设他们给了您一个证书，它要么有错误的发行者(尽管他们的服务器可以使用更具体的警报代码)，要么是错误的主题。我们知道证书与您的私钥匹配--因为curl和openssl client都对它们进行了配对，而没有抱怨不匹配；但我们实际上并不知道它与它们想要的CA匹配--因为您的curl使用openssl，而openssl客户端没有强制要求配置的客户端证书与certreq.CAs匹配。

在测试的openssl x509 <clientcert.pem -noout -subject -issuer和测试P12的证书上执行相同的操作。执行openssl s_client (或检查您所做的)并在Acceptable client certificate CA names下面查看；那里的名称或其中之一应该匹配(完全正确！)你方证书的发行人。如果不是，那很可能是你的问题，你需要与他们检查，你提交了你的CSR到正确的地方，以正确的方式。也许他们在不同的地区有不同的制度，或业务线，或测试与刺激，或主动与待定，等等。

如果您证书的颁发者确实匹配所需的in，请将其主题与工作(test-P12)的内容进行比较:它们是否具有类似的格式？你的工作部件中有没有不存在的部件？如果他们允许，尝试生成和提交一个新的CSR，其主题名称与测试P12完全相同，或者尽可能接近，看看它是否产生了一个更好的证书。(您不需要生成一个新的键就可以做到这一点，但是如果您选择这样做的话，请跟踪哪些证书匹配哪个键，这样就不会混淆它们。)如果这无助于查看openssl x509 <cert -noout -text的证书扩展，看看可能与主题授权(如KeyUsage、ExtendedKeyUsage、可能的策略、可能的约束，甚至是一些不标准的东西)有关的任何差异。

如果所有其他操作都失败了，请询问服务器操作员他们的日志对问题的看法，或者如果您有访问权限，请自己查看日志。

Answer 2

在客户端证书的同时应该发送什么SSL私钥？

(没有:)

客户端证书最吸引人的地方之一是它不会做一些愚蠢的事情，比如将纯文本中的秘密(如密码)传输给服务器(HTTP )。密码仍然用于解锁客户端证书的密钥，只是在交换或tp验证客户端期间不直接使用。

相反，客户端为该会话选择一个临时的随机密钥。然后，客户端用他的证书在临时的随机密钥上签名，并将其发送给服务器(一些人放弃)。如果一个坏人截取了任何东西，它是随机的，所以它不能在将来使用。它甚至不能在服务器上第二次运行协议，因为服务器也会选择一个新的随机值。

失败:错误:14094410:SSL routines:SSL3_READ_BYTES:sslv3警报握手失败

使用TLS1.0及以上版本，并使用服务器名称指示。

你没有提供任何代码，所以我不清楚如何告诉你该怎么做。相反，下面是测试它的OpenSSL命令行：

openssl s_client -connect www.example.com:443 -tls1 -servername www.example.com \
    -cert mycert.pem -key mykey.pem -CAfile <certificate-authority-for-service>.pem

您还可以使用-CAfile来避免“验证error:num=20”。参见，例如，连接到error:num=20时“验证gateway.sandbox.push.apple.com”。

Answer 3

在/etc/crypto-policies/config 8系统上，我的解决方案是通过验证CentOS读取默认的默认值而不是任何其他值来检查系统密码策略。

将此值更改为默认后，运行以下命令：

/usr/bin/update-crypto-policies --set DEFAULT

重新运行curl命令，它应该可以工作。