共用方式為

瞭解數位憑證和 SSL

  • 發行項

 

適用版本： Exchange Server 2010 SP2, Exchange Server 2010 SP3

上次修改主題的時間： 2016-11-28

安全通訊端層 (SSL) 是一種用來保護用戶端與伺服器之間通訊安全的方法。 在 Microsoft Exchange Server 2010 Client Access Server 上，SSL 係用來協助確保伺服器與用戶端之間的連線安全。 這些用戶端包括行動裝置、組織網路中的電腦，以及組織網路外的電腦。 包括具備或不具備虛擬私人網路 (VPN) 連線的用戶端。

依預設，當您安裝 Exchange 2010 時，在使用 MicrosoftOfficeOutlook Web AppExchange ActiveSync 和 Outlook 無所不在時，會使用 SSL 加密用戶端通訊。 依預設，郵局通訊協定第 3 版 (POP3) 與網際網路訊息存取通訊協定第 4 版修訂版 1 (IMAP4) 並未設定為透過 SSL 通訊。

SSL 會要求您使用數位憑證。 本主題提供各種數位憑證類型的概觀，以及如何設定 Client Access Server 來使用這些數位憑證類型的相關資訊。

注意事項附註：
MicrosoftExchange Server 2010 不支援新一代密碼編譯 (CNG) 憑證。

目錄

數位憑證概觀

數位憑證及代理

數位憑證的最佳作法

用戶端限制

數位憑證概觀

數位憑證是電子檔案，其運作的方式類似線上密碼，可驗證使用者或電腦的身分。 它們會用來建立用戶端通訊使用的 SSL 加密通道。 憑證是由憑證授權單位 (CA) 發出的數位聲明，可證實憑證持有者的身分，並可讓各方透過加密功能，以安全的方式來通訊。

數位憑證可以執行下列作業：

  • 驗證其持有者—人員、網站，甚至網路資源 (例如：路由器)—的確就是其所宣稱的身分。

  • 它會保護在線上交換的資料不被竊取或擅改。

數位憑證可由信任的協力廠商 CA 或 MicrosoftWindows 公開金鑰基礎結構 (PKI) 使用憑證服務發出，或是自行簽署。 每種憑證類型都各有優缺點。 每種憑證類型都有防止擅改的特性，而且無法進行偽造。

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

憑證會包含一個公開金鑰，並會將該公開金鑰附加至具有相對應之私密金鑰的個人、電腦或服務的識別碼。 用戶端及伺服器都會使用公開及私密金鑰，先將資料加密，再進行傳輸。 對於 Windows 型使用者、電腦及服務而言，當信任的根憑證儲存區中有根憑證的副本，且該憑證包含有效的憑證路徑時，就會在 CA 中建立信任。 若要讓憑證生效，則憑證必須尚未遭到撤銷，且有效期限尚未到期。

憑證類型

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

自我簽署憑證hzwxtu

當您安裝 Exchange 2010 時，即會自動設定自行簽署的憑證。 自行簽署的憑證會由建立它的應用程式簽署。 憑證的主旨與名稱會相符。 憑證上會定義簽發者與主旨。自行簽署的憑證可允許某些用戶端通訊協定使用 SSL 進行通訊。Exchange ActiveSync 和 Outlook Web App 可以使用自行簽署的憑證來建立 SSL 連線。 Outlook 無所不在無法與自行簽署的憑證搭配使用。 自行簽署的憑證必須以手動方式複製到用戶端電腦或行動裝置上的信任根憑證儲存區中。 當用戶端透過 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 ActiveSync Mobile 6.0 或更高版本的裝置及來自信任之協力廠商 CA 的數位憑證，來執行 Windows 的憑證型驗證。

預設 Exchange 憑證

根據預設，Exchange 會安裝預設的自我簽署憑證，以便加密處理所有的網路通訊。 要加密所有的網路通訊時，每一台 Exchange 伺服器都必須具備可使用的 X.509 憑證。 請使用用戶端自動信任的任何一個憑證，來取代此自我簽署憑證。

