在 PKI 中支持带有 S/MIME 控件的 Outlook Web Access

  • 项目

 

上一次修改主题： 2006-09-11

在基于 Exchange 2003 的邮件安全系统中，大多数 S/MIME 功能是电子邮件客户端与 PKI 进行交互的结果。作为 PKI 管理员，您的配置选项和需求的主要信息源是特定的 PKI 文档。另外，您应该咨询电子邮件客户端管理员，以获取有关用于支持特定电子邮件客户端的 PKI 需求的信息。

凭借带有 S/MIME 控件的 Outlook Web Access，Exchange 2003 可提供 S/MIME 电子邮件客户端功能。此部分向 PKI 管理员提供有关将 PKI 与使用 S/MIME 控件的 Outlook Web Access 进行集成的信息。

Outlook Web Access 与数字证书

本部分详细描述带有 S/MIME 控件的 Outlook Web Access 如何在以下方面与数字证书进行交互：

  • 带有 S/MIME 控件的 Outlook Web Access 中的证书处理。
  • 带有 S/MIME 控件的 Outlook Web Access 和数字证书的检索。
  • 带有 S/MIME 控件的 Outlook Web Access 和证书验证。
  • 带有 S/MIME 控件的 Outlook Web Access 和 S/MIME 操作。
  • 带有 S/MIME 控件的 Outlook Web Access 和智能卡。
  • 带有 S/MIME 控件的 Outlook Web Access 和 S/MIME 加密功能。

带有 S/MIME 控件的 Outlook Web Access 中的证书处理

用户的 Exchange 服务器为所有证书提供数字证书验证。使用带有 S/MIME 控件的 Outlook Web Access 时，用户的 Exchange 服务器还执行大多数与公钥相关的证书处理。但是，当处理与用户的私钥相关的数字证书时，用户客户端系统上的 S/MIME 控件将获取存储于用户客户端系统上的数字证书。

让用户的 Exchange 服务器处理所有数字证书验证操作可以减少客户端系统与 Exchange 服务器之间必须传递的通信量，从而提高性能。因为只有用户的 Exchange 服务器必须配置成支持证书验证，所以证书管理已简化。由于客户端系统只提供证书存储，因此不需要在客户端系统上启用证书处理。让客户端系统存储带有用户私钥的数字证书可以确保用户的私钥永远不会通过网络发送出去。带有 S/MIME 控件的 Outlook Web Access 不直接处理私钥。相反，所有私钥处理都由操作系统执行。带有 S/MIME 控件的 Outlook Web Access 可与操作系统的加密功能进行交互。下图显示了带有 S/MIME 控件的 Outlook Web Access 的体系结构。

e3fc5d17-8881-4073-a552-9fe22b043348

如此图所示，使用带有 S/MIME 控件的 Outlook Web Access 时，证书处理是一系列所有权明确且独立的操作。用户的 Exchange 服务器处理所有证书验证处理，并获取大多数公钥的数字证书，而用户的客户端系统则存储任何带有私钥的数字证书。

用户的 Exchange 服务器依靠基本操作系统的证书存储来获取所有证书处理功能，这将使用用户 Exchange 服务器上 LocalSystem 帐户的个人证书存储。个人证书存储是用户配置文件中的 CryptoAPI My store。由于 Exchange 2003 需要 Microsoft Windows® 2000 Server 或 Windows Server 2003，而它们都提供个人证书存储，因此，在 Exchange 服务器上支持带有 S/MIME 控件的 Outlook Web Access 没有特殊的操作系统需求。

带有 S/MIME 控件的 Outlook Web Access 有下列需求：

  • Windows 2000 或更高版本（提供个人证书存储功能以存储带有私钥的数字证书）。
  • Internet Explorer 6 或更高版本（以利用安全增强功能）。

虽然 Windows 2000 之前的 Windows 版本以及 Internet Explorer 6 或更高版本以外的浏览器不能与带有 S/MIME 控件的 Outlook Web Access 一起使用，但它们可以与不带 S/MIME 控件的 Outlook Web Access 一起使用。

带有 S/MIME 控件的 Outlook Web Access 和数字证书的检索

虽然用户的 Exchange 服务器依靠 Windows 2000 或更高版本来处理证书验证，但它会检索数字证书以获取大多数公钥。带有 S/MIME 控件的 Outlook Web Access 将在用户的客户端系统上检索数字证书以获取私钥。

使用带有 S/MIME 控件的 Outlook Web Access 进行证书搜索

