今儿咱们来聊Exchange里的证书，CAS与MBX角色都有用到证书的地方，只是CAS角色更依赖证书一些，在一台Exchange服务器刚刚安装完成的时候，安装程序会自动生成一张自签名证书，这张自签名证书往往并不满足咱们的需求，所以咱们一般会向企业CA再去针对Exchange所涉及到的多个IIS服务的DNS备用名称申请合适的额证书。
Exchange在哪些地方用到证书
1、 让客户端验证服务器的身份。这是最常规的用法，大多数管理员可能都碰到过证书名称不匹配引起的客户端报错。
2、 服务器去验证客户端或者设备的身份，也就是客户端证书验证。
3、
保护SMTP邮件传输，配合传输层加密协议（TLS）来加密SMTP连接。同组织内的Exchange服务器之间传递邮件默认应用了TLS连接，与组织之外的Exchange服务器同样也可以手动打开TLS选项。
4、 服务器与服务器之间的身份验证，也称为相互TLS，最常用于与Lync服务器集成。
在windows操作系统和一些应用上也会用到证书，比如用IPsec加密的，或者数字签名的Powershell脚本。咱们在这里就只说Exchange。需要提到的是，Exchange
2013目前还不能支持IIS8的集中证书存储功能，不知道Exchange 2016有没有改观。
如果你只是在内部网络里运行Exchange，压根没打算提供外部用户访问的话。只要你不怕麻烦去给客户端和ActiveSync设备统一安装一下，Exchange2013默认的自签名证书是完全够用的。对于加域的客户端比较简单，做一个GPO，将这张自签名证书下发到加域的PC的信任证书颁发机构里去，当然了，一张证书对应一台CAS服务器，有几台CAS服务器，就得把这几天CAS上的自签名证书全下发下去。这还是PC机，如果你碰上windows
phone那种手动装证书的，那可就…想象一下这个工作量吧…默认的自签名证书有效期为五年，还行，至少你忙乎了一阵可以管上五年时间。
但是当你有外部客户端访问需求的时候，这个可就真不行了。因为自签名的证书，并不被外部的客户端所信任（除非你说服他们都装上，类似一开始的12306）。
从哪里获得证书
Ok，看了上面的东西，你醒悟过来说咱不要用自签名证书，这时候你有两个选择，一是在域内启用Windows证书服务功能，然后构建企业内的PKI结构。二是去从第三方证书提供商（根证书授权的）买证书。每种方法都有自己的好处和坏处。
第三方的证书需要额外的金钱成本花费，一般企业的单域名证书在3000-6000一年不等（看厂商和种类）加一个域名则翻一倍，通配符域名的证书基本定价政策都是单域名价格x3。但是买了这种第三方的公网证书之后，你的域名就被纳入了互联网级的信任链，比方你买了VeriSign或者DigiCert，国内的什么WoSign，这些机构已经是被认为是默认信任的，换句话说，你可以在一台新装好的操作系统的证书存储里翻到这些机构的根CA证书。这样别的公司或者组织，或者外部的计算机和设备，就可以默认信任你的Exchange服务器，而不用做任何额外的设置了。
设置自有的PKI架构是完全免费的，因为它依靠windows
server自带的证书服务来运行，而且这样就让管理员完全管控了证书的签发，并且知道哪些证书是用来做啥的。出了问题也很好解决，你只需要重新签发一张正确的证书就可以了。而且如果你想在后期在环境内部署EFS或者是智能卡登陆，拥有自己的CA来干这些事可比用第三方证书简单的多。用自己架设的域内的CA，给每台Exchange服务器进行签发证书，只要是在域内的客户端默认都会安装域根CA的根证书，于是乎它们默认的也会信任Exchange服务器。然而外部的设备或者是客户端仍然需要安装，但是只用装一张，也就是你们内部域CA的根证书即可达到信任Exchange服务器的效果。当然如果你有钱也可以买通配符证书，让整个组织的服务器都被外部用户默认信任。这依然涉及到成本问题，而且非常高，如果有需要，就去各种证书网站上看看价格吧。
证书内容
不管以哪种方法签发了证书，SSL证书里都会包含公钥和私钥来为客户端和服务器之间的内容进行加密。CAS服务器提供一份公钥的拷贝给连接上来的客户端，客户端使用公钥加密通信，而CAS能够使用其自己的私钥解密通信，这样客户端和服务器之间就建立起了一个安全通道。接着，客户端生成一个共享的key，并且使用CAS的公钥来加密这个共享Key，CAS能够用私钥解密出这个共享的Key，然后两边约定使用这个共享的Key来加密信息进行交流，注意这里不光是客户端和CAS使用的公钥和私钥，还存在一个共享的Key。这样哪怕有人截取了数据，并且拿到了CAS的公钥，它依然无法获得里边儿的内容，因为他没有CAS的私钥，拿不到这个共享Key。（具体的SSL
handshake过程请参考：https://support.microsoft.com/en-us/kb/257591）
除了公钥和私钥这些事，证书还有其他的一些附加的嵌入属性，包括有效期，主体名称，其他的使用者可选名称（subject alternative names
SANS）。当你为一台服务器请求了证书，CA会在签发这张证书的时候，将这些嵌入属性进行数字签名，以保证其在证书被签发之后不被篡改。这就意味着，如果你在证书都生成好了之后，发现证书里头有些信息存在问题，那就只能老老实实重新申请一张吧。
规划证书的建议
对于这个问题，我这儿有以下几个建议
1、 最小化你所使用的证书数量，你使用的证书越多，花费越高，或者说，环境变得越复杂
2、
使用SAN证书，常规的证书只包含一个域名，但是SAN证书，也就是使用者可选名称里可以包含多个域名。这样就可以减少证书的数量，你完全可以用一张SAN证书来涵盖所有的Exchange
2013服务的命名空间，比如将autodiscover.contoso.com,mail.contoso.com,cas01.contoso.com,cas02.contoso.com等等集合在一张SAN证书里。
3、 不要在证书的主要名称里用计算机名，考虑周全，不要写计算机名，而是用负载均衡阵列的名字，也就是一个服务器场统一访问点的FQDN
4、 记住你可以对不同的服务应用不同的证书
5、 部署vista SP1或者更新的客户端，这样你就不用担心由于客户端的兼容性引起的各种关于证书主体名称的问题了。
请求并应用证书
微软建议使用EAC内置的证书管理工具来申请和应用证书，然而不像Exchange
2010那样，在最后你不会看到PowerShell执行的具体细节。具体的步骤这里就不多介绍，使用过EAC和Exchange2010的同学对比一下就会发现微软在易用性上还是下了些功夫的。同样的也可以使用PowerShell命令来申请证书，比如我这里要申请一张多个使用者替代名称的证书：
New-ExchangeCertificate –GenerateRequest –Path ‘c:\temp\cert.req’ –SubjectName ‘c=CN;o=contoso;cn=mail.contoso.com’ –domainname ‘mail.contoso.com, autodiscover.contoso.com, legacy.contoso.com’ –PrivateKeyExportable $True
结合命名空间，再多说一些
还记得之前那篇关于命名空间的文章，我们把证书和命名空间结合起来，来看看以下三个场景的证书规划
场景一：
Contoso在Redmond和Portland有两个办公室，目前的环境是Exchange2007与Exchange2013共存的情况，且为两个2013的MBX部署了双Active的DAG，以增加站点恢复能力。客户端不用担心连接到了哪一个数据中心都可以正确的拿到邮箱数据，并且保证不存在连接上的单点故障，负载均衡器上则继续开启SSL卸载。
那么对于以上需求，Contoso需要以下命名空间
1、 autodiscover.contoso.com –自动发现
2、 legacy.contoso.com –Ex2007客户端在共存条件下必须的命名空间
3、 mail.contoso.com --OWA,ActiveSync,OutlookAnywhere主要命名空间
4、 smtp.contoso.com—IMAP客户端使用
5、 imap.contoso.com—IMAP客户端使用
那么我们就有了以下符合非绑定模型的命名空间，（开启了SSL卸载，负载均衡可以在7层上面对各协议进行健康检测和负载均衡。）
场景二：
Contoso公司在Redmond和Bel
Air各有一个数据中心，目前是Exchange
2010与Exchange2013共存的情况，Contoso公司要求用户连接到自己最近的客户端，除非是发生了故障才进行切换，并且在负载均衡设备上禁用SSL
卸载（那么就得通过每服务一个命名空间的方式来解决健康检测的问题）。
为了符合以上需求，我们需要以下命名空间
1、 autodiscover.contoso.com
2、 mail-wa.contoso.com Redmond数据中心的OWA服务的主要命名空间
3、 mail-md.contoso.com Bel Air数据中心的OWA服务的主要命名空间
4、 mailfb-wa.contoso.com Redmond数据中心的OWA服务的failback命名空间
5、 mailfb-md.contoso.com Bel Air数据中心的OWA服务的failback命名空间
6、 eas-wa.contoso.com -Redmond数据中心的EAS命名空间
7、 eas-md.contoso.com -BelAir数据中心的EAS命名空间
8、 oa-wa.contoso.com -Redmond的OutlookAnywhere
9、 oa-md.contoso.com -BelAir的OutlookAnywhere
10、 ews-wa.contoso.com - Redmond的Exchange Web Services
11、 ews-md.contoso.com
12、 oab-wa.contoso.com - Redmond的离线地址簿
13、 oab-md.contoso.com
这样咱们的方案就符合了绑定的命名空间的模型
场景三：
Contoso在Redmond和Portland有两个办公室，目前的环境是Exchange2007与Exchange2013共存的情况，且为两个2013的MBX部署了双Active的DAG，以增加站点恢复能力。客户端不用担心连接到了哪一个数据中心都可以正确的拿到邮箱数据，并且保证不存在连接上的单点故障，负载均衡器上关闭了SSL卸载。
那么满足了以上需求，我们需要以下命名空间
1、 autodiscover.contoso.com
2、 legacy.contoso.com
3、 mail.contoso.com
4、 oa.contoso.com
5、 ews.contoso.com
6、 oab.contoso.com
OK，证书我们就扯完了，目前为止一共是9篇文章，关于CAS前端部分基本告一段落，下一章开始咱们就聊聊Exchange 2013中的传输服务。