当InitializeSecurityContext失败并使用SEC_E_WRONG_PRINCIPAL

如何解决当InitializeSecurityContext失败并使用SEC_E_WRONG_PRINCIPAL

当服务器提供的证书上的名称均与服务器名称pszTargetName参数都不匹配时，InitializeSecurityContext（Schannel）因SEC_E_WRONG_PRINCIPAL而失败。

如果您具有完整的安全上下文，则可以通过调用SECPKG_ATTR_REMOTE_CERT_CONTEXT的QueryContextAttributes来获取服务器的证书。如果将失败的InitializeSecurityContext协商中部分形成的安全上下文用作phContext参数，则对QueryContextAttributes的调用将失败，并显示SEC_E_INVALID_HANDLE。

在这种情况下，客户端是否可以访问服务器发送的证书，以便我们在证书上报告名称？

NB。如果我们真的真的想要，我们可以重做协商，指定ISC_REQ_MANUAL_CRED_VALIDATION，然后在那个安全上下文的上调用QueryContextAttributes（然后立即销毁它），但这似乎愚蠢的。

解决方法

您可以尝试在 SCH_CRED_NO_SERVERNAME_CHECK 中指定 SCH_CREDENTIALS.dwFlags。您可能必须与 SCH_CRED_SNI_CREDENTIAL 结合使用。但是，您必须在检查名称后通过在代码中发送 TLS 警报来中止连接。这些链接可能会有所帮助：
https://github.com/tokio-rs/tokio-tls/issues/32
https://social.msdn.microsoft.com/Forums/vstudio/en-US/0b7e3858-00ef-41f9-8772-dd1896e519ac/how-to-add-sni-client-hello-extension-using- schannel-api

否则，如果您希望内联执行此操作，则可能必须在手动协商时对接收到的数据进行手动 ASN.1 解析以查找证书。此函数可能有用：CertCreateCertificateContext 。