第 4 章：設計公開金鑰基礎結構

  • 發行項

發佈日期: 2004 年 11 月 10 日 | 更新日期: 2005 年 5 月 26 日

本頁內容

簡介
定義憑證需求
設計憑證授權階層
設定憑證設定檔
建立憑證管理規劃
總結

簡介

前章說明以公開金鑰基礎結構 (PKI) 為基礎的安全無線解決方案的邏輯設計。本章為解決方案定義以 Microsoft® Windows® 2003 憑證服務為基礎的 PKI 設計程序。為了降低部署與管理的成本，解決方案的設計相對簡單，而且很適合為安全的無線用戶端及無線區域網路 (WLAN) 基礎結構發行憑證。

但是，因為主要目標是設計能支援安全 WLAN 的 PKI，所以請注意，PKI 也能成為您組織整體安全性基礎結構的重要部分 — 您環境中的許多其他應用程式未來都能採用。為了保障您在基礎結構上的投資，解決方案的設計可以延伸。這表示雖然設計可能不適於發行所有類型的憑證，但是能允許您將來增加更多的功能和容量，以滿足比此處還要廣泛的安全性需求。

本章主要目標有三。第一，討論解決方案的設計決策，以及背後的原因。第二，提供您一些背景規劃資訊，協助您決定那些決策是否適合您的 PKI。第三，說明您可以用哪些方法延伸基本解決方案，以滿足超出本解決方案範圍的安全性需求。

本章出現「本解決方案使用選項...」或「本設計使用...」這類句子時，是指在解決方案的《建置指南》與《作業指南》內所建置的解決方案設計中，做為一部分的決策。

出現「您應決定這個...」這類句子時，表示您必須依據本身需求做成決定。這種狀況大多數出現在討論您如何延伸解決方案，以滿足組織更廣泛的安全性需求這類文字中。因此，某些主題進行更詳細的討論，以協助您瞭解步驟的含意，並使您不需要參考其他文件。

本章先決條件

您應深入瞭解 PKI 的一般原則及詞彙。如果您對技術陌生，請閱讀本章最後＜其他資訊＞一節中的一些文件。

您在繼續閱讀本章之前，應先熟悉《Microsoft Windows Server™ 2003 部署套件》的＜設計公開金鑰基礎架構＞一章。如要瞭解何處可以找到這些資訊，請參閱本章末尾的＜其他資訊＞一節。本章遵循開發套件＜設計公開金鑰基礎架構＞一章的結構，讓您能輕易參照相關的背景資訊，以及此處的詳細討論內容。

如需如何規劃及設計 Windows Server 2003 PKI 的其他詳細資訊的連結，也請參閱＜其他資訊＞一節。

本章概觀

計劃和部署一個 PKI，使其能滿足組織目前及未來的需求，這絕不是微不足道的小事。一般而言，PKI 的目的並不是為單一、獨立的安全性問題來提供解決方案。組織部署 PKI 的目的是滿足許多內部的安全性需求，以及和外部客戶或商業伙伴合作時的商業安全性需求。

下列流程圖說明本章結構。

圖 4.1 用於規劃憑證服務的章節結構

4 個主要步驟如下：

  • 定義憑證需求。此步驟涉及定義您嘗試解決的安全性問題。這步驟是以需要增強安全性的特定應用程式與使用者、這些使用者所在的位置、以及需要的增強安全性的程度作為基礎。您必須先定義安全性及商業需求，才能開始建立 PKI。

  • 設計憑證授權單位階層。您必須以許多因素為基礎，建立憑證授權單位 (CA) 的基礎結構。此步驟涉及定義信任模式、決定您需要多少 CA、您要如何管理 CA、您如何啟用其他 CA或建立與其他組織之間的信任，以便延伸 PKI。此外，此步驟說明 PKI 如何整合 IT 基礎結構內的其他技術，例如 Active Directory® 目錄服務，以及 Microsoft 網際網路資訊服務 (IIS)。

  • 設定憑證設定檔。此步驟包括決定使用哪些類型的憑證、憑證相關的加密金鑰必須具備多高的安全性、憑證的有效壽命為何，以及憑證是否可以更新。

  • 建立憑證管理計劃。此步驟定義憑證如何發行給一般使用者、如何處理憑證要求、如何管理及散佈憑證撤銷清單 (CRL)。

回到頁首

定義憑證需求

本節定義了 PKI 發行憑證的目的，以及每一目的的安全性需求。

建立憑證實施準則

在設計 PKI 時，應該記錄有關憑證如何發行及如何在組織中使用的決策。這些決策稱為憑證原則，而記錄這些原則的文件則稱為憑證原則聲明及憑證實施準則。

在正式名詞中，「憑證原則」(CP) 是 PKI 據以運作的一套規則。例如，它能將憑證的適用性記錄到具有一般安全性需求的用戶端或應用程式的特定群組。「憑證實施準則」(CPS) 是組織用於管理其發行之憑證的實施準則。它說明了如何在組織的系統架構和作業程序環境下解釋組織的憑證原則。CP 是使用於整個組織的文件。但是 每個 CA 各有特定 CPS(雖然 CA 執行相同工作時可以有共同的 CPS；例如您為了效能或恢復，將 CA 負載分散到多部伺服器)。

對於一些組織和憑證使用而言，CP 與 CPS 都被視為法律文件或法律上的免責聲明。這些一般都需要專門的法律建議，不在本章討論範圍之內。不過，並不會嚴格要求您一定要製作任一份文件作為 PKI 的一部份。如果沒有特定的法律或商業理由要這麼做，您可以免除製作和維護正式憑證原則與實施準則的時間和費用。

雖然您可能不需要正式的 CP 或 CPS，但您仍應該記載憑證原則與操作實務。憑證原則應作為組織整體安全性原則的一部份，而操作實務則應作為一部份安全性管理程序。您可以將之參考為非正式的 CPS。

根據 PKI 的使用目的，您應該決定是否需要提供一個正式的原則聲明與 CPS。若需要正式的 CPS，則可能需要加以公佈，並在 CA 憑證中參照。雖然此解決方案未涉及撰寫正式 CPS 的指南，但是第 7 章＜實作公開金鑰基礎結構＞含有如何公佈正式 CPS 的指示。一般情況下，無需公佈非正式 CPS。

在本章的其他部份，經常會參考到在 CPS 中記載決策。這些指示同時適用於正式 CPS 和非正式 CPS。

本章最後的＜其他資訊＞一節包括製作 CPS 的其他來源。

識別憑證應用程式

PKI 設計程序的第一個步驟即識別要使用憑證的應用程式清單。對於每個應用程式，您應該記載每一應用程式所需的憑證類型與估計數量。在這個階段不需要指定憑證的任何詳細資訊，只要提供簡短說明即可。

安全的無線解決方案需要無線用戶端的憑證及「Windows 遠端驗證撥號使用者服務 (Windows Remote Authentication Dial-In User Service，RADIUS)」伺服器的憑證。Microsoft RADIUS 伺服器是 Windows 伺服器的一個元件，稱為網際網路驗證服務 (IAS)。

所需的憑證類型顯示在下表中。雖然本解決方案沒有嚴格要求，但是 PKI 也會將憑證公佈到網域控制站上 (這是樹系中裝有 Windows 2003 Enterprise CA 時的預設設定)。

表 4.1：安全的無線解決方案之憑證需求

應用程式 憑證類型 憑證數量
安全的 WLAN 使用者的用戶端驗證憑證。 需要 WLAN 存取權的所有使用者。
  電腦的用戶端驗證憑證。 所有無線區域網路電腦。
  IAS 伺服器的伺服器驗證憑證 所有 IAS 伺服器。
Active Directory 網域控制站驗證。 樹系中的所有網域控制站。
將來您可延伸 PKI 以發行下表顯示的應用程式之憑證。 **表 4.2：未來可能的憑證需求**

應用程式 憑證類型 憑證數量
用戶端存取的虛擬私人網路 (VPN) 電腦用戶端驗證 (IPSec) 所有遠端 VPN 用戶端
分部至分部 VPN VPN 伺服器驗證 (IPSec) 所有 VPN 路由器
IP 安全性 (IPSec) 電腦用戶端驗證 需要 IPSec 的所有用戶端及伺服器電腦。
網路安全性 內部網路應用程式的使用者驗證。 所有使用者
  內部網路伺服器 安全的內部網路伺服器
加密檔案系統 (EFS) EFS 使用者 所有使用者
  EFS 資料修復 復原代理
安全電子郵件 安全或多用途網際網路郵件延伸標準 (S/MIME) 的簽章及加密 所有電子郵件使用者
  金鑰修復 復原代理
智慧卡 智慧卡登入 網域使用者
程式碼簽章 內部程式碼與巨集簽章 程式碼版本管理員
#### 定義憑證用戶端 對於前一節列出的應用程式，您應定義將使用憑證的用戶端。在此內容中，「用戶端」一詞指的是使用 PKI 所發行憑證的任何人員、軟體處理程序或裝置。例如，用戶端包括使用者、伺服器、工作站、與網路裝置。為了瞭解將如何使用發行的憑證，您必須考慮用戶端的兩大類別：憑證主體 (或終端實體)，以及憑證的其他使用者。 終端實體是獲得 PKI 所發行憑證的用戶端。憑證在 \[主體\] 或 \[主體替代名稱\] 欄位中 (例如主機名稱、電子郵件位址、或目錄識別名稱)，具有一個或更多個項目，可辨識用戶端為該憑證的擁有者。其他類別的憑證使用者是指可能需要驗證終端實體憑證或在目錄內查詢憑證，但未必需要由此 PKI 將憑證發行給自己的用戶端。 一個普通的範例能協助釐清其中的差異：在安全網站上購買某商品的網際網路使用者，將是網站安全通訊端階層 (SSL) 憑證的使用者。網站是憑證終端實體；其身份：www.woodgrovebank.com 則編碼到憑證的 \[主體\] 欄位內。只有憑證主體擁有存取權限，能使用憑證私密金鑰 - 憑證的其他使用者則否。附註：憑證「主體」幾乎永遠都是自己的憑證「使用者」，通常也是他人憑證的使用者。 **附註：**「終端實體」是技術上正確的詞彙，但是在本章的絕大部分中，使用比較好懂的詞彙--「憑證主體」來取代。 對於憑證主體和憑證使用者這兩者而言，您應回答下列問題以針對每個用戶端類型來進行分類： - 用戶端是人員、電腦或裝置，還是軟體處理程序？ - 憑證要在何種平台 (作業系統版本) 上使用？ - 用戶端的網路位置為何？ 例如，它是連線到內部 LAN、在合作夥伴組織內，還是在網際網路上？ - 用戶端是否為網域成員？ 如果是，它是否在不同的網域、或來自 CA 的不同樹系？ 它是否為未受信任的網域？ - 用戶端需要執行何種類型的操作？ 例如，註冊憑證、用憑證簽章、驗證憑證信任、在目錄中查詢憑證，以及檢查憑證撤銷狀態。 這項分類會影響到很多設計決策，如憑證發行的方式、在指定憑證中所定位的信任層級，以及公佈憑證撤銷資訊的方式。 對於此解決方案，下表詳細說明用戶端類別。 **表 4.3：憑證主體 (終端實體) 類別**

憑證 用戶端類型 平台 位置 網域 憑證作業
無線用戶端驗證 使用者 Windows XP 內部網路 網域成員 –註冊 –驗證
無線用戶端驗證 電腦 Windows XP 內部網路 網域成員 –註冊 –驗證
IAS 伺服器驗證 電腦 Microsoft Windows Server™ 2003 內部網路 網域成員 –註冊 –驗證 –安全通道

在此應用程式中，憑證的使用者就是一組相同的用戶端，只是對換了角色。例如，IAS 伺服器會成為用戶端憑證的使用者，並且需要對這些憑證進行驗證。驗證通常包括確認憑證鏈結到受信任根 CA，而且用戶端提供的簽章必需符合用戶端憑證內的公開金鑰。憑證可能必需接受撤銷檢查。如需本主題的詳細說明，請參閱文件《疑難排解憑證狀態與撤銷》(英文)。如需完整的參考資訊，請參閱本章結尾的＜其他資訊＞一節。

表 4.4：憑證使用者類別