使用带有 S/MIME 控件的 Outlook Web Access 时，它和用户的 Exchange 服务器都根据下列条件搜索和匹配证书：

  • 将电子邮件路由地址与证书中找到的地址相匹配 用户的 Exchange 服务器或带有 S/MIME 控件的 Outlook Web Access 尝试将电子邮件路由地址与证书中找到的地址相匹配。并尝试将电子邮件路由地址与证书使用者相匹配。如果找不到匹配，则尝试将电子邮件路由地址与使用者备用名称相匹配。如果不能匹配电子邮件路由地址，则尝试基于目录中的简单邮件传输协议 (SMTP) 代理地址来匹配邮件路由地址。通过在注册表中设置 CertMatchingDoNotUseProxies 的值，可以禁止对 SMTP 代理地址的搜索。

    note注意：
    有关详细信息，请参阅与 Outlook Web Access S/MIME 控件相关的设置。

  • 确定证书的功能 如果找到使用者的多个证书，应复查每个证书的密钥用法，以确定证书有哪些用途（包括数字签名、邮件加密或二者兼有）。如果找到了具有与当前操作匹配的单一密钥用法的证书，则选择此证书，而不选择具有多个密钥用法的其他证书。例如，如果当前操作是数字签名，且找到两个证书，一个证书只将密钥用于数字签名，而另一个证书将密钥用于数字签名和加密，则选择只将密钥用于数字签名的证书。

  • 根据开始日期和过期日期选择证书 根据数字证书的开始日期和过期日期，只选择有效的数字证书。

  • 检查从智能卡传播的数字证书 当检索用户的私钥时，如果在用户的 Exchange 服务器上已设置了 SmartCardOnly 值，则只检查从智能卡传播的数字证书。

    note注意：
    有关详细信息，请参阅与 Outlook Web Access S/MIME 控件相关的设置。

获取数字证书后，请检查证书的整个信任列表。

获取公钥的数字证书

验证数字签名时，S/MIME 控件将检索已签名的邮件所附带的数字证书，并使用该证书进行验证。

当检索数字证书以便从目录获取用于发送加密邮件的公钥时，用户的 Exchange 服务器将按顺序查看下列位置，直到它找到用于所请求的操作的有效数字证书。一旦找到有效证书，将使用该证书，并暂停处理。

  • Active Directory 中其他用户对象中的 userCertificate 属性。
  • Active Directory 中其他用户对象中的 userSMIMECertificate 属性。
  • Active Directory 中其他用户联系人对象中的 userCertificate 属性（位于 Exchange 服务器上用户收件箱中的“联系人”文件夹中）。
  • Active Directory 中其他用户联系人对象中的 userSMIMECertificate 属性（位于 Exchange 服务器上用户收件箱中的“联系人”文件夹中）。
note注意：
虽然 Outlook Web Access 可以使用附加到 Exchange 的“联系人”文件夹中某一项目的数字证书，但是您不能使用 Outlook Web Access 将数字证书添加到“联系人”文件夹中的项目上。必须使用 Outlook 才能将数字证书添加到联系人。

如果用户的 Exchange 服务器在这些位置中都无法找到证书以获得另一用户的公钥，则会出现警告。尝试发送加密的电子邮件时，发件人可以发送未加密的邮件，也可以发送加密的邮件（此时将出现某些用户可能无法阅读邮件的警告）。

获取用户的私钥数字证书

选择数字证书以获取用户的私钥时，带有 S/MIME 控件的 Outlook Web Access 将查找当前已登录用户的个人证书存储。带有 S/MIME 控件的 Outlook Web Access 将搜索证书存储中的可用证书，直到找到所请求的操作的有效数字证书。如果找到基于软件的证书和基于硬件的证书，则带有 S/MIME 控件的 Outlook Web Access 将始终使用基于硬件的数字证书（包括智能卡）。请注意，如果已经在用户的 Exchange 服务器上设置了 SmartCardOnly 值，则只检查从智能卡传播的数字证书。

如果带有 S/MIME 控件的 Outlook Web Access 无法找到用户的私钥证书，则会出现警告。当提示阅读加密的电子邮件时，收件人无法解密和显示邮件。当发送已签名的电子邮件时，Outlook Web Access 将显示警告消息。

note注意：
使用基于硬件的证书时，用户必须激活设备以便使证书可用。例如，使用智能卡时，必须将智能卡插入读卡器且必须输入个人标识号 (PIN)，然后才能使用证书。

