在生产中实施基于证书的身份验证时，客户端是否提供其证书，服务器需要将其添加到其受信任的人员存储中？或服务器提供证书（由服务器签名）。
在安全服务中，服务器证书是强制性的。客户端证书是可选的。服务器可以配置为忽略、接受或要求客户端证书。
我想在配置 wcf 服务器时，我们只是配置证书位置和存储。我们从不将其与任何域绑定。因此，任何出示此证书的客户都可以访问我的服务。如果证书需要绑定到域。他们为什么我们不能只允许来自该域的所有请求。
不确定如何在没有客户端证书的情况下绑定到域。你的意思是反向DNS查找？这需要一个 IP 地址，恶意用户可以欺骗它。
通过客户端证书限制访问的典型方法是将客户端证书中的一个字段（通常是主题或域）映射到用户帐户。您可以有一对一的映射（每个客户端证书代表一个用户）或多对一的映射（如果客户端有一个在列表中的证书，他被视为某个用户）。如果证书未映射，则用户将被视为匿名用户。假设您使用的是 IIS，请在此处了解更多信息。
当客户端调用 wcf 服务时，它会出示其证书。这个证书是否只携带公钥？并且这个证书可以被盗（因为它在网络上传播）并被黑客用来消费网络服务。
您在安装过程中处理的证书文件包含公钥和私钥。证书本身包含在该文件中；它包含一个包含公钥和 MAC 签名的有效负载，但不包含私钥。
私钥被放入安全存储中，并且永远不会在任何 HTTP 请求中发送。只有证书（及其公钥）通过网络发送。不发送整个文件。
编辑以回应更多问题
我想创建一个 Web 服务，并且我希望三个客户端（A、B 和 C）可以使用它。我想通过证书对这三个客户端进行身份验证。在设置时，这些客户是否需要将他们的证书发送给我。或者我必须为他们创建证书？
在设置期间，客户端证书必须由证书颁发机构 (CA) 生成。实际上，您可以充当从根 CA（例如 Verisign）获得授权的中间 CA（用于生产证书）。为此，您必须向根授权请求证书。他们将向您颁发带有自己的公钥的证书，并为您提供私钥，以便您能够生成自己的证书并进行数字签名。您通常必须为此特权付费。
此外，您还可以成为自己的根 CA！这在开发阶段很常见。基本上，您生成自己的公钥和私钥并开始生成自己的证书。这些被称为自签名证书。作为您自己的 CA 的不利方面是没有人会识别您的公钥，因此为了让任何人使用您的证书，您必须手动将您添加到他们的受信任根权限列表中。
客户是否也会共享他们的私钥（在设置时）
不，在整个 PKI 中，没有人与任何人共享私钥。曾经。这正是它被称为私钥的原因。唯一的例外是当您是证书颁发机构并且您正在生成私钥以创建证书时。在这种情况下，私钥在处理过程中必须小心保护。它永远不会作为 SSL 通信的一部分通过网络发送。
我是否需要将这些证书放入受信任的人员存储中？
是和不是。如果您使用的是自签名证书，可以。如果您使用的证书由 CA 签名，而该证书又具有由根 CA 签名的证书，则根 CA 也必须在受信任的根权限列表中，但您可能不必添加它. 它应该自动在那里。这就是使用受信任的根权限的全部目的——每个人都应该知道它们并且应该识别它们的公钥。根证书通常在安装期间自动分发给浏览器，并使用浏览器的补丁和更新服务保持最新。
当他们请求网络服务时，他们将出示他们的证书（仅带有公钥）。如果他们只提供公钥，黑客可以窃取这个公钥并请求我的网络服务。我的网络服务将如何区分黑客/实际客户端。
这是一个很好的问题。
认识到 SSL 握手不仅仅包括共享证书，这一点很重要。除其他外，还有一个挑战/响应步骤。以下是它的工作原理：
您的服务器将生成一个随机数或时间戳（“挑战”）并将其发送到您的浏览器，挑战它对其进行加密。然后，浏览器将使用私钥（它只能访问）对质询进行加密。然后将此“响应”发送回服务器进行验证。服务器使用客户端证书中的公钥来解密响应。由于只有客户端拥有私钥，并且由于公钥是公开的且可验证的（因为它包含在签名且防篡改的证书中），因此服务器可以判断响应必须已由与客户端关联的客户端加密证书。而且由于挑战是由服务器生成的，并且每次都不同，因此黑客无法通过重放先前挑战的响应来冒充客户端。