在 OS X 上使用 S/MIME 加密和签名邮件

非常感谢楼主的科普，我已经拥有了属于自己的证书
只不过，在使用Mail.app发送邮件的时候，“签名”按钮可用，而“加密”不可用，不知道出了什么问题。

@Autonomous 是这样的，首先你需要检查一下，在你的钥匙串中是否有邮件接收者的 S/MIME 证书，也就是说，如果你想发邮件给某人，但是目前没有对方的 S/MIME 证书，或者是对方根本没有 S/MIME 证书的话，是无法加密的，只能签名邮件。

你可以找一个拥有 S/MIME 证书的人进行试验，也可以用自己的其他邮箱进行试验。

这里有我的 S/MIME 证书： https://www.dropbox.com/s/rftyxxrq0o7kbc7/Tong-G%40outlook.com.cer?dl=0

你可以尝试给我发一封测试邮件，我的邮箱是 [email protected]。当你将上面的证书导入到钥匙串中后，别忘了构建完整的信任链，博文里“构建信任链”一节有讲述。

如果信任链构建完成，你在 Apple Mail 中输入我的邮箱地址之后，应该就可以看到，那个小锁头按钮会变成可用（enabled）状态，这时就可以加密邮件了。

@NSTongG

感谢你的解答！

那么我该如何导出我的S/MIME证书文件呢？

@Autonomous

导出 S/MIME 证书分两种：

1. 导出 .p12 格式的证书
2. 导出 .cer 格式的证书

两者的区别就是，.p12 格式的证书中包含了你的 S/MIME 的私钥，而 .cer 格式的证书中只有公钥。也就是说，如果你新买了一台计算机，或者你想在你的 iOS/Android 设备上使用自己的 S/MIME 证书发送加密邮件，那么就需要导出 .p12 格式的证书，这个证书中包含了私钥，所以一定要注意，在在其他设备上倒入这个证书之后一定要将其销毁。

而.cer 格式的证书，就是在你想把你的 S/MIME 证书给你的朋友，或者放到互联网上的时候使用的，这个格式只包含你的证书的公钥，别人可以将它用于给你发送加密邮件。

嗯...两者的区别，我打个比方，

1. p12 格式的证书，就好比你的 银行卡号（公钥）＋你的银行卡密码（私钥），有了它你可以用它给别人打款（发送加密数据），也可以同时收款（解密别人给你发的加密数据）。

2. .cer 格式的证书，就仅仅相当于你的 银行卡号（公钥），别人只能用你的银行卡号给你打款，谁都可以给你打，但是他们无法提取其中的钱，只有你自己可以。

在 OS X 上导出这两种格式的证书非常容易：

打开 OS X 自带的 Keychain Access 程序，找到你想导出的证书项（你自己的或是其他人的都可以）:
http://i.imgbox.com/TNLNTMGj.png

右击 => Export "xxxx" （导出xxx证书）：
http://i.imgbox.com/qCxJAhe0.png

在保存对话框中选择你想导出的格式（迁移到其他机器，导出 .p12 格式。给朋友和其他人让他们能够给你发送加密邮件，导出 .cer 格式）：
http://i.imgbox.com/uS3P8f0C.png

千万不要把 .p12 格式的证书给任何人。

@Autonomous 导入就很容易了，双击证书，会默认用 Keychain Access 打开，这样 Keychain Access 会自动将其导入。

@NSTongG

非常感谢！

你的公存放在Dropbox当中，我的梯子不够长，获取不到……

我已经将我的公发送到你的邮箱里面了。

已经成功和楼主互发加密邮件，再次感谢分享！

不过我周围的人基本都不用客户端，而是直接在网页上操作邮件，应用上还是有些限制。不过也算是get一招了

刚去看了网页版Gmail，确实无法看到加密邮件的内容，只能显示双方邮箱还有一个叫做“smime.p7m”的附件……

@Autonomous 如果能显示，那还叫加密嘛。你看不到，维护这些服务器的人也都看不到，只有你在本地用你自己的 S/MIME 证书才能解密这些内容。

@Autonomous 即使拿到你的 Gmail 密码并登录到你的 Gmail 的人也是无法查看的，因为他们没有你的私钥，所以即使邮件发错了邮箱，或者邮箱账号被 hack，其他人也是无法阅读到有意义的内容的。

事实上可以不必用share公钥网址的方式来传递公钥，签名邮件时会自动附上自己的公钥的，具体操作可以这样：
A以签名的方式发送一封测试邮件给B，B收到邮件后在mail.app里点击那个已签名的图标，就会看到提示是否要把A的公钥加入自己的Keychain里。
B用A的公钥加密邮件并用自己的私钥签名一封邮件发回给A，然后A也能拿到B的公钥了。

@Daniel65536 你说的对，邮件往来的时候会自动将证书公钥以邮件附件的形式发送。

但是问题来了，如果 A 和 B 在这之前从没有互发过加密邮件，那么也就是说，这个时候 A 没有 B 的公钥，B 也没有 A 的公钥。A 和 B 也就无法互发加密邮件，而必须有一个人先发一封非加密的邮件，将自己的证书公钥传递给对方，对方才能反过来给自己发加密邮件。

如果从一开始（即两人从没有通信过的情况下）就想要所有的邮件都是被加密的，那么最好的解决办法就只能是将自己的公钥放置在互联网的某一个公共空间。这样，A 在与 B 第一次进行邮件通信之前，就可以获取到 B 的公钥，直接给他发送加密邮件，vice versa。

@Daniel65536 像你说的这种方式，应该是在这样的场景中比较适用：