带有 S/MIME 控件的 Outlook Web Access 和证书验证

选择数字证书的过程包括确定可用数字证书是否有效。用户的 Exchange 服务器依靠基本 Windows 操作系统的证书处理功能来执行证书验证。有关证书检查过程的详细概述，请参阅 Troubleshooting Certificate Status and Revocation（英文）。当 PKI 管理员在带有 S/MIME 控件的 Outlook Web Access 中查看证书检查时，应该考虑下列事项：

  • 时间有效性验证（对所有证书执行）。
  • 证书吊销检查（应执行，除非已通过 DisableCRLCheck 注册表设置禁用了证书吊销列表 (CRL) 检查）。
  • 信任验证（当颁发证书的证书颁发机构 [CA] 没有出现在已检索到证书的系统内的证书存储中时执行）。

时间有效性验证

CA 创建证书时，会对证书标记有效期。证书的“有效起始日期”和“有效终止日期”属性指定了有效期。并且，这些属性提供了表示证书有效期的时间窗口。

检索数字证书以使用它时，用户的 Exchange 服务器会验证当前日期是否位于“有效起始日期”和“有效终止日期”属性指定的时间范围内。如果证书由于当前日期晚于“有效终止日期”而已经过期，或者由于当前日期早于“有效起始日期”而尚未生效，则 Outlook Web Access 会显示此证书无效的警告。

证书吊销检查

CRL 是按时间有效性表示为当前有效但 CA 认为无效的证书的列表。CA 通过 CRL 分发点（数字证书中指定的位置）使此列表可用。此列表的获取方法是：通过 HTTP、轻型目录访问协议 (LDAP) 或者那些需要用该 PKI 来验证数字证书的系统所采用的其他方法。

使用 CRL，PKI 管理员可以在时间有效性窗口过期之前将证书视为无效。当证书的安全受到威胁（如证书持有者的私钥丢失或泄露）或由于颁发者不再确信证书持有者（如终止登记）时，将执行此吊销操作。

根据 X.509 规范，任何 S/MIME 电子邮件客户端都可以检查数字证书是否已吊销。执行此项检查的一个方法是使用 PKI 所颁发的 CRL。用户的 Exchange 服务器使用 Windows 2000 或更高版本操作系统的加密功能来执行 CRL 检查。默认情况下，对带有 S/MIME 控件的 Outlook Web Access 已启用 CRL 检查，但是可以通过将用户的 Exchange 服务器上的 DisableCRLCheck 值设置为 True 来禁用 CRL 检查。有关详细信息，请参阅与 Outlook Web Access S/MIME 控件相关的设置。

由于检索 CRL 的过程非常耗时，系统在从 PKI 获取 CRL 后，将缓存此 CRL，直到此 CRL 过期。另外，Exchange 管理员可以通过 RevocationURLRetrievalTimeout 和 CertURLRetrievalTimeout 注册表设置，来配置返回错误之前允许检索 CRL 的时间长度。有关详细信息，请参阅与 Outlook Web Access S/MIME 控件相关的设置。

用户的 Exchange 服务器获取数字证书并对其时间有效性进行验证之后，将发生下列序列操作。

  1. Exchange 服务器试图对照此 CRL 验证证书。用户的 Exchange 服务器将检查是否已为此证书启用了 CRL 检查。
  2. 如果启用了 CRL 检查，则 Exchange 服务器试图找到此 CRL 的缓存副本。
  3. 如果 Exchange 服务器无法找到此 CRL 的缓存副本，则尝试与 CRL 分发点进行联系，以获取已更新的 CRL。
  4. 如果 Exchange 服务器无法获取 CRL，它将根据 CheckCRL 注册表设置采取操作。默认情况下，Outlook Web Access 不显示错误，并允许发送邮件。
  5. 如果 CheckCRL 注册表设置已更改为非默认值，则 Outlook Web Access 会显示错误，但允许发送邮件。有关 CheckCRL 注册表设置的详细信息，请参阅与 Outlook Web Access S/MIME 控件相关的设置。
  6. 如果用户的 Exchange 服务器可以获取 CRL 或可以找到 CRL 的缓存副本，则对照此 CRL 检查当前证书。
    • 如果在 CRL 中找到了此证书，则此证书被标记为无效，不予使用。
    • 如果在 CRL 中找不到此证书，则假设此证书有效，可以使用。

信任验证