憑證 用戶端類型 平台 位置 網域 憑證作業
無線用戶端驗證 –電腦 Windows Server 2003 內部網路 網域成員 –驗證 –檢查撤銷
無線用戶端驗證 –電腦 Windows Server 2003 內部網路 網域成員 –驗證 –檢查撤銷
IAS 伺服器驗證 –使用者 –電腦 Windows XP 內部網路 網域成員 –驗證
從上表中您可以識別需要支援的平台及作業類型。雖然它不是 WLAN 案例中的情況，但是對於環境中的其他應用程式，您可能需要支援網際網路上用戶端的憑證查詢或驗證，或支援來自非 Windows 平台的註冊。因為當中許多項目必須在設計程序的早期階段決定，因此考慮未來可能的憑證需求很重要。 此解決方案對未來需求進行了如下假設： - 很可能需要驗證來自非 Windows 用戶端的憑證。 - 可能需要驗證來自網際網路的憑證。 - 需要在不同於 Windwos XP 和 Windows Server 2003 的平台上支援憑證主體和憑證使用者。 雖然此設計現在未必符合這些需求，但是很容易就能將這些需求納入設計之中。 #### 定義憑證安全性需求 憑證的安全性也稱為保證層級。它可視為將憑證的主體繫結至憑證本身的強度度量。它反映出您對於下列說法的信心程度：使用憑證的人員 (或裝置) 確實與憑證中命名的主體相同。保證層級是兩個主要事項的度量： - 登錄和憑證註冊程序的嚴密性 - 例如，人員是否需要親自出面並提供附照片的身分證件來取得他或她的憑證，或者有電子郵件地址就足夠了？ - 私密金鑰的儲存方式 - 金鑰越難複製或越難洩漏時，就越能保證金鑰為原始擁有者所獨佔 - 憑證主體。 這兩件事關係密切，因為若您從未真正確定私密金鑰的擁有者身分，也就沒有理由投資購買昂貴的私密金鑰保護措施。同樣地，註冊程序涉及廣泛的背景檢查和 DNA 指紋識別，如果隨後的私密金鑰未能安全儲存，這一費力的註冊程序就沒什麼價值。 不過要安全保障憑證必須花錢，而且很多憑證使用通常不需如此。如果您認為屬於授權網域使用者的保證已足夠，不需要任何來自憑證的更強大保證，則網域認證完全可用來作為註冊證明，來註冊憑證。 您應當記載用於憑證原則和實施準則之保證級別的意義。 針對此解決方案，下表定義了三個保證層級。 **表 4.5：憑證保證層級**

等級 登錄需求 金鑰儲存需求
標準 (低) 自動核准取決於網域或其他密碼型的識別。 軟體金鑰
中 憑證管理員核准、可視 ID 檢查 (智慧卡) 或註冊辦公室簽章。 軟體金鑰和硬體防篡改權杖 (智慧卡或 USB 權杖)。
高 指定的註冊長官簽章和憑證管理員核准。 硬體防篡改權杖 (智慧卡或 USB 權杖)。
這些類別之間有部分重疊。它們之間並無嚴格的技術劃分，而是原則劃分。在您組織內部，關於如何處理憑證所定的原則決策便是劃分的基礎。一般而言，擁有較高保證的憑證很少見，然而標準保證的憑證卻越來越普遍。 **重要：**本章使用「標準價值」憑證以及「標準保證」憑證這兩個詞彙，而非「低價值」以及「低保證」。因為後面兩個詞彙具有負面涵意，「標準」更能反映真正的意義。 前一表格中定義的保證類別可分割成不同的主題類型，而進一步精簡類別。通用類別如下： - 電腦 - 您組織內實際的電腦或裝置。 - 內部使用者 - 代表全職員工或您認為職務相當的人員 (例如，約聘人員)。 - 外部使用者 - 代表位於您組織外部  ，但與您有某種業務或法律關係的所有其他實體 (例如，商業夥伴和客戶)。 作此區別的原因在於，不同的主題類型通常會套用不大相同的憑證原則；亦即，據以發行、撤銷或更新憑證的條件。即使您對於某個類別沒有任何憑證計畫，可能還會想記載套用到該類別的憑證原則，以便適當準備您的原則和 CPS。下表說明了將保證層級以及主題類別相合併的結果。 **表 4.6：憑證安全性類別**

憑證安全性類別 安全性類別的範例特徵 範例憑證類型
電腦憑證
標準保證電腦憑證 -根據電腦網域認證的自動核准。 –每年更新。 –WLAN 電腦 –IPsec
中度保證電腦憑證 –需要憑證管理員核准。 –軟體內的金鑰儲存區。 –每年更新。 –網頁伺服器 –IAS 伺服器驗證
高度保證電腦憑證 –憑證管理員核准。 –金鑰儲存於硬體安全性模組 (HSM)。 –憑證授權單位 –安全時間服務 –登錄授權單位
內部使用者憑證
標準保證內部使用者憑證 -根據使用者網域認證的自動核准。 –每年更新。 EFS 使用者
中度保證內部使用者憑證 –需要憑證管理員或註冊長官核准。 –金鑰儲存於智慧卡或軟體中。 –每年更新。 –安全電子郵件 –中低價值財務授權 –智慧卡登入 –內部程式碼簽章 –資料修復代理程式 –金鑰修復代理程式
高度保證內部使用者憑證 –需要憑證主體的實體 ID 驗證。 –需要憑證管理員核准。 –要求時需要註冊辦公室簽章。 –金鑰儲存於智慧卡中。 –六個月更新。 –高價值財務授權 –商業程式碼簽章
外部 (使用者) 憑證
標準保證外部憑證 –根據預先指派密碼的自動核准。 –每年更新。 用戶端驗證 (向網際網路網站驗證)
中度保證外部憑證 –需要憑證管理員核准。 –金鑰儲存於智慧卡中。 –六個月更新。 商務對商務 (B2B) 財務授權
高度保證外部憑證 –需要憑證主體的實體 ID 驗證。 –需要憑證管理員核准。 –要求時需要註冊辦公室簽章。 –金鑰儲存於智慧卡中。 –六個月更新。 非常高價值的 B2B 交易
**附註：**如果您不使用特定的分類，就不需要建立。您可能想使用較簡單或更複雜的分類系統，而且並非每一組合需求會產生您將要發行的憑證類型。 不同的憑證主體類型為何無法以同樣的方式對待，這其中並沒有任何技術原因。但是，您通常會為不同的主體類型定義不同的安全原則；例如，對待內部員工與對待其他組織內人員不一樣。不同的憑證原則 (和它們以不同 CPS 的化身) 可能會在您決定如何組織 CA，以發行各種不同憑證類型時產生影響。這稍後將在本章討論。 您還應考慮是否最終由同一系統管理員負責發行至這三類憑證使用者 (或 PKI 詞彙中的「終端實體」) 的憑證。在許多組織中，可以認證一部電腦是合法網域成員的人員和認證夥伴公司身分的人員並非同一人。您應在您的 CPS 中記載這些責任關係。 ##### 定義應用程式憑證安全性 前一節中定義的憑證安全性類別可用來分類設計的憑證類型。這已列於下表中。 **表 4.7：憑證安全性需求**

