在 Win32 中验证 SSL 证书的正确方法是什么？

Question

我想使用 C++ 在 Win32 中验证 SSL 证书。我想我想使用 Cert* API，以便获得 Windows 证书存储的好处。这就是我想出的办法。

• 正确吗？
• 有更好的方法吗？
• 我做错了什么吗？

bool IsValidSSLCertificate( PCCERT_CONTEXT certificate, LPWSTR serverName )
{
    LPTSTR usages[] = { szOID_PKIX_KP_SERVER_AUTH };

    CERT_CHAIN_PARA params                           = { sizeof( params ) };
    params.RequestedUsage.dwType                     = USAGE_MATCH_TYPE_AND;
    params.RequestedUsage.Usage.cUsageIdentifier     = _countof( usages );
    params.RequestedUsage.Usage.rgpszUsageIdentifier = usages;

    PCCERT_CHAIN_CONTEXT chainContext = 0;

    if ( !CertGetCertificateChain( NULL,
                                   certificate,
                                   NULL,
                                   NULL,
                                   &params,
                                   CERT_CHAIN_REVOCATION_CHECK_CHAIN,
                                   NULL,
                                   &chainContext ) )
    {
        return false;
    }

    SSL_EXTRA_CERT_CHAIN_POLICY_PARA sslPolicy = { sizeof( sslPolicy ) };
    sslPolicy.dwAuthType                       = AUTHTYPE_SERVER;
    sslPolicy.pwszServerName                   = serverName;

    CERT_CHAIN_POLICY_PARA policy = { sizeof( policy ) };
    policy.pvExtraPolicyPara      = &sslPolicy;

    CERT_CHAIN_POLICY_STATUS status = { sizeof( status ) };

    BOOL verified = CertVerifyCertificateChainPolicy( CERT_CHAIN_POLICY_SSL,
                                                      chainContext,
                                                      &policy,
                                                      &status );

    CertFreeCertificateChain( chainContext );
    return verified && status.dwError == 0;
}

Answer 1

您应该了解 RFC3280 第 6.1 节 和 RFC5280 第 6.1 节。两者都描述了验证证书路径的算法。尽管 Win32 API 会为您处理一些事情，但总体了解该过程仍然很有价值。

另外，这里有一个（在我看来）非常值得信赖的参考： Chromium证书验证码。

总的来说，我认为您的代码没有错误。但如果我是你，我会研究/更改以下几件事：

1. 单独的公用名验证

Chromium 独立于链验证证书公用名。显然他们已经注意到了一些问题。请参阅注释以了解其基本原理：

cert_verify_proc.win.cc:731 // Certificate name validation happens separately, later, using an internal
cert_verify_proc.win.cc:732 // routine that has better support for RFC 6125 name matching.

2. 使用 CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT

Chromium 还使用 CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT 标志而不是 CERT_CHAIN_REVOCATION_CHECK_CHAIN。实际上，在找到他们的代码之前，我就开始研究这一点，这增强了我的信念，即您应该使用 CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT。