对于所有数字证书都将执行信任验证。用户的 Exchange 服务器将调用操作系统的加密功能来对证书进行验证，在该过程中，将会验证证书链中的每个证书，直到到达可信的根证书。在大多数情况下，完成此操作的方法是，通过证书中颁发机构信息的访问路径来获取中间证书，直到找到可信根证书。中间证书也可以附带在经过数字签名的电子邮件上。如果系统找到可信根证书，则此数字证书的数字证书链被视为有效、可信，并且可以使用。

如果系统无法找到可信根证书，或者原来获取的数字证书现在位于 Exchange 服务器的不可信证书存储中，则此证书被视为无效和不可信。带有 S/MIME 控件的 Outlook Web Access 在使用该不可信数字证书时会生成错误。

作为 PKI 管理员，您可以选择信任其他 PKI 颁发的数字证书，以避免在使用根证书不可信的 PKI 所颁发的数字证书时发生错误。您可以选择信任其他 PKI 的根证书，但是，这样会隐含地信任此 PKI 颁发的每个证书。作为可选方案，还可以选择交叉验证策略，以便只信任来自其他 PKI 的一组选定的证书。

有关每个方法的风险和优点以及如何在 PKI 中实现交叉验证的信息，请参阅 PKI 文档。有关 Windows Server 2003 中的交叉验证的信息，请参阅 Planning and Implementing Cross-Certification and Qualified Subordination Using Windows Server 2003（英文）。通常，建议使用交叉验证策略。

无论您选择何种特定策略，都需要确保在 Exchange 服务器上可以使用适当的根证书，以启用信任验证。这些根证书可以手动添加，也可以使用组策略传播。建议在可能时使用组策略。

有关使用组策略传播数字证书的信息，请参阅 Windows Server 2003 文档。有关将数字证书手动添加到用户系统中的步骤的信息，请参阅 Exchange Server 2003 中的 S/MIME 疑难解答。

在对照 CRL 检查数字证书的时间有效性，并验证了此证书是否可信之后，Exchange 服务器可以将它识别为有效证书，并且可以将它用于数字签名和加密（取决于颁发证书的目的）。

带有 S/MIME 控件的 Outlook Web Access 和 S/MIME 操作

本部分讨论下列 S/MIME 操作：

  • 带有 S/MIME 控件的 Outlook Web Access 中的数字签名。
  • 带有 S/MIME 控件的 Outlook Web Access 中的加密操作。
  • 带有 S/MIME 控件的 Outlook Web Access 中的数字签名和加密。

带有 S/MIME 控件的 Outlook Web Access 中的数字签名

此部分讨论下列操作：

  • 发送经过数字签名的电子邮件。
  • 验证经过数字签名的电子邮件。

发送经过数字签名的电子邮件

在发送经过数字签名的电子邮件时，Outlook Web Access 必须获取发件人的私钥。运行 Outlook Web Access 的客户端系统（不是用户的 Exchange 服务器）负责获取数字证书和私钥。

note注意：
此序列操作描述明文签名的邮件，这是带有 S/MIME 控件的 Outlook Web Access 的默认行为。此行为由发件人的 Exchange 服务器上的 ClearSign 注册表设置控制。默认情况下，启用此设置。有关 ClearSign 注册表设置的信息，请参阅与 Outlook Web Access S/MIME 控件相关的设置。

发送经过数字签名的电子邮件时，将发生下列序列操作。

  1. 捕获邮件（由客户端系统执行）。
  2. 使用 defaultSigningAlgorithms 项所指定的算法计算邮件的哈希值（由客户端系统和用户的 Exchange 服务器执行）。
    有关 defaultSigningAlgorithms 注册表设置的详细信息，请参阅与 Outlook Web Access S/MIME 控件相关的设置。
  3. 检索发件人的数字证书私钥（由客户端系统执行）。
  4. 验证发件人的数字证书（由用户的 Exchange 服务器执行）。
  5. 使用发件人的私钥加密哈希值（由客户端系统和用户的 Exchange 服务器执行）。
  6. 将加密的哈希值作为数字签名附加到邮件中（由客户端系统执行）。
  7. 发送邮件（由客户端系统执行）。

验证经过数字签名的电子邮件

在验证经过数字签名的电子邮件时，Outlook Web Access 必须获取发件人的公钥。收件人的 Exchange 服务器负责获取数字证书和公钥。