「自我簽署」意指僅由 Exchange 伺服器本身所建立並簽署的憑證。 由於預設的自我簽署憑證並非由一般信任的 CA 所建立與簽署，因此除了相同組織裡的其他 Exchange 伺服器外，任何軟體都無法信任此預設自我簽署憑證。 所有 Exchange 服務會啟用預設的憑證。 該憑證的主體別名 (SAN) 對應至所安裝之 Exchange 伺服器的伺服器名稱。 並同時包含一份 SAN 清單，其中同時包括伺服器名稱與伺服器的完整網域名稱 (FQDN)。

儘管您的 Exchange 組織裡的 Exchange 伺服器會自動信任此憑證，網頁瀏覽器之類的用戶端、Outlook 用戶端、行動電話與其他電子郵件用戶端，甚至是外部電子郵件伺服器都無法自動信任此憑證。 因此，請考慮在安裝有 Client Access Server role 的 Exchange 伺服器，以及在任何面向外部的 Hub Transport Server 上，將此憑證取代為信任的協力廠商憑證。 如果您有專屬的內部 PKI，而且所有用戶端都信任該實體，您也可以使用自行發行的憑證。

依服務的憑證需求

Exchange 有一些項目會用到憑證。 大多數客戶會在一台以上的 Exchange 伺服器上使用憑證。 一般而言，擁有的憑證越少，憑證管理就越簡單。

IIS

下列所有的 Exchange 服務，會在指定的 Exchange 伺服器上使用相同的憑證：

  • Outlook Web App

  • Exchange 控制台

  • Exchange Web 服務

  • Exchange ActiveSync

  • Outlook 無所不在

  • 自動探索

  • Outlook 通訊錄發佈

由於一個網站只能與一個憑證關聯，且這些服務預設全都需要透過單一網站來提供，因此這些服務的用戶端所使用的所有名稱，都必須屬於同一個憑證 (或是憑證中某個萬用字元名稱)。

POP/IMAP

POP 或 IMAP 所使用的憑證，可以在 IIS 所使用的憑證之外個別來指定。 不過，為了簡化管理，建議您將 POP 或 IMAP 服務名稱都包含在 IIS 憑證中，並讓這些服務全部使用同一個憑證。

SMTP

您在 Hub Transport Server 或 Edge Transport Server 上所設定的每個接收連接器，都可以使用個別的憑證。 此憑證必須包含 SMTP 用戶端 (或其他 SMTP 伺服器) 用來與該連接器聯繫的名稱。 為了簡化憑證管理，請考慮將必須支援 TLS 流量的所有名稱包含在單一憑證中。

Live 同盟

在 Windows 共用案例中，用來與 Exchange Live 進行同盟的憑證可以包含任何名稱。 在同盟流程期間，您會識別要 Exchange 伺服器使用的憑證。 此憑證必須由 Windows Live 所信任的協力廠商憑證授權單位來發行。 如果其他服務的 Exchange 憑證係來自 Windows Live 所信任的協力廠商憑證授權單位，則您可以讓這些服務與 Windows Live 的同盟使用單一憑證。

整合通訊

當您將 Exchange Unified Messaging Server 連線至 Microsoft Office Communications Server 2007 R2 伺服器時，或連線至協力廠商 SIP 閘道或專用交換機 (PBX) 電話語音設備時，您可以使用自行簽署或信任的協力廠商憑證，以建立安全的工作階段。 只要憑證的 SAN 清單中具有所有 Unified Messaging Server 的 FQDN，您就可以在所有 Unified Messaging Server 上使用單一憑證。 否則，您必須為每一個 Unified Messaging Server 產生不同憑證，此時，Unified Messaging Server 的 FQDN 位於主體一般名稱 (CN) 或 SAN 清單中。 Exchange 整合通訊不支援 Communications Server 2007 和 Communications Server 2007 R2 使用萬用字元憑證。

