本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 設計 CA 階層
使用 AWS 私有 CA，您可以建立最多五個層級的憑證授權單位階層。位於階層樹狀結構頂端的根 CA，可以有任何數量的分支。根 CA 在每個分支上最多可以有四個層級的次級 CA。您也可以建立多個階層，每個階層都具有自己的根。
設計完善的 CA 階層具有下列優點：
+ 適用於每個 CA 的精細安全控制
+ 具有更佳負載平衡與安全的管理任務分工
+ 使用有限且可撤銷信任的 CA 進行日常操作
+ 有效期間和憑證路徑限制
下圖說明簡單的三層 CA 階層。
樹狀結構中的每個 CA，都受到一個具有簽署授權機構的 X.509 v3 憑證支援 (以筆與紙張圖示表示)。這表示其做為 CA 可以簽署其他從屬於其下方的憑證。當 CA 簽署較低層級的 CA 憑證時，會對已簽署的憑證授予有限且可撤銷的授權。層級 1 中的根 CA，會簽署層級 2 中的高階次級 CA 憑證。這些 CA 會依次簽署層級 3 中 CA 的憑證，而這些 CA 則是由管理終端實體憑證的 PKI (公有金鑰基礎設施) 管理員所使用。
CA 階層中的安全，應在樹狀目錄的頂端設為最強。此設定可保護根 CA 憑證及其私有金鑰。根 CA 會錨定所有次級 CA 及其下方終端實體憑證的信任。雖然對終端實體憑證造成的危害會導致局部損害，但對根造成的危害會破壞整個 PKI 中的信任。根和高階次級 CAs只會不常使用 （通常用來簽署其他 CA 憑證）。因此，這些 CA 會受到嚴格控制與稽核，以確保降低危害風險。階層中的較低層級，對安全方面的限制則較少。這種方法可讓您執行例行管理任務，例如發行及撤銷使用者、電腦主機和軟體服務的終端實體憑證。
**注意**
使用根 CA 簽署次級憑證是罕見事件，只發生在少數情況下：
建立 PKI 時
需要更換高階憑證授權機構時
需要設定憑證撤銷清單 (CRL) 或線上憑證狀態通訊協定 (OCSP) 回應程式時
根和其他高階 CA，需要高度安全的操作程序和存取控制通訊協定。
**Topics**
+ [驗證終端實體憑證](#end-entity-validation)
+ [規劃 CA 階層的結構](#ca-layers)
+ [設定認證路徑的長度限制](#length-constraints)
## 驗證終端實體憑證
終端實體憑證會從透過次級 CA 回到根 CA 的認證路徑取得信任。當 Web 瀏覽器或其他用戶端提供終端實體憑證時，其會嘗試建構信任鏈。例如，其可能會檢查憑證的「發行者辨別名稱」**和「主體辨別名稱」**是否與發行 CA 憑證的對應欄位相符。接著會繼續在階層的每個連續層級往上繼續比對，直到用戶端到達其信任存放區中所包含的信任根目錄為止。
信任存放區是瀏覽器或作業系統所包含的信任 CA 資源庫。針對私有 PKI，您組織的 IT 必須確保每個瀏覽器或系統先前已將私有根 CA 新增至其信任存放區。否則會無法驗證認證路徑，而導致用戶端錯誤。
下圖顯示在提供終端實體 X.509 憑證時，瀏覽器會遵循的驗證路徑。請注意，終端實體憑證缺少簽署授權機構，並且僅可用於驗證擁有該憑證的實體。
瀏覽器檢查終端實體憑證。瀏覽器發現憑證提供次級 CA (層級 3) 的簽章做為其信任登入資料。次級 CA 的憑證必須包含在相同 PEM 檔案中。或者，也可以位於包含組成信任鏈結之憑證的個別檔案中。找到這些資訊後，瀏覽器檢查次級 CA (層級 3) 的憑證，並發現其提供次級 CA (層級 2) 的簽章。反過來，次級 CA (層級 2) 會提供來自根 CA (層級 1) 的簽章做為其信任登入資料。如果瀏覽器發現預先安裝在其信任存放區中的私有根 CA 憑證複本，則會將終端實體憑證驗證為受信任。
一般來說，瀏覽器也會根據憑證撤銷清單 (CRL) 來檢查每個憑證。已過期、已撤銷或設定錯誤的憑證會遭拒絕，且驗證會失敗。
## 規劃 CA 階層的結構
一般而言，您的 CA 階層應該要反映出組織的結構。目標*路徑長度* （即 CA 層級數量） 不超過委派管理和安全角色所需的值。將 CA 新增至階層，表示增加認證路徑中的憑證數量，而這會增加驗證時間。在驗證終端實體憑證時，將路徑長度保持在最短，也會減少從伺服器傳送至用戶端的憑證數量。
理論上，沒有 [pathLenConstraint](PcaTerms.md#terms-pathlength) 參數的根 CA 可以授權不限層級的次級 CAs。次級 CA 可以有與其內部 configuration 允許的次級 CAs 數量一樣多。 AWS 私有 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 發行憑證，則可以遷移至 AWS 私有 CA。這樣做可提供與使用透過 [OpenSSL](https://www.openssl.org/) 或其他軟體管理的根 CA 相比的安全性和控制優勢。
### 製造商的私有 PKI 範例
在此範例中，一家虛構的科技公司生產兩種物聯網產品：智慧型燈泡和智慧型烤麵包機。在生產過程中，會將終端實體憑證發行給每部裝置，以便裝置能夠透過網際網路與製造商安全通訊。公司 PKI 也會確保其電腦基礎設施的安全，包括內部網站和各種自我裝載電腦服務，這些服務負責執行財務和業務營運。
因此，CA 階層會密切為業務的這些管理和操作層面建立模型。
此階層包含三個根目錄，一個用於內部操作，另外兩個用於外部操作 (每個產品系列都有一個根 CA)。它還說明了多個認證路徑長度，其中兩個 CA 層級用於內部操作，三個層級用於外部操作。
在外部操作端使用分離的根 CAs和其他次級 CA 層，是滿足商業和安全性需求的設計決策。具備多個 CA 樹狀結構時，PKI 就可以適應未來的企業重新組織、撤資或併購。在發生變更時，整個根 CA 階層都可以隨著其保護的部門而整潔地移動。由於具備了兩個層級的次級 CA，根 CA 擁有高度隔離的效果，可與負責大量簽署數千或數百萬個製造項目之憑證的層級 3 CA 區隔。
在內部方面，企業 Web 和內部電腦操作可完成兩個層級的階層。這些層級可讓 Web 管理員和操作工程師獨立管理其工作領域的憑證發行。將 PKI 區分為不同的功能領域是安全最佳實務，可保護每個領域免受可能影響另一個網域的危害。Web 管理員會發行終端實體憑證供整個公司的 Web 瀏覽器使用，以驗證及加密內部網站上的通訊。操作工程師會發行終端實體憑證，以互相驗證資料中心主機和電腦服務。此系統會藉由在 LAN 上加密資料以協助保護敏感資料的安全。
## 設定認證路徑的長度限制
CA 階層架構的結構，由每個憑證所包含的「基本限制條件延伸」**來定義及強制執行。延伸會定義兩個限制條件：
+ `cA` – 憑證是否定義 CA。如果此值為 *False* (預設值)，則憑證為終端實體憑證。
+ `pathLenConstraint` – 可存在於有效信任鏈中的較低層級次級 CAs 數目上限。不會計算終端實體憑證，因為它不是 CA 憑證。
根 CA 憑證需要具備最大的彈性，且不包含路徑長度限制條件。這可讓根定義任何長度的認證路徑。
**注意**
AWS 私有 CA 會將認證路徑限制為五個層級。
次級 CA 的 `pathLenConstraint` 值會等於或大於零，取決於階層放置中的位置與所需功能。例如，在具有三個 CA 的階層中，不會對根 CA 指定任何路徑限制條件。第一個次級 CA 的路徑長度為 1，因此可以簽署子 CA。每個子 CA 都必須具有值為零的 `pathLenConstraint`。這表示其可以簽署終端實體憑證，但無法發行其他 CA 憑證。限制建立新 CA 的能力，是一項重要的安全控制。
下圖說明了階層中受限授權能力的這種傳播方式。
在四層階層中，根目錄是不受限制的 (如同往常)。但第一個次級 CA 的 `pathLenConstraint` 值為 2，這會限制其子 CA 深入超過兩個層級。因此，針對有效的認證路徑，限制條件值必須在接下來的兩個層級遞減為零。如果 Web 瀏覽器遇到來自此分支的終端實體憑證，且路徑長度大於 4，則驗證就會失敗。這類憑證可能是意外建立的 CA、設定錯誤的 CA 或未經授權的發行所造成。
### 使用 範本管理路徑長度
AWS 私有 CA 提供用於發行根憑證、次級憑證和終端實體憑證的範本。這些範本納入了基本限制條件值 (包括路徑長度) 的最佳實務。範本包括下列項目：
+ RootCACertificate/V1
+ SubordinateCACertificate\_PathLen0/V1
+ SubordinateCACertificate\_PathLen1/V1
+ SubordinateCACertificate\_PathLen2/V1
+ SubordinateCACertificate\_PathLen3/V1
+ EndEntityCertificate/V1
如果您嘗試建立路徑長度大於或等於其發行 CA 憑證路徑長度的 CA，則 `IssueCertificate` API 將傳回錯誤。
如需憑證範本的詳細資訊，請參閱[使用 AWS 私有 CA 憑證範本](UsingTemplates.md)。
### 使用 自動化 CA 階層設定 AWS CloudFormation
當您完成 CA 階層的設計時，您可以進行測試，並使用 AWS CloudFormation 範本將其投入生產環境。如需這類範本的範例，請參閱*CloudFormation 《 使用者指南*》中的[宣告私有 CA 階層](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-acmpca-certificateauthority.html#aws-resource-acmpca-certificateauthority--examples)。