使用PKI证书进行Web身份验证

我从概念的角度（即私钥/公钥）背后的数学，使用哈希和加密来签署证书，使用交易或文档进行数字签名等，对PKI相当了解。 C库与用于安全通信和身份验证的证书一起使用。我也非常熟悉openssl命令行工具。

但是，我对基于Web的启用PKI的项目几乎没有经验，因此我试图设计和编写个人项目以更好地理解这一点。

要求

这是一家银行的网站。允许所有网上银行用户使用由一些已知CA（verisign，Thawte，entrust等）颁发的任何证书。银行不负责为用户购买证书。这些证书将用于银行网站的身份验证。平台/操作系统等仍未修复。

设计

我想知道什么是进行身份验证的最佳方法。

1. 我看到Apache有一种启用2种方式的SSL的方法-在这种情况下，我认为导航到该网站会自动向用户请求证书。但是我不确定这是否足够，因为似乎它所验证的只是证书是否由受信任的CA签名，还可能是证书是否位于证书主题行的白名单中，等等。但这还不够银行案例，因为您需要能够将bankuserid与证书相关联。

2. IIS似乎有一种方法可以让我为Active Directory中的每个用户存储证书。通过阅读几篇MSDN文章，我了解了这一点。您在IIS中打开2种方式的SSL，然后，当用户尝试导航到网站时，IIS将向浏览器发送带有已批准CA列表的请求，浏览器将允许用户从其证书库中选择适当的证书并将其发送到后端。我假设IIS将做2件事

   • 确保用户具有与证书相对应的私钥（通过掩盖协商）
   • IIS根据AD用户证书映射，将用户名报告给应用程序。

3. 通过调用加密函数显式地进行身份验证，而不是依赖于依赖于Web服务器的身份。

   • 显示一个用户屏幕，在该屏幕上他上传证书，并且应用程序确保用户具有与证书相对应的私钥（通过要求前端使用证书对某些字符串进行签名）。
   • 该应用程序具有数据库，其中存储了一些数据，该数据允许每个用户映射到其用户ID。这可能是
   • 与每个用户标识相对应的整个证书
   • 与每个用户ID对应的CA和证书序列号。

我想知道哪种是常用的方法？最佳做法是什么？如果我应该选择＃3，那么最好的方法是什么？

可以轻松与智能手机应用程序一起使用的功能将是额外的好处。

更新资料

让我澄清一下我的声明“自己编写身份验证部分”，因为某些答案似乎表明它已经被误解了-我的缺点是不清楚。

这并不意味着我自己写加密货币。这只是意味着我实际上将显式调用加密例程，而不是依赖IIS或任何其他Web服务器隐式地执行加密例程。

虽然我确实想逐个问题地回答，但我想我会逐个主题地讨论这个问题：

授权/认证

好，首先 对于您的示例，您同时需要：

• 身份验证 -证明用户就是他说的人。您选择了PKI，并将隐含的私钥证明作为您的身份验证。
• 授权 -用户与他被允许执行的操作的联系。这是登录和访问允许的帐户之间的连接点。证书到帐户和帐户访问功能的映射是授权。

在授权方面，您需要弄清楚将用户的主题DN连接到他们的银行帐户的过程。考虑到交易的重要性，您绝对希望为此制定一个强有力的流程，并且这里没有唯一正确的方法。您必须与银行（可能是律师）进行协商，以找出如何按照政策进行操作。

SSL，客户端/服务器身份验证，私钥证明

SSL协议始终包括服务器身份验证，以及用于客户端授权的其他可选设置。您对＃1的看法是正确的，因为Apache提供了一个设置，可以通过PKI添加“客户端身份验证”，并且可以为其提供信任的CA列表。在需要通过PKI进行客户端身份验证的SSL会话的设置过程中-您将获得私钥证明。

选项＃1或选项＃2将提供此功能-可以通过这种方式配置Apache和IIS。最佳实践是明智的选择，我会选择其中一种来推广您自己的解决方案。＃3危险地接近“不要自己编写密码”规则。假定您可以将事务与经过身份验证的SSL会话绑定在一起，则没有理由进行自己的事务。

另外-在选项＃1或选项＃2中，都有一种方法可以使您着手整个证书，并从那里到达证书的任何部分。通常，主题DN和/或证书序列号用于确定用户身份以进行授权。

在“常见用法”方面-所有主要的Web服务器都很常见。可以使用客户端身份验证SSL配置IIS，Apache，Tomcat和许多其他配置。那里的决定很大程度上取决于整体实施情况。主要的Web服务器都具有访问SSL会话中提供的证书的方法，这是更详细的验证所需要的。

证书验证插件

至少，您需要：

• 设置SSL会话
• 提取证书（大多数Web服务器将检查证书的签名和私钥证明）
• 验证证书的有效日期（不是任何Web服务器提供的日期）
• 执行此证书可以访问的帐户的授权检查

考虑到银行业务的高风险，您可能还需要验证证书的吊销状态-如果用户的私钥丢失或被盗，则应吊销其证书。

IIS可能具有进行OCSP或CRL验证的功能-它往往是一种更全面的（手持！）类型的系统，但我不记得要花时间了。我也不记得这是否会迫使您为此使用Microsoft产品。对于Apache，几乎可以肯定，您必须编写代码或添加OCSP / CRL检查。我相信它在SSL会话建立过程中会产生异常现象-通常在建立SSL会话时执行一次此检查。