Outlook Web App 立即訊息搭配 Office Communications Server 2007 R2

Outlook Web App 中的 Exchange 2010 包含程式設計介面，可讓立即訊息提供者撰寫增益集來控制目前狀態和立即訊息功能。 Communications Server 2007 R2 有可用的增益集。 當您使用此增益集時，必須使用憑證來保護 Communications Server 2007 R2 伺服器與 Exchange 2010 Client Access Server 之間的連線安全。 該憑證必須安裝在 Exchange Client Access Server 上。 只要憑證 CN 或SAN 中有一個主機名稱存在於 Communications Server 的 [主機授權清單] 中，您就可以在所有 Exchange 2010 Client Access Server 上使用多個憑證或單一憑證。 此值可以是憑證中可用的任何主機名稱，例如 mail.contoso.com。不支援使用萬用字元憑證來建立對 Communications Server 2007 或 2007 R2 的連線安全。

傳統 Exchange 伺服器

當您遵照最佳作法將 Microsoft Exchange Server 2003 或 Exchange Server 2007 轉換成 Exchange 2010 時，會產生新的主機名稱 (legacy.contoso.com)，可在舊版的 Exchange 與 Exchange 2010 並存期間運用在信箱上。 此舊版主機名稱必須同時包含在您使用的憑證中。 如需如何從 Exchange Server 2003 和 Exchange 2007 升級至 Exchange 2010的相關資訊，請參閱從 Exchange 2003 Client Access 升級和從 Exchange 2007 Client Access 升級。

回到頁首

數位憑證及代理

當某一台 Client Access Server 將用戶端連線傳送給另一台 Client Access Server 時，便會用到代理方式。 當某一台 Client Access Server 將流量代理至另一台 Client Access Server 時，會出現兩種情況。

  1. 面向網際網路之 Active Directory 網站中的 Client Access Server，會將流量代理至不是面向網際網路之網站中的 Client Access Server。 此舉可確保儘可能接近用戶端信箱伺服器要求，以處理所有用戶端要求。

  2. Exchange 2010 的 Client Access Server 會代理來自 Exchange 2003 或 Exchange 2007 上具有信箱的用戶端連線。 這些用戶端連線將會被代理至 Exchange 2007 Client Access Server。 會發生這種情況，是因為對許多 Exchange 服務而言，Client Access Server 無法處理執行舊版 Exchange 的信箱伺服器所提供的各種要求。

當 Client Access Server 開始代理要求時，會使用 SSL 進行加密處理 (而非驗證用途)。 在大多數情況中，自我簽署憑證可以用於 Client Access Server 代理程序。 如果貴公司需要格外安全的規則，可以將組態金鑰設為進行 Client Access Server 代理時，會要求提供信任的憑證。 在此情況下，您可以將下列金鑰設為 false：

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeOWA\AllowInternalUntrustedCerts

編輯登錄錯誤可能會導致嚴重的問題，要求您重新安裝作業系統。因編輯登錄錯誤所造成的問題可能無法解決。所以，請在編輯登錄之前，備份任何有用的資料。

如需代理的相關資訊，請參閱了解 Proxy 與重新導向。

反向 Proxy 和憑證

大多數的 Exchange 部署會使用反向 Proxy，將 Exchange 服務發佈在網際網路上。 常見的反向 Proxy 產品範例，包括 Microsoft Internet Security and Acceleration (ISA) Server 與檢查點。 這些反向 Proxy 可以設定來終止 SSL 加密，檢查伺服器中的未加密流量，然後從反向 Proxy 伺服器，對位於後方的 Exchange 伺服器開啟新的 SSL 加密通道。 這稱為 SSL 橋接。 另一種設定反向 Proxy 伺服器的方式，就是讓 SSL 連線直接穿透並傳送至位於反向 Proxy 伺服器後方的 Exchange 伺服器。 不管是哪一種部署模式，網際網路上的用戶端都可以透過某個主機名稱 (例如 mail.contoso.com) 連線至反向 Proxy 伺服器以便存取 Exchange。接著反向 Proxy 伺服器會使用不同的主機名稱 (例如 Exchange Client Access Server 的機器名稱) 連線至 Exchange。 您無須將 Exchange Client Access Server 包含在憑證當中，因為最常見的反向 Proxy 伺服器，能夠將用戶端使用的原始主機名稱與 Exchange Client Access Server 的內部主機名稱進行比對。

