共用方式為

Service Fabric 叢集中的 X.509 憑證型驗證

  • 發行項

本文補充 Service Fabric 叢集安全性的簡介，並深入探討 Service Fabric 叢集中的憑證型驗證。 我們假設讀者已經熟悉基本安全性概念，以及 Service Fabric 公開以控制叢集安全性的控制項。

本標題下涵蓋的主題：

  • 憑證式驗證基本概念
  • 身分識別及其各自的角色
  • 憑證設定規則
  • 疑難排解和常見問題

憑證式驗證基本概念

總而言之，在安全性中，憑證是一種檢測，旨在將實體 (主體) 的相關資訊繫結至其擁有的一組非對稱式密碼編譯金鑰，因此構成公開金鑰加密的核心結構。 憑證所代表的金鑰可以用於保護資料，或是證明金鑰持有者的身分識別；搭配公開金鑰基礎結構 (PKI) 系統使用時，憑證可以代表其主體的其他特性，例如網際網路網域的擁有權，或憑證簽發者 (稱為憑證授權單位或 CA) 授與其的特定權限。 常見的憑證應用是支援傳輸層安全性 (TLS) 密碼編譯通訊協定，以允許透過電腦網路進行安全通訊。 具體而言，用戶端和伺服器會使用憑證來確保其通訊的隱私權和完整性，同時也會進行相互驗證。

在 Service Fabric 中，叢集 (同盟) 的基礎層也建立在 TLS (其他通訊協定之間)，以實現可靠且安全的參與節點網路。 透過 Service Fabric 用戶端 API 連線到叢集時，也會使用 TLS 來保護流量，同時建立合作對象的身分識別。 具體而言，在 Service Fabric 中用於驗證時，憑證可以用來證明下列宣告：a) 憑證認證的呈現者擁有憑證的私密金鑰、b) 憑證的 SHA-1 雜湊 (「指紋」) 符合叢集定義中包含的宣告，或 c) 憑證的辨別主體一般名稱符合叢集定義中包含的宣告，而且憑證的簽發者是已知或受信任的。

在上述清單中，'b' 俗稱為「指紋鎖定」；在此情況下，宣告會參考特定憑證，而驗證配置的強度則會基於下列前提：偽造的憑證會產生與另一個憑證相同的雜湊值，同時在其他所有方面仍然是有效且格式正確的物件，這在計算上是不可行的。 項目 'c' 代表宣告憑證的替代形式，其中配置的強度基於憑證主體和簽發授權單位的組合。 在此情況下，宣告會參考憑證的類別 - 任何兩個憑證若具有相同特性，則會將其視為完全相等。

下列各節將深入說明 Service Fabric 執行階段如何使用並驗證憑證，以確保叢集安全性。

身分識別及其各自的角色

在深入探討驗證的詳細資料或或保護通訊通道的安全之前，請務必列出參與執行者及其在叢集中扮演的對應角色：

  • Service Fabric 執行階段 (稱為「系統」)：一組服務，其會提供代表叢集的抽象概念和功能。 提到系統執行個體之間的叢集內通訊時，我們會使用「叢集身分識別」一詞，而提到叢集作為叢集外部流量的接收者/目標時，則會使用「伺服器身分識別」一詞。
  • 裝載的應用程式 (稱為「應用程式」)：叢集擁有者所提供的程式碼，該程式碼是在叢集中進行協調和執行
  • 用戶端：根據叢集設定，允許連線至其中，以及其可在叢集中執行功能。 我們會分別區分兩個權限層級 - 「使用者」和「管理員」。 「使用者」用戶端限制為只能進行唯讀作業 (但不是所有唯讀功能)，而「管理員用戶端」則可無限制地存取叢集的功能。 (如需其他詳細資料，請參閱 Service Fabric 叢集中的安全性角色。)
  • (僅限 Azure) Service Fabric 服務，這些服務會協調和公開 Service Fabric 叢集的作業和管理控制項，簡稱為「服務」。 根據環境，「服務」可能指的是 Azure Service Fabric 資源提供者，或 Service Fabric 小組擁有和操作的其他資源提供者。