尽管上述两个 RFC 都指定自签名信任锚不被视为链的一部分，但 CertGetCertificateChain 的文档 (http://msdn.microsoft.com/en-us/library/windows/desktop/aa376078(v=vs.85).aspx) 说它建立了一条链，如果可能的话，受信任的根证书。受信任的根证书被定义为（在同一页面上）作为受信任的自签名证书。

这消除了 *EXCLUDE_ROOT 可能跳过非根信任锚的撤销检查的可能性（Win32 实际上要求信任锚进行自签名，即使任何 RFC 都没有要求。尽管这没有正式记录）。

现在，由于根 CA 证书无法撤销自身（无法签署/验证 CRL），因此在我看来这两个标志是相同的。

我做了一些谷歌搜索，偶然发现了这个论坛帖子：http://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/9f95882a-1a68-477a-80ee-0a7e3c7ae5cf/x509replicationflag-question?forum=windowssecurity。 .NET 产品组的一名成员（据说）声称，如果根是自签名的，那么这些标志在实践中的作用是相同的（理论上，如果根证书包含 CDP 扩展，则 ENTIRE_CHAIN 标志将检查根证书是否被吊销，但是不可能发生）。

他还建议使用 *EXCLUDE_ROOT 标志，因为如果自签名根 CA 包含 CDP 扩展，则另一个标志可能会导致不必要的网络请求。

不幸的是：

• 我找不到任何关于这两个标志之间差异的官方记录解释。
• 尽管链接的讨论可能适用于 .NET 底层的相同 Win32 API 标志，但不能保证。

为了完全确定可以使用 CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT，我在 google 上进行了更多搜索，找到了我在回复顶部链接到的 Chromium SSL 证书验证代码。

作为额外的好处，Chromium cert_verify_proc_win.cc 文件包含以下有关 IE 验证代码的提示：

618: // IE passes a non-NULL pTime argument that specifies the current system
619: // time.  IE passes CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT as the
620: // chain_flags argument.

不确定他们如何知道这一点，但此时我觉得使用 CERT_CHAIN_REVOCATION_CHECK_EXCLUDE_ROOT 很舒服。

3. 接受的不同证书用法

我注意到 Chromium 还指定了 3 种证书用法，而不是 1 种：

szOID_PKIX_KP_SERVER_AUTH,
szOID_SERVER_GATED_CRYPTO,
szOID_SGC_NETSCAPE

根据我通过 Google 收集到的信息，较旧的 Web 浏览器可能需要其他用法，否则它们可能无法建立安全连接。

如果 Chromium 认为适合包含这些用法，我会效仿。

请注意，如果更改代码，还应将 params.RequestedUsage.dwType 设置为 USAGE_MATCH_TYPE_OR 而不是 USAGE_MATCH_TYPE_AND。

——

我现在想不出任何其他评论。但如果我是你，我会自己检查 Chromium 源代码（也许还有 Firefox）——只是为了确保我没有错过任何东西。

Answer 2

我认为最好的答案取决于您到底想做什么。

我要提醒您的是，SSL 基于两个端点都需要安全连接的假设。如果任一端点对维护安全性不感兴趣，那么就没有端点。

将字节码放入分布式代码中只需为此函数返回 true 即可，这是一项微不足道的工作。这就是 Windows 将大量验证移入内核的原因。但他们没有预料到人们会在虚拟硬件上运行 Windows，这使得绕过操作系统变得微不足道。

现在考虑一下您希望从某个来源获得证书，但假装无法从可靠来源提供相同的信息。然后交给你。因此，您不能依赖证书来“证明”任何人是特定的任何人。

从证书获得的唯一保护是防止外部人员（而不是端点）破坏所传输消息的机密性。

任何其他用途都注定会失败，并且最终会失败并带来潜在的灾难性后果。

抱歉发了这么大的帖子。评论区有字数限制。

Answer 3

函数CertGetCertificateChain 和CertVerifyCertificatePolicy 一起使用。这部分是正确的。

对于 CertGetCertificateChain，如果您想要检查吊销情况，则可以将标志设置为以下三个中的任意一个：

• CERT_CHAIN_REVOCATION_CHECK_END_CERT
• CERT_CHAIN_REVOCATION_CHECK_CHAIN
• CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT。

只能使用其中之一，这三个选项不能进行ORed。除了这些标志之一之外，您还可以考虑如何创建链；使用本地缓存或仅使用CRL或OCSP。对于这些注意事项阅读此链接。

执行函数时出错，或者更简单地说，如果返回值为0，这并不意味着证书无效，而是您无法执行该操作。要获取错误信息，请使用GetLastError()。所以你返回 false 的逻辑是错误的，它更多的是抛出错误并让客户端代码决定是重试还是继续做其他事情。

在此链接中有名为“对错误进行分类”的部分，请阅读。基本上你应该检查 certChainContext->TrustStatus.dwErrorStatus。这里将对错误状态列表进行“或”运算。请检查 CERT_TRUST_STATUS msdn 参考。所以在这里你可以拥有你的业务逻辑。例如，如果您发现无法执行证书吊销检查的值 (CERT_TRUST_REVOCATION_STATUS_UNKNOWN | CERT_TRUST_IS_OFFLINE_REVOCATION) 的错误状态，您可以选择决定您想要什么（放弃证书或仍然标记）视为无效）。

因此，在调用 CertVerifyCertificatePolicy 之前，您可以选择放弃或已经标记验证错误。

如果您选择使用CertVerifyCertificatePolicy，那么 chromium 代码是关于如何将policy_status.dwError 映射到您的错误类/枚举的绝佳参考。