验证经过数字签名的电子邮件时，将发生下列序列操作。

  1. 接收邮件（由用户的 Exchange 服务器执行）。
  2. 从邮件中检索包含加密哈希值的数字签名（由客户端系统执行）。
  3. 检索邮件（由客户端系统执行）。
  4. 计算邮件的哈希值（由客户端系统和用户的 Exchange 服务器执行）。
  5. 从电子邮件中检索出发件人的公钥（由客户端系统执行）。
  6. 使用发件人的公钥解密加密的哈希值（由客户端系统执行）。
  7. 将解密的哈希值与接收邮件时产生的哈希值进行比较（由客户端系统执行）。
  8. 如果值匹配，则传输过程中邮件未被修改（由客户端系统执行）。
  9. 验证发件人的数字证书（由用户的 Exchange 服务器执行）。
    note注意：
    在验证证书的同时将显示邮件，以提高读取数字签名电子邮件的性能。

带有 S/MIME 控件的 Outlook Web Access 中的加密操作

此部分讨论下列操作：

  • 发送加密的电子邮件。
  • 查看加密的电子邮件。

发送加密的电子邮件

在发送加密的电子邮件时，Outlook Web Access 必须获取收件人的公钥。发件人的 Exchange 服务器负责获取数字证书和公钥。

发送加密的电子邮件时，将发生下列序列操作。

  1. 捕获邮件（由客户端系统执行）。
  2. 从收件人的数字证书检索公钥（由用户的 Exchange 服务器执行）。
  3. 验证收件人的数字证书（由用户的 Exchange 服务器执行）。
  4. 生成一次性对称会话密钥（由客户端系统执行）。
  5. 使用会话密钥对邮件执行加密操作（由客户端系统执行）。
  6. 使用收件人的公钥加密会话密钥（由客户端系统执行）。
  7. 将加密的会话密钥包含在加密的邮件中（由客户端系统执行）。
  8. 发送邮件（由客户端系统执行）。

查看加密的电子邮件

在查看加密的电子邮件时，Outlook Web Access 必须获取收件人的私钥。运行 Outlook Web Access 的客户端系统（不是用户的 Exchange 服务器）负责获取数字证书和私钥。

查看加密的电子邮件时，将发生下列序列操作。

  1. 接收邮件（由用户的 Exchange 服务器执行）。
  2. 从邮件中检索加密的邮件和加密的会话密钥（由客户端系统执行）。
  3. 检索收件人的数字证书私钥（由客户端系统执行）。
  4. 使用收件人的数字证书私钥解密会话密钥（由客户端系统执行）。
  5. 使用解密的会话密钥解密邮件（由客户端系统执行）。
  6. 将未加密的邮件返回给收件人（由客户端系统执行）。

带有 S/MIME 控件的 Outlook Web Access 中的数字签名和加密

检查下列操作：

  • 发送经过数字签名且已加密的电子邮件。
  • 查看经过数字签名且已加密的电子邮件。

发送经过数字签名且已加密的电子邮件

在发送经过数字签名且已加密的电子邮件时，Outlook Web Access 必须获取发件人的私钥和收件人的公钥。运行 Outlook Web Access 的客户端系统（不是用户的 Exchange 服务器）将获取发件人的数字证书和私钥。发件人的 Exchange 服务器则获取收件人的数字证书和公钥。

发送经过数字签名且已加密的电子邮件时，将发生下列序列操作。

note注意：
此序列操作描述经过签名、加密、而后再签名的邮件。此过程被称为“三层包装”，它是带有 S/MIME 控件的 Outlook Web Access 的默认行为。此行为受发件人的 Exchange 服务器上的 TripleWrap 注册表设置控制。默认情况下，此设置被启用。有关 TripleWrap 注册表设置的信息，请参阅与 Outlook Web Access S/MIME 控件相关的设置。
  1. 捕获邮件（由客户端系统执行）。
  2. 计算邮件的哈希值（由客户端系统执行）。
  3. 检索发件人的数字证书私钥（由客户端系统执行）。
  4. 验证发件人的数字证书（由用户的 Exchange 服务器执行）。
  5. 从收件人的数字证书检索公钥（由用户的 Exchange 服务器执行）。
  6. 验证收件人的数字证书（由用户的 Exchange 服务器执行）。
  7. 使用发件人的私钥加密哈希值（由客户端系统执行）。
  8. 将加密的哈希值作为数字签名附加到邮件中（由客户端系统和用户的 Exchange 服务器执行）。
  9. 生成一次性对称会话密钥（由客户端系统执行）。
  10. 使用会话密钥对邮件执行加密操作（由客户端系统执行）。
  11. 使用收件人的公钥加密会话密钥（由客户端系统执行）。
  12. 将加密的会话密钥包含在加密的邮件中（由用户的 Exchange 服务器执行）。
  13. 计算带有加密会话密钥的邮件的哈希值（由客户端系统执行）。
  14. 使用发件人的私钥加密哈希值（由客户端系统执行）。
  15. 将加密的哈希值作为数字签名附加到邮件中（由客户端系统和用户的 Exchange 服务器执行）。
  16. 发送邮件（由客户端系统执行）。