在安全的叢集中，其中每個角色都可以使用自己的相異身分識別進行設定，將其宣告為預先定義角色名稱與其對應認證的配對。 Service Fabric 支援將認證宣告為憑證或網域型服務主體。 (此外，也支援 Windows/Kerberos 型身分識別，但不在本文的討論範圍內；請參閱Service Fabric 叢集中的 Windows 型安全性。)在 Azure 叢集中，用戶端角色也可以宣告為 Microsoft Entra ID 型身分識別。

如前文所述，Service Fabric 執行階段會在叢集中定義兩個權限層級：「管理員」和「使用者」。 管理員用戶端和「系統」元件將以「管理員」權限運作，因此彼此無法區分。 建立與叢集的連線時，Service Fabric 執行階段會將這兩個角色之一授與已驗證的呼叫者，作為後續授權的基礎。 我們將在下列各節中深入探討驗證。

憑證設定規則

驗證規則

Service Fabric 叢集的安全性設定會以主體形式描述下列層面：

  • 驗證類型；這是叢集建立時不可變的特性。 這類設定的範例為 'ClusterCredentialType'、'ServerCredentialType'，而允許的值為 'none'、'x509' 或 'windows'。 本文著重於 x509 類型驗證。
  • (驗證) 驗證規則；這些設定是由叢集擁有者所設定，並描述給定角色應該接受哪些認證。 下面將深入探討範例。
  • 用來調整或細微改變驗證結果的設定；此處範例包含的旗標會限制或解除限制憑證撤銷清單的強制執行等。

注意

下面提供的叢集設定範例是來自叢集資訊清單中 XML 格式的摘錄，此格式為最簡要的格式，可直接支援本文中所述的 Service Fabric 功能。 相同的設定可直接以叢集定義的 JSON 表示法表示，不論其是獨立 JSON 叢集資訊清單，還是 Azure 資源管理範本。

憑證驗證規則包含下列元素：

  • 對應角色：用戶端、管理員用戶端 (特殊權限角色)
  • 角色接受的認證，以指紋或主體一般名稱宣告

指紋型憑證驗證宣告

若是指紋型驗證規則，要求連線至叢集的呼叫者所提供的認證將會依照下列方式進行驗證：

  • 認證是有效且格式正確的憑證：可建立其鏈結，簽章相符
  • 憑證有效時間 (NotBefore < = now < NotAfter)
  • 憑證的 SHA-1 雜湊符合宣告，作為不區分大小寫的字串比較 (排除所有空格)

在建置或驗證鏈結期間遇到的任何信任錯誤將會隱藏以進行指紋型宣告，但過期的憑證除外 - 儘管還有針對該案例的佈建。 具體而言，與下列相關的失敗：撤銷狀態未知或離線、不受信任的根、無效的金鑰使用方式、部分鏈結被視為非嚴重錯誤；在此情況下，憑證只是金鑰組的封套 - 安全性基於叢集擁有者已設定適當措施來保護私密金鑰的事實。

來自叢集資訊清單的下列摘錄舉例說明如此一組指紋型驗證規則：

<Section Name="Security">
  <Parameter Name="ClusterCredentialType" Value="X509" />
  <Parameter Name="ServerAuthCredentialType" Value="X509" />
  <Parameter Name="AdminClientCertThumbprints" Value="d5ec...4264" />
  <Parameter Name="ClientCertThumbprints" Value="7c8f...01b0" />
  <Parameter Name="ClusterCertThumbprints" Value="abcd...1234,ef01...5678" />
  <Parameter Name="ServerCertThumbprints" Value="ef01...5678" />
</Section>

上述每個項目都會參考先前所述的特定身分識別；每個項目也允許將多個值指定為以逗號分隔的字串清單。 在此範例中，成功驗證傳入的認證時，具有 SHA-1 指紋 'd5ec...4264' 的憑證呈現者被授與「管理員」；相反地，使用憑證 '7c8f...01b0' 進行驗證的呼叫者會被授與「使用者」角色，但限制為只能執行唯讀作業。 呈現憑證的輸入呼叫者，若其憑證的指紋為 'abcd...1234' 或 'ef01...5678'，系統將接受其作為叢集中的對等節點。 最後，連線到叢集管理端點的用戶端會預期伺服器憑證的指紋為 'ef01...5678'。

