「深刻 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中的傳輸服務。