☰

PolarProxy 生成 SAN 证书并产生 curl 错误

tag-icon • tag-icon proxy curl
PolarProxy 生成 SAN 证书并产生 curl 错误

我运行的是 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 经验并可能让我知道发生了什么的人，请告诉我。非常感谢大家的帮助。

答案1

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

感谢您报告此问题@AlMo320！

答案2

不，没有仅禁用 SAN 检查的选项。对于 HTTPS，SAN 扩展不必存在1，但如果存在是存在，则它始终优先于主题 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。

相关内容