如先前所提，Service Fabric 會進行接受過期憑證的佈建，原因是憑證確實具有受到限制的存留期，而且由指紋宣告 (這會參考特定的憑證執行個體) 時，允許憑證到期會導致無法連線到叢集，或叢集直接垮掉。 太過容易以致忘記或忽略指紋鎖定憑證的輪替，而且不幸的是，若要從這類情況復原很困難。

總之，叢集擁有者可以明確陳述指紋所宣告的自我簽署憑證應視為有效，如下所示：

  <Section Name="Security">
    <Parameter Name="AcceptExpiredPinnedClusterCertificate" Value="true" />
  </Section>

此行為不會延伸至 CA 簽發的憑證；如果是這種情況，已撤銷且已知將遭盜用的過期憑證不再出現在 CA 的憑證撤銷清單後，立即就會變成「有效」，因此出現安全性風險。 使用自我簽署憑證時，叢集擁有者會被視為唯一負責保護憑證私密金鑰的一方，但使用 CA 發出的憑證時不是如此 - 叢集擁有者可能不會察覺系統如何或何時宣告其憑證遭盜用。

一般名稱型憑證驗證宣告

一般名稱型宣告會採用下列其中一種形式：

  • 主體一般名稱 (唯一)
  • 具有簽發者鎖定的主體一般名稱

讓我們首先考慮來自叢集資訊清單的摘錄，其會舉例說明這兩種宣告樣式：

    <Section Name="Security/ServerX509Names">
      <Parameter Name="server.demo.system.servicefabric.azure-int" Value="" />
    </Section>
    <Section Name="Security/ClusterX509Names">
      <Parameter Name="cluster.demo.system.servicefabric.azure-int" Value="1b45...844d,d7fe...26c8,3ac7...6960,96ea...fb5e" />
    </Section>

宣告會分別參考伺服器和叢集身分識別；請注意，CN 型宣告會在叢集資訊清單中具有自己的區段，與標準「安全性」分開。 在這兩個宣告中，'Name' 代表憑證的辨別主體一般名稱，而 'Value' 欄位則代表預期的簽發者，如下所示：

  • 在第一種情況下，宣告會陳述伺服器憑證辨別主體的一般名稱元素應符合 "server.demo.system.servicefabric.azure-int" 字串，空白 'Value' 欄位表示預期憑證鏈結的根在伺服器憑證驗證所在的節點/電腦上是受信任的；在 Windows 上，這表示憑證可以鏈結至安裝在「信任的根 CA」存放區中的任何憑證；
  • 在第二種情況下，宣告會陳述如果憑證的一般名稱符合 "cluster.demo.system.servicefabric.azure-int" 字串，「且」憑證直接簽發者的指紋符合 'Value' 欄位的其中一個逗點分隔項目，系統就會接受憑證的呈現者作為叢集中的對等節點。 (此規則類型俗稱為「具有簽發者鎖定的一般名稱」。)

在任一情況下，都會建立憑證鏈結，而且應該不會發生錯誤；亦即，撤銷錯誤、部分鏈結或時間無效信任錯誤會被視為嚴重，而且憑證驗證將會失敗。 鎖定簽發者會導致將「不受信任的根」狀態視為非嚴重錯誤；儘管外觀上，但這是一種更嚴格的驗證形式，因為其可讓叢集擁有者將一組已授權/接受的簽發者限制為自己的 PKI。

在建立憑證鏈結之後，會使用宣告的主體作為遠端名稱，針對標準 TLS/SSL 原則進行驗證；如果憑證的主體一般名稱或其任何主體替代名稱符合來自叢集資訊清單的 CN 宣告，則系統會將憑證視為相符。 在此情況下支援萬用字元，且字串比對不區分大小寫。

