主页 / computer / 问题 / 1729646
Accepted
AlMo320
Asked: 2022-07-03 22:13:51 +0800 CST

PolarProxy 生成 SAN 证书生成 curl 错误

  • 772

我使用 -v 运行 curl 7.58.0（参见附图中的版本），得到的结果表明证书中的 CN=example.com 正常，但是 curl 找不到匹配的 subjectAltName。是否有禁用此检查的开关或参数，或者我是否应该假设问题出在 PolarProxy 上（尝试从此页面安装）。它确实适用于 -k/--insecure 标志。我正在执行安装 inetsim 和 PolarProxy 以进行恶意软件分析的步骤。我的远程客户端也无法通过 https 或 smtps 进行连接，因此我正在尝试解决此屏幕截图中出现的错误。这是 ubuntu 服务器 18.04。

* TLSv1.2 (IN), TLS header, Supplemental data (23):

* TLSv1.3 (IN), TLS handshake, CERT verify (15):

* TLSv1.2 (IN), TLS header, Supplemental data (23):

* TLSv1.3 (IN), TLS handshake, Finished (20):

* TLSv1.2 (OUT), TLS header, Finished (20):

* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):

* TLSv1.2 (OUT), TLS header, Supplemental data (23):

* TLSv1.3 (OUT), TLS handshake, Finished (20):

* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384

* ALPN, server did not agree to a protocol

* Server certificate:

*  subject: CN=example.com

*  start date: Jul  2 20:44:34 2022 GMT

*  expire date: Jul  3 20:44:34 2023 GMT

*  subjectAltName does not match example.com

* SSL: no alternative certificate subject name matches target host name 'example.com'

* Closing connection 0

* TLSv1.2 (OUT), TLS header, Supplemental data (23):

* TLSv1.3 (OUT), TLS alert, close notify (256):

curl: (60) SSL: no alternative certificate subject name matches target host name 'example.com'

More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

从我在远程客户端上可以看出，证书是由 PolarProxy 生成的'Subject Alternative Name' = 'DNS Name=CN=example.com'，在我看来它看起来不合法，curl 似乎反对。

PolarProxy 可执行文件上似乎没有任何开关来抑制 x509 证书中伪造（我认为）SAN 元素的生成。

任何有 PolarProxy 经验并可能让我知道发生了什么的人，请这样做。感谢所有帮助。

proxy curl

2 个回答

  1. 不，没有选项可以仅禁用 SAN 检查。对于 HTTPS，SAN 扩展不必存在1，但如果存在，那么它总是优先于 Subject CN - 在这一点上，它对于 HTTPS 客户端几乎是强制性行为（技术上自 2000 年的 RFC 2818 以来一直存在 -虽然对于其他基于 TLS 的协议来说仍然不是一个硬“必须”，但它也已经到了那里）。因此，PolarProxy 确实在生成一个错误的证书，--insecure这正是您所要求的。

    但是我刚刚尝试了 PolarProxy 0.9.6.0，我没有看到这里的问题——它完全模仿了代理本身从上游服务器接收的证书，包括复制与真实证书相同的 SAN。

    因此，如果您将“CN=”视为 SAN 的一部分，则很可能真实服务器的证书也格式不正确......

    1由公共CA运营的“CA/浏览器论坛”制定的证书颁发策略已经要求所有公共HTTPS证书都有一个SAN；如果我没记错的话，他们甚至不鼓励将任何 CN 放入主题中。

    CA/B 颁发规则不适用于私人运营的 CA（例如您的 MITM 代理），并且 Web 浏览器通常不会对本地安装的根执行它们（非 Web TLS 客户端更不严格），因此从技术上讲 SAN 仍然是可选的对于 HTTPS，尽管靠近 CA/B 配置文件总是一个好主意。

    但是，无论 CA 类型如何，HTTPS RFC 中设置的证书验证规则仍然适用，因此如果您的代理确实生成了 SAN 扩展，那么它必须是有效的 SAN。

    • 2
  2. Best Answer

    不正确的主题备用名称 (SAN) 是由于 PolarProxy 0.9.6 版中引入的错误。由于您的错误报告，它现在已在 0.9.7 版中得到修复。此错误仅影响 PolarProxy 的--terminate模式，在该模式下，PolarProxy 无法访问域的原始 X.509 证书。在这种模式下，PolarProxy 从头开始​​生成叶证书，而不是创建对真实证书稍作修改的克隆。正如您所注意到的，SAN 被错误地设置为，DNS Name=CN=example.com而不是DNS Name=example.com由于这个错误。

    感谢您报告此问题@AlMo320！

    • 0

相关问题