負載平衡及憑證

如果您使用一台以上的 Client Access Server，請考慮設定 Client Access Server 陣列。 此陣列可讓所有用戶端透過單一主機名稱，連線至您的 Exchange Client Access Server。 您可以儘可能地將所有 Client Access Server 電腦，新增至單一 Client Access Server 陣列當中，只要所有 Client Access Server 都位於相同的 Active Directory 網站中即可。 如需負載平衡與 Client Access Server 陣列的相關資訊，請參閱了解 Proxy 與重新導向和管理用戶端存取伺服器。

SSL 和分割 DNS

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

小型 Exchange 部署環境中通常不需要用到分割 DNS 技術，因為不管使用者來自內部網路或網際網路，都可以存取相同的 DNS 端點。 不過，對於較大型部署環境來說，這項組態會造成外送的網際網路 Proxy 伺服器與反向 Proxy 伺服器過高的負載。 在較大型的部署環境中，請設定分割 DNS 以便讓外部使用者存取 mail.contoso.com，並讓內部使用者存取 internal.contoso.com。在此組態中使用分割 DNS 時，使用者便無須記得依據所在位置，便可使用不同的主機名稱。

遠端 PowerShell

從 Exchange 管理主控台與 Exchange 管理命令介面進行遠端 PowerShell 存取時，會用到 Kerberos 驗證與 Kerberos 加密技術。 因此，使用遠端 PowerShell 時，無須設定 SSL 憑證。

回到頁首

數位憑證的最佳作法

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

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

為防止用戶端收到有關不信任的憑證錯誤，Exchange 伺服器所使用的憑證，必須由用戶端信任的某人發行。 雖然大多數用戶端可以設為信任任何憑證或憑證發行者，不過直接在您的 Exchange 伺服器上設定使用信任的協力廠商憑證，是比較簡單的作法。 這是因為大部分用戶端都信任自己的根憑證。 有數個協力廠商憑證發行者，都可提供專為 Exchange 設定的憑證。 您可以使用 Exchange 管理主控台，產生適用於大多數憑證發行者的憑證要求。

如何選取憑證授權單位

憑證授權單位指的是負責發行，並確保憑證有效性的公司。 用戶端軟體 (例如，Microsoft Internet Explorer 之類的瀏覽器，或 Windows 或 MAS CS 之類的作業系統)，都有能信任的內建憑證授權單位 (CA) 清單。 此清單一般可以設為新增與移除 CA，不過這項設定作業通常會非常繁瑣。 請使用下列準則，選取出售憑證的 CA：

  • 確保此 CA 可被將與您的 Exchange 伺服器連線之用戶端軟體 (作業系統、瀏覽器與行動電話) 所信任。

  • 選擇 CA 時，請認明標示有「整合通訊憑證」支援字樣，以便使用在 Exchange 伺服器上。

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

  • 確保您所購買的憑證授權，可供您將憑證放到想要使用的所有伺服器上。 某些 CA 只允許您將憑證放在一部伺服器上。

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

最佳作法： 使用 SAN 憑證

依據您的 Exchange 部署中的服務名稱設定方式而定，您的 Exchange 伺服器可能需要使用可代表多個網域名稱的憑證。 雖然使用萬用字元憑證 (例如 *.contoso.com) 可以解決此問題，但許多客戶對於維護一個任何子網域都可使用的憑證所引發的安全疑慮，始終會感到不安。 比較安全的作法是在憑證中，將每一個必要的網域列為 SAN。 Exchange 產生憑證要求時，預設是使用這種方法。

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