授权书

在＃1与＃2上-没错，IIS具有一些内置功能，可以将SSL会话中提供的证书绑定到AD存储库。在这种情况下，Microsoft会加倍努力以使其易于购买和使用更多产品。:) IIS与AD之间的联系存在细微差别，这超出了此问题的范围，也超出了我的直接回忆。我已经用IIS和AD做过一些非常疯狂的事情，并且我的一般想法是，虽然您做的事情相对简单，但是却很简单，就像基于基于证书的用户名从AD存储库中提取用户名一样。当您遇到更复杂的数据存储问题，奇怪的AD查找以及使用PKI特别疯狂（但合法）的问题时，

即使使用IIS，也仍然可以-您需要在AD结构中或其他位置添加一些内容，以便将用户名绑定到银行帐户。通常在银行业务中，用户有多个帐户。并且2个用户可以拥有一个联合帐户，因此这是多对多关系。

对于＃1-是的，您需要编写自己的查找。您需要编写以下代码：-将证书连接到用户并将用户连接到用户银行帐户的数据库或LDAP层次结构。证书的唯一保证部分是序列号+颁发者DN。通常，主题DN会起作用，但并非在所有PKI系统中都可以保证。

这通常是开发人员使用PKI与Apache进行高端身份验证的方式。在许多此类系统中工作过之后，我还没有遇到过简单的授权重用的情况，因此我从来没有真正看到它是一个巨大的缺点-我将不得不以任一种方式进行专门的设置，因为角色/特权是从来都不容易。

这听起来像是＃1和＃3的混合-我的强烈建议是-使用您用于生成SSL会话的任何应用程序/ Web服务器的本机功能。这将使浏览器到服务器的证书查询设置以标准的最佳实践方式进行。从那里开始，使用Apache，您需要推出自己的授权系统。IIS将为您提供Microsoft的想法。

已知陷阱

做一堆浏览器测试。一年又一年，在浏览器之间，我发现使用SSL会话处理的陷阱。正确地将SSL会话链接到一系列网页请求并确保注销得到正确处理是最大的关注领域。服务器和浏览器软件都有很多关系。SSL足够稳定，以至于它可以正常工作时就可以正常工作，尽管可能存在IE与其他所有问题。

特别是，上次我这样做时，强制编码和会话超时的问题非常重要。

智能手机

好。运气。几乎是我能说的。我根本不是移动应用程序开发人员，但是到目前为止，我的印象是，在普通的智能手机中，PKI证书处理不达标或根本不存在。

我很想被证明是错误的。

个人证书可以很好地用于定期续订证书（其背后具有相当强大的过程），并且可以实现为客户喜欢的“无密码”身份验证

但失败的地方是

• 每张证书的费用
• 与现代浏览器的兼容性
• 最终用户提取证书并不安全地存储私钥

请注意，带有sha-2签名的现代个人证书不适用于iPad和许多现代浏览器上的Safari。这是因为个人证书从未真正像证书颁发机构的组织那样起飞。发行30,000个证书（我们的工作）的成本与某些硬件令牌类型的每个证书大致相同。

您允许客户找到自己的证书的策略并不是真的有效。如今很难找到个人证书的供应商，而且它们的价格非常昂贵-您需要确保业务案例有效，否则客户根本不会购买。

好吧，这里发生了很多事情。首先，如果端点不支持客户端证书身份验证，则它是无用的。因此，我们在Intrepidus上发表了一篇精彩的文章，内容涵盖了智能手机应用程序的客户端身份验证的基础知识。

接下来，让我强烈建议您不要编写自己的身份验证例程。有很多很棒的经过审查的库都可以解决这个问题。通过使用成熟的身份验证库运行，可以节省功能和安全性漏洞。为此，使用经过审查的成熟库绝对是最佳实践。

下一个最佳实践是使用目录来处理client：certificate映射。因此，您将研究AD或LDAP。如您所提到的，Windows和IIS为您提供了无缝的连接。IIS.net在配置IIS下的证书映射方面有不错的选择。

如果您使用Apache，那么开箱就不那么容易了。看起来mod_authz_ldap可以进行客户端证书映射，但是我个人还没有使用它。

因此，这使我们进入了实际实施此类工作的后勤阶段。您没有在用户证书上签名，因此您需要一个铁定的流程来使用户提交其证书并将您的应用程序发布到目录中。我希望看到两个因素，分别是密码验证和短信，或致电受信任的号码。我会向用户发送电子邮件，以告知他们证书已添加到他们的帐户。我会让用户通过应用程序中的帐户管理页面删除用户证书映射。

我将看看Google和Facebook在设置可信任设备的Cookie以避免两因素方面的作用。在允许仅证书身份验证之前，我将使用两因素进行新设备身份验证。

我还要考虑如何处理被撤销的用户证书。这意味着检查外部证书吊销列表（CRL）。如果客户端证书未定义CRL分发点，该怎么办？由于用户仅会使用少数几个CRL，您是否在用户登录时或作为工作的一部分定期检查CRL？

的确，这归结为：我怎么知道我可以相信用户的证书没有受到损害，以及我如何相信我可以将证书X映射到用户Y。