(我們應該釐清，您可以針對憑證所宣告的每個金鑰使用類型執行上述順序；如果憑證指定用戶端驗證金鑰使用方式，則系統會先針對用戶端角色建立並評估鏈結。若成功，表示評估完成且驗證成功。如果憑證沒有用戶端驗證使用方式或驗證失敗，Service Fabric 執行階段將會建立並評估用於伺服器驗證的鏈結。)

為了完成此範例，下列摘錄說明如何依照一般名稱宣告用戶端憑證：

    <Section Name="Security/AdminClientX509Names">
      <Parameter Name="admin.demo.client.servicefabric.azure-int" Value="1b45...844d,d7fe...26c8,3ac7...6960,96ea...fb5e" />
    </Section>
    <Section Name="Security/ClientX509Names">
      <Parameter Name="user.demo.client.servicefabric.azure-int" Value="1b45...844d,d7fe...26c8,3ac7...6960,96ea...fb5e" />
    </Section>

上述宣告分別對應至管理員和使用者身分識別；以這種方式宣告的憑證驗證，完全如同先前叢集和伺服器憑證範例所述。

注意

一般名稱型宣告旨在簡化輪替，而且通常會簡化叢集憑證的管理。 不過，建議您遵循下列建議，以確保叢集的持續可用性和安全性：

  • 偏好簽發者鎖定至依賴受信任的根
  • 避免混合來自不同 PKI 的簽發者
  • 確保憑證宣告上列出所有預期的簽發者；不相符的簽發者會導致驗證失敗
  • 確保 PKI 的憑證原則端點可探索、可用且可存取 - 這表示 AIA、CRL 或 OCSP 端點是在分葉憑證上宣告，而且可以存取它們，以便可以完成憑證鏈結的建立。

將其全部整合在一起，在以 x.509 憑證保護的叢集中收到連線要求時，Service Fabric 執行階段將會使用叢集的安全性設定來驗證遠端方的認證 (如上面所述)；如果成功，則會將呼叫者/遠端方視為已驗證。 如果認證符合多個驗證規則，則執行階段會將任何相符規則的最高權限角色授與呼叫者。

呈現規則

上一節描述了驗證如何在憑證保護的叢集中運作；本節將說明 Service Fabric 執行階段本身如何探索和載入用於叢集內通訊的憑證，我們稱之為「呈現」規則。

如同驗證規則，呈現規則會指定角色和相關聯的認證宣告 (以指紋或一般名稱表示)。 不同於驗證規則，一般名稱型宣告沒有簽發者鎖定的佈建；這允許更大的彈性以及改善的效能。 針對每個不同的節點類型，呈現規則是在叢集資訊清單的 'NodeType' 區段中宣告；這些設定是從叢集的 [安全性] 區段分割的，以允許每個節點類型在單一區段中具有其完整設定。 在 Azure Service Fabric 叢集中，節點類型憑證宣告預設為其對應設定，而這些設定在叢集定義的 [安全性] 區段中。

指紋型憑證呈現宣告

如先前所述，Service Fabric 執行階段會區分其角色，作為叢集中其他節點的對等節點，以及作為伺服器進行叢集管理作業。 原則上，這些設定可用不同方式加以設定，但實際上它們可能會傾向一致。 在本文的其餘部分，為簡單起見，我們將假設設定相符。

讓我們考慮來自叢集資訊清單的下列摘錄：

  <NodeTypes>
    <NodeType Name="nt1vm">
      <Certificates>
        <ClusterCertificate X509FindType="FindByThumbprint" X509FindValue="cc71...1984" X509FindValueSecondary="49e2...19d6" X509StoreName="my" Name="ClusterCertificate" />
        <ServerCertificate X509FindValue="cc71...1984" Name="ServerCertificate" />
        <ClientCertificate X509FindValue="cc71...1984" Name="ClientCertificate" />
      </Certificates>
    </NodeType>
  </NodeTypes>