查看经过数字签名且已加密的电子邮件

在查看经过数字签名且已加密的电子邮件时，Outlook Web Access 必须获取收件人的私钥（以显示邮件）和发件人的公钥（以验证邮件中的签名）。运行 Outlook Web Access 的客户端系统（不是用户的 Exchange 服务器）将获取收件人的数字证书和私钥。用户的 Exchange 服务器则获取发件人的数字证书和公钥。

发送经过数字签名且已加密的电子邮件时，将发生下列序列操作。

note注意：
此序列操作描述经过三层包装的邮件，这是带有 S/MIME 控件的 Outlook Web Access 的默认行为。此行为受发件人的 Exchange 服务器上的 TripleWrap 注册表设置控制。默认情况下，此设置被启用。有关 TripleWrap 注册表设置的信息，请参阅与 Outlook Web Access S/MIME 控件相关的设置。
  1. 接收邮件（由用户的 Exchange 服务器执行）。
  2. 从邮件中检索包含带有加密会话密钥的邮件的加密哈希值的数字签名（由客户端系统执行）。
  3. 从邮件中检索邮件和加密的会话密钥（由客户端系统执行）。
  4. 计算邮件和加密会话密钥的哈希值（由客户端系统执行）。
  5. 从邮件中检索发件人的公钥（由用户的 Exchange 服务器执行）。
  6. 使用发件人的公钥，对带有加密会话密钥的邮件的加密哈希值进行解密（由客户端系统执行）。
  7. 将带有加密会话密钥的邮件的解密哈希值与接收邮件时产生的加密会话密钥的邮件的哈希值进行比较（由客户端系统执行）。
  8. 如果值匹配，则传输过程中邮件未被修改（由客户端系统执行）。
  9. 从邮件中检索加密的邮件和加密的会话密钥（由客户端系统执行）。
  10. 检索收件人的数字证书私钥（由客户端系统执行）。
  11. 使用收件人的数字证书私钥解密会话密钥（由客户端系统执行）。
  12. 使用解密的会话密钥解密邮件（由客户端系统执行）。
  13. 从邮件中检索包含加密哈希值的数字签名（由客户端系统执行）。
  14. 计算邮件的哈希值（由客户端系统执行）。
  15. 使用发件人的公钥解密加密的哈希值（由客户端系统执行）。
  16. 将解密的哈希值与接收邮件时产生的哈希值进行比较（由客户端系统执行）。
  17. 如果值匹配，则传输过程中邮件未被修改（由客户端系统执行）。
  18. 将未加密的邮件返回给收件人（由客户端系统执行）。
  19. 验证发件人的数字证书（由用户的 Exchange 服务器执行）。
note注意：
在验证证书的同时将显示邮件，以提高读取数字签名电子邮件的性能。

带有 S/MIME 控件的 Outlook Web Access 和智能卡

通过带有 S/MIME 控件的 Outlook Web Access，PKI 管理员可以使用他们的智能卡来存储用户数字证书和私钥。在多个客户端系统上，对于带有 S/MIME 控件的 Outlook Web Access 来说，最好使用智能卡。

由于带有 S/MIME 控件的 Outlook Web Access 依靠 Windows 2000 或更高版本的操作系统，因此对智能卡的数字证书支持与此操作系统提供的支持直接绑定。有关在 PKI 中实现对智能卡的支持的信息，请参阅 Windows 2000 或更高版本操作系统的文档。下面是有关将智能卡支持与带有 S/MIME 控件的 Outlook Web Access 集成的具体信息。此信息补充了 PKI 文档以及 Windows 2000 或更高版本操作系统的文档。

带有 S/MIME 控件的 Outlook Web Access 如何与智能卡一起工作

