S/MIME是一套使用加密和数字签名安全发送电子邮件的系统。目前的加密(隐藏)技术分为两大类：对称(秘密)密钥算法，如数据加密标准(DES)或高级加密标准(AES);以及非对称(公开/私密)密钥算法，如 RSA 或椭圆曲线加密(ECC)。现代的发件人验证工具是单向的算术函数，称为哈希，它可以生成唯一的签名。消息摘要MD5和安全哈希算法(SHA)是两种常用的哈希方法。计算机可以使用这些算法来生成与单个源文本对应的唯一哈希或数字(相同的源文本会哈希成相同的值)。运用和结合这些简单的工具可以构建公共密钥基础结构(PKI) 系统。
可验证的身份
PKI系统中的身份通过数字证书进行管理，这跟大多数人跨国界时携带的政府身份识别 — 护照 — 并没有什么不同。数字证书世界的护照标准是 X.509 格式，这种格式广泛用于各种技术中的签名和加密操作，例如S/MIME、Internet 协议安全性(IPsec)、安全外壳(SSH)、无线网络安全性、虚拟专用网(VPN)，甚至安全服务器通信(例如SSL网站)也包括在内。
证书是以非对称加密和哈希为基础构建而成。若要创建证书，请求者(等候一些较高颁发机构签署的密钥的实体)会生成一个私钥。该密钥会被锁定起来，这样一来它的真实性永远不会受到质疑。生成私钥的同时还会生成一个对应的公钥。顾名思义，这个密钥对的公开部分并不是秘密，而且会公开发布，但在某种程度上还是会确保它的真实性。
这个密钥对允许进行两项基本的操作。首先，任何人都可以使用公钥来加密只有私钥可以解密的内容，其次，公钥可用来解密以私钥加密的内容。这对于验证只有私钥可能创建的签名很重要。
对证书颁发机构提出的请求包括各种详细信息，例如密钥的目标人员或计算机的身份、算法类型和强度，以及密钥对的公开部分。证书颁发机构 (CA) 会接收请求中的信息并对其进行验证，并使用哈希算法创建与该信息相对应的唯一标识符。
CA 会使用它的私钥加密信息的哈希，并把它组合成标准格式(例如 X.509)，然后创建与原始要求相对应的证书。X.509 证书将包含声明列表，包括证书(主体)的身份、有效期限、公钥，以及可使用证书进行的操作等。然后将证书返回给请求者，证书事实上是个令牌，表明：“我，CA，担保这个公钥，以及与之对应的私密部分，仅作为此处所描述的这些用途”。
对于根CA(位于信任链最高级别)，证书是自签名的。大部分可接受的根CA 都会预安装在基本操作系统或应用程序中，但可通过程序包或企业配置进行更新或更改。在根CA和叶节点(通常是指个体或系统)之间，可以有一或多个中间CA。
信任链包括所有节点以及其中先前内嵌的所有证书，由CA在该级别签名。尝试验证证书的第三方可以检查本地计算的哈希，并将其与从证书解密(使用该特定CA或个体的相应公钥)的哈希进行比较。就是这么一回事 — 从叶到根经过完整验证的信任链 — 当然前提是假设根是受信任的。
更新证书状态
每个良好的CA 都有方法可以分发不应该再受信任的证书清单。这份证书吊销列表(CRL)说明CA特别取消了哪些已颁发的证书。方便的是，CRL的位置通常是CA证书的属性。
CA会基于以下两项不断颁发CRL：计划(也许是每两个星期)或事件(表明颁发的证书不应该再受信任的一些情况)。CA 会在发布颁发的CRL时对其进行签署。当接收系统评估信任链的有效性时，它通常会尝试取得信任链中每个颁发CA的CRL(通过证书本身内嵌的详细信息，或是通过一些预先定义的受信任分发机制)。如果存在无法获取的CRL，客户端可能会改用最近成功缓存的副本，只要此副本没有超过指定的CRL 更新期限。不过，如果连这样都办不到的话，客户端系统通常会显示某种错误，指明证书看似有效但无法确认吊销状态。
许多应用程序如果无法验证信任链，或信任链中每个节点的CRL，则需要花费很长一段时间加载证书。视证书所保护的内容而定，用户不一定会需要信任它。每个CA必须要有定期更新、广泛可用的CRL发布点，尤其是对那些公共根CA来说更是如此。
根CA是证书链的基础，而链结是所有证书层次结构的基石。大部分客户端系统或应用程序只会在叶节点链结回信任的根CA 时，才认为叶节点证书有效。这可以是企业CA，由特定公司所拥有或经营的CA，也可以是公共根CA(例如VeriSign)。
对于公共根CA，为了确保完整性，必须具备丰富的操作专业知识。企业对于内部运营也应该努力达成相同的等级，因为根CA 的安全性在那样的环境下也同样重要。为了获得最好的保护，根CA实际上应该保持脱机状态，而且只用于颁发证书和更新CRL。有关 CA 操作最佳实践的详细信息，请参阅“证书颁发机构资源”侧栏中所列文章。
密钥恢复是需要考虑的一个重要方面。为了方便调查，并确保数据不会被用户锁定而无法恢复，企业应该将所有用户发布的密钥进行备份。而且这些备份副本应该保存在安全的存储库中。这样一来，即使用户的密钥不见了，类似于智能卡被丢在出租车里，该用户仍然可以访问密钥保护的所有内容。
最后，每个良好的加密系统中都有生命周期管理的概念。随着计算机的速度越来越快，算法也变得越来越薄弱。每个良好的加密系统都必须能够自行更新，并随着时间转换到新算法和密钥大小。在识别出加密弱点，以及逐步采用或停止特定功能时，应该相应更新CA。
实施S/MIME
使用S/MIME启动、撰写、发送和接收经过签名或加密电子邮件分为几个阶段。我们会在介绍典型的S/MIME 案例时，讲述相关细节、问题和可能的解决方案：两名用户从两个不同的Active Directory® 林和不同的证书颁发机构链(也就是从独立的操作实体，不管是否属于同一公司)，使用Microsoft® Office Outlook® 2007相互发送经过签名和/或加密的电子邮件。
我们将假设必要的基础结构已经就位，随时可以开始我们即将介绍的操作。在我们的案例中，使用的是集成Active Directory的企业证书服务器。
获得证书
第一项任务是获得相应的证书。为此，请打开“证书管理器”MMC (certmgr.msc)，右键单击“个人”文件夹，在弹出列表上选择“所有任务”，然后从列表中选择“申请新证书”。
这将启动“证书注册”向导，如图 1 所示。默认情况下，将显示几个以企业为中心的选项，但重要的是“用户证书”。稍后将用它来开始签名和加密流程。证书必须能够用于：
图1 请求证书
数字签名(创建消息，创建者密封了真实性)
密钥加密(对于诸如“加密文件系统”这样的技术，使用一个密钥保护另一个密钥)
保护邮件(只有拥有相应私钥的目标收件人才能阅读加密邮件)
发送 S/MIME 签名的电子邮件时并不需要密钥加密属性。但在发送或接收加密邮件时则需要这个属性，但不需要签名属性。默认情况下，Windows® 证书服务中的模板启用这三个属性。如果不允许用户申请新证书，则向导启动时三个属性都不会显示。如果没有任何企业 CA 可用，会向用户显示“注册错误”，指明无法联系域或 CA。对于此演练，我们将假设单一证书同时允许签名和加密。
交换证书
两个用户开始发送加密电子邮件的最简单方法就是彼此直接传送已签名的邮件。撰写好邮件之后，用户可单击“签名”按钮。(有时候除非至少用过一次，否则在 Outlook 中会默认隐藏这个按钮。可以通过依次单击新邮件的“选项”设置、“安全设置”按钮，然后选中“安全属性”对话框上的“为此邮件添加数字签名”框找到该按钮)。签名按钮(带有红色缎带的黄色小信封，写着“签名”)会将数字签名添加到邮件中以建立它的来源真实性。
按下“发送”按钮之后，可能会提示用户提供另外持有的密钥令牌，如插入智能卡或输入 PIN。这会视组织中所采用的特定密钥保护方法而定。
收到 S/MIME 签名邮件的用户需要查看并右键单击发件人名称(发件人: 之后)，然后从上下文菜单中选择“添加到 Outlook 联系人”来添加新的联系人项或更新现有联系人。证书随后会与该特定的联系人项建立关联。请注意，在常见的 Active Directory 环境中(两个用户位于相同的林或公司中)，公用用户证书分发是通过用户的 Active Directory 对象中的属性自动完成的。
交换证书的另一种方法是每个用户以附件的形式发送其 S/MIME 证书。为此，双方都必须将其证书导出为 CER 文件。用户需要查看证书，并遵循我们即将讨论的导出过程，注意不要使用该导出过程导出私钥，如图 2 所示。
图2 交换证书时，不要导出私钥
每个收件人接下来会在 Outlook 中手动创建联系人项，然后将证书添加到该发件人项中。两个用户交换证书后，他们就能够彼此交换加密的电子邮件了。
疑难解答
有时收件人会无法打开加密的邮件。对于在这个领域中出现的问题，最有可能的三个原因分别是根 CA 不受信任、无法验证中间 CA 以及无法使用 CRL。
不受信任的根CA 通常会在Outlook中显示为与签名相关联的错误消息：“该签名有问题。单击签名按钮可获取详细信息。”若要解决问题，请从Outlook中打开证书，然后单击弹出对话框中的“查看证书颁发机构”按钮。查看证书属性对话框“常规”选项卡上的消息。如果消息指示CA根证书不受信任，而且需要安装，请转到“详细信息”选项卡。单击“复制到文件…”按钮，并按照向导说明进行操作，接受所有默认设置并在收到提示时提供文件名和文件夹。
现在以计算机管理员的身份打开一个新的 Microsoft 管理控制台(MMC)。转到“文件”|“添加/删除管理单元(Ctrl+M)”，选择“证书”，并添加它以用于计算机帐户，在提示时选择“本地计算机”。接下来，在左边树状结构中展开“证书”节点，然后对“受信任的根证书颁发机构”执行相同的操作。右键单击并从弹出菜单中选择“所有任务”|“导入”。将前述导出的证书文件导入到“受信任的根证书颁发机构”并单击“完成”。然后让受影响的用户重新启动Outlook。
应该仅使用上述说明添加已知的受信任根CA。并不是创建的所有根CA 都是平等的。请先审慎考虑是谁拥有和操作根CA，再使用该方法将根证书添加到整个系统的存储区。如果企业通过组策略控制受信任的根CA 列表，则会将配置推送到客户端系统。在这种情况下，上述的说明可能并不适用。如果事实如此，您可能需要探索其他替代办法，如确保网站或服务器的安全以交换数据，因为使用电子邮件的体验并不顺畅，也不会受到保护。
上面提出的第二个问题，即无法验证中间CA，通常在两种情况下发生：尝试验证证书的客户端无法到达证书中所定义的颁发机构信息访问(AIA)位置，或者客户端所拥有的中间CA 证书版本与CA 所颁发的版本不符(客户端通常晚于一两个版本)。这些情况在Outlook用户界面中看起来十分类似。我们只在非常特殊的情形下看到过这种情况，就是当信任链中的中层 CA 已过期，并在它颁发的其他从属证书到期之前重新颁发。
基本上，这个问题发生在信任链中存在中断的情况下。有些父证书可能不具备完善的详细资料或者没有适当内嵌在叶节点中，进而使整个情况更加复杂。
若要解决此问题，发件人需要打开新邮件，并依次单击新邮件的“选项”、“安全设置”按钮以及“更改设置”按钮。现在单击适用于签名证书的“选择”按钮，然后单击弹出对话框上的“查看证书”按钮。转到“证书路径”选项卡，选择叶节点的颁发者(也就是在信任链中往上一层)，然后单击“查看证书”按钮。依次单击“详细信息”选项卡、“复制到文件…”按钮，然后完成导出向导，选择PKCS #7(.P7B)。确定已选中“包括证书路径中所有证书”选项，如图 3 所示。最后，将导出的信任链文件发送到目标收件人。
图3 修正证书链中的中断
获得导出的证书链后，收件人需要打开并导出信任链，做法跟我们之前导入根证书相似。一个区别是所选的存储文件夹应该是“中间证书颁发机构”。如果邮件已打开并且证书在Outlook中显示为有效，则一切都会适当运作。
至于第三个问题，即无法使用CRL，解决方法相对简单。Outlook 的最初响应看起来与前一个问题非常相似。不过，即使根或中间签名CA是受信任的，也会显示错误。对于证书链中叶节点以上的每个级别，请依次打开证书的属性和“详细信息”选项卡，然后查看称为“CRL 分发点”的字段。
对于列出的每个CRL分发点(尤其是Internet可以访问的分发点)，确保CRL文件URL可以打开。验证完每个级别则在信任链中向上移动一个级别。如果有任何CRL无法获得，则它可能是问题的根源。若要解决问题，您应该确认本地网络策略并没有阻止您的访问。否则，请尝试与拥有CA的公司联系或等待CA的CRL分发点恢复正常运作状态。
分发证书
分发是非常简单的过程。基本上，已签名的邮件传输到邮件服务器，该服务器然后通过可靠的方法(即SMTP)将它从一个位置传送到另一个位置。对于传输中的已签名或已加密邮件，我们发现的一个问题是，有些邮件系统会拒绝或中断通过它们的已签名或已加密邮件。解决方法是与系统的 IT 经理合作来允许这些邮件类型。当然，您可能不得不接受某些邮件类型会被阻止的事实。接收方可能有正当的理由在特定的操作环境下不允许加密邮件。
加密回复
若要创建加密回复(假设上述启动过程已完成)，发件人只需要新建邮件，然后在邮件撰写窗口中单击“加密”按钮(带有蓝色锁的黄色小信封，写着“加密”)。如果“加密”按钮不可用，请按照发送已签名邮件的步骤(最后一步除外)，选中“加密邮件内容和附件”复选框。
将加密邮件发送到收件人并不需要 S/MIME 签名，但是两者搭配也无妨，因为签名可使读者验证发件人(加密功能并不会对发件人进行任何声明)。加密过程将尝试使用所有收件人已知的公钥来加密邮件。如果系统无法找到某些指定收件人的证书，则会在弹出对话框中将其标示出来，建议向其发送未加密邮件，如图 4 所示。
图4 如果您使用证书时遇到问题，可决定发送未加密的邮件
默认情况下，签名和加密应该与其他同等配置的客户端系统搭配使用，但是如果哈希或加密算法不支持下层的话，有时跨版本加密或签名邮件可能会产生问题。我们在将经过签名的电子邮件(使用 SHA-512 作为哈希算法)发送到运行 Windows XP SP2 的用户时，会遇到这样的问题。因为接收系统并不支持哈希，所以用户无法验证签名或阅读邮件。但是，除非 Outlook 默认值有所更改，否则用户不可能在这个阶段遇到太多问题。
收到邮件后，假如与共用证书相关联的私钥可用，目标收件人应该能够打开邮件。此外，用户可能需要提供其他令牌以证明持有私钥，具体取决于私钥的部署方式。已完成类似启动过程的其他用户可与发件人进行类似的签名和加密通信。如果用户更改了他的私钥(也许是因为计算机遗失)，他必须重新请求证书，然后将签名邮件或证书文件重新分发到想要交换加密邮件的其他人。
总结
使两个不同目录或组织中的两名用户之间能够进行签名和加密的S/MIME通常不会比我们刚刚所讨论的复杂多少。签名在使用得当时非常实用，因为它可增加邮件的真实性。对于敏感的详细信息，加密邮件为传输中的数据提供另外一个级别的安全保护。两者结合可实现来源的真实性和数据的秘密性。通过我们在本文中对过程的介绍，对于大多数用户来说，利用这些功能应该不成问题。