'ClusterCertificate' 元素示範完整的結構描述，包括選擇性參數 ('X509FindValueSecondary') 或具有適當預設值的參數 ('X509StoreName')；其他宣告則會顯示縮寫格式。 上述叢集憑證宣告會陳述節點 (類型為 'nt1vm' ) 的安全性設定是以 'cc71..1984' 作為主要憑證，以 '49e2..19d6' 作為次要憑證進行初始化；這兩個憑證應該可在 LocalMachine'My' 憑證存放區 (或 Linux 對等路徑 var/lib/sfcerts) 中找到。

一般名稱型憑證呈現宣告

節點類型憑證也可以透過主體一般名稱來宣告，如下列範例所示：

  <NodeTypes>
    <NodeType Name="nt1vm">
      <Certificates>
        <ClusterCertificate X509FindType="FindBySubjectName" X509FindValue="demo.cluster.azuredocpr.system.servicefabric.azure-int" Name="ClusterCertificate" />
      </Certificates>
    </NodeType>
  </NodeTypes>

針對任一類型的宣告，Service Fabric 節點將會在啟動時讀取設定、找出並載入指定的憑證，並以其 NotBefore 屬性的遞減順序排序、忽略過期的憑證，然後選取清單中的第一個元素，作為此節點所嘗試任何 Service Fabric 連線的用戶端認證。 (實際上，Service Fabric 優先於最新簽發的憑證。)

注意

在版本 7.2.445 (7.2 CU4) 之前，Service Fabric 已選取最遠到期憑證 (具有最遠 'NotAfter' 屬性的憑證)

請注意，對於以一般名稱型呈現宣告，如果憑證的主體一般名稱等於宣告的 X509FindValue (或 X509FindValueSecondary) 欄位，就會將憑證視為相符，進行區分大小寫的確切字串比較。 相較於驗證規則，其支援萬用字元比對，以及不區分大小寫的字串比較。

其他憑證設定

先前已提及 Service Fabric 叢集的安全性設定也允許稍微變更驗證碼的行為。 當 Service Fabric 叢集設定上的發行項代表全面性且最新的設定清單時，我們會在這裡詳述一些安全性設定的意義，以完成憑證型驗證的完整公開。 針對每個設定，我們將說明意圖、預設值/行為、其如何影響驗證，以及哪些值是可接受的。

如先前所提，憑證驗證一律暗示建立和評估憑證的鏈結。 針對 CA 簽發的憑證，這種明顯簡單的 OS API 呼叫通常需要對發出 PKI、快取回應等的各種端點進行數個輸出呼叫。 鑑於憑證驗證呼叫在 Service Fabric 叢集中的普遍性，PKI 端點中的任何問題可能會導致叢集的可用性降低，或直接無法運作。 儘管無法隱藏輸出呼叫 (如需此情況的詳細資訊，請參閱下列常見問題一節)，但下列設定可用來遮罩由於 CRL 呼叫失敗所造成的驗證錯誤。

  • CrlCheckingFlag - 在 "Security" 區段下，字串已轉換成 UINT。 Service Fabric 使用此設定的值，藉由變更鏈結建立的行為來遮罩憑證鏈結狀態錯誤；其會以 'dwFlags' 參數的形式傳入至 Win32 CryptoAPI CertGetCertificateChain 呼叫，並且可以設定為函數所接受旗標的任何有效組合。 0 值會強制 Service Fabric 執行階段忽略任何信任狀態錯誤 - 這不是建議值，因為使用 0 值會構成重大的安全性風險。 預設值為 0x40000000 (CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT)。

使用時機：進行本機測試時，使用的自我簽署憑證或開發人員憑證沒有完整的形式/沒有適當的公開金鑰基礎結構來支援憑證。 在 PKI 之間進行轉換期間，也可能在實體隔離斷網的環境中用作緩解措施。

使用方式：我們將會採取一個範例，強制撤銷檢查只存取快取的 URL。 假設：

#define CERT_CHAIN_REVOCATION_CHECK_CACHE_ONLY         0x80000000

然後叢集資訊清單中的宣告會變成：

  <Section Name="Security">
    <Parameter Name="CrlCheckingFlag" Value="0x80000000" />
  </Section>
  • IgnoreCrlOfflineError - 在 "Security" 區段下，預設值為 'false' 的布林值。 代表隱藏「撤銷離線」鏈結建立錯誤狀態 (或後續鏈結原則驗證錯誤狀態) 的捷徑。