客户端所运行的操作系统提供了在带有 S/MIME 控件的 Outlook Web Access 中使用智能卡的支持。操作系统将智能卡无缝地与其证书处理功能集成在一起，以便 Outlook Web Access 不需要处理或管理这些证书。带有 S/MIME 控件的 Outlook Web Access 将监视智能卡以获取任何更改，并指导操作系统何时将附加数字证书从智能卡移动到个人证书存储，并在用户注销 Outlook Web Access 时删除这些证书。

智能卡使数字证书可用的方法是：当插入智能卡和使用用户的私钥解锁数字证书时，将证书复制到个人证书存储中。此操作将数字证书放在与使用基于软件的证书时相同的位置。应用程序不需要采取任何特殊操作，即可使用基于智能卡的数字证书，这是因为 Windows 操作系统对基于智能卡的证书所特定的所有操作进行了处理。

将智能卡与 Outlook Web Access 一起使用时，请根据您在实现过程中的需要，确保颁发的数字证书能够提供数字签名和加密功能。

使用用户的 Exchange Server 上的 SmartCardOnly 注册表设置，可以将带有 S/MIME 控件的 Outlook Web Access 配置为只需要基于智能卡的数字证书。默认情况下，不启用此设置。有关 SmartCardOnly 注册表设置的详细信息，请参阅与 Outlook Web Access S/MIME 控件相关的设置。

终端服务支持

Windows Server 2003 附带的远程桌面客户端可以支持智能卡重定向。使用 Windows Server 2003 远程桌面客户端，可以在终端会话中使用远程桌面客户端（如网亭）所连接的读卡器中插入的智能卡。

智能卡重定向可以与带有 S/MIME 控件的 Outlook Web Access 一起使用，以便让用户可以在终端会话中使用基于智能卡的证书。

对于哪些客户端和服务器组合能够与智能卡重定向一起使用，Windows Server 2003 远程桌面客户端是有限制的。表 6.1 列出了将 Windows Server 2003 远程桌面客户端用于智能卡重定向时，受支持的客户端和服务器组合。

表 6.1 使用 Windows Server 2003 远程桌面客户端进行智能卡重定向时受支持的客户端和服务器平台

运行 Windows Server 2003 远程桌面的客户端系统 运行远程桌面服务的服务器系统

Windows XP

Windows XP 远程桌面

Windows XP

Windows Server 2003

Windows 2000

Windows XP 远程桌面

Windows 2000

Windows Server 2003

Windows Server 2003

Windows XP 远程桌面

Windows Server 2003

Windows Server 2003

如表 6.1 所示，提供终端服务的服务器必须是 Windows XP 或 Windows Server 2003。Windows 2000、Windows XP 和 Windows Server 2003 都可以用作客户端平台来运行 Windows Server 2003 远程桌面。Windows 的其他版本都不能与 Windows Server 2003 远程桌面客户端一起使用来提供智能卡重定向。有关智能卡重定向的详细信息，请参阅 Windows Server 2003 远程桌面客户端文档。

带有 S/MIME 控件的 Outlook Web Access 和 S/MIME 加密功能

使用带有 S/MIME 控件的 Outlook Web Access 时，可以强制用户按照指定的加密算法对电子邮件进行加密。带有 S/MIME 控件的 Outlook Web Access 并不完全依靠用户的加密证书中详述的 S/MIME 加密功能，而是复查发件人 Exchange 服务器上的注册表中的信息，以确定应该使用何种加密算法和强度。通过此功能可以强制实施与电子邮件加密相关的组织特定策略。EncryptionAlgorithms 注册表设置可控制加密算法的选择。有关 EncryptionAlgorithms 注册表设置的详细信息，请参阅与 Outlook Web Access S/MIME 控件相关的设置。

如果发件人的 Exchange 服务器无法获取其功能与注册表中设置的需求相匹配的收件人的加密证书，则带有 S/MIME 控件的 Outlook Web Access 将根据 AlwaysEncrypt 注册表设置对此邮件进行处理。如果未启用 AlwaysEncrypt （默认设置），则发件人可以选择将邮件发送给未加密的收件人。如果启用了 AlwaysEncrypt，则发件人无法发送邮件。有关 AlwaysEncrypt 注册表设置的详细信息，请参阅与 Outlook Web Access S/MIME 控件相关的设置。如果带有 S/MIME 控件的 Outlook Web Access 找到了收件人加密证书，但它不支持指定的算法，或支持指定的算法但未达到指定的加密强度，将视为未找到证书。将根据 AlwaysEncrypt 设置对邮件进行处理。

支持来自其他组织的 S/MIME 邮件