0. B 将自己的 S/MIME 证书公钥放在了互联网上的某一公共空间（比如 blog，或者是 Twitter 的 bio ），任何人都可以直接获取。
1. A 与 B 从未互相通信过，但是此时 A 想直接给 B 发送一封加密邮件（可能是由于邮件内容及其敏感）。
2. A 在互联网上找到了 B 的公钥。
3. A 使用 B 的公钥给 B 发送了加密邮件。
4. B 收到了 A 的加密邮件，并想与之保持联系，这是就可以直接从 A 发来的邮件中提取出 A 的证书公钥，导入到自己的 keychain 中（而不必再费力地在互联网上去寻找 A 的公钥）。

所以将公钥 share 到一个公共空间还是很重要的，因为这能很好地解决“第一次”建立加密通信的问题。

楼主您好，我让我的朋友也去申请了一个证书，还是阁下给的那个网址，但是我这边不认他的公钥，提示无效，我仔细看了下他的签发者是"COMODO SHA-256 Client Authentication and Secure Email CA"


而我们的则是"COMODO RSA Client Authentication and Secure Email CA"


这个究竟是什么缘故呢？

好吧，图片有问题，已经发邮件给楼主，还请指导啊

@Autonomous 啊，这个好办，这是因为缺少你的朋友的证书的签发者 "COMODO SHA-256 Client Authentication and Secure Email CA" 的证书而无法构建信任链，你可以在这里下载，然后导入到 keychain 中即可：

http://crt.comodoca.com/COMODOSHA256ClientAuthenticationandSecureEmailCA.crt

@Autonomous 有一个小 tip：当你发现缺少一个中间证书的时候，可以将缺少的证书的完整的名字中的非 alphanumeric 字符全部删除，末尾加上".crt"，在开头加上 "http://crt.comodoca.com" 来组成证书的下载地址，放到浏览器的地址栏或者 curl 这类 HTTP 工具中下载该证书。

比如你现在缺少名为 "COMODO SHA-256 Client Authentication and Secure Email CA" 的中间证书，

那么就可以把 "COMODO SHA-256 Clent Authentication and Secure Email CA" 中的所有非 alphanumeric 字符删掉变成 ""COMODOSHA256ClientAuthenticationandSecureEmailCA",然后在结尾加上 ".crt"，在开头加上 "http://crt.comodocaom"，组合而成：

http://crt.comodoca.com/COMODOSHA256ClientAuthenticationandSecureEmailCA.crt

这就是我在上一楼中给出的 URL，输入到浏览器就可以从 Comodo 的证书站点下载到改名成的证书。

@NSTongG 感谢解答！现在已经可以正确信任朋友的公钥了，不过我依然有几个疑问：
1.我和朋友都是在同一家CA申请的证书，只是我要早些，他在昨天晚上完成了申请，为什么我俩的中级证书颁证机构（签发者）不一样呢？
2.我注意到KeyChain Access当中已经存有许多的证书，为什么却还要下载并导入COMODO的crt证书呢？为什么系统没有预先将此证书整合到KeyChain Access中去而是需要用户手动导入并构建信任链呢？这其中会不会有潜在的安全风险呀？

朋友的：


我的：

以后不用微博图床了，这图都缩成这鬼样子。

@Autonomous

0. 这可能与 Comodo 内部的证书签发规则有关，比如你可以看到，两者的区别是一个是 "SHA-256 Client" 而另一个则是 "RSA Client"。

Comodo 的证书签发规则我太不清楚，但是我可以用 Apple 的证书签发规则来举个例子：

所有的加入了 Apple 的开发者计划的开发者们都会得到一组 Apple 签发的开发者证书，拿 OS X 应用来说，这组开发者证书所要进行代码签名（code signing）的 OS X 的应用主要分两种：“要在 Mac App Store 上架” 的和 “使用其他渠道分发（如 GitHub 或者 Sourceforge.net）” 的。

所有的开发者证书的根证书都是名为 Apple Root CA 的根证书，你可以在 Keychain Access 的 System Roots 中找到：





上两张图中可以看到，用于对要提交到 Mac App Store 的应用进行代码签名的证书的中间签发机构名为：Apple Worldwide Developer Relations Certification Authority，而用于对第三方渠道发布的应用进行代码签名的证书的中间签发机构名为：Developer ID Certification Authority。

Apple Worldwide Developer Relations Certification Authority 和 Developer ID Certification Authority 都是由 Apple Root CA 签发的，两者都适用于签发其他证书的，都处于以 Apple Root CA 为根的证书的信任链中，但是两者的用法又有所不同，这就有点像你的朋友的证书的签发者：COMODO SHA-256 Client Authentication and Secure Email CA 与我们的证书的签发者 COMODO RSA Client Authentication and Secure Email CA 之间的不同。

1. 导入 Comodo 的其它证书是为了构建完整的信任链，这在理论上是不存在潜在的安全风险的。OS X 系统自带了很多根证书，你可以在 Keychain Access 的 System Roots 中找到，这其中包括 VeriSign 和 DigiCert 等根证书，也包括了 Comodo 的 CA 证书。只要一张证书能够向上追溯到 System Roots 中的根证书，就说明这张证书是受信任的。关于信任链（chain of trust）的概念可以参考： https://en.wikipedia.org/wiki/Chain_of_trust

感谢楼主的耐心解答！解决了我的疑问！

确实很棒，但是我发送的对象大都习惯于使用网页端，想推广加密都做不到啊……

@Sharuru 那就应该向对方普及，这也是为了自己隐私的安全。我一般新认识朋友之后就会让他们使用加密技术发送邮件 XD

@NSTongG 如果对面是小白的话……感觉真的没什么动力去普及……ORZ