基于证书的认证基础

Posted 2023-04-13

【中文标题】基于证书的认证基础

【英文标题】：Fundamental of certificate based authentication

【发布时间】：2013-10-16 08:03:19

【问题描述】：

我搜索了很多，找到了很多关于如何在 wcf 中实现基于证书的身份验证的答案。但我的问题与它的基本原理有关。

在生产中实施基于证书的身份验证时，客户端是否提供其证书，服务器需要将其添加到其受信任的人员存储中？或者服务器提供证书（由服务器签名）。

我猜在配置 wcf 服务器时，我们只是配置证书位置和存储。我们从不将其与任何域绑定。因此，任何出示此证书的客户都可以访问我的服务。如果证书需要绑定到域。他们为什么我们不能只允许来自该域的所有请求。

当客户端调用 wcf 服务时，它会出示其证书。这个证书是否只携带公钥？并且该证书是否会被盗（因为它在网络上传播）并被黑客用来消费网络服务。

我知道 ssl 是如何工作的。在 ssl 的情况下，浏览器会处理所有这些事情，但在 wcf 服务的情况下（当我们只想允许特定客户端访问我们的服务时）它是如何被管理的。

提前致谢。

让我说得简单点：

我想创建一个 Web 服务，并且我希望三个客户端（A、B 和 C）可以使用它。我想通过证书对这三个客户端进行身份验证。在设置时，这些客户是否需要将他们的证书发送给我。或者我必须为他们创建证书？客户是否也会分享他们的私钥（在设置时） 我是否需要将这些证书放入受信任的人员存储中？ 当他们请求 Web 服务时，他们将出示他们的证书（仅带有公钥）。如果他们只提供公钥，黑客可以窃取这个公钥并请求我的网络服务。我的网络服务将如何区分黑客/实际客户端。

【参考方案1】：

在生产中实施基于证书的身份验证时，客户端是否提供其证书，服务器需要将其添加到其受信任的人员存储中？或者服务器提供证书（由服务器签名）。

在安全服务中，服务器证书是强制性的。客户端证书是可选的。服务器可以配置为忽略、接受或要求客户端证书。

我想在配置 wcf 服务器时，我们只是配置证书位置和存储。我们从不将其与任何域绑定。因此，任何出示此证书的客户都可以访问我的服务。如果证书需要绑定到域。他们为什么我们不能只允许来自该域的所有请求。

不确定如何在没有客户端证书的情况下绑定到域。你的意思是反向DNS查找？这需要一个 IP 地址，恶意用户可以欺骗它。

通过客户端证书限制访问的典型方法是将客户端证书中的一个字段（通常是主题或域）映射到用户帐户。您可以有一对一的映射（每个客户端证书代表一个用户）或多对一的映射（如果客户端有一个在列表中的证书，他被视为某个用户）。如果证书未映射，则用户将被视为匿名用户。更多信息here 假设您使用的是 IIS。

当客户端调用 wcf 服务时，它会出示其证书。这个证书是否只携带公钥？并且该证书是否会被盗（因为它在网络上传播）并被黑客用来消费网络服务。

您在安装过程中处理的证书文件包含公钥和私钥。证书本身包含在该文件中；它包含一个包含公钥和 MAC 签名的有效负载，但不包含私钥。

私钥被放入安全存储中，绝不会在任何 HTTP 请求中发送。只有证书（及其公钥）通过网络发送。不发送整个文件。

编辑以回答更多问题

我想创建一个 Web 服务，并且我希望三个客户端（A、B 和 C）可以使用它。我想通过证书对这三个客户端进行身份验证。在设置时，这些客户是否需要将他们的证书发送给我。或者我必须为他们创建证书？

在设置期间，客户端证书必须由证书颁发机构 (CA) 生成。实际上，您可以充当从根 CA（例如 Verisign）获得授权的中间 CA（用于生产证书）。为此，您必须向根授权请求证书。他们将向您颁发带有自己公钥的证书，并为您提供私钥，以便您能够生成自己的证书并进行数字签名。您通常需要为此特权付费。

此外，您还可以成为自己的根 CA！这在开发阶段很常见。基本上，您生成自己的公钥和私钥并开始生成自己的证书。这些被称为self-signed certificates。作为您自己的 CA 的不利方面是没有人会识别您的公钥，因此为了让任何人使用您的证书，他们需要您手动将您添加到他们的受信任根权限列表中。

客户是否也会共享他们的私钥（在设置时）

不，在整个 PKI 中，没有人与任何人共享私钥。曾经。这正是它被称为私钥的原因。唯一的例外是当您是证书颁发机构并且您正在生成私钥以创建证书时。在这种情况下，私钥在处理过程中必须小心保护。它永远不会作为 SSL 通信的一部分通过网络发送。

我是否需要将这些证书放入受信任的人员存储中？