使用带有 S/MIME 控件的 Outlook Web Access 与其他组织中的用户交换 S/MIME 电子邮件时，用户的 Exchange 服务器以用户的身份对 S/MIME 邮件执行证书验证操作。若要成功验证来自其他组织的 S/MIME 邮件，用户的 Exchange 服务器必须验证可信根证书的整个证书链。如果计划使用 S/MIME 与其他组织交换电子邮件，并且想要验证其他组织的证书以验证数字签名，则必须在 PKI 中实现对其他组织的证书的信任。

Exchange 2003 可以通过信任颁发者的根证书或通过与您的 PKI 进行交叉验证的过程来信任证书。Exchange 管理员可以通过将该根证书添加到用户的 Exchange 服务器的本地计算机证书存储中的“受信任根证书授权机构”文件夹来启用对颁发者的根证书的信任。若要实现此操作，请咨询 Exchange 管理员。有关详细信息（包括如何导入已交叉验证的证书的详细步骤说明），请参阅当收件人的 Exchange 服务器的本地计算机证书存储中没有发件人的根 CA 数字证书时，不能验证发件人的数字签名。

虽然添加颁发者的根证书可以解决此问题，但是它隐含地对该 PKI 发布的所有证书授予了信任。此级别的信任可能超过了您的组织的安全策略可接受的程度。替代的解决方案是：通过颁发来自 PKI 的证书并将此证书添加到用户的 Exchange 服务器的本地计算机证书存储中的“受信任根证书授权机构”文件夹，从而只对其他组织的 PKI 中可接受的那些证书进行交叉验证。

有关如何实现交叉验证的信息，请参阅 PKI 文档。有关在 Windows Server 2003 中实现交叉验证的信息，请参阅“Planning and Implementing Cross-Certification and Qualified Subordination Using Windows Server 2003”(https://go.microsoft.com/fwlink/?LinkId=17806)（英文）。

除了信任证书颁发者的根证书，用户的 Exchange 服务器还必须访问并成功验证所有中间证书。根据其他组织的 PKI 管理员如何选择配置 PKI，这些中间证书可以包含在已签名的电子邮件中，也可以在数字证书颁发机构的信息访问参数所指定的位置访问它们。若要提供对任何中间证书的访问，Exchange 管理员必须确保用户的 Exchange 服务器可以成功地连接到这些证书，并可以检索通过数字证书颁发机构的信息访问参数可获取的证书。若要提供对中间证书的验证，Exchange 管理员必须确保用户的 Exchange 服务器可以成功连接到 CRL 分发点，并验证数字证书中指定了此 CRL。因此，为了使用户的 Exchange 服务器可以访问并成功验证任何中间证书，Exchange 管理员必须确保用户的 Exchange 服务器与在数字证书的颁发机构信息访问和 CRL 分发点参数中所指定的位置之间可以连通。对于大多数组织来说，此位置是位于 Exchange 服务器和 Internet 之间的代理服务器。Exchange 管理员必须确保安装并配置了适当的代理客户端软件。如果无法访问中间证书进行验证，请考虑让 Exchange 管理员通过 disableCRLCheck 注册表项禁用 CRL 检查。有关此设置的详细信息，请参阅与 Outlook Web Access S/MIME 控件相关的设置。

有关详细信息，Exchange 管理员可以参阅实现带有 S/MIME 控件的 Outlook Web Access中的“配置 Exchange 服务器”。

在 PKI 中配置中间证书处理

默认情况下，使用带有 S/MIME 控件的 Outlook Web Access 发送的电子邮件只包含签名和加密证书。不包括根证书和中间证书。可以使用 SecurityFlags 注册表项配置此设置。有关此设置的详细信息，请参阅与 Outlook Web Access S/MIME 控件相关的设置。

默认情况下，带有 S/MIME 控件的 Outlook Web Access 只发送签名和加密证书。因此，建议配置 PKI，以使用证书中的颁发机构信息访问参数，并让中间证书可以通过 LDAP 或 HTTP 公共使用。有关如何使用此功能的详细信息，请参阅 PKI 文档。

如果不能使用颁发机构信息访问来让中间证书可用，则应该对带有 S/MIME 控件的 Outlook Web Access 进行配置，以包括中间证书和电子邮件。有关所需的任何更改，请咨询 Exchange 管理员。有关 SecurityFlags 注册表项的信息，请参阅与 Outlook Web Access S/MIME 控件相关的设置。