「深刻 Exchange 2013」09 证书

今儿我们来聊Exchange里的证书，CAS与MBX角色都有用到证书的地方，只是CAS角色更依赖证书一些，在一台Exchange服务器刚刚安装完成的时候，安装程序会自动生成一张自签名证书，这张自签名证书每每并不知足我们的需求，因此我们通常会向企业CA再去针对Exchange所涉及到的多个IIS服务的DNS备用名称申请合适的额证书。

Exchange在哪些地方用到证书

一、 让客户端验证服务器的身份。这是最常规的用法，大多数管理员可能都碰到过证书名称不匹配引发的客户端报错。

二、 服务器去验证客户端或者设备的身份，也就是客户端证书验证。

三、 保护SMTP邮件传输，配合传输层加密协议（TLS）来加密SMTP链接。同组织内的Exchange服务器之间传递邮件默认应用了TLS链接，与组织以外的Exchange服务器一样也能够手动打开TLS选项。

四、 服务器与服务器之间的身份验证，也称为相互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会在签发这张证书的时候，将这些嵌入属性进行数字签名，以保证其在证书被签发以后不被篡改。这就意味着，若是你在证书都生成好了以后，发现证书里头有些信息存在问题，那就只能老老实实从新申请一张吧。

规划证书的建议

对于这个问题，我这儿有如下几个建议

一、 最小化你所使用的证书数量，你使用的证书越多，花费越高，或者说，环境变得越复杂

二、 使用SAN证书，常规的证书只包含一个域名，可是SAN证书，也就是使用者可选名称里能够包含多个域名。这样就能够减小证书的数量，你彻底能够用一张SAN证书来涵盖全部的Exchange 2013服务的命名空间，好比将autodiscover.contoso.com,mail.contoso.com,cas01.contoso.com,cas02.contoso.com等等集合在一张SAN证书里。

三、 不要在证书的主要名称里用计算机名，考虑周全，不要写计算机名，而是用负载均衡阵列的名字，也就是一个服务器场统一访问点的FQDN

四、 记住你能够对不一样的服务应用不一样的证书

五、 部署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须要如下命名空间

一、 autodiscover.contoso.com –自动发现

二、 legacy.contoso.com –Ex2007客户端在共存条件下必须的命名空间

三、 mail.contoso.com --OWA,ActiveSync,OutlookAnywhere主要命名空间

四、 smtp.contoso.com—IMAP客户端使用

五、 imap.contoso.com—IMAP客户端使用

那么咱们就有了如下符合非绑定模型的命名空间，（开启了SSL卸载，负载均衡能够在7层上面对各协议进行健康检测和负载均衡。）

场景二：

Contoso公司在Redmond和Bel Air各有一个数据中心，目前是Exchange 2010与Exchange2013共存的状况，Contoso公司要求用户链接到本身最近的客户端，除非是发生了故障才进行切换，而且在负载均衡设备上禁用SSL 卸载（那么就得经过每服务一个命名空间的方式来解决健康检测的问题）。

为了符合以上需求，咱们须要如下命名空间

一、 autodiscover.contoso.com

二、 mail-wa.contoso.com Redmond数据中心的OWA服务的主要命名空间

三、 mail-md.contoso.com Bel Air数据中心的OWA服务的主要命名空间

四、 mailfb-wa.contoso.com Redmond数据中心的OWA服务的failback命名空间

五、 mailfb-md.contoso.com Bel Air数据中心的OWA服务的failback命名空间

六、 eas-wa.contoso.com -Redmond数据中心的EAS命名空间

七、 eas-md.contoso.com -BelAir数据中心的EAS命名空间

八、 oa-wa.contoso.com -Redmond的OutlookAnywhere

九、 oa-md.contoso.com -BelAir的OutlookAnywhere

十、 ews-wa.contoso.com - Redmond的Exchange Web Services

十一、 ews-md.contoso.com

十二、 oab-wa.contoso.com - Redmond的离线地址簿

1三、 oab-md.contoso.com

这样我们的方案就符合了绑定的命名空间的模型

场景三：

Contoso在Redmond和Portland有两个办公室，目前的环境是Exchange2007与Exchange2013共存的状况，且为两个2013的MBX部署了双Active的DAG，以增长站点恢复能力。客户端不用担忧链接到了哪个数据中心均可以正确的拿到邮箱数据，而且保证不存在链接上的单点故障，负载均衡器上关闭了SSL卸载。

那么知足了以上需求，咱们须要如下命名空间

一、 autodiscover.contoso.com

二、 legacy.contoso.com

三、 mail.contoso.com

四、 oa.contoso.com

五、 ews.contoso.com

六、 oab.contoso.com

OK，证书咱们就扯完了，目前为止一共是9篇文章，关于CAS前端部分基本告一段落，下一章开始我们就聊聊Exchange 2013中的传输服务。