是和不是。如果您使用的是自签名证书，可以。如果您使用的证书由 CA 签名，而该 CA 又具有由根 CA 签名的证书，则根 CA 也必须在受信任的根权限列表中，但您可能不必添加它.它应该自动在那里。这就是使用受信任的根权限的全部目的——每个人都应该知道它们并且应该识别它们的公钥。根证书通常在安装期间自动分发给浏览器，并使用浏览器的补丁和更新服务保持最新。

当他们请求网络服务时，他们将出示他们的证书（仅带有公钥）。如果他们只提供公钥，黑客可以窃取这个公钥并请求我的网络服务。我的网络服务将如何区分黑客/实际客户端。

这是一个很好的问题。

认识到 SSL 握手不仅仅包括共享证书，这一点很重要。除其他外，还有一个挑战/响应步骤。以下是它的工作原理：

您的服务器将生成一个随机数或时间戳（“挑战”）并将其发送到您的浏览器，挑战它对其进行加密。然后，浏览器将使用私钥（它只能访问）对质询进行加密。然后将此“响应”发送回服务器进行验证。服务器使用客户端证书中的公钥来解密响应。由于只有客户端拥有私钥，并且由于公钥是公开的且可验证的（因为它包含在签名且防篡改的证书中），因此服务器可以判断响应必须已由与客户端关联的客户端加密证书。而且由于挑战是由服务器生成的，并且每次都不同，因此黑客无法通过重放先前挑战的响应来冒充客户端。

【讨论】：

很好的解释。我已经编辑了我的问题。如果您也能对此有所了解，那就太好了。

非常感谢约翰！但是你错过了一个非常重要的观点。我只想允许 A、B 和 C 访问我的 Web 服务（而不是其他任何人）。由于许多其他人将拥有由 CA 签署的有效证书。我应该在哪里定义只允许 A、B 和 C 的证书。

请参阅我的答案部分，开头是“通过客户端证书限制访问的典型方法是将客户端证书中的一个字段（通常是主题或域）映射到用户帐户。 "提供特定配置说明的链接。希望这会有所帮助。

什么挑战-响应步骤？客户端在 CertificateVerify 消息中提供了对他的证书和握手消息的数字签名，由他的私钥签名。请参阅 RFC 2646 和后续版本。该文件的哪里有质询-响应信息？ A. 无处。

我认为您的意思是 RFC 2246。挑战在于对话本身，而响应就是签名。 OP 要理解的一点是签名的输入包含客户端未完全选择的熵。但你是对的，我们可以深入了解更多细节。

【参考方案2】：

在生产环境中实施基于证书的身份验证时，客户端是否提供其证书，服务器需要将其添加到其受信任的人员存储中？

是的，如果服务器要求它，否则没有。

或服务器提供证书（由服务器签名）。

总是。这些并不相互排斥。两者都可能发生。

我想在配置 wcf 服务器时，我们只是配置证书位置和存储。我们从不将其与任何域绑定。因此，任何出示此证书的客户都可以访问我的服务。如果证书需要绑定到域。他们为什么我们不能只允许来自该域的所有请求。

这一切我都猜不透。

当客户端调用 wcf 服务时，它会出示其证书。

如果服务器要求它。

这个证书是否只携带公钥？

是的。

并且该证书是否可以被盗（因为它在网络上传播）并被黑客用来消费网络服务。

不，因为它只包含公钥。

编辑回复“让我简单点”：

在设置时，这些客户是否需要将他们的证书发送给我。

仅当它们是自签名的。

或者我必须为他们创建证书？

这是另一种可能性，但您必须成为迷你 CA（证书颁发机构）。太宽泛了。

客户是否也会共享他们的私钥（在设置时）

绝对不是。

我是否需要将这些证书放入受信任的人员存储中？

没有“值得信赖的人商店”这样的东西。有一个受信任的证书 存储，它通常只包含 CA 证书。如果它们是自签名的，您只需要添加实际的客户端证书。如果他们的 CA 证书不存在，您可能需要添加它。

当他们请求网络服务时，他们将出示他们的证书（仅带有公钥）。如果他们只提供公钥，黑客就可以窃取此公钥并请求我的网络服务。

我已经回答过了。没有。

我的网络服务将如何区分黑客/实际客户端。

他们不会“仅仅”出示他们的证书：他们还将在证书上提供由他们的私钥签名的数字签名。仅拥有证书对攻击者来说毫无价值。如果没有私钥，他们甚至无法通过 TLS 握手。您的网络服务甚至不会看到它们。

【讨论】：

+1 出于兴趣，为什么服务器不要求客户端证书？谢谢

默认不询问。需要告诉它这样做。大多数情况下，服务器不关心客户端是谁（例如，允许匿名访问的公共网站），或者使用不同形式的身份验证，例如带有用户名/密码的登录表单，几乎普遍用于 HTTP。大多数客户端，即浏览器，甚至没有客户端证书。

EJP- 我已更新文本以使问题更清晰。你能不能给它增加一些价值。