共用方式為

數位憑證和 SSL

  • 發行項

適用於：Exchange Server 2013

安全通訊端層 (SSL) 是保護用戶端與伺服器之間通訊的方法。 針對 Exchange Server 2013，SSL 可用來協助保護伺服器與用戶端之間的通訊。 用戶端包括行動電話、組織網路內的電腦，以及組織網路外部的電腦。

根據預設，當您安裝 Exchange 2013 時，當您使用 Outlook Web App、Exchange ActiveSync 和 Outlook Anywhere 時，會使用 SSL 加密用戶端通訊。

SSL 會要求您使用數位憑證。 本主題摘要說明不同類型的數位憑證，以及如何將 Exchange 2013 設定為使用這些數位憑證類型的相關資訊。

數位憑證概觀

數位憑證是電子檔案，其運作的方式類似線上密碼，可驗證使用者或電腦的身分。 它們可用來建立用於用戶端通訊的 SSL 加密通道。 憑證是由憑證授權單位單位 (CA) 發出的數位語句，可保證憑證持有者的身分識別，並可讓合作物件使用加密以安全的方式進行通訊。

數位憑證會執行下列動作：

  • 他們會驗證其擁有者 (人員、網站，甚至是路由器等網路資源，) 是真正或他們所宣告的身分。

  • 它們可保護線上交換的資料免于遭竊或竄改。

數位憑證可以由受信任的協力廠商 CA 或 Windows 公開金鑰基礎結構發行， (PKI) 使用憑證服務，也可以自我簽署。 每種類型的憑證都有優缺點。 每種類型的數位憑證都是防竄改的，而且無法偽造。

可針對數種用法來發出憑證。 這些用途包括 Web 使用者驗證、Web 服務器驗證、安全/多用途網際網路郵件擴充功能 (S/MIME) 、網際網路通訊協定安全性 (IPsec) 、傳輸層安全性 (TLS) ，以及程式碼簽署。

憑證會包含一個公開金鑰，並會將該公開金鑰附加至具有相對應之私密金鑰的個人、電腦或服務的識別碼。 用戶端和伺服器會使用公用和私密金鑰來加密資料，然後再傳輸資料。 針對以 Windows 為基礎的使用者、電腦和服務，當受信任的根憑證存放區中有根憑證複本且憑證包含有效的憑證路徑時，就會建立 CA 的信任。 若要讓憑證有效，憑證不得已撤銷，且有效期間不得過期。

憑證類型

數位憑證有三種主要類型：自我簽署憑證、Windows PKI 產生的憑證和協力廠商憑證。

自我簽署憑證

當您安裝 Exchange 2013 時，會在信箱伺服器上自動設定自我簽署憑證。 自我簽署憑證是由建立該憑證的應用程式所簽署。 憑證的主體和名稱相符。 簽發者和主體定義于憑證上。 此自我簽署憑證可用來加密用戶端存取伺服器與信箱伺服器之間的通訊。 用戶端存取伺服器會自動信任信箱伺服器上的自我簽署憑證，因此信箱伺服器上不需要任何協力廠商憑證。 當您安裝 Exchange 2013 時，也會在 Client Access 伺服器上建立自我簽署憑證。 此自我簽署憑證可讓某些用戶端通訊協定使用 SSL 進行通訊。 Exchange ActiveSync和Outlook Web App可以使用自我簽署憑證來建立 SSL 連線。 Outlook Anywhere 無法在用戶端存取伺服器上使用自我簽署憑證。 自我簽署憑證必須手動複製到用戶端電腦或行動裝置上受信任的根憑證存儲。 當用戶端透過 SSL 連線到伺服器，而伺服器顯示自我簽署憑證時，系統會提示用戶端確認憑證是由受信任的授權單位所簽發。 用戶端必須明確信任發行授權單位。 如果用戶端確認信任，則 SSL 通訊可以繼續。

注意事項

根據預設，安裝在信箱伺服器或伺服器上的數位憑證是自我簽署憑證。 您不需要將組織中信箱伺服器上的自我簽署憑證取代為受信任的協力廠商憑證。 用戶端存取伺服器會自動信任信箱伺服器上的自我簽署憑證，而且信箱伺服器上的憑證不需要其他設定。

小型組織通常會決定不使用協力廠商憑證，或不安裝自己的 PKI 來發行自己的憑證。 他們可能會做出此決定，因為這些解決方案的成本太高，因為他們的系統管理員缺乏建立自己的憑證階層的經驗和知識，或基於這兩個原因。 成本最低，而且當您使用自我簽署憑證時，安裝程式很簡單。 不過，當您使用自我簽署憑證時，建立憑證生命週期管理、更新、信任管理和撤銷的基礎結構會更加困難。

Windows 公開金鑰基礎結構憑證

第二種類型的憑證是 Windows PKI 產生的憑證。 PKI 是數位憑證、憑證授權單位單位和註冊授權單位 (RA) 系統，可使用公開金鑰密碼編譯來驗證與電子交易相關之每一方的有效性。 當您在使用 Active Directory 的組織中實作 PKI 時，您會提供憑證生命週期管理、更新、信任管理和撤銷的基礎結構。 不過，部署伺服器和基礎結構以建立和管理 Windows PKI 產生的憑證需要一些額外成本。

憑證服務是部署 Windows PKI 的必要專案，而且可以透過在 主控台 中新增或移除程式來安裝。 您可以在網域中的任何伺服器上安裝憑證服務。

如果您從已加入網域的 Windows CA 取得憑證，您可以使用 CA 來要求或簽署憑證，以簽發給您網路上自己的伺服器或電腦。 這可讓您使用類似協力廠商憑證廠商的 PKI，但成本較低。 這些 PKI 憑證無法公開部署，因為可以是其他類型的憑證。 不過，當 PKI CA 使用私密金鑰簽署要求者的憑證時，會驗證要求者。 此 CA 的公開金鑰是憑證的一部分。 在受信任根憑證存儲中具有此憑證的伺服器可以使用該公開金鑰來解密要求者的憑證，並驗證要求者。

部署 PKI 產生憑證的步驟類似于部署自我簽署憑證所需的步驟。 您仍然必須將受信任根憑證的複本從 PKI 安裝到您想要能夠建立 Microsoft Exchange SSL 連線之電腦或行動裝置的受信任根憑證存放區。

Windows PKI 可讓組織發佈自己的憑證。 用戶端可以從內部網路上的 Windows PKI 要求和接收憑證。 Windows PKI 可以更新或撤銷憑證。

受信任的協力廠商憑證

協力廠商或商業憑證是由協力廠商或商業 CA 所產生的憑證，然後購買以供您在網路伺服器上使用。 自我簽署和 PKI 型憑證的其中一個問題是，因為憑證不是由用戶端電腦或行動裝置自動信任，所以您必須確定您將憑證匯入用戶端電腦和裝置上受信任的根憑證存放區。 協力廠商或商業憑證沒有這個問題。 大部分的商業 CA 憑證都已經受到信任，因為憑證已經位於受信任的根憑證存儲中。 因為簽發者是受信任的，所以憑證也是受信任的。 使用協力廠商憑證可大幅簡化部署。

對於必須公開部署憑證的較大型組織，最佳解決方案是使用協力廠商或商業憑證，即使憑證有相關聯的成本也一般。 商業憑證可能不是中小型組織的最佳解決方案，而且您可能會決定使用其中一個其他可用的憑證選項。

選擇憑證類型

當您選擇要安裝的憑證類型時，需要考慮幾件事。 憑證必須經過簽署才能有效。 它可以是自我簽署或由 CA 簽署。 自我簽署憑證有限制。 例如，並非所有行動裝置都可讓使用者在受信任的根憑證存放區中安裝數位憑證。 在行動裝置上安裝憑證的能力取決於行動裝置製造商和行動服務提供者。 某些製造商和行動服務提供者會停用對受信任根憑證存儲的存取。 在此情況下，無法在行動裝置上安裝自我簽署憑證或來自 Windows PKI CA 的憑證。

預設 Exchange 憑證

根據預設，Exchange 會在 Client Access 伺服器和信箱伺服器上安裝自我簽署憑證，以便加密所有網路通訊。 加密所有網路通訊需要每部 Exchange 伺服器都有可使用的 X.509 憑證。 您應該將用戶端存取伺服器上的這個自我簽署憑證取代為用戶端自動信任的憑證。

「自我簽署」表示憑證只由 Exchange Server 本身建立和簽署。 因為它不是由一般信任的 CA 建立和簽署，所以除了相同組織中的其他 Exchange 伺服器以外，預設的自我簽署憑證不會受到任何軟體的信任。 所有 Exchange 服務都會啟用預設憑證。 其主旨別名 (SAN) ，對應至安裝在其中的 Exchange Server 伺服器名稱。 它也有包含伺服器名稱和完整功能變數名稱的 SAN 清單， (伺服器的 FQDN) 。

雖然 Exchange 組織中的其他 Exchange 伺服器會自動信任此憑證，但網頁瀏覽器、Outlook 用戶端、行動電話和其他電子郵件用戶端等用戶端不會自動信任它。 因此，請考慮將此憑證取代為 Exchange 用戶端存取伺服器上受信任的協力廠商憑證。 如果您有自己的內部 PKI，且所有用戶端都信任該實體，您也可以使用您自行發出的憑證。

依服務的憑證需求

憑證用於 Exchange 中的幾個專案。 大部分的客戶也會在多個 Exchange 伺服器上使用憑證。 一般而言，您擁有的憑證越少，憑證管理就會變得更容易。

IIS

下列所有 Exchange 服務都會在指定的 Exchange 用戶端存取伺服器上使用相同的憑證：

  • Outlook Web App

  • Exchange 系統管理中心 (EAC)

  • Exchange Web 服務

  • Exchange ActiveSync

  • Outlook 無所不在

  • 自動探索

  • Outlook 通訊錄散發

因為只有單一憑證可以與網站相關聯，而且這些服務預設會在單一網站下提供，所以這些服務的用戶端使用的所有名稱都必須位於憑證 (中，或落在憑證) 中的萬用字元名稱之下。

POP/IMAP

用於 POP 或 IMAP 的憑證可以與用於 IIS 的憑證分開指定。 不過，為了簡化系統管理，建議您在 IIS 憑證中包含 POP 或 IMAP 服務名稱，並針對所有這些服務使用單一憑證。

SMTP

您可以針對您設定的每個接收連接器使用個別的憑證。 憑證必須包含 SMTP 用戶端 (或其他 SMTP 伺服器) 用來連線到該連接器的名稱。 若要簡化憑證管理，請考慮在單一憑證中包含您必須支援 TLS 流量的所有名稱。

數位憑證和 Proxy

Proxy 是一部伺服器將用戶端連線傳送至另一部伺服器的方法。 在 Exchange 2013 的案例中，當用戶端存取伺服器向包含用戶端信箱使用中複本的信箱伺服器代理傳入用戶端要求時，就會發生這種情況。

當用戶端存取伺服器 Proxy 要求時，SSL 會用於加密，但不會用於驗證。 信箱伺服器上的自我簽署憑證會加密用戶端存取伺服器與信箱伺服器之間的流量。

反向 Proxy 和憑證

許多 Exchange 部署會使用反向 Proxy 在網際網路上發佈 Exchange 服務。 反向 Proxy 可以設定為終止 SSL 加密、檢查伺服器上的清除流量，然後開啟從反向 Proxy 伺服器到其後方 Exchange 伺服器的新 SSL 加密通道。 這稱為 SSL 橋接。 設定反向 Proxy 伺服器的另一種方式是讓 SSL 連線直接傳遞至反向 Proxy 伺服器後方的 Exchange 伺服器。 使用任一部署模型，網際網路上的用戶端會使用 Exchange 存取的主機名稱連線到反向 Proxy 伺服器，例如 mail.contoso.com。 然後反向 Proxy 伺服器會使用不同的主機名稱連線到 Exchange，例如 Exchange 用戶端存取伺服器的電腦名稱稱。 您不需要在憑證上包含 Exchange 用戶端存取伺服器的電腦名稱稱，因為最常見的反向 Proxy 伺服器能夠將用戶端使用的原始主機名稱與 Exchange 用戶端存取伺服器的內部主機名稱相符。

SSL 和分割 DNS

分割 DNS 是一種技術，可讓您針對相同的主機名稱設定不同的 IP 位址，視原始 DNS 要求的來源位置而定。 此技術同時稱為分割地平線 DNS、分割檢視 DNS 或分腦 DNS。 分割 DNS 可讓您的用戶端透過相同的主機名稱 (不論是從網際網路或內部網路連線) 連線至 Exchange，協助您減少必須管理的 Exchange 主機名稱數量。 分割 DNS 可讓源自內部網路的要求接收與源自網際網路的要求不同的 IP 位址。

在小型 Exchange 部署中通常不需要分割 DNS，因為使用者可以存取來自內部網路或網際網路的相同 DNS 端點。 不過，使用較大的部署時，此設定會導致傳出的網際網路 Proxy 伺服器和反向 Proxy 伺服器的負載過高。 針對較大的部署，請設定分割 DNS，例如外部使用者存取 mail.contoso.com 和內部使用者存取 internal.contoso.com。 針對此設定使用分割 DNS，可確保您的使用者不需要記得使用不同的主機名稱，視其所在位置而定。

遠端 Windows PowerShell

Kerberos 驗證和 Kerberos 加密是用於從 Exchange 系統管理中心 (EAC) 和 Exchange 管理命令介面進行遠端Windows PowerShell存取。 因此，您不需要設定 SSL 憑證以與遠端Windows PowerShell搭配使用。

數位憑證最佳做法

雖然組織的數位憑證組態會因為特殊需求而有所不同，還是會提供最佳作法相關資訊，協助您選擇適合的數位憑證組態。

最佳做法：使用受信任的協力廠商憑證

若要防止用戶端收到有關未受信任憑證的錯誤，您的 Exchange Server 所使用的憑證必須由用戶端信任的人員簽發。 雖然大部分的用戶端都可以設定為信任任何憑證或憑證簽發者，但在 Exchange Server 上使用受信任的協力廠商憑證會比較簡單。 這是因為大部分的用戶端都已經信任其根憑證。 有數個協力廠商憑證簽發者提供專為 Exchange 設定的憑證。 您可以使用 EAC 來產生與大部分憑證簽發者搭配運作的憑證要求。

如何選取憑證授權單位單位

CA) (憑證授權單位單位是一家發行並確保憑證有效性的公司。 例如，用戶端軟體 (，例如 Microsoft Internet Explorer 之類的瀏覽器，或 Windows 或 Mac OS 等作業系統) 具有他們信任的 CA 內建清單。 此清單通常可以設定為新增和移除 CA，但該組態通常很麻煩。 當您選取要從中購買憑證的 CA 時，請使用下列準則：

  • 請確定將連線到 Exchange 伺服器的用戶端軟體 (作業系統、瀏覽器和行動電話) 信任 CA。

  • 選擇 CA，指出它支援「整合通訊憑證」以搭配 Exchange Server 使用。

  • 請確定 CA 支援您將使用的憑證類型。 請考慮使用主體別名 (SAN) 憑證。 並非所有 CA 都支援 SAN 憑證，而其他 CA 則不支援所需的主機名稱數目。

  • 請確定您為憑證購買的授權可讓您將憑證放在您想要使用的伺服器數目上。 某些 CA 只允許您將憑證放在一部伺服器上。

  • 比較 CA 之間的憑證價格。

最佳做法：使用 SAN 憑證

根據您在 Exchange 部署中設定服務名稱的方式，您的 Exchange 伺服器可能需要可代表多個功能變數名稱的憑證。 雖然萬用字元憑證，例如 *.contoso.com 的萬用字元憑證，可以解決此問題，但許多客戶對於維護可用於任何子域的憑證的安全性影響感到不自在。 更安全的替代方法是在憑證中將每個必要網域列為 SAN。 根據預設，當 Exchange 產生憑證要求時，會使用此方法。

最佳做法：使用 Exchange 憑證精靈來要求憑證

Exchange 中有許多使用憑證的服務。 要求憑證時常見的錯誤是提出要求，而不包含正確的服務名稱集。 Exchange 系統管理中心的憑證精靈可協助您在憑證要求中包含正確的名稱清單。 精靈可讓您指定憑證必須使用的服務，並根據選取的服務，包含憑證中必須具備的名稱，以便與這些服務搭配使用。 當您已部署 Exchange 2013 伺服器的初始集合，並決定要針對部署的不同服務使用哪一個主機名稱時，請執行憑證精靈。 在理想情況下，您只需要針對部署 Exchange 的每個 Active Directory 網站執行憑證精靈一次。

您可以使用免費提供寬限期的憑證授權單位單位，在這段期間內，您可以傳回憑證並要求具有一些額外主機名稱的相同新憑證，而不必擔心忘記所購買憑證 SAN 清單中的主機名稱。

最佳做法：盡可能少使用主機名稱

除了盡可能少使用憑證之外，您也應該盡可能少使用主機名稱。 此做法可以節省成本。 許多憑證提供者會根據您新增至憑證的主機名稱數目來收取費用。

您可以採取的最重要步驟，減少您必須擁有的主機名稱數目，因此，憑證管理的複雜度是不要在憑證的主體別名中包含個別的伺服器主機名稱。

您必須在 Exchange 憑證中包含的主機名稱是用戶端應用程式用來連線到 Exchange 的主機名稱。 以下是名為 Contoso 的公司所需的一般主機名稱清單：

  • Mail.contoso.com：此主機名稱涵蓋 Exchange 的大部分連線，包括 Microsoft Outlook、Outlook Web App、Outlook Anywhere、離線通訊錄、Exchange Web 服務、POP3、IMAP4、SMTP、Exchange 主控台 和 ActiveSync。

  • Autodiscover.contoso.com：支援自動探索的用戶端會使用此主機名稱，包括 Microsoft Office Outlook 2007 和更新版本、Exchange ActiveSync和 Exchange Web 服務用戶端。

  • Legacy.contoso.com：在與 Exchange 2007 和 Exchange 2013 共存的案例中，需要此主機名稱。 如果您的用戶端在 Exchange 2007 和 Exchange 2013 上具有信箱，則設定舊版主機名稱可防止使用者在升級程式期間學習第二個 URL。

瞭解萬用字元憑證

萬用字元憑證是設計來支援網域和多個子域。 例如，設定 *.contoso.com 的萬用字元憑證會產生適用于 mail.contoso.com、web.contoso.com 和 autodiscover.contoso.com 的憑證。