Exchange 中有許多服務都會用到憑證。 要求憑證時常見的錯誤，就是提出不含正確服務名稱集合的要求。 Exchange 管理主控台中的憑證要求精靈，會協助您將正確的名稱清單包含在憑證要求中。 此精靈可讓您指定該憑證必須搭配哪些服務一起運作，並且依據選取的服務項目將必須具備的名稱包含在憑證當中，以便搭配這些服務一起使用。 在您部署完畢首次的 Exchange 2010 伺服器集合，並決定要針對不同的部署服務使用哪些主機名稱時，請執行此憑證精靈。 理想狀態下，您只需要針對每個要部署 Active Directory 的 Exchange 網站執行此憑證精靈一次即可。

您可以透過免費提供寬限期的憑證授權單位，在這段期間傳回憑證並要求提供具備幾項額外主機名稱的相同新憑證，這樣您就不用擔心會忘記購買之憑證內 SAN 清單中的主機名稱。

最佳作法： 儘可能使用較少的主機名稱

除了儘可能使用較少的憑證之外，請同時儘可能減少使用的主機名稱。 這種作法可以節省金錢。 許多憑證提供者會依據您新增到憑證中的主機名稱數量來向您收費。

要減少必須具備的主機名稱數量，進而降低憑證管理複雜度時，所能採取的最重要步驟，並非將個別的伺服器主機名稱包含在憑證的主體別名當中。

您必須包含在 Exchange 憑證中的主機名稱，就是用戶端應用程式連線至 Exchange 時所使用的主機名稱。 以下列出名為 Contoso 的公司所需的典型主機名稱清單：

  • Mail.contoso.com   此主機名稱涵蓋最常見的 Exchange 連線，包括 Microsoft Office OutlookOutlook Web AppOutlook Anywhere、離線通訊錄、Exchange Web 服務、POP3、IMAP4、SMTP、Exchange 控制台與 ActiveSync。

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

  • Legacy.contoso.com   此主機名稱是 Exchange Server 2003 或 Exchange 2007 共存案例中的必要項目。 如果您即將同時在舊版的 Exchange 與 Exchange 2010 上使用具備信箱的用戶端時，請設定舊版主機名稱，這樣使用者在升級期間就不用知道第二個 URL。 如需升級與共存的相關資訊，請參閱 從 Exchange 2003 Client Access 升級 和 從 Exchange 2007 Client Access 升級。

瞭解萬用字元憑證

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

回到頁首

用戶端限制

數個 Exchange 用戶端會限制所支援的憑證。 這些用戶端和其限制概述如下：

  • Windows XP 或更早期作業系統上的 Outlook   用於 Windows Anywhere 上的 Outlook RPC over HTTP 元件要求 SAN 或憑證常見名稱，必須符合 Outlook Anywhere 上所設定的憑證主體名稱。Outlook 2007 與更新版本會使用自動探索，來取得此憑證主體名稱。 若要在您的 Exchange 2010 用戶端存取伺服器上設定此值，請使用 Set-OutlookProvider 命令與 -CertPrincipalName 參數。 在外部主機名稱中設定此參數，讓 Outlook 用戶端用來連線至 Outlook Anywhere。

  • 比 Outlook 2010 更早的 Outlook 版本不支援使用 SAN 憑證來存取 POP3 與 IMAP4   Outlook 2007 Service Pack 2 中已對 SAN 提供一個 Hotfix。您可以在此處 找到此項 Hotfix。

  • 行動裝置   某些行動裝置 (包括執行 Windows Mobile 5.0 與一些 Palm 裝置) 並不支援萬用字元憑證。

 © 2010 Microsoft Corporation. 著作權所有，並保留一切權利。