憑證類型 安全性類別 平台 邏輯位置 核准 金鑰 大小 有效期間
用戶端驗證 - 使用者 標準保證電腦憑證 –Windows XP –Windows Server 2003 內部 自動 (網域驗證) 中 中
用戶端驗證 - 電腦 標準保證使用者憑證 –Windows XP –Windows Server 2003 內部 自動 (網域驗證) 中 中
IAS 伺服器驗證 中度保證電腦憑證 –Windows XP –Windows Server 2003 內部 手動 中 中
這些廣泛的需求將在本章稍後的＜設定憑證設定檔＞一節中，精簡為特定的憑證設定檔。 ##### 合併憑證目的 多個應用程式功能 (或使用方式) 可以合併到單一憑證上，這樣一來，您便可使用一個憑證來簽署電子郵件、登入網路以及授予對某個應用程式的存取權。將使用方式合併可降低憑證和目錄伺服器的管理和儲存負荷。 但是多用途的憑證也有缺點。例如，不同的應用程式對憑證可能需要不同的核准程序。使用多份憑證多數是技術上的原因，但主要原因通常是不同的應用程式需要不同的憑證安全性層級；即不同的保證層級會將憑證繫結到憑證主體上。這可能包括以下任一或全部的差異： - 憑證核准程序 - 金鑰長度 - 金鑰儲存機制 - 憑證生命週期 因此，合併具相同安全性層級的憑證使用方式的策略，通常是最佳的策略。本解決方案內使用的用戶端驗證憑證類型  包括其他標準應用程式的使用方式，例如 IPsec 和電腦驗證。當您定義其他憑證使用方式的需求時，這些使用方式可以包含在內，且憑證可以重新發行；這需要您從憑證範本定義啟動強制更新。 但是，IAS 伺服器憑證被視為是中度保證憑證。未經授權伺服器憑證所具有的威脅，遠大於非法用戶端憑證。因此，更審慎處理伺服器憑證是合理的作法，而且 Microsoft 建議不要和標準保證應用程式的使用方式進行合併。 [](#mainsection)[回到頁首](#mainsection) ### 設計憑證授權階層 若要支援您組織內以憑證為主的應用程式，您必須建立連結 CA 的架構，負責視需要發行、檢驗、更新以及撤銷憑證。相反地，CA 也會依賴基本 IT 基礎結構來處理一些事務，如憑證主體驗證、憑證發佈以及憑證撤銷資訊的發佈。 建立 CA 基礎結構的目標是向使用者提供可靠的服務、系統管理員的管理性以及滿足目前以及未來需求的靈活性，同時維護組織最佳的安全性層級。 #### 選取信任模式 設計 CA 基礎結構的第一步是決定最適合您需求的信任模式。兩個基本模式是「階層信任」和「網路信任」，不過可將兩者的元素合併到「混合信任」模式中。如需進一步討論這些模型，請參閱《Windows Server 2003 部署套件》＜設計公開金鑰基礎架構＞一章內的＜其他資訊＞一節。 本指南內的解決方案使用「階層信任」模型。其中的原因包括： - 處理離線 CA 時的安全性層級可以比線上 CA 更高。一或多個離線 CA 層會增加發行憑證中信任的整體層級。 - 階層可以在目錄不存在的情況下更輕易工作；這對於支援那些不能存取您內部目錄的外部用戶端而言非常重要。網路信任通常需要目錄，以便使用者查詢 CA 交互憑證來建立信任鏈結。階層內的信任鏈結永遠明確。 - 維護和分配給用戶端的信任錨定很少 - 您必須只將根 CA 憑證分配給憑證使用者。 - 在未來，甚至是根階層，您都可以透過與其他階層的交叉認證來選擇包含多個信任錨定 (或根目錄)。這表示該設計可以容納組織合併者和特殊目的之部門憑證的委任控制。 單個根目錄對於建議的解決方案業已足夠。 ##### 協力廠商與 內部根目錄 內部根目錄可用作為 PKI 信任錨定，或為此使用商業 CA 的服務。使用協力廠商根目錄表示您發行的 CA 是由商業根 CA 所認證 (通常是透過一或多個中繼 CA)。因此，發行的所有憑證在此外部根 CA 中都有它們的信任錨定。 **附註：**雖然這在本指南中沒有明確考量，但是您組織的所有憑證需求都可能外包給商業 CA。您可以使用到站管理的服務，或從憑證提供者處直接獲得憑證。除了小型組織或非常有限的憑證使用方式外，這在財務方面通常屬於不可行的替代方案。這項決策與是否使用內部或協力廠商根目錄的問題完全無關，雖然這兩者經常會混淆。 將商業根目錄用於內部發行的憑證包括許多優點： - 商業根目錄為外部廠商 (如造訪您安全網站的客戶或接收已簽章之電子郵件的夥伴組織) 在與您組織進行安全交易時提供了更大的信心。一般而言，它們已信任協力廠商根 CA，因此不必決定是否信任您的憑證。 - 商業根目錄允許組織利用專業服務提供者的專門知識，包括提供者對於憑證使用相關之技術、法律和商業問題的瞭解。(儘管如此，除非憑證提供者發行您的全部憑證，否則您仍要負責憑證發行及使用的方式，且應將此記載在您的 CPS 中)。 但是，這種方法有許多缺點： - 它往往會造成每次憑證的高額成本。 - 憑證提供者可能會要求商業根 CA 從屬之所有 CA 的嚴格安全性和稽核方法。 - 內部使用者和裝置對網際網路上發佈之協力廠商 CA 的 CRL 必須具有存取權。 - 某些應用程式可能會要求根目錄和中繼 CA 憑證中存在特定的參數和延伸功能 (例如，Microsoft Windows 智慧卡登入)，但它們可能無法從憑證提供者處獲得。 - 您組織和憑證提供者間的商業合約可能會限制您可以自次級 CA 發行的憑證類型。例如，可能不允許發行網頁伺服器憑證。 - 信任商業根 CA 對於您組織所需的安全性而言，信任的範圍過於寬鬆。您可能必須採用特殊的檢查機制或特別的內部 CA 層，來區別您組織所發行的憑證與處於相同根目錄下其他組織發行的憑證。 儘管存在這些不利因素，但是如果您需要發行大量將由組織以外的使用者信任的憑證，那麼您應該考慮至少將您 PKI 的一部份存放於商業根目錄下 (儘管這可能需要建立兩個單獨的階層)。 對於組織內使用的主要憑證，此解決方案會使用建立於內部根 CA 之上的階層。此方法具備下列優點： - 它可讓組織維護對中央信任錨定 - 根 CA - 的直接控制，以及掌控組織所發行之憑證的發行和使用之安全性原則。 - 內部 PKI 能夠以相對低成本發行大量憑證。 - 而對於您能夠發行的憑證類型並沒有任何限制。 - 並且內部憑證與外部憑證的信任之間不存在意義不明確的狀況。 - 您可以視需求，在內部或外部發行 CRL 及「授權資訊存取」(AIA) 的資訊。 如果您無法輕易管理憑證使用者的受信任根目錄，您應考慮使用外部根目錄。此解決方案建議在下列服務使用協力廠商的憑證，以及外部根目錄： - 網際網路網頁伺服器 - 商業程式碼簽章 - 商業文件簽章 - 外部信任的安全電子郵件 ##### 定義外部憑證信任 前一節論及了其他組織之憑證基礎結構中的信任。在這一節中，您必須考慮的更為廣泛一些，決定如何控制您組織中憑證的信任。「信任」一詞在文中具有三個顯著條件： - 可信任的人或實體 - 誰是您信任的對象？ - 您信任該實體會執行的操作或活動 - 您信任對象可進行的作業是什麼？ - 該信任可以維持的時間 - 您將信任它們多久？ 對於憑證而言，「信任的對象」即為發行憑證的授權單位，而「信任對象可進行的作業」即為您要控制的使用狀況及其他憑證特性。「信任多久」既可以由根 CA 憑證的有效期間來定義，也可以由 (在某些情況下) 您所建立的特殊交互信任憑證的有效期間來定義。 當您與其他組織建立新的業務關係，或者要為您的使用者啟用某些功能時，您有可能會需要變更您組織與外部廠商的預設信任關係 (例如，信任網頁憑證以允許安全 HTTP 工作階段)。例如，您可能會進行執行的事項為： - 發佈夥伴組織 (或新的商業憑證提供者) 的 CA 憑證，從而使您的部份或全部使用者信任該夥伴或商業 CA 憑證。 - 發佈組織內用於特殊目的之 CA 或 PKI 的 CA 憑證，但不讓整個組織都信任這些憑證。 - 取代用戶端根目錄存放區中的預先存在商業根目錄，以使您可以限制信任憑證的使用狀況。例如，您可決定您只信任所提供的商業根收發電子郵件，以及安全網頁伺服器憑證，但並不信任它用在智慧卡登入憑證。 您可以透過以下幾種方式來達到這些目的： - 在內部根目錄與要信任的 CA 憑證之間建立合格的子關係，也稱為交互憑證。這個過程中，需要您的其中一個內部 CA 對外部 CA 憑證進行重新簽章。這樣做會將外部的 CA 作為簽章 CA 的信任次級，有效新增至您的內部 PKI 中。您可以對這種類型的憑證進行限制，嚴格限制憑證的使用狀況與原則、主旨名稱類型，或您會信任的發行原則。 **重要：**合格子關係或交互憑證的主體非常複雜，也是最難成功實作的方法。請參閱本章結尾＜其他資訊＞一節中的技術文件《使用 Windows Server 2003 規劃與實作交互憑證或合格的分類》(英文)。 - 建立憑證信任清單 (CTL)。這可讓您定義信任根 CA 的清單，並指定您信任這些 CA 的目的 (例如，保護電子郵件安全)。隨後即可使用「Active Directory 群組原則物件 (GPO)」來部署 CTL。儘管這種方法很方便，但它為 Microsoft 所專用。只有執行 Windows 2000 或更新版本的用戶端才能使用 CTL。此選項只會影響 CTL GPO 所套用之網域中的用戶端。 - 將根 CA 憑證安裝至「Active Directory 信任憑證授權單位」存放區 (位於「設定」容器中)。這會在根 CA (及所有次級 CA) 中建立一個無條件信任，用於整個樹系中的所有使用者與裝置。但是您在賦予這種類型的信任之前，必需非常謹慎。這個方法僅能用於您組織控制的 CA。 - 使用「群組原則」將信任根 CA 憑證部署至使用者或電腦的子集中。這與前一個選項類似，但可讓您針對更特定的對象來接收信任根目錄 (即 GPO 所針對的目標使用者或電腦)。此選項只會影響 GPO 所套用之網域中的使用者。 - 使用「Microsoft 根目錄更新」服務。此服務的目的是讓商業憑證提供者輕鬆將新的根目錄分派給大量使用者。如果您要管理您的信任根 CA，請考慮停用您所有企業系統上的這項服務。 - 使用「群組原則」停用協力廠商信任根目錄。與此清單中的其他項目相比，這是一個限制信任而非增強信任的方式。執行 Windows 的每部電腦 (以及使用這些電腦的使用者) 會繼承一組預設安裝的根目錄。(這對於跨平台的其他作業系統和網頁瀏覽器也是很常見的)。您可以使用「群組原則」停用這些根目錄中的自動信任。隨後再使用先前所說明的其中一個方法，選擇性地加回您所需的信任根目錄 (根據您的安全性需求，可以使用也可以不使用限制)。 **附註：**您無法停用某些根憑證。這是因為作業系統會依賴它們來提供某些功能，比如驅動程式簽章原則。這個「群組原則」設定不會停用這些必要的根目錄。 此解決方案會停用 CA 的「更新根憑證」服務。您應考慮停用組織內其他電腦上的這項服務。還應考慮使用「群組原則」對所有網域使用者停用預設協力廠商根目錄。第 7 章＜實作公開金鑰基礎結構＞提供這些項目的詳細說明。 這個解決方案內的 PKI 根 CA 憑證會將憑證匯入到 Active Directory 內，以便散佈到用戶端，如下一節所述。 ##### 根 CA 憑證散發 根 CA 憑證會自動發佈至 Active Directory 樹系成員。透過將 CA 憑證匯入至「憑證授權單位」容器，樹系中所有網域的成員 (電腦及使用者) 會將此憑證安裝至他們的本機信任根 CA 存放區中。建議對需要整個樹系信任範圍的所有內部根 CA 使用此方法。 您一般也會需要在您的內部根目錄中以更窄的信任範圍來發佈根目錄。如需有關此主題的更多資訊，請參閱本章稍後＜延伸憑証授權基礎結構＞一節。 若要將根 CA 憑證發佈至其他平台上或樹系以外的使用者與電腦上，您必須手動安裝憑證，或使用一些其他的方法來發佈根憑證。 #### 定義憑證授權角色 現在您已經定義了信任模式並選取了根 CA 策略，就可以規劃 CA 基礎結構的其餘部份。若要實現此目的，您必須定義 CA 要在您的組織中實現的不同角色。您可將 CA 設定成根 CA 或次級 CA。反過來，次級 CA 可以是發行 CA 也可以是中繼 CA (這種情況下，次級 CA 是介於發行 CA 與根 CA 之間的中繼信任步驟)。 ##### 根 CA 根 CA 角色在任何組織中都具有非常重要的地位。它是組織中所有使用者及裝置明確信任的角色。許多安全性決策從根本上都是建立在此根目錄的安全性和提供其身分之私密金鑰的基礎上 (例如是否允許某人登入、信任某封電子郵件、或允許一筆 1,000 萬美元的有價證券交易)。因為有太多的作業依賴此根目錄，因此更改根目錄的金鑰及憑證可能會非常複雜、容易出錯，而且會使應用程式及使用者的服務中斷一段較長時間。 有鑑於此，盡最大能力保護根 CA 私密金鑰就變得異常重要。達到此目的的最佳方法之一就是中斷 CA 與網路的連線，這樣對 CA 的存取就會受到極大的限制 (您應將這個保護措施與等效的措施相結合，以限制對於伺服器的實體存取)。保護 CA 金鑰的更有效方法是使用專用的「硬體安全性模組 (HSM)」。以上的方法會為離線 CA 提供額外的金鑰安全性，同時會大大增強線上 CA 的安全性。 這個指南內定義的解決方案使用離線根 CA。 **重要：**您應該考慮為您的根 CA 使用一個 HSM，以增強該 CA 金鑰的安全性。您可以在安裝 CA 之後新增 HSM，但是從一開始就這麼做會簡單得多，而且更安全。如果以後安裝 HSM，那麼即使有許多廠商都允許您匯入現有的金鑰，您也應該使用新的金鑰更新 CA。 ##### 中繼與發行 CA 將根 CA 離線會使該 CA 無法每天發行憑證。若要建立可用於發行憑證的 CA 供每天使用，根 CA 需要認證次級 CA，以代表自己發行憑證。這會讓次級 CA 繼承根 CA 的可信度，而不會讓根 CA 金鑰暴露在安全性威脅下。 之後還可以採用此程序。次級 CA 並不會直接發行憑證，而是通過認證 CA 的更深層級來發行至終端實體 (使用者及電腦)。這樣做不僅為根 CA 金鑰提供額外的安全性層級，而且還允許您分割了次級 CA 分支之間的風險。例如，一個中繼 CA 可以認證內部發行 CA，而其他中繼 CA 則可以認證發行外部憑證的 CA。此方法具備下列優點： - 有助於減少 CA 洩漏給整個 PKI 階層之較小部份的問題。 - 允許為 CA 階層的所有分支實作獨立的憑證原則。 - 降低使用根 CA 金鑰的次數，從而減少洩漏金鑰的機會。 儘管中繼 CA 的額外層級會增強 PKI 的整體安全性，但這樣做會增加複雜性、增加軟硬體成本，並增加管理負荷 (後者通常遠大於硬體或軟體授權的成本)。對於許多應用程式而言，安全性需求並不需要三層式階層。特別是當以 HSM 保護 CA 金鑰時，情況更是如此。 本指南定義的解決方案建議使用兩層式階層。解決方案的設計在良好的安全性與成本負擔之間，提供了可以接受的平衡點，同時為將來的憑證應用程式提供了彈性空間 (請參閱本章稍早＜定義憑證需求＞一節中所述的詳細資訊)。 **附註：**關於政府或法令規定您必須使用三層式階層一事並不在本指南討論範圍內。這些規定顯然超越其他考量。 ##### 建議的 CA 階層 下圖舉例說明了建議的階層。目前的實作包括根 CA 與一個發行 CA。發行 CA 主要為電腦或使用者發行標準保證 (有時稱為「技術」) 憑證，而為電腦發行高價值憑證。 [![](images/Dd548183.04fig4-2(zh-tw,TechNet.10).gif)](https://technet.microsoft.com/zh-tw/dd548183.04fig4-2_big(zh-tw,technet.10).gif) **圖 4.2 憑證授權階層** 此設計可讓您部署全功能的 PKI，在硬體、軟體、以及管理成本上花費相對較低的費用，來獲得支援安全無線區域網路驗證 (802.1X) 的功能。 **附註：**這個簡單的基礎結構設計可以透過數種方法加以延伸，從而滿足不同的需求。本主題會在＜延伸 CA 基礎結構＞一節中進行討論。 發行 CA 最初會被設定為發行下列類型的憑證 (這些憑證在上圖中顯示於粗體方塊中)： - 用戶端驗證 - 使用者 - 用戶端驗證 - 電腦 - IAS 伺服器驗證 前兩個驗證都是標準憑證，並且都是在使用者或電腦之網域認證的基礎上自動發行的。擁有這些憑證並不表示此主體比擁有有效網域使用者名稱及密碼有更緊密的繫結。但是，請注意：以憑證代替網域名稱及密碼具有安全性及其他技術上的優點。 「IAS 伺服器驗證」歸類為中等保障憑證，因為 IAS 伺服器可執行高安全性功能。此類憑證的發行一般包括對要求之有效性的額外檢查，並且會需要憑證管理員核准。 **附註：**建置指南稍後部分中描述此憑證類型的建立，其中「憑證管理員」核准需求已經處於停用狀態。這使得 IAS 伺服器能夠自動更新過期憑證，並可在憑證過期時避免停用服務。只要您有適當的程序，能對憑證要求進行充分判斷並核准，就應該考慮啟用「憑證管理員」核准需求。 ##### CA 的硬體及軟體需求 本節會討論 CA 的硬體及軟體需求。 ###### 根 CA 根 CA 的硬體需求最少。電腦規格不必高於單純執行 Windows Server 2003 的最低需求。根 CA 硬體的關鍵特性是長期的穩定性及可維護性。根 CA 通常儲存在壽命長、但大部分時間都關機的電腦中。但是「打開」電腦電源後，您希望它可以穩穩啟動。為因應可能的硬體故障，您會希望能輕易更換元件，特別是該型電腦已停產數年之後。 Microsoft 依據這些考量，建議您： - 選擇具有良好支援以及長期硬體維護記錄的知名電腦製造商。詢問您何時能從供應商取得備份零件。 - 使用伺服器而非工作站或可攜式電腦硬體，因為前者較有標準化傾向而且比較不常變更。 - 考慮維護備用系統，以便在硬體故障且無法在短時間內修復時，讓該系統接管根 CA 的角色。 - 保留原始安裝媒體、驅動程式與補充程式的複本，以便在系統故障時重建系統。 - 考慮使用 HSM 以獲得額外的安全性。 根 CA 不需要 Windows Server 2003 企業版的其他功能。因此，本指南內的解決方案使用 Windows Server 標準版。 ###### Issuing CA 儘管發行 CA 存在一些效能需求，但是這些需求都相對較少，因為 CA 平常的工作量不大。即使負荷非常沈重，效能度量也會建議：對「企業 CA」來說，通常與 Active Directory 之間的互動才是限制 (而非 CA 本身)。因此硬體效能需求並不多。對於根 CA而言，穩定性及可維護性都是您硬體選擇時的關鍵考量。 「憑證服務」使用與 Active Directory 相同的資料庫技術，因此會套用很多相同的效能準則。對大多數組織而言，好的指標就是為 Active Directory 網域控制站使用相同的硬體規格。 如需有關 CA 效能的詳細資訊，請參閱本章結尾所參照的＜設計公開金鑰基礎結構＞一章中的＜CA容量、效能及擴充性＞一節。 第 7 章＜實作公開金鑰基礎結構＞提供了建議的硬體設定檔。除前面的根 CA 指南之外，Microsoft 建議您指定發行 CA 的伺服器硬體時，應該考慮以下幾點： - 使用 NIC 小組功能的重複網路介面卡 (NIC)。 - 兩個獨立磁碟容錯陣列 (RAID 1) 磁碟區是建議的最小值，以便將 CA 記錄儲存於獨立的實體儲存單位中。這會增加效能優勢以及硬體失敗的恢復能力。 - 考慮使用三個 RAID 1 磁碟區 (而不是兩個) 以分別在獨立的磁碟區中儲存作業系統、憑證服務資料庫以及憑證服務記錄，以獲得較佳效能。 - 高效能小型電腦系統介面 (SCSI) 磁碟機和控制站比起整合裝置電子 (IDE) 等同項目，建議您使用前者，因為它具有較優異的效能和恢復特性。除了與 Active Directory 的互動之外，磁碟子系統的效能可能是決定 CA 整體效能的最重要因素。 - 考慮在發行憑證期間，使用 HSM 來為簽章作業獲得額外的安全性和提昇的效能。 與根 CA 相比，發行 CA 肯定需要 Windows Server 2003 企業版的其他功能，以支援可編輯的憑證範本，以及使用者憑證自動註冊。 ###### 使用多個發行 CA 以獲得服務恢復能力 本節會討論可能要安裝多個發行 CA 的技術原因。因為有安全性和原則方面的原因，所以您可能要用不同的發行 CA 來註冊不同的憑證類型。本章稍後部分將提到這些理由。 具有少量硬體需求的單個發行 CA，已完全能夠將先前所述之憑證類型發行至上萬個用戶端，因此您可能不會單純因為效能方面的原因就需要多個發行 CA。但您應該考慮您發行 CA 的可用性需求是否表示您必須部署多個 CA，用於註冊相同的憑證類型。 一個 CA 不具有與許多服務相同的可用性發行類型。用戶端不需要聯絡 CA，就可以使用或檢驗憑證。用戶端只有在 CA 必需執行下列工作時，才會直接聯繫 CA： - 註冊新的憑證。 - 更新憑證。 - 撤銷憑證。 - 發佈新的 CRL。 - 更新 CA 憑證本身。 清單上每一項的可用性需求都在下表中進行了詳細說明。 **表 4.8：CA 服務可用性需求**

CA 服務 可用性需求
註冊服務 - 新的憑證 這可能是所提供的最主要因素，因為它可能會避免新的使用者存取需要憑證的網路或其他服務。您必須評估從備份修復 CA 所需的時間是否比您組織可等待新使用者註冊憑證的時間長。大部分的組織判斷，等待 CA 復原的成本低於管理額外 CA 的成本。否則相關的憑證類型就需要多個發行 CA。
註冊服務 - 更新憑證 如果對不確定的憑證類型使用了自動更新，那麼根據預設，在前一個憑證過期前六個星期，該憑證就會自動更新。相反的，從備份修復 CA 的時間，通常以小時作為計算單位。手動更新的憑證需要擁有者自己來更新。您可能想要設立一個自動化的警告系統，在關鍵憑證到期時提醒擁有者更新憑證。 否則，可用性標準就會與註冊新憑證的標準相同了。
撤銷憑證 一個憑證一般只可由發行它的 CA 來撤銷 - 其他 CA 無法辦到。 如果撤銷作業執行的時間極為關鍵 (即只有執行了該撤銷作業後才可以復原 CA)，那麼只要您擁有待撤銷憑證的序號和 CA 私密金鑰，您就可以在目前的 CRL 中插入撤銷項目 (還原至不同電腦)。 您應該記住，CRL 一般有一天或多天的延遲。除非 CA 的修復時間長於下一次發佈 CRL 的間隔，否則您手動更新 CRL 只能獲得非常少的資訊。
發佈 CRL 一個 CRL 只對到一個 CA - 其他的 CA 無法使 CRL 發佈更具恢復能力，而只能將 CRL 發佈失敗所產生的影響減至最低 (並非 100% 的發行憑證都會依賴這個這個失敗的 CRL)。 對許多憑證應用程式而言，能夠存取當前撤銷狀態非常重要。這表示尚未過期的 CRL 在發佈的「CRL 發佈點 (CDP)」中必須可以使用。如果情況不是這樣，那麼可區分撤銷的憑證應用程式將會失敗。 CA 修復期始終不應該比先前 CRL 過期與新 CRL 發行的重疊期更久。即使這種狀況很少，CRL 也可以重新簽署，並且延長其有效期間。《作業指南》會討論此程序。
更新 CA 憑證 第二份發行 CA 無法處理這項工作。 在此程序中，執行此作業的時間不應該拖延太久，否則 CA 的修復時間將會成為問題。但即使問題發生了，也可以使用父 CA 金鑰來重新簽署 CA 憑證，以延長其效期。

**附註：**在前面的表格中，CA 復原時間和 CA 可用性牽涉到任何影響 CA 遞送服務至一般使用者的能力的因素。這並不僅限於伺服器失敗。實際上，各網站之間的網路中斷很可能就是造成服務失敗的其中一個原因。當決定您需要的服務可用性等級時，您應該考慮可能會影響服務遞送給使用者的所有因素。

只要您能夠妥善管理 CA 的備份和修復，那麼在決定使用多個 CA 來提供服務恢復能力時，只有註冊和某些更新需求會對您的決定產生影響。您必須權衡這些服務不可用時的成本與提供額外 CA 的安裝和管理成本。

除了可用性提升之外，多個發行 CA 也提供較好的憑證發行效能，大小也只有 CRL 的一半。這些因素在本指南的解決方案中並不重要。本解決方案審慎管理 CA，並包括適當的備份和修復程序，來處理修復問題。綜合這些理由之後，本解決方案只需要單個發行 CA。

使用 HSM 保護 CA 金鑰

本指南為您提供一個很有效的改進措施，可讓您增強基本解決方案的安全性，就是使用 HSM 來保護所有 CA 的私密金鑰。儘管這樣做常會所費不眥 (很有可能超過 CA 伺服器的成本)，  但可顯著加強您環境的安全性。採用這項措施允許您將 CA 金鑰作業的存取權限侷限於獲得授權的使用者。機密作業 (例如匯出及備份 CA 金鑰) 通常是由多個智慧卡來保護。這比只靠軟體金鑰更安全，因為本機系統管理員或備份操作員群組的任何成員都能從 CA 複製軟體金鑰。

除了 HSM 提供眾多的安全性優點之外，還能將 CPU 的負載卸除到專屬的加密加速處理器。

CA 安全性

本節將說明 CA 的安全性，包括作業系統和實體安全性、安全性稽核與監視，以及使用角色委派 CA 的管理責任。

作業系統的安全性

可以使用 Windows 安全性原則來保護 CA。這些設定依據《Windows Server 2003 安全性指南》(英文) 中的「憑證授權單位」伺服器角色而定。

如需此角色中所用設定的詳細資訊，請參閱第 7 章＜實作公開金鑰基礎結構＞。

根 CA 的安全性設定可以使用安全性範本來直接套用，而發行 CA 設定則使用「群組原則」來套用。

實體安全性

CA 伺服器的實體安全性最為重要。除非您能控制伺服器的實體存取權，否則網路或作業系統的安全性均無效。

根 CA 應放置於嚴格控制伺服器存取權的位置。需要存取 CA 的次數很少 (每年兩到三次)，而且在此以外的時間都不必開啟伺服器電源。這表示伺服器可以置於一個沒有配備伺服器室必需之標準電腦設備的安全儲藏室內。例如，該儲藏室不需要有網路連線、精密的伺服器設施，或特殊的電源與溫度管理。

發行 CA 還應位於嚴格控制實體存取權的位置。實體安全性的重要性在於，如果攻擊者對電腦系統有實體存取權，那麼他就會有許多方法來破壞電腦系統的安全性 (這些攻擊可能主要是透過網路)。因為此伺服器需要持續上線，因此您應該將伺服器存放在擁有標準電腦伺服器室設備 (溫度控制、電源管理、空氣過濾、滅火功能) 的位置。

如果可能，存放這兩台伺服器的位置應該儘量遠離可能損壞伺服器的外部威脅，比如：火災、水災。

同樣重要的是控制對備份、關鍵材料和其他配置資料的實體存取，以及確保其實體安全。這些資訊應儲存在不同於伺服器本身的位置，這樣，在整個地點受到破壞時 (如遇上天災和火災)，還可以修復 CA。

CA 的安全性管理

憑證基礎結構可能是一項高價值的資產。但其價值的高低取決於您的組織使用這些憑證的理由，不僅指現在，而且包括往後五年甚至更長時間。因此，與安裝其他 IT 基礎結構相比，您必須採取更加嚴格的安全性和驗證措施來安裝、設定和管理 CA 基礎結構。這些措施至少應該等同於那些為網域控制站所設計的措施。在某些狀況下，您可能會發現您需要比這個更高的安全性等級。

您對於 CA 的信任取決於您對該 CA 已經過安全設定和管理產生高度信心。如果您無法保證 CA 的私密金鑰未被暗中複製，那麼就無法真正確信該 CA 發行之憑證的有效性。

這樣的保證或信心不能輕易回溯增加，所以您必須一開始就將這一特殊狀態建置到與 CA 進行的所有互動之中。例如，如果您可以提供一些稽核記錄和其他證據可證明 CA 的所有存取都合法，則您的組織就對 CA 的私密金鑰未洩漏一事更有信心。例如，對 CA 的所有管理操作都已受到管理員之外的其他人員見證，或紀錄存在錄影帶上。如果是離線 CA，則因從未連接到網路而大幅減低洩漏的可能性。

如果您的組織曾因所發行憑證的有效性而捲入法律爭端，則可能需要這種高度保證。在此情況下，如果您能證明 CA 並未洩漏，那麼您將會有較大的勝訴機會。本指南不詳細討論此主題，您應諮詢您的稽核員和法律顧問以深入主題。

您可以採取各種步驟來大幅提高您 CA 的保證層級，以下是一些步驟範例：

  • 確保 CA 的實體安全性，以防未經授權的人員存取 CA 硬體或備份媒體。

  • 有見證人在場的情況下執行所有安裝和設定步驟 - 記錄主要安裝步驟，並讓見證人在記錄上簽字，來確認這些步驟已成功執行。(另一個方法是，將安裝過程錄影，然後將錄影帶複本交給您信任的人)。

  • 在類似的情況下，在根 CA 上執行所有憑證發行和撤銷作業。理想情況下，對根 CA 的所有存取應該都會得到見證。

  • 請確保擁有 CA 系統管理存取權的所有人員都擁有可進行追蹤的唯一個人帳戶。稽核 CA 上進行的所有作業。

  • 考慮在 CA 上啟用角色分離。(本章稍後會更詳細討論這部分。)

以下類型的措施對根 CA 伺服器尤其重要。視需要發行的憑證類型，發行 CA 只要求很低的保證層級。例如，如果 CA 未發行高價值憑證 (只有標準憑證，例如電腦和使用者網路驗證)，則您不需要為此 CA 提供高於網域控制站的安全性。

只要根 CA 具備了高保證層級，您以後就可以彈性地新增更高保證層級的發行 CA，來發行高價值憑證。您可以一起維護高保證 CA 和現有標準 CA。但是，如果根 CA 已安裝並設定於安全性相對較低的環境中，而您稍後想要發行高價值憑證時，可能會需要重新安裝或者建立新的根 CA。

安全性監視和稽核

作業系統和「憑證服務」稽核會用於所有 CA。為了達到效果，您必需監視稽核以及任何可疑的項目。如需「憑證服務」稽核事件項目的討論資料，請參閱第 11 章＜管理公開金鑰基礎結構＞。

管理角色

「憑證服務」讓您有較大能力控制管理角色的委派。此解決方案使用這項功能，讓您在管理 PKI 時更有彈性。「憑證服務」定義的每個核心系統管理角色，都已使用網域安全性群組或本機安全性群組 (針對離線 CA) 進行實作。此外，本解決方案已定義額外兩個角色或安全性群組，來協助經由 Active Directory 的 PKI 元件委派系統管理職責。

有一點必須瞭解的是，您組織內的這些角色和不同的 IT 人員之間不必一一對應。大多數組織都會發現同一個人可以充當許多角色。只需將某個人新增至下表所列的任一或所有安全性群組，您就可以輕鬆實作這一動作。相反的，如果您的組織對系統管理責任已有更複雜的分隔，也可以實作以上動作。

實作角色以及他們與安全性群組 (實作位置) 的對應關係將顯示在下表中。

表 4.9：核心憑證服務角色

角色名稱 安全性群組 範圍 說明
企業 PKI 系統管理員 企業 PKI 系統管理員 Active Directory 樹系 負責整體 PKI - 定義企業的憑證類型、套用原則及信任路徑等。
企業 PKI 發行者 企業 PKI 發行者 Active Directory 樹系 負責將信任的根憑證、次級 CA 憑證和 CRL 發行到目錄。
CA 系統管理員 CA 系統管理員 CA 負責 CA 設定。經常是擔任企業 PKI 管理員及系統管理員角色的同一個人。 當憑證使用上有需要時，則可以由多位 CA 系統管理員負責不同 CA。
Administrator 本機系統管理員 CA 管理 CA 作業系統和伺服器。負責安裝 CA 以及更新 CA 憑證。一般與「CA 系統管理員」角色共用。
CA 稽核員 CA 稽核員 CA 管理來自 CA 的稽核事件日誌與可稽核事件的原則。
憑證管理員 憑證管理員 CA 核准需要手動核准及撤銷憑證的憑證要求。 當憑證使用上有需要時，則可由多位憑證管理員負責核准不同的 CA。
註冊管理中心 或者 註冊長官 尚未定義 憑證設定檔 這是「憑證管理員」角色的延伸。負責在超出範圍 ID 驗證之後，核准及簽署憑證要求。 可以是個人、IT 程序或裝置 (例如指紋掃描器與資料庫)。 可為不同的憑證設定檔 (範本) 指定不同的註冊管理中心，並能跨越多個 CA。
金鑰復原代理 尚未定義 CA 保留用於解密 CA 資料庫中已保存的私密金鑰之金鑰。
CA 備份操作員 CA 備份操作員 CA 負責 CA 伺服器的備份和修復以及備份媒體的安全儲存。
這些安全性群組會實作為網域萬用群組，並套用至發行 CA 和目錄。對於根 CA，相關的群組會實作為本機群組 (但是離線 CA 中的「企業 PKI 系統管理員」和「企業 PKI 發行者」沒有相應的群組)。解決方案假設同一安全性群組用於企業內的所有 CA。如果此方案在您的組織內無效，則您必須為每個 CA 在 CA 範圍內的所有角色，實作不同的群組 (很顯然地，這些角色必須重新適當命名，例如 CA 系統管理員 - 發行 CA 1)。 此解決方案中並未實作註冊管理中心 (或註冊長官) 以及金鑰保存和修復，因此這些角色沒有已定義的安全性群組。 可以在 CA 的不同角色之間強制執行角色分離。啟用這一動作後，屬於多個角色群組的任何使用者都將無法取得所有角色群組的特殊權限。此解決方案中並未實作角色區隔。 ##### Active Directory 整合 CA 有兩種安裝模式 - 企業模式 (或 Active Directory 整合) 和獨立模式。這兩種模式的主要差異在於：企業 CA 依賴 Active Directory 來儲存設定資訊；可以將 Active Directory 作為註冊管理中心；並可以自動發佈已發行的憑證至目錄。獨立 CA 可以將憑證和 CRL 發佈到目錄，但是 Active Directory 不一定非存在不可。 如需詳細說明的相關資源，請參閱本章最後的＜其他資訊＞一節。 由於它離線，因此您只能將根 CA 設定為獨立伺服器。如果您計畫將離線的中繼 CA 部署到您的環境中，情況也相同。 發行 CA 會基於以下原因設定為「企業 CA」： - 本解決方案中所用的憑證類型需要進行自動註冊和自動核准。 - 本解決方案中需要憑證範本 - 它們可以透過簡化多種憑證類型 (通常跨越多個 CA) 的管理來提供相當多的好處。 - IAS 需要 Active Directory 執行信任的憑證對應來驗證無線用戶端。CA必須在 NTAuth 存放區中註冊，才能允許此動作。 - 有可能可以將憑證自動發行到相對應的使用者或電腦物件 (雖然在本解決方案中不需要)。 - CA 要求提供信任來源，以取得憑證請求和發行憑證中所用的主體名稱資訊 - Active Directory 可從儲存於目錄中的使用者和電腦屬性中提供此資訊。 - 以後可能還會需要智慧卡登入憑證 - 使用企業 CA 較容易實作。 **附註：**這些功能依預設是由企業 CA 提供，但是從正確設定的獨立 CA 也可提供部分功能。「憑證服務」產品說明文件會更詳細討論這部分。請參閱本章結尾的參考資料。 ###### 在網域中安裝 CA 如果您的組織內有多網域樹系 (甚至多個樹系)，您就必須決定要安裝 CA 的一個或多個網域。您的決定會受很多因素影響，例如需要委派控制權給不同的網域管理員，某些國家和地區法律會影響您組織提供給各個部門的憑證。 最常見的方法是，將 CA 安裝到樹系的根網域或安裝到提供管理用途的專用網域。您應將它們安裝到長期穩定的網域內。(安裝後，CA 名稱、網域成員資格以及 DNS 網域名稱就無法變更。) 同時您也應避免將 CA 安裝到無法保證電腦帳戶安全性或完整性的網域。雖然把 CA 安裝到相同網域內會使集中式管理更簡單，但是不需要如此。 在此解決方案中，CA 伺服器帳戶 (僅限於企業發行 CA) 會安裝到樹系根網域或單一網域樹系。 ##### 將憑證的實施準則對應到 CA 如果您打算發佈 CPS，就必須確定 CPS 的範圍。您可以為整個 CA 階層或部份階層建立 CPS，也可以為每個 CA 建立 CPS。 後一種選項提供最大的彈性空間，但同時也會增加管理多個 CPS 的負擔。標準作法是為每個 CA，或擁有一般憑證原則、主體類型和安全性層級的 CA 群組建立獨立的 CPS。對於不同的 CA，這些都大不相同，因此您需要使用多個 CPS。當然，如果您因為恢復能力或效能原因而部署了許多相同的 CA，那麼這些 CA 應該具有相同的 CPS。 如前所述，只建立 CPS 但不發佈也是合法的。例如，如果您認為您的 CPS 包含了內部性質的操作和安全性資訊，就可能要避免將其發佈到外部。您也可以決定發佈列示了 CA 重要作業原則的 CPS 精簡版，而不必透露任何內部操作詳細資訊。 如果您決定要發佈 CPS，而且要通告它在 CA 憑證中的位置，就必須從官方的物件識別元 (OID) 命名空間取得憑證原則的 OID，該命名空間是由國際標準組織 (ISO) 指定給您的組織。憑證原則對您的組織具有獨特性，所以需要一個全域唯一的 OID 以便識別。 這個 CP OID 編碼到組織的每一份憑證中做為憑證延伸。「憑證延伸」是憑證資料欄位的一個類型。包含 URL 做為這個延伸的一部分，而延伸指向發行特定憑證的 CA 的 CPS。 通常這還可以包括使用者須知文字，來指出憑證的用途或來源 (該文字長度不得超過 200 個字元，因此很明顯，它不可以替代單獨的 CPS 文件)。 如需憑證原則 OID 與 CPS URL 如何編碼到憑證的詳實資料，請參閱本章末＜其他資訊＞一節中的RFC 3280＜網際網路 X.509 公開金鑰基礎結構憑證與 CRL 設定檔＞(英文)。 當您取得 CP OID，並根據 URL 決定 CPS 的發佈位置之後，就可以將此文字包括在 CA 憑證中。如需本程序的相關說明，請參閱第 7 章＜實作公開金鑰基礎結構＞。 #### 支持 IT 基礎結構 此解決方案中的 PKI 依賴其他基礎結構服務才能正確運作。下圖舉例說明了主要作業 — Active Directory 與 IIS — 以及它們如何與 CA 及憑證用戶端互動。 [![](images/Dd548183.04fig4-3(zh-tw,TechNet.10).gif)](https://technet.microsoft.com/zh-tw/dd548183.04fig4-3_big(zh-tw,technet.10).gif) **圖 4.3 CA 與 IT 基礎結構間的互動** 監視、警告、和管理基礎結構對於「憑證服務」的成功操作也是關鍵，雖然圖中沒有顯示這些元件。第 11 章＜管理公開金鑰基礎結構＞會更詳細說明此基礎結構。下列章節會說明 Active Directory 和 IIS 為 PKI 提供的服務。 ##### Active Directory 如前面的＜Active Directory 整合＞一節中所述，Active Directory 提供了許多對於 PKI 非常重要的不同服務。其中包括憑證發佈、憑證註冊、憑證帳戶對應，以及信任和設定資訊的儲存等。 所有這些服務都會自動提供給「企業 CA」。線上獨立 CA 也可以利用其中的某些服務。但離線 CA 無法直接與 Active Directory 互動，因此無法儲存和擷取資訊。 在本解決方案中，離線根 CA 的 CA 憑證會發佈到 Active Directory 的信任根存放區。如此使得根 CA 憑證會自動分派至樹系內所有 Active Directory 用戶端的信任根存放區。 根 CA 也可使用 Active Directory 來取得下列發佈服務 (雖然本解決方案並沒有使用這些服務)： - CRL 發佈   — 網域用戶端 (整個樹系中) 能從已經發佈到 Active Directory 的本機網域控制站來擷取 CRL。 - 交互憑證散佈至網域用戶端 — 發佈到 Active Directory 的交互憑證將自動散佈到樹系內每一 Active Directory 用戶端的本機憑證存放區中。 發行 CA 將把 Active Directory 用於＜Active Directory 整合＞一節中所述的所有服務。 ###### 將 Active Directory 用於非 Active Directory 用戶端 對於支持那些不屬於另一個不信任 Active Directory 樹系一員，或者任何 Active Directory 樹系一員的 PKI 用戶端，有幾點需要考慮。 如果您要讓這些類型的外部用戶端使用「輕量型目錄存取通訊協定 (LDAP)」擷取 CA 憑證和 CRL，就必須考慮以下各項： - 外部用戶端需要您為 CDP 和 AIA 路徑設定明確的 LDAP 主機名稱。如需詳細資訊，請參閱本章稍後的＜設定 CDP 和 AIA 路徑＞一節。 - 依據預設，外部用戶端不對 Active Directory 執行匿名 LADP 查詢。您必須變更樹系的 **dsHeuristics** 值，並將存取權限明確地授予「匿名」帳戶。如需進一步的資訊，請參閱本章最後的＜其他資訊＞一節。 **警告：**這適用於樹系中所有網域控制站的匿名 LDAP (未經驗證的用戶端只可存取已授予明確「匿名」帳戶存取權限的項目)。在操作之前，請仔細考慮允許未經驗證的使用者存取您的目錄會產生的影響。 - 外部用戶端不會繼承目錄中設定的信任根資訊 - 您必須透過其他方法來設定此資訊。 ###### 網際網路用戶端的注意事項 組織外用戶端的 CDP 與 AIA 設定有一些重要的考量 (例如網際網路用戶端)。本章稍後的＜設定 CDP 和 AIA 路徑＞一節將予以說明。 如果您需要為網際網路用戶端提供憑證查詢來支持電子郵件憑證查詢等動作，可能就需要為網際網路用戶端建立獨立的 LDAP 目錄。由於涉及安全問題，Microsoft 強烈建議您不要將前一節所述的啟用匿名 LDAP 的方法用於您的內部 Active Directory 樹系。建議您建立獨立的 Active Directory 樹系，並使用中繼目錄 (Metadirectory) 產品--LDIFDE 工具 (例如 Microsoft Metadirectory Services)，或其他目錄同步化產品，從內部樹系複製資訊。 ##### 網際網路資訊服務 在此設計中，IIS 為 PKI 提供兩項服務： - 它可發佈 CA 資訊，如 CRL、CA 憑證，甚至可以發佈 CPS 文件。 - 它還可以使用 Web 介面註冊憑證 - 這對非 Windows 用戶端特別有用 - 不過此功能在本解決方案中並未使用。 ###### 使用 IIS 發佈 CA 資訊 在此解決方案中，根 CA 和發行 CA 的 CDP 和 AIA 資訊都發佈到網頁伺服器。使用 HTTP 發佈可讓最大範圍的用戶端擷取需要的資訊。 為此目的而將 IIS 安裝在發行 CA 上很常見，但這並不永遠是最佳方法。如果您能使用其他 IIS 伺服器發佈 CRL 和 CA 資訊，建議您改用該伺服器。請嘗試限制使用者存取 CA 的方法，因為 CA 上每多一種通訊協定和服務，就可能給攻擊者增加了一個進入伺服器的存取點。在 CA 上使用 IIS也可以避免因進行維護而關閉 CA ，因為這可能是許多用戶端唯一有效的 CRL 位置。 在《建置指南》中，發行 CA 是用來裝載 CRL 和 CA 發佈的 IIS。這是為了簡化建置程序，並減少額外的硬體需求。但是，Microsoft 建議您盡可能分開放置。 ###### 使用 IIS 註冊網頁來註冊憑證 IIS 註冊頁面在許多狀況下很有用：非網域用戶端註冊、非 Windows 用戶端註冊、或 Microsoft Internet Explorer 以外的瀏覽器用戶端。 但是，CA 上不需要網頁註冊頁面。但在此解決方案中，這些頁面會預設安裝在發行 CA 上，雖然它們也可以安裝在獨立的網頁伺服器上 (伺服器必需執行 IIS 5.0 或更新版本，以支援 ASP 頁面)。註冊頁面會讓某些註冊工作變得更加簡便，但是如果您不需要的話，根本不用安裝。如需安裝和使用 Web 註冊頁面的更多資訊，請參閱本章最後的＜其他資訊＞一節。 #### 設定 CDP 和 AIA 路徑 為了判斷憑證是否已被撤銷，用戶端需要存取最新的 CRL。用戶端還需要擷取 CA 憑證，來驗證終端實體憑證是否鏈結到信任根。每個 CA 都需要將一或多個 URL 編碼到憑證中，這些 URL 提供了用戶端能用以取得有關憑證資訊的位置。 您為每一 CA 設定哪些 CDP 與 AIA，是取決於會使用您憑證的用戶端類型。例如，憑證打算只由屬於 Active Directory 樹系成員的使用者及電腦使用嗎？ 或者外部使用者或裝置也需要使用它們？ 如何定義憑證用戶端在本章前面部分已有討論。 ##### 根 CA 在此解決方案中，根 CA 會設定如下： - CDP 和 AIA 的主要路徑 (列在第一位) 為 HTTP URL。根 CA CRL 通常很小 (1 到 2 KB)，而發佈間隔很長 (6 個月)，因此將它發佈到單一位置不會對擷取 CRL 的用戶端造成很大的限制。 - 次要路徑會設定為 LDAP URL，以建立 HTTP 位置的備份。由於不使用 LDAP 主機名稱，因此同一樹系中的用戶端就可以從它們的本機網域控制站中擷取資訊。樹系外的用戶端則無法存取此位置。 此設定可讓 Active Directory 樹系外的用戶端使用來自此 CA 及其次級 CA 的憑證，因為預設它們會使用 HTTP 路徑。 ##### Issuing CA 在此解決方案中，發行 CA 最適合內部 Active Directory 用戶端使用。CA 會設定如下： - CDP 和 AIA URL 的主要路徑為 LDAP 目錄路徑。 - CDP 和 AIA URL 中不指定 LDAP 主機名稱；因此用戶端可以使用其預設的 LDAP 伺服器。對於 Active Directory 用戶端而言，預設的 LDAP 伺服器是它們的本機網域控制站。但是，其他 LDAP 用戶端查詢這些 LDAP 路徑時可能會失敗。 對於與 CA 處於同一樹系的用戶端來說就最好使用這一設定。基本 CRL 會每週發佈，而 Delta CRL 則會每天發佈。因為這兩個的預設位置都是 Active Directory，所以用戶端會從離它最近的網域控制站來擷取它們。這樣一來提供了恢復能力，並將網路流量最佳化。 ###### 設定 CDP 及 AIA 來支援外部用戶端 之前的安排對於另一個 Active Directory 樹系的成員，或不是任何 Active Directory 樹系 (例如，路由器) 成員的用戶端來說，並不是最理想。因為這些外部用戶端無法存取 LDAP CDP 及授權資訊存取 (AIA)，所以外部使用者在嘗試檢查撤銷和 AIA 資訊的過程中會發生相當嚴重的延遲。這些延遲會造成這些外部使用者的應用程式發生失敗。 如果您 Active Directory 樹系之外的用戶端有可能會使用憑證，您必需設定 CDP 及 AIA 值，將 HTTP URL 做為主要路徑使用，而非 LDAP URL。 若要包括外部用戶端能使用的 LDAP URL，您必需執行下列工作： - 為 CDP 和 AIA 路徑設定明確的 LDAP 主機名稱 - 您不能使用預設的 Null 路徑 (LDAP:///)。若要變更 CA 的 CDP 或 AIA 路徑，則需要重新發行 (更新) CA 憑證。 - 按照本章稍早所述，啟用匿名 LDAP 存取。 ###### 網際網路用戶端的注意事項 如果您打算把憑證散佈到組織外在網際網路中使用，那麼您還需考慮一些其他事項。 具有內部 LDAP URL 的憑證會提供內部 Active Directory 以及 CA 結構和名稱的相關資訊。若要避免提供這些資訊，您應當： - 對於根 CA 的 CDP 和 AIA 值，以及鏈結中的任何次級 CA 都僅使用 HTTP URL。 - 從一個獨立的 CA 發行供外部使用的憑證。此 CA 僅會使用 HTTP CDP 和 AIA URI。 在以上兩種情況下，您都應提供一個次要 HTTP 位置以供 CRL 擷取，這樣用戶端在主要位置無法使用時就可以使用這一個選項。 如需使用 CRL 和 CDP 的進一步說明，請參閱本章最後的＜其他資訊＞一節中所含的參考資料。 #### 延伸 CA 基礎結構 ＜定義憑證安全性需求＞一節討論了如何按照安全性層級及按照主體類型將憑證分類。分離出不同主體類型的主要原因是：不同的憑證原則與操作實務 (如 CPS 中所述) 很可能會套用到這些主體類型上。 一般而言，每一個 CA 會套用一個 CPS。在單一 CA 中，很可能出現不同的原則控制不同的主體類型，但這樣可能使得 CPS 變得更複雜，且常常難以正確實作。延伸此 PKI 來發行涵蓋了不同原則與安全性需求的憑證，其策略就是為主要的主體類別建立額外的發行 CA。這在下圖中進行了舉例說明。 **附註：**此圖只說明您如何延伸較早的 CA 階層。您的組織很可能需要更複雜或更簡單的設計來滿足未來的需求。額外的 CA 及憑證功能的設計必須以您的需求為基礎 — PKI 並沒有絕對正確或錯誤的設計。延伸 PKI 以滿足其他憑證需求時，您應依循類似於此處所述的簡單 PKI 設計方法。 [![](images/Dd548183.04fig4-4(zh-tw,TechNet.10).gif)](https://technet.microsoft.com/zh-tw/dd548183.04fig4-4_big(zh-tw,technet.10).gif) **圖 4.4 延伸 CA 階層** 此圖顯示您可以如何延伸本章先前所呈現的簡單 CA 階層，以處理更多種憑證需求。新的 CA 與憑證功能會以灰色背景顯示。本圖同時還舉例說明了如何使用高價值憑證 (金鑰和鎖的符號)，以及當使用者憑證 CA (內外部) 處於線上時，它們會從第一個 CA 接管發行標準使用者憑證的角色。 這一延伸 CA 基礎結構的策略包括一些假設： - 集中管理 CA 基礎結構 - 亦即不需要按照組織或地理位置來委派對 CA 的控制。 - 在整個組織中會使用一般憑證標準 - 亦即指定類型的憑證在整個組織中擁有一般都可接受且贊同的使用方式與原則。 - 不需要現有 PKI 的交互操作性。 - 所顯示的不同憑證類型需要有不同的安全性等級與原則 (還可能需要任何其他條件)。 如果這些假設對於您的組織來說無效，則您可能需要不同的結構。如需有關延伸 CA 基礎結構的不同選項及方法的詳細討論，請參閱本章最後的＜設計公開金鑰基礎結構＞參考資料。 ##### 合格子關係 您所建立的憑證定義可用於定義憑證範本，以及發行憑證而無需進一步自訂。但是，為了延伸 PKI，您可能想要限制您發行 CA 憑證的委派，進而限制 CA 可發行憑證的範圍。 本章先前所述的合格子關係可用於控制您組織內信任的範圍與目標，其方法即是在您的 CA 基礎結構與外部組織基礎結構之間建立交互憑證。您可以使用這項技術來限制憑證類型以及您自己的 CA 階層中的某些憑證屬性。本主題的詳細內容並不在本指南的討論範圍內。如需關於此主題的更多資訊，請參閱 請參閱本章最後的參考文件《*使用 Windows Server 2003 規劃與實作交互憑證或合格的分類*》(英文)。 此解決方案中的 PKI不需要在 CA 階層內使用合格子關係。 [](#mainsection)[回到頁首](#mainsection) ### 設定憑證設定檔 本節討論了如何設定憑證來滿足本章先前所定義的需求。 #### 定義憑證參數 對於您需要的每一個憑證類型，您都應當為該類型記錄憑證設定檔。接著可將設定檔參數設定到憑證範本內，由範本控制您 CA 將發行的憑證類型。 **附註：**獨立 CA 不會使用憑證範本。您必須使用 Certreq.exe 之類的工具、使用 Web 註冊頁面上的表單，或者以程式建構要求等方式來建立要求。如果您使用獨立 CA，仍然要定義每一憑證類型的憑證設定檔，並在為獨立 CA 建立憑證要求時，使用設定檔。 憑證設定檔定義包括下列內容： - 範本名稱及顯示名稱 (您應為它們定義命名標準)。 - 憑證金鑰長度 - 憑證有效期 - 選用的憑證延伸 - 註冊與更新原則 - 與有效期相關的原則 - 與應用程式用法相關的原則 - 與金鑰用法相關的原則 - 與金鑰保存相關的原則 - 憑證授權單位 - 主體名稱建立 - 憑證註冊代理 - 金鑰建立 - 金鑰和 CSP 類型 金鑰長度、有效期、金鑰建立選項，以及註冊和授權原則都由所需的憑證安全性層級以及本章稍早所指出的應用程式需求來決定。 #### 定義憑證與金鑰生命週期 一些因素會影響到憑證生命週期，例如：憑證類型、您組織的安全性需求、您企業中的標準實施守則，以及政府法規。一般而言，較長的金鑰會支援較長的憑證生命週期和金鑰生命週期。 金鑰長度和金鑰類型存在以下限制： - 相容性 - 某些憑證應用程式可能不支援長度超過 2,048 位元的金鑰。金鑰類型也可能會影響到相容性；一般而言，RSA 金鑰具有最佳相容性，但是某些應用程式可能需要其他金鑰類型。對於鏈結中的所有 CA，您都需考慮金鑰長度和金鑰類型相容性，因為會要求應用程式處理鏈結中的所有憑證。 - 效能 - 較大金鑰的簽章及加密作業比起較小金鑰來說，需要更大的處理能力。因此，大於 2,048 位元的金鑰一般不應用於憑證發行率較高的發行 CA。 - 儲存區 - 較大的金鑰會建立較大的憑證，該憑證在憑證資料庫中需要更大的儲存區。如果憑證會發佈到 Active Directory 上，則其儲存區需求也會同時增長。備份的大小及時間也會相應適當增長。 選擇憑證及金鑰生命週期時，您必須考慮到因金鑰洩漏而遭到攻擊以及這種洩漏會帶來的潛在後果。下列因素會影響您為憑證和金鑰所選擇的生命週期： - 私密金鑰長度 - 較長的金鑰不易被破解，因而可以採用較長的金鑰生命週期。 - CA 安全性 - CA 及其私密金鑰越安全，安全生命週期的時間就越長。 - 特定加密硬體的使用 - 智慧卡和 HSM 會使得私密金鑰更加安全，這樣可採用較長的生命週期。 - 憑證主體中的信任 - 您可能會讓您的員工及內部電腦擁有比外部使用者及電腦更長的憑證生命週期。 - 使用 CA 金鑰簽署的憑證數量 - 存取金鑰的次數越多、CA 私密金鑰發佈範圍越廣泛時，金鑰就越容易受到攻擊並可能洩漏。 對於在此解決方案中所用的 CA 和終端實體而言，此金鑰生命週期和更新期會顯示在下列表格中。 **表 4.10：憑證與金鑰生命週期**

憑證主體 金鑰長度 金鑰生命週期 更新間隔
根 CA 4,096 位元 16 年 8 年
Issuing CA 2,048 位元 8 年 4 年
終端實體 1,024 至 2,048 位元 一年半 有效期的 90%
在金鑰長度方面，1,024 位元的金鑰目前被視為超出實用密碼分析範疇。它們應在超出建議的兩年終端實體值的情況下，還會擁有一個安全的金鑰生命週期。512 位元長度的金鑰一般不再視為可以安全使用，除非應用程式的安全性需求非常低。因此，本解決方案不使用 512 位元金鑰。 發行 CA 的金鑰強度在安全性和效能需求之間是一大妥協。這一大小的金鑰目前擁有超過了四年更新期的金鑰生命週期。 根 CA 沒有實質的效能限制，因此您可將金鑰強度設為最大的 16 千位元。但是考慮到相容性之後，本解決方案會將它的層級設定為較低。即使如此，4,096 位元的金鑰還擁有超過八年更新期的安全金鑰生命週期。 所有的 CA 都會使用 RSA 金鑰，儘管如此，終端實體的金鑰類型還是由其應用程式的需求來決定。 雖然可能會使用相同的金鑰來更新憑證，但是在正常狀況下  不會建議您這麼做。在本解決方案中，每一次憑證更新時會產生新的金鑰組。 CA 發行憑證的有效期無法超出發行 CA 的剩餘有效期，也無法超過高於根 CA 的所有 CA 的剩餘有效期。例如，如果 CA 憑證在六個月之後將過期，您只能發行其最大生命週期為六個月的憑證。因此，此解決方案指定 CA 憑證在其歷經一半的憑證生命週期之後要進行更新。由 CA 發行的所有憑證，其有效期不能長於發行 CA 憑證之一半的生命週期。 這說明終端實體、發行 CA 和根 CA 的巢狀最長有效期分別為 4 年、8 年和 16 年。但是在本解決方案中，終端實體憑證的最長有效期為 2 年。如此一來，便可允許引入額外的中繼 CA 層，而且對憑證的生命週期階層也不會有太大的影響。 #### 將安全性需求與憑證參數相對應 下表列示本章先前指出的憑證類型，以及如何將每種類型的安全類別對應至憑證設定檔參數。 **表 4.11：憑證參數**

憑證類型 發行原則 核准方法 金鑰 有效期間 金鑰存放 金鑰匯出 CSP
用戶端驗證 - 使用者 低 自動 (網域驗證) 1024 1 年 軟體 否 已具名
用戶端驗證 - 電腦 低 自動 (網域驗證) 1024 1 年 軟體 否 已具名
IAS 伺服器驗證 中 手動 (憑證管理員) 1024 1 年 軟體 否 已具名
**附註：**  \[發行原則\] 欄位內列出的「低」原則，是指「憑證服務」內預先定義的「低度保證」憑證原則。它相當於本章稍早所述的標準保證或安全性等級。 CPS (密碼編譯服務提供者) 欄位內的「已具名」值是指：該憑證類型所允許的 CSP 應於範本中指定，而不是讓用戶端決定。因為用戶端電腦憑證與伺服器憑證分別具有特定的 CSP 需求。 #### 將憑證需求與憑證範本參數相對應 通常，應用程式都期望能夠精確地設定憑證。它們可能需要某種特定的主體名稱格式，也可能需要包含特定的應用程式原則 OID，或者可能需要以特定的發行原則發行憑證。如果沒有其他要求，應用程式至少需要正確定義金鑰用法。因此，您必須從應用程式擁有者 (或廠商) 處取得所有這些參數，才能定義憑證設定檔。 下面表格中顯示了本解決方案中所需憑證清單的應用程式需求。這些表格對憑證屬性和 CA 參數 (根據憑證範本中的設定) 都進行了舉例說明。但未列示所有可能的屬性。 **附註：**以下詳述的每種憑證類型都與內建的範本類型之一密切相關。請不要編輯原始範本，而是複製內建範本並編輯複本，以獲得所需的設定。這可讓您在必要的時候，輕鬆地還原內建範本，因為它們未經修改。 **表 4.12：用戶端驗證 - 使用者**

憑證參數 所需的值
憑證範本名稱 用戶端驗證 —使用者
Active Directory 發佈 否
金鑰用法 數位簽章
金鑰保存 否
最小金鑰大小 1024
主體名稱 一般名稱
主體替代名稱 使用者主要名稱
應用程式原則/延伸金鑰用法 用戶端驗證
密碼編譯服務提供者 (CSP) Microsoft Base Cryptographic Provider v1.0 Microsoft Enhanced Cryptographic Provider v1.0
自哪一個範本衍生 已驗證的工作階段
**表 4.13：用戶端驗證 - 電腦**

憑證參數 所需的值
憑證範本名稱 用戶端驗證 —電腦
Active Directory 發佈 否
金鑰用法 數位簽章 金鑰加密
金鑰保存 否
最小金鑰大小 1024
主體名稱 一般名稱
主體替代名稱 DNS 名稱
應用程式原則/延伸金鑰用法 用戶端驗證
密碼編譯服務提供者 (CSP) Microsoft RSA SChannel Cryptographic Provider
自哪一個範本衍生 工作站驗證
**表 4.14：802.1X 伺服器驗證**

憑證參數 所需的值
憑證範本名稱 802.1X 伺服器驗證
Active Directory 發佈 否
金鑰用法 數位簽章 金鑰加密
金鑰保存 否
最小金鑰大小 1024
主體名稱 一般名稱
主體替代名稱 DNS 名稱
應用程式原則/延伸金鑰用法 伺服器驗證
密碼編譯服務提供者 (CSP) Microsoft RSA SChannel Cryptographic Provider
自哪一個範本衍生 RAS 和 IAS 伺服器
#### 建立憑證範本 Windows Server 2003 內的 Active Directory 包含許多通用功能的預先定義憑證範本。如果您安裝了「企業 CA」，則會依預設設定為發行數種內建憑證。所有這些內建範本的說明都可在 Windows Server 2003 企業版的產品說明文件中找到。(請參閱本章最後的＜其他資訊＞一節，以獲得精確的參考資料) 在本指南提供的解決方案中，大多數範本都從 CA 中移除；也就是說，它們是從憑證授權單位管理主控台的範本資料夾中移除，您不應將範本定義從目錄中刪除。 如果預先定義的範本符合您的需求，您就可選擇使用它們；這些範本涵蓋了大多數基於 Windows 憑證的應用程式 (例如加密檔案系統、VPN 驗證等等)。如果您要發行其他類型的憑證，最好建立專門滿足您需求的範本。但是，如果您在不瞭解其功能的情況下使用預先定義的範本，則可能會冒啟用您並不想使用的功能的風險。例如，打算用於簡單用戶端驗證的電腦憑證，也可作為網頁伺服器憑證使用。 若要建立新範本，您應該先尋找一個與您的憑證設定檔需求相類似的預先定義範本，然後建立該範本的複本，並以它作為基礎來建立新範本。設定範本是選擇屬性以符合本節內所定義憑證設定檔的一個簡單程序。 **附註：**您不能從頭建立新範本；而必須從現有範本中製作複本，然後視需求進行編輯。因此，電腦範本必須固定從電腦範本中衍生出來，而使用者範本則必須固定都從使用者範本中衍生出來 - 這兩者不能互相對換。 當您建立並修改範本時，應該詳細記錄範本參數，作為您組態管理系統的一部份。 [](#mainsection)[回到頁首](#mainsection) ### 建立憑證管理規劃 當為您的組織設定好憑證之後，您必須建立一個規劃，對憑證的整個生命週期進行管理。建立憑證管理規劃包括下列決策內容： - 如何處理新憑證的要求與憑證更新 - 如何將憑證對應到使用者帳戶 - 如何管理並散佈 CRL - 修復加密資料的策略 #### 選取註冊和更新方法 您可以使用數種不同的方法來執行憑證註冊 (同樣可以使用所有這些方法來更新憑證)： - Windows 自動註冊。 - 使用「憑證註冊精靈」進行線上註冊 (通常從「憑證管理主控台」啟動)。 - 使用應用程式或指令碼的 CryptoAPI 或 CAPICOM 介面進行線上註冊。 - 使用 Certreq.exe 工具來建立並提交要求，然後擷取發行的憑證。 **附註：**上面介紹的四種方法其實是針對相同的線上註冊介面提供了不同的介面。 - 網頁註冊。 - 手動離線註冊 (這包括使用上述定義的一種方法，以檔案形式產生要求，將它送到 CA，使用「憑證授權單位管理主控台」提交要求，並使用管理主控台擷取要求。) 所有這些方法都是有效、且適用於某些狀況下。本解決方案使用下列註冊方法： - Windows 自動註冊。在允許的情況下，這是降低憑證管理負擔所偏好的方法。您甚至可以在憑證要求手動核准 (但不要求註冊代理簽章) 的情況下使用自動註冊。此方法即使不會立即發行憑證，也會將要求提交給 CA，並在核准要求後完成註冊。 - 手動離線註冊。此方法可用於根 CA 的所有憑證註冊和更新。 但是，這兩種方法都不足以應付某些更為複雜的狀況，例如，將憑證要求提交給 CA 之前，需要協力廠商對它進行簽章。大多數非 Windows 平台 (例如，路由器) 也不支援RPC 的線上註冊。而且，在憑證要求中需要定義主體名稱或替代主體名稱 (而不是允許 Active Directory 來產生它) 的情況下，都不可能使用自動註冊。 若要滿足諸如此類的其他進階需求，應該考慮使用下列其中一種方法： - 建立要在用戶端獨立電腦上執行的 CAPICOM 指令碼，例如，作為登入指令檔的一部份。 - 在命令檔或批次檔中執行 certreq.exe，以產生並提交要求，然後擷取並安裝已發行的憑證。 - 建立一個自訂的網頁 (ASP 或 Microsoft ASP.NET)，並利用 CAPICOM 來建立並提交要求。使用後者這種技術可為廣大用戶端提供註冊服務，並包括複雜的多階段程序 (例如，當您需要多個簽章來核准一份要求時)。 #### 將憑證與身分對應 憑證與憑證中具名主體之間的對應是一大主題，不在本章討論範圍之內。但是，這個主題有兩個重點值得考慮： - 憑證主體的身分在發行憑證之前如何確認？ - 憑證主體的身分如何從目錄提供的資訊中發現？ 上述第一個問題牽涉到如何執行憑證註冊程序。下一節＜建立憑證原則＞會討論這點。第二個問題涵蓋的是憑證使用者 (應用程式和服務) 如何將憑證主體的身分正確對應到他們可以使用的其他身分。後者的範例為： - 要讓使用者登入到網域，建立存取權杖時，網域控制站如何從使用者他/她的智慧卡憑證中識別使用者？ - 電子郵件使用者是如何發現他們要發送安全電子郵件之收件人的憑證？ 在註冊程序中，大多數憑證都會自動對應到 Active Directory 安全性主體 (使用者和電腦) 上。Active Directory 定義了憑證的主體名稱以及主體替代名稱，以便在憑證與憑證中具名的安全性主體之間建立隱含的對應。主體替代名稱將包含使用者的 UPN 和/或電子郵件名稱，以及電腦或電腦程序的「服務主要名稱」(SPN)，或 DNS 主機名稱。UPN 和 SPN 值在 Active Directory 樹系中是唯一的。而電子郵件名稱和 DNS 名稱則應是全域唯一的，雖然 Active Directory 沒有對此進行強制要求。其他 Windows 服務，例如 IIS 與 IAS 能執行對應於使用者或電腦身份的憑證。 **附註：**憑證對應與憑證發佈無關。憑證對應表示憑證的某些屬性 (通常是主體替代名稱) 能在目錄中特別識別某一物件。IAS 伺服器使用這個對應，以決定來自於出示憑證的使用者或電腦的身份。IAS 使用這個隱含的對應，而非查看目錄中的憑證。憑證的發佈、推論及憑證的查閱，說明憑證做為使用者或電腦物件的屬性而在目錄中的確實存放位置。然後使用者可以搜尋目錄中的某人，並擷取屬於該位使用者的憑證。 可能可以使用 Active Directory 使用者及電腦管理主控台，將其他憑證匯入或對應到使用者或電腦物件。 相反的，有許多範例並不需要直接對應到目錄，包括下列例子： - 其中主要識別元為網站 DNS 主機名稱的網頁伺服器。 - 憑證發行給不具有相當的 Active Directory 之實體 (例如，路由器或來自其他組織的使用者) 的情況。 本指南解決方案中的所有終端實體都具有對於 Active Directory 使用者和電腦的直接 (與隱含) 對應。 其中，CA 屬於特殊情況，因為它們無需對應到電腦物件上。但是，它們幾乎永遠對應到 Active Directory AIA 和「信任憑證授權單位」容器中的「憑證授權單位」物件上。 #### 建立憑證原則 您至少應該為每種憑證安全性類別 (高、中及標準) 定義憑證核准方法，Microsoft 也建議您為每種憑證主體類別 (電腦、內部使用者和外部使用者) 定義憑證核准方法。您不大可能需要更詳細定義原則。您應該在憑證原則聲明和 CPS 中記錄這些原則決策。 不同的憑證原則用於表明憑證註冊中使用的憑證核准程序的類型，和私密金鑰的安全性層級。您可以 (但非必要) 使用 OID 將它編碼到憑證中，以表示不同的原則。核准程序的嚴密性應能反映發行憑證的值。核准 (或註冊) 程序的目的是要提供適當的信心程度，使憑證要求者與該憑證主體成為同一實體。金鑰安全性的強度可以衡量您對於私密金鑰保持私密性及僅限憑證主體擁有私密金鑰一事抱持多少信心。 此解決方案中使用的憑證保證層級，已在本章稍早＜定義憑證安全性需求＞一節中加以定義。您可以併入與那些憑證中的保證層級相對應的憑證原則 OID，來指示您發行憑證的保證層級。應用程式 (和使用者) 可使用原則來決定指定憑證的可信任度。 在稍早單元中定義的這三種保證層級對應於 Windows Server 2003 中的三種預先定義的憑證原則 (在憑證範本 MMC 內稱為發行原則)。下表包含在本解決方案內如何使用不同憑證原則的詳細資訊。您的憑證範本內應包括原則 OID   (至少對於中層及高層保證憑證而言)，才能輕易識別較高的保證憑證。無憑證原則的憑證會被當成標準保證。 **表 4.15：憑證發行原則層級**

憑證 (發行) 原則 註冊需求 金鑰最低儲存需求
低 (標準) 自動核准取決於成功的網域驗證。 對於獨立 CA 來說，這是未經驗證的核准，也就是說，CA 會在未檢查要求者 (或只檢查一點) 之情況下發行該憑證。 軟體金鑰
中 憑證管理員核准。 您必須在原則中定義憑證管理員應在他或她核准憑證要求前執行的檢查類型。 軟體金鑰或硬體金鑰。 如果使用軟體金鑰，請考慮使用增強式金鑰保護，除非應用程式無法使用此種保護。(例如，電腦憑證無法使用增強式金鑰保護。)
高 指定的註冊長官簽章和憑證管理員核准。 您必須定義註冊長官和憑證管理員必須在核准要求前執行的檢查類型。 硬體防篡改權杖。 例如，智慧卡或使用者的通用序列匯流排 (USB) 加密權杖或電腦的 HSM。

**附註：**如果對您的組織需求合理的話，沒有什麼理由不能定義更多或更少的憑證原則和保證層級。

定義憑證撤銷原則

在某些情況下，您可能需要在憑證的生命週期到期前使其無效。建立憑證撤銷原則包含下列工作：

  • 定義保證憑證撤銷的條件。

  • 選取 CRL 發佈位置。

  • 選取您要使用的 CRL 的一種或多種類型。

  • 建立 CRL 發佈的排程。

您憑證原則將會定義用於保證憑證撤銷的條件。它和不同類型的憑證可能會有所不同，並且會隨著各種 CA 的不同保證層級和主體類型憑證的變化而變化。

您也應記錄憑證遭到撤銷時，如何使用撤銷原因碼。下列表格說明了不同的原因碼。

表 4.16：憑證撤銷代碼

原因碼 說明
金鑰洩漏 憑證的私密金鑰已洩漏 (或懷疑洩漏)。
CA 洩漏 CA 的私密金鑰已洩漏 (或懷疑洩漏)。
聯盟變更 該主體已被移至另一組織。
已取代 已發行的新憑證將取代此憑證。
操作停止 CA 不再作業。
憑證保留 需要暫時停止使用憑證 (例如，假設使用者不知道他或她的智慧卡放在哪裡，但不確定是否遺失)。
未指定 其他代碼未涵蓋的任何原因。
**重要：**除非狀況確實許可，否則您應避免使用「憑證保留」原因碼。保留然後釋放憑證後，幾乎不可能在指定的時間內判斷憑證的撤銷狀態 (以及憑證簽章的有效性)。 作為撤銷程序的一部份，您應確保您的文件能解答下列問題。這些問題一般會儲存在變更管理或事件管理記錄中： - 撤銷此憑證的原因為何？ - 誰要求撤銷此憑證？ - 您會再需要此憑證 (如驗證簽章或解密訊息) 嗎？ 如果是，需要什麼 (如驗證簽章、解密訊息、一般用途) 呢？ - 身為系統管理員的您，必須符合什麼樣的特殊條件才能撤銷憑證(例如他或她必需作為憑證管理員)？ - 組織在撤銷憑證時 (如備份) 時，您必須遵循任何已記錄的操作程序嗎？ 還有許多支配憑證撤銷的技術參數。Microsoft 建議您，在您的 CA 原則中記錄這些參數。下列表格中的參數用來說明此解決方案的根 CA 與發行 CA。 **表 4.17：根 CA 憑證撤銷參數**

參數 選擇值 原因
CRL 發佈位置 (CDP) 至內部網頁伺服器的 HTTP 路徑 發佈至網頁伺服器將允許備份至 LDAP 位置，並允許非 LDAP 用戶端存取 CRL。
  至 Active Directory CDP 容器的 LDAP 路徑 發佈至所有網域控制站，將允許所有網域使用者輕易存取本機。
CRL 類型 僅針對基本 CRL 由於曾經發行的憑證數量較少，所以使用 Delta CRL 沒有好處。
發佈排程 六個月 這會使得撤銷發行 CA 憑證變得更困難，因此需要確保發行 CA 的信任度。但是，如此長的週期會使對根 CA 的管理工作減至最小。
CRL 重疊期 (新發佈的 CRL 與已經過期的 CRL 之間的間隔) 10 天 這容許從根 CA 擷取新 CRL時發生某種程度的錯誤。
**表 4.18：發行 CA 憑證撤銷參數**

參數 選擇值 原因
CRL 發佈位置 (CDP) 至 Active Directory CDP 容器的 LDAP 路徑 (適用於基本 CRL 及 Delta CRL) 發佈至所有網域控制站，將允許所有網域使用者輕易存取本機。 (請參閱有關發佈 Delta CRL 至 Active Directory 的後續註解。)
  至內部網頁伺服器的 HTTP 路徑 發佈至網頁伺服器將允許備份至 LDAP 位置，並允許非 LDAP 用戶端存取 CRL。
CRL 類型 基本 CRL Delta CRL Delta CRL 在為待發佈的撤銷資訊指定一個相對短期的延隔時，有利於最佳化 CRL 擷取流量。
發佈排程 基本 CRL - 7 天 此間隔頻繁的程度需要足以讓系統滿足不瞭解 Delta CRL 卻仍接收相對近期的撤銷資訊。
  Delta CRL - 1 天 對於可使用 Delta CRL 的現今用戶端來說，這會提供相對短的撤銷延隔。
基本 CRL 重疊期 (正在發佈的新 CRL 與即將過期的舊 CRL 之間的間隔) 4 天 無法按時發佈基本 CRL 時，允許出現一定範圍的 CA 修復錯誤。選擇四天，因為預計最壞的狀況是週末放長假，而星期五晚上遇到 CA 故障，一直到下個星期二之前都沒有人注意到這個情況。
Delta CRL 重疊期 1 天 Delta CRL 不是關鍵性服務，因此在 Delta CRL 發佈失敗時，並不會產生嚴重問題。因此這樣設定，重疊期就會大於 Active Directory 複製延遲。
**附註：**因為正在使用相對短期 (1 天) 的 Delta CRL，所以您必須確保 Active Directory 複製延遲的最大值小於 Delta CRL 發佈期的 50%。否則，會導致憑證用戶端使用過時的撤銷資訊，同樣也可能會對受限網路頻寬之網站的目錄複製流量產生不良影響。Delta CRL 重疊時間應設定為大於透過樹系來複製目錄資訊所花費的最長時間。 如果 Active Directory 延遲時間大於此值，或您不想增加額外的目錄複製流量，請延長 Delta CRL 發佈期或避免將 Delta CRL 發佈至該目錄。如果您變更了 Delta CRL 位置，則您必須發行一個新的基本 CRL。 使用 HTTP 位置而非 LDAP URL 來發佈 Delta CRL 時，通常很少關切複製延遲的問題。 #### 金鑰及資料修復規劃 金鑰修復及資料修復不在本解決方案所涉及的範圍之內。如果您需要其中之一或是兩者都需要，則必須規劃並仔細管理它們以避免資料遺失並避免加密資料的不經意公開。 您應閱讀《Windows Server 2003 部署套件》內的＜資料修復及金鑰修復規劃＞以及＜設計公開金鑰基礎結構＞這兩節 (英文)，還有 Microsoft 技術文件《Windows Server 2003 中的金鑰保存與管理》(英文)。 [](#mainsection)[回到頁首](#mainsection) ### 總結 本章涵蓋了針對安全無線區域網路(WLAN) 而設計公開金鑰基礎結構 (PKI) 的過程。由於許多組織未來有可能將該 PKI 用於其他應用程式，因此本指南詳述的 PKI 設計也考慮到這點。本章所介紹的設計決策具有足夠彈性，可讓您擴展以涵蓋將來的各種需求。您可以使用此處的資訊，協助您設計夠安全的 PKI，以符合比 WLAN 應用程式所要求的安全性標準更嚴格的標準。 本章說明的設計決策用於《建置指南》和《作業指南》中，以實作 PKI。這些資訊在解決方案指南的第 7 與第 11 章內有詳細說明。 在《規劃指南》的其他章節中，您將學習設計本解決方案的其他核心元件 - 即 RADIUS 基礎結構 (與 IAS 實作) 和 WLAN 安全性基礎結構。 #### 其他資訊 下列參考資料針對本章所涵蓋的許多主題提供更詳細的背景說明，以及其他有關資訊： - 《Windows Server 2003 部署套件》的＜[設計公開金鑰基礎架構](https://go.microsoft.com/fwlink/?linkid=4735)＞一章，網址是：https://go.microsoft.com/fwlink/?LinkId=4735。 - 如需 PKI 概念和 Windows 2000 憑證服務功能的一般介紹，請參閱＜[*Windows 2000 公開金鑰基礎結構簡介*](https://www.microsoft.com/technet/archive/windows2000serv/evaluate/featfunc/pkiintro.mspx)＞(英文)，網址是：https://www.microsoft.com/technet/archive/windows2000serv/evaluate/ featfunc/pkiintro.mspx。 - 如需 Windows Server 2003 和 Windows XP PKI 中增強型 PKI 功能的詳細說明，請參閱＜[*Windows XP Professional 與 Windows Server 2003 中的 PKI 增強功能*](https://www.microsoft.com/technet/prodtechnol/winxppro/plan/pkienh.mspx)＞(英文)，網址是：https://www.microsoft.com/technet/prodtechnol/winxppro/plan/pkienh.mspx。 - Windows 2003 Server 企業版[公開金鑰基礎結構](https://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/depkit/b1ee9920-d7ef-4ce5-b63c-3661c72e0f0b.mspx)產品文件討論了「憑證服務」的重要概念和管理工作，網址是：https://www.microsoft.com/technet/prodtechnol/windowsserver2003 /library/DepKit/B1EE9920-D7EF-4CE5-B63C-3661C72E0F0B.mspx - 如需有關編寫憑證實施準則的詳細資訊，請參閱 RFC2527＜[*網際網路 X.509 公開金鑰基礎結構憑證原則與憑證實施架構*](https://www.ietf.org/rfc/rfc2527.txt)＞(英文)，網址是：www.ietf.org/rfc/rfc2527.txt。 - 如需 CPS 的範例，請參閱 [VeriSign 憑證實施準則 (CPS)](https://www.verisign.com/repository/cps/) 頁面，網址是：www.verisign.com/repository/CPS/。 - 如需憑證原則 OID 與 CPS URL 如何編碼到憑證中的詳細資料，請參閱 RFC 3280＜[*網際網路 X.509 公開金鑰基礎結構憑證與 CRL 設定檔*](https://www.ietf.org/rfc/rfc3280.txt)＞，網址是：www.ietf.org/rfc/rfc3280.txt。 - 如需對於合格子關係的詳細說明，請參閱技術文件《[*使用 Windows Server 2003 規劃與實作交互憑證或合格的分類*](https://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/ws03qswp.mspx)》，網址是：https://www.microsoft.com/technet/prodtechnol/windowsserver2003/ technologies/security/ws03qswp.mspx。 - 如需企業 CA 和獨立 CA 之差異的詳細說明，請參閱「憑證服務」產品文件中的＜[憑證授權單位](https://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/serverhelp/f15bc83f-43b0-4b09-9bb5-c668e901b864.mspx)＞一節，網址是：https://www.microsoft.com/technet/prodtechnol/windowsserver2003/ library/ServerHelp/f15bc83f-43b0-4b09-9bb5-c668e901b864.mspx。 - 如需在 Windows Server 2003 內啟用匿名 LDAP 存取的更多資訊，請參閱 Microsoft 知識庫文件編號 Q326690，《[對 Active Directory 的匿名 LDAP 操作在 Windows Server 2003 網域控制站是停用的](https://support.microsoft.com/default.aspx?scid=326690)》(英文)，網址是：https://support.microsoft.com/default.aspx?scid=326690。 - 如需憑證撤銷的相關詳細討論，請參閱《[*疑難排解憑證狀態與撤銷*](https://www.microsoft.com/technet/prodtechnol/winxppro/support/tshtcrl.mspx)》(英文)，網址是：https://www.microsoft.com/technet/prodtechnol/winxppro/support/tshtcrl.mspx。關於 CDP 延伸的章節是特別針對本章中的一些討論。 - 有關安裝和使用「憑證服務」網頁註冊頁面的詳細資訊，請參閱 [Windows Server 2003 的產品說明文件](https://www.microsoft.com/windowsserver2003/proddoc/default.mspx)網頁 (英文)，網址是：https://www.microsoft.com/windowsserver2003/proddoc/default.mspx；然後搜尋 "Security"、"Public Key Infrastructure"、"Certificate Services"、"How to..." 與 "Set up a Certification Authority"。 - 如需「憑證範本」的詳細指南，請參閱《[*實作與管理 Windows Server 2003 中的憑證範本*](https://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/ws03crtm.mspx)》(英文)，網址是：https://www.microsoft.com/technet/prodtechnol/windowsserver2003/ technologies/security/ws03crtm.mspx。 - 所有內建憑證範本的說明都可在 Windows Server 2003 產品文件的＜[疑難排解](https://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/serverhelp/8dd5dd9e-d163-4260-bc9d-3286af55bad3.mspx)＞一節 (英文) 中找到，網址是：https://www.microsoft.com/technet/prodtechnol/windowsserver2003/ library/ServerHelp/8dd5dd9e-d163-4260-bc9d-3286af55bad3.mspx。 - 如需憑證自動註冊的更多資訊，請參閱《[*Windows Server 2003 中的憑證自動註冊*](https://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/autoenro.mspx)》(英文)，網址是：https://www.microsoft.com/technet/prodtechnol/windowsserver2003/ technologies/security/autoenro.mspx。 - 如需 Windows Server 2003 內有關金鑰保存與管理的資訊，請參閱技術文件《[*Windows Server 2003 中的金鑰保存與管理*](https://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/kyacws03.mspx)》(英文)，網址是：https://www.microsoft.com/technet/prodtechnol/windowsserver2003/ technologies/security/kyacws03.mspx。 - 如需進階憑證註冊案例的更多資訊，請參閱文件《[*進階憑證註冊與管理*](https://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/advcert.mspx)》(英文)，網址是：https://www.microsoft.com/technet/prodtechnol/windowsserver2003/ technologies/security/advcert.mspx。 - 如需使用註冊網頁進行憑證註冊的有關資訊，請參閱文件《[*設定與疑難排解 Windows 2000 及 Windows Server 2003 憑證服務 Web 註冊*](https://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/webenroll.mspx)》(英文)，網址是：https://www.microsoft.com/technet/prodtechnol/windowsserver2003/ technologies/security/webenroll.mspx。 - 如需實作 Windows Server 2003 PKI 的詳細資訊，請參閱文件《[實作 Microsoft Windows Server 2003 公開金鑰基礎結構的最佳作法](https://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/ws3pkibp.mspx)》(英文)，網址是：https://www.microsoft.com/technet/prodtechnol/windowsserver2003/ technologies/security/ws3pkibp.mspx。 - 如需其他實作資訊，請到 [Windows 伺服器系統參考架構](https://www.microsoft.com/resources/documentation/msa/2/all/solution/en-us/msa20ik/vmhtm1.mspx)頁面下載《Microsoft 系統架構 2.0 版實作指南》，網址是：https://www.microsoft.com/resources/documentation/msa/2/all/solution/en-us/msa20ik/vmhtm1.mspx. [](#mainsection)[回到頁首](#mainsection)