使用時機：本機測試，或使用不受適當 PKI 支援的開發人員憑證。 在實體隔離斷網的環境中或在已知 PKI 無法存取時，用作緩解措施。

使用方式：

  <Section Name="Security">
    <Parameter Name="IgnoreCrlOfflineError" Value="true" />
  </Section>

其他值得注意的設定 (全部都在 "Security" 區段下)：

  • AcceptExpiredPinnedClusterCertificate - 在專用於指紋型憑證驗證一節中討論過；允許接受過期的自我簽署叢集憑證。
  • CertificateExpirySafetyMargin - 間隔，在憑證的 NotAfter 時間戳記之前以分鐘表示，在這段期間系統會將憑證視為有到期風險。 Service Fabric 會監視叢集憑證，並定期發出有關其剩餘可用性的健康情況報告。 在「安全」間隔內，這些健康情況報告會提升至「警告」狀態。 預設值為 30 天。
  • CertificateHealthReportingInterval - 控制健康情況報告的頻率，這些報告與叢集憑證的剩餘時間有效性有關。 報告只會根據此間隔發出一次。 值是以秒表示，預設值為 8 小時。
  • EnforcePrevalidationOnSecurityChanges - 布林值，控制偵測安全性設定變更時叢集升級的行為。 如果設定為 'true'，叢集升級會嘗試確保至少其中一個符合任何展示規則的憑證可以通過對應的驗證規則。 預先驗證會先執行，然後才會將新的設定套用至任何節點，但只會在起始升級時裝載叢集管理員服務主要複本的節點上執行。 在撰寫本文時，此設定的預設值為 'false'，且會針對新的 Azure Service Fabric 叢集設定為 'true'，而執行階段版本從 7.1 開始。

端對端案例 (範例)

我們已探討呈現規則、驗證規則和調整旗標，但這全部如何共同運作？ 在本節中，我們將逐步解說兩個端對端範例，示範如何運用安全性設定來進行安全的叢集升級。 請注意，這並不是全面論述 Service Fabric 中的適當憑證管理。請尋找該主題的相關文章。

呈現規則與驗證規則的分隔會造成明顯的問題 (或顧慮)，即它們是否可以分離，以及結果為何。 節點的驗證憑證選擇確實不能通過另一個節點的驗證規則。 事實上，此差異是驗證相關事件的主要原因。 同時，這些規則的分隔可讓叢集在升級期間繼續運作，此升級會變更叢集的安全性設定。 請考慮，第一步首先加強驗證規則，所有叢集的節點將藉以聚合在新的設定上，同時仍會使用目前的認證。

回想一下，在 Service Fabric 叢集中，升級會透過 (最多 5 個)「升級網域」或 UD 進行。 只有目前 UD 中的節點會在給定時間進行升級/變更，而且只有在叢集的可用性允許升級時，升級才會在下一個 UD 繼續。 (如需其他詳細資料，請參閱 Service Fabric 叢集升級，以及有關相同主題的其他文章。)憑證/安全性變更特別有風險，因為它們可以隔離叢集中的節點，或使叢集處於仲裁遺失的邊緣。

我們將使用下列標記法來描述節點的安全性設定：

Nk: {P:{TP=A}, V:{TP=A}}，其中：

  • 'Nk' 代表升級網域 k中的節點
  • 'P' 代表節點目前的呈現規則 (假設我們只參考叢集憑證)；
  • 'V' 代表節點目前的驗證規則 (僅限叢集憑證)
  • 'TP=A' 代表指紋型宣告 (TP)，而 'A' 是憑證指紋
  • 'CN=B' 代表一般名稱型宣告 (CN)，而 'B' 是憑證的主體一般名稱

輪替指紋所宣告的叢集憑證

下列序列描述如何使用 2 階段升級安全地引進指紋所宣告的次要叢集憑證；第一個階段會在驗證規則中引進新的憑證宣告，而第二個階段則會在呈現規則中引進該宣告：

  • 初始狀態：N0 = {P:{TP=A}, V:{TP=A}}, ...Nk = {P:{TP=A}, V:{TP=A}} - 叢集為待用叢集，所有節點共用一般設定
  • 完成升級網域 0 時：N0 = {P:{TP=A}, V:{TP=A, TP=B}}, ...Nk = {P:{TP=A}, V:{TP=A}} - UD0 中的節點會呈現憑證 A，並接受憑證 A 或 B；所有其他節點都會呈現並只接受憑證 A
  • 完成最後一個升級網域時：N0 = {P:{TP=A}, V:{TP=A, TP=B}}, ...Nk = {P:{TP=A}, V:{TP=A, TP=B}} - 所有節點都會呈現憑證 A，所有節點都將接受憑證 A 或 B

此時，叢集會再次處於均衡狀態，而且升級/變更安全性設定的第二個階段可以開始：

  • 完成升級網域 0 時：N0 = {P:{TP=A, TP=B}, V:{TP=A, TP=B}}, ...Nk = {P:{TP=A}, V:{TP=A, TP=B}} - UD0 中的節點將會開始呈現 B，而叢集中的任何其他節點都會接受此情況。
  • 完成最後一個升級網域時：N0 = {P:{TP=A, TP=B}, V:{TP=A, TP=B}}, ...Nk = {P:{TP=A, TP=B}, V:{TP=A, TP=B}} - 所有節點都已切換為呈現憑證 B。現在可以透過後續的一組升級，從叢集定義中淘汰/移除憑證 A。

將叢集從指紋轉換為一般名稱型憑證宣告

同樣地，變更憑證宣告的類型 (從指紋變更為一般名稱) 將遵循與上述相同的模式。 請注意，驗證規則允許在相同的叢集定義中，以指紋和一般名稱宣告給定角色的憑證。 不過，相較之下呈現規則只允許一種形式的宣告。 順便一提，將叢集憑證從指紋轉換為一般名稱的安全方法是首先依指紋引進預定的目標憑證，然後將該宣告變更為一般名稱型宣告。 在下列範例中，我們將假設指紋 'A' 和主體一般名稱 'B' 參考相同的憑證。

  • 初始狀態：N0 = {P:{TP=A}, V:{TP=A}}, ...Nk = {P:{TP=A}, V:{TP=A}} - 叢集為待用叢集，所有節點共用一般設定，而 A 成為主要憑證指紋
  • 完成升級網域 0 時：N0 = {P:{TP=A}, V:{TP=A, CN=B}}, ...Nk = {P:{TP=A}, V:{TP=A}} - UD0 中的節點會呈現憑證 A，並接受具有指紋 A 或一般名稱 B 的憑證；所有其他節點都會呈現並只接受憑證 A
  • 完成最後一個升級網域時：N0 = {P:{TP=A}, V:{TP=A, CN=B}}, ...Nk = {P:{TP=A}, V:{TP=A, CN=B}} - 所有節點都會呈現憑證 A，所有節點都將接受憑證 A (TP) 或 B (CN)

此時，我們可以繼續使用後續的升級來變更呈現規則：

  • 完成升級網域 0 時：N0 = {P:{CN=B}, V:{TP=A, CN=B}}, ...Nk = {P:{TP=A}, V:{TP=A, CN=B}} - UD0 中的節點會呈現 CN 找到的憑證 A，並接受具有指紋 A 或一般名稱 B 的憑證；所有其他節點都會呈現並只接受指紋所選取的憑證 A
  • 完成最後一個升級網域時：N0 = {P:{CN=B}, V:{TP=A, CN=B}}, ...Nk = {P:{CN=B}, V:{TP=A, CN=B}} - 所有節點都會呈現 CN 找到的憑證 B，所有節點都將接受憑證 A (TP) 或 B (CN)

完成階段2也會將叢集的轉換標示為一般以名稱為基礎的憑證;您可以在後續的叢集升級中移除以指紋為基礎的驗證宣告。

注意

在 Azure Service Fabric 叢集中，以上呈現的工作流程是由 Service Fabric 資源提供者協調；叢集擁有者仍負責根據指出的規則 (呈現或驗證)，將憑證佈建至叢集，並建議您在多個步驟中執行變更。

在另一篇文章中，我們將討論在 Service Fabric 叢集中管理和佈建憑證的主題。

疑難排解和常見問題

儘管在 Service Fabric 叢集中偵錯與驗證相關的問題並不容易，但我們希望下列提示和秘訣可以提供協助。 開始調查的最簡單方式是檢查叢集節點上的 Service Fabric 事件記錄 - 不一定只是顯示徵兆的事件記錄，還有已啟動但無法連線到其中一個相鄰節點的節點。 在 Windows 上，重要性的事件通常會分別記錄在 Applications and Services Logs\Microsoft-ServiceFabric\Admin' 或 'Operational' 通道底下。 有時候，啟用 CAPI2 記錄可能有助於擷取其他有關憑證驗證、CRL/CTL 擷取等的詳細資料。(記得在完成重現之後將其停用，它可能非常冗長。)

在發生驗證問題的叢集中，資訊清單本身的一般徵兆如下：

  • 節點已關閉/迴圈中
  • 連線嘗試遭到拒絕
  • 連線嘗試逾時

每個徵兆都可能因為不同的問題而造成，而且相同的根本原因可能會顯示不同的表徵；因此，我們只會列出一般問題的小型範例，以及修正這些問題的建議。

  • 節點可以交換訊息但無法連線。 連線嘗試終止的可能原因是「憑證不符」錯誤 - Service Fabric 至 Service Fabric 連線的其中一方正在呈現憑證，而該憑證無法通過接收者的驗證規則。 可能伴隨下列其中一個錯誤：

    0x80071c44	-2147017660	FABRIC_E_SERVER_AUTHENTICATION_FAILED

    若要進一步診斷/調查：在嘗試連線的每個節點上，判斷正在呈現的憑證；檢查憑證，然後嘗試並模擬驗證規則 (檢查指紋或一般名稱是否相等、檢查簽發者指紋 (如果已指定))。

    另一個常見的伴隨錯誤碼可能是：

    0x800b0109	-2146762487	CERT_E_UNTRUSTEDROOT

    在此情況下，憑證是由一般名稱所宣告，且下列其中一項適用：

    • 未鎖定簽發者且不信任根憑證，或
    • 已鎖定簽發者，但宣告未包含此憑證的直接簽發者指紋

  • 節點已啟動，但無法連線到其他節點；其他節點未收到來自失敗節點的輸入流量。 在此情況下，可能無法在本機節點上載入憑證。 請尋找下列錯誤：

    • 找不到憑證 - 請確定呈現規則中宣告的憑證可由 LocalMachine\My (或如指定般) 憑證存放區的內容加以解析。 可能的失敗原因包括：

      • 指紋宣告中有無效字元
      • 未安裝憑證
      • 憑證過期
      • 一般名稱宣告包含前置詞 'CN='
      • 宣告指定萬用字元，而且沒有確切的相符項存在於憑證存放區中 (宣告：CN=*.mydomain.com，實際憑證：CN=server.mydomain.com)

    • 未知認證 - 表示對應至憑證的遺漏私密金鑰，通常伴隨錯誤碼：

      0x8009030d	-2146893043	SEC_E_UNKNOWN_CREDENTIALS
0x8009030e	-2146893042	SEC_E_NO_CREDENTIALS

      若要補救，請檢查私密金鑰是否存在；驗證 SFAdmins 是否已獲授與私密金鑰的「讀取|執行」存取權。

    • 提供者類型不對 - 表示密碼編譯新世代 (CNG) 憑證 (「Microsoft 軟體金鑰儲存提供者」)：此時，Service Fabric 只支援 CAPI1 憑證。 通常伴隨錯誤碼：

      0x80090014	-2146893804	NTE_BAD_PROV_TYPE

      若要補救，請使用 CAPI1 (例如「Microsoft Enhanced RSA 和 AES 密碼編譯提供者」) 提供者重新建立叢集憑證。 如需密碼編譯提供者的其他詳細資料，請參閱了解密碼編譯提供者