Převod certifikátů clusteru z deklarací založených na kryptografickém otisku na běžné názvy

Článek
05/11/2023

Podpis certifikátu (běžně označovaný jako kryptografický otisk) je jedinečný. Certifikát clusteru deklarovaný kryptografickým otiskem odkazuje na konkrétní instanci certifikátu. Díky této specifičnosti je výměna certifikátů a správa obecně obtížná a explicitní. Každá změna vyžaduje orchestraci upgradů clusteru a základních výpočetních hostitelů.

Převod deklarací certifikátů clusteru Azure Service Fabric z kryptografických otisků na deklarace založené na běžném názvu subjektu certifikátu (CN) výrazně zjednodušuje správu. Zejména vrácení certifikátu už nevyžaduje upgrade clusteru. Tento článek popisuje, jak převést existující cluster na deklarace založené na CN bez výpadků.

Poznámka

K interakci s Azure doporučujeme použít modul Azure Az PowerShell. Začněte tím, že si projdete téma Instalace Azure PowerShellu. Informace o tom, jak migrovat na modul Az PowerShell, najdete v tématu Migrace Azure PowerShellu z AzureRM na Az.

Přechod na certifikáty podepsané certifikační autoritou

Zabezpečení clusteru, jehož certifikát je deklarován kryptografickým otiskem, spočívá na tom, že je nemožné nebo výpočetně neproveditelné vytvořit certifikát se stejným podpisem jako jiný. V tomto případě je původ certifikátu méně důležitý, takže certifikáty podepsané svým držitelem jsou adekvátní.

Naproti tomu zabezpečení clusteru, jehož certifikáty jsou deklarovány CN, pochází z implicitního vztahu důvěryhodnosti vlastníka clusteru ve svém poskytovateli certifikátů. Zprostředkovatel je služba infrastruktury veřejných klíčů (PKI), která certifikát vydala. Důvěryhodnost je mimo jiné založena na certifikačních postupech infrastruktury veřejných klíčů, na tom, jestli je jejich provozní zabezpečení auditováno a schvalováno dalšími důvěryhodnými stranami atd.

Vlastník clusteru musí mít také podrobné znalosti o tom, které certifikační autority certifikáty vydávají, protože se jedná o základní aspekt ověřování certifikátů podle subjektu. To také znamená, že certifikáty podepsané svým držitelem jsou pro tento účel zcela nevhodné. Certifikát s daným předmětem může vygenerovat doslova kdokoli.

Certifikát deklarovaný cn se obvykle považuje za platný, pokud:

Jeho řetěz lze úspěšně sestavit.
Předmět má očekávaný prvek CN.
Jeho vystavitel (okamžitě nebo vyšší v řetězci) je důvěryhodný agentem provádějícím ověření.

Service Fabric podporuje deklarování certifikátů cn dvěma způsoby:

S implicitními vystaviteli, což znamená, že řetěz musí končit kotvou důvěryhodnosti.
S vystaviteli deklarovanými kryptografickým otiskem, který se označuje jako připnutí vystavitele.

Další informace najdete v tématu Deklarace ověřování certifikátů založených na běžných názvech.

Pokud chcete převést cluster pomocí certifikátu podepsaného svým držitelem deklarovaného kryptografickým otiskem na CN, musí být cílový certifikát podepsaný certifikační autoritou nejprve zaveden do clusteru kryptografickým otiskem. Teprve pak je možný převod z kryptografického otisku na CN.

Pro účely testování může cn deklarovat certifikát podepsaný svým držitelem, ale pouze v případě, že vystavitel je připnutý k vlastnímu kryptografickému otisku. Z hlediska zabezpečení je tato akce téměř ekvivalentní deklarování stejného certifikátu kryptografickým otiskem. Úspěšný převod tohoto typu nezaručuje úspěšný převod z kryptografického otisku na CN s certifikátem podepsaným certifikační autoritou. Doporučujeme otestovat převod pomocí správného certifikátu podepsaného certifikační autoritou. Pro toto testování existují bezplatné možnosti.

Nahrajte certifikát a nainstalujte ho do škálovací sady.

Doporučený mechanismus pro získání a zřizování certifikátů v Azure zahrnuje azure Key Vault a její nástroje. Certifikát odpovídající deklaraci certifikátu clusteru musí být zřízený pro každý uzel škálovacích sad virtuálních počítačů, které tvoří váš cluster. Další informace najdete v tématu Tajné kódy ve škálovacích sadách virtuálních počítačů.

Před provedením změn v deklaraci certifikátů clusteru je důležité nainstalovat na virtuální počítače všech typů uzlů clusteru aktuální i cílový certifikát clusteru. Cesta od vystavení certifikátu ke zřízení do uzlu Service Fabric je podrobně popsána v tématu Cesta k certifikátu.

Uvedení clusteru do optimálního počátečního stavu

Převod deklarace certifikátu z dopadu založených na kryptografickém otisku na cn:

Jak každý uzel v clusteru najde a zobrazí své přihlašovací údaje jiným uzlům.
Způsob, jakým každý uzel ověřuje přihlašovací údaje svého protějšku při navázání zabezpečeného připojení

Než budete pokračovat, projděte si pravidla prezentace a ověření pro obě konfigurace . Nejdůležitějším aspektem při provádění převodu kryptografického otisku na CN je to, že upgradované a dosud neupgradované uzly (tj. uzly patřící do různých upgradovaných domén) musí být schopny kdykoli během upgradu provést úspěšné vzájemné ověřování. Doporučeným způsobem, jak tohoto chování dosáhnout, je deklarovat cílový nebo cílový certifikát kryptografickým otiskem při počátečním upgradu. Pak dokončete přechod na CN v následujícím. Pokud je cluster již v doporučeném počátečním stavu, můžete tuto část přeskočit.

Existuje několik platných počátečních stavů pro převod. Invariantní je, že cluster již používá cílový certifikát (deklarovaný kryptografickým otiskem) na začátku upgradu na CN. V tomto článku uvažujeme GoalCerto , OldCert1a OldCert2 .

Platné počáteční stavy

Thumbprint: GoalCert, ThumbprintSecondary: None
Thumbprint: GoalCert, ThumbprintSecondary: OldCert1, kde GoalCert má pozdější NotBefore datum než datum OldCert1
Thumbprint: OldCert1, ThumbprintSecondary: GoalCert, kde GoalCert má pozdější NotBefore datum než datum OldCert1

Poznámka

Před verzí 7.2.445 (7.2 CU4) vybral Service Fabric certifikát s nejvyšší platností (certifikát s nejnovější vlastností NotAfter), takže výše uvedené počáteční stavy před verzí 7.2 CU4 vyžadují, aby měl GoalCert pozdější NotAfter datum než OldCert1

Pokud váš cluster není v jednom z platných stavů, které jsme popsali dříve, přečtěte si informace o dosažení tohoto stavu v části na konci tohoto článku.

Vyberte požadované schéma ověřování certifikátů založených na CN.

Jak je popsáno výše, Service Fabric podporuje deklarování certifikátů pomocí CN s implicitním vztahem důvěryhodnosti nebo explicitním připnutím kryptografických otisků vystavitele. Další informace najdete v tématu Deklarace ověřování certifikátů založených na běžných názvech.

Ujistěte se, že dobře rozumíte rozdílům a důsledkům výběru obou mechanismů. Syntakticky je tento rozdíl nebo volba určena hodnotou parametru certificateIssuerThumbprintList . Prázdné znamená, že se spoléháte na důvěryhodnou kořenovou certifikační autoritu (kotvu důvěryhodnosti), zatímco sada kryptografických otisků omezuje povolené přímé vystavitele certifikátů clusteru.

Poznámka

Pole certificateIssuerThumbprint umožňuje zadat očekávané přímé vystavitele certifikátů deklarovaných subjektem CN. Přijatelné hodnoty jsou jeden nebo více kryptografických otisků SHA1 oddělených čárkami. Tato akce posílí ověření certifikátu.

Pokud nejsou zadáni žádní vystaviteři nebo je seznam prázdný, certifikát se přijme k ověření, pokud bude možné sestavit jeho řetěz. Certifikát pak skončí v kořenovém adresáři, kterému validátor důvěřuje. Pokud je zadán jeden nebo více kryptografických otisků vystavitele, certifikát se přijme, pokud kryptografický otisk jeho přímého vystavitele extrahovaný z řetězu odpovídá některé z hodnot zadaných v tomto poli. Certifikát se přijme bez ohledu na to, jestli je kořenový adresář důvěryhodný nebo ne.

Infrastruktura veřejných klíčů může k podepisování certifikátů s daným subjektem používat různé certifikační autority (označované také jako vystavitelé). Z tohoto důvodu je důležité zadat všechny očekávané kryptografické otisky vystavitele pro daný předmět. Jinými slovy, prodloužení platnosti certifikátu není zaručeno, že bude podepsáno stejným vystavitelem jako obnovovací certifikát.

Určení vystavitele se považuje za osvědčený postup. Vynechání vystavitele bude nadále fungovat pro zřetězování certifikátů s důvěryhodným kořenem, ale toto chování má omezení a v blízké budoucnosti může být vyřazeno. Clustery nasazené v Azure, zabezpečené pomocí certifikátů X509 vydaných privátní infrastrukturou PKI a deklarované subjektem, nemusí být možné ověřit service Fabric (pro komunikaci mezi clustery a službami). Ověření vyžaduje, aby zásady certifikátů infrastruktury veřejných klíčů byly zjistitelné, dostupné a přístupné.

Aktualizace šablony Azure Resource Manager clusteru a nasazení

Spravujte clustery Service Fabric pomocí šablon Azure Resource Manager (ARM). Alternativou, která také používá artefakty JSON, je Azure Resource Explorer (Preview). V Azure Portal momentálně není k dispozici ekvivalentní prostředí.

Pokud původní šablona odpovídající existujícímu clusteru není k dispozici, můžete v Azure Portal získat ekvivalentní šablonu. Přejděte do skupiny prostředků, která obsahuje cluster, a v nabídce Automatizace na levé straně vyberte Exportovat šablonu. Pak vyberte požadované prostředky. Minimálně by se měla exportovat škálovací sada virtuálních počítačů a prostředky clusteru. Vygenerovanou šablonu je také možné stáhnout. Tato šablona může vyžadovat změny, aby byla plně nasaditelná. Šablona také nemusí přesně odpovídat původní šabloně. Je to odraz aktuálního stavu prostředku clusteru.

Potřebné změny jsou následující:

Aktualizuje se definice rozšíření uzlu Service Fabric (v rámci prostředku virtuálního počítače). Pokud cluster definuje více typů uzlů, budete muset aktualizovat definici každé odpovídající škálovací sady virtuálních počítačů.
Aktualizuje se definice prostředku clusteru.

Podrobné příklady najdete tady.

Aktualizace prostředků škálovací sady virtuálních počítačů

"virtualMachineProfile": {
        "extensionProfile": {
            "extensions": [
                {
                    "name": "[concat('ServiceFabricNodeVmExt','_vmNodeType0Name')]",
                    "properties": {
                        "type": "ServiceFabricNode",
                        "autoUpgradeMinorVersion": true,
                        "protectedSettings": {
                            ...
                        },
                        "publisher": "Microsoft.Azure.ServiceFabric",
                        "settings": {
                            ...
                            "certificate": {
                                "thumbprint": "[parameters('certificateThumbprint')]",
                                "x509StoreName": "[parameters('certificateStoreValue')]"
                            }
                        },
                        ...
                    }
                },

Do:

"virtualMachineProfile": {
        "extensionProfile": {
            "extensions": [
                {
                    "name": "[concat('ServiceFabricNodeVmExt','_vmNodeType0Name')]",
                    "properties": {
                        "type": "ServiceFabricNode",
                        "autoUpgradeMinorVersion": true,
                        "protectedSettings": {
                            ...
                        },
                        "publisher": "Microsoft.Azure.ServiceFabric",
                        "settings": {
                            ...
                            "certificate": {
                                "commonNames": [
                                    "[parameters('certificateCommonName')]"
                                ],
                                "x509StoreName": "[parameters('certificateStoreValue')]"
                            }
                        },
                        ...
                    }
                },

Aktualizace prostředku clusteru

V prostředku Microsoft.ServiceFabric/clusters přidejte vlastnost certificateCommonNames s nastavením commonNames a vlastnost certifikátu úplně odeberte (všechna její nastavení).

    {
        "apiVersion": "2018-02-01",
        "type": "Microsoft.ServiceFabric/clusters",
        "name": "[parameters('clusterName')]",
        "location": "[parameters('clusterLocation')]",
        "dependsOn": [
            ...
        ],
        "properties": {
            "addonFeatures": [
                ...
            ],
            "certificate": {
              "thumbprint": "[parameters('certificateThumbprint')]",
              "x509StoreName": "[parameters('certificateStoreValue')]"
            },
        ...

Do:

    {
        "apiVersion": "2018-02-01",
        "type": "Microsoft.ServiceFabric/clusters",
        "name": "[parameters('clusterName')]",
        "location": "[parameters('clusterLocation')]",
        "dependsOn": [
            ...
        ],
        "properties": {
            "addonFeatures": [
                ...
            ],
            "certificateCommonNames": {
                "commonNames": [
                    {
                        "certificateCommonName": "[parameters('certificateCommonName')]",
                        "certificateIssuerThumbprint": "[parameters('certificateIssuerThumbprintList')]"
                    }
                ],
                "x509StoreName": "[parameters('certificateStoreValue')]"
            },
        ...

Další informace najdete v tématu Nasazení clusteru Service Fabric, který místo kryptografického otisku používá běžný název certifikátu.

Nasazení aktualizované šablony

Po provedení změn znovu nasaďte aktualizovanou šablonu.

$groupname = "sfclustertutorialgroup"

New-AzResourceGroupDeployment -ResourceGroupName $groupname -Verbose `
    -TemplateParameterFile "C:\temp\cluster\parameters.json" -TemplateFile "C:\temp\cluster\template.json"

Dosažení platného počátečního stavu pro převod deklarací certifikátů clusteru na certifikáty založené na CN

Počáteční stav	Upgrade 1	Upgrade 2
`Thumbprint: OldCert1, ThumbprintSecondary: None` a `GoalCert` má pozdější `NotBefore` datum než `OldCert1`	`Thumbprint: OldCert1, ThumbprintSecondary: GoalCert`	-
`Thumbprint: OldCert1, ThumbprintSecondary: None` a `OldCert1` má pozdější `NotBefore` datum než `GoalCert`	`Thumbprint: GoalCert, ThumbprintSecondary: OldCert1`	`Thumbprint: GoalCert, ThumbprintSecondary: None`
`Thumbprint: OldCert1, ThumbprintSecondary: GoalCert`, kde `OldCert1` má pozdější `NotBefore` datum než `GoalCert`	Upgradovat na `Thumbprint: GoalCert, ThumbprintSecondary: None`	-
`Thumbprint: GoalCert, ThumbprintSecondary: OldCert1`, kde `OldCert1` má pozdější `NotBefore` datum než `GoalCert`	Upgradovat na `Thumbprint: GoalCert, ThumbprintSecondary: None`	-
`Thumbprint: OldCert1, ThumbprintSecondary: OldCert2`	Odebráním některého z nebo `OldCert1OldCert2` se dostanete do stavu `Thumbprint: OldCertx, ThumbprintSecondary: None`	Pokračovat od nového počátečního stavu

Poznámka

V případě clusteru ve verzi starší než 7.2.445 (7.2 CU4) nahraďte NotBefore za NotAfter ve výše uvedených stavech.

Pokyny k provedení některého z těchto upgradů najdete v tématu Správa certifikátů v clusteru Azure Service Fabric.

Další kroky

Přečtěte si o zabezpečení clusteru.
Zjistěte, jak převést certifikát clusteru podle běžného názvu.
Zjistěte, jak nakonfigurovat cluster pro automatický bezdotykový automatický zápis.

Převod certifikátů clusteru z deklarací založených na kryptografickém otisku na běžné názvy

Přechod na certifikáty podepsané certifikační autoritou

Nahrajte certifikát a nainstalujte ho do škálovací sady.

Uvedení clusteru do optimálního počátečního stavu

Platné počáteční stavy

Vyberte požadované schéma ověřování certifikátů založených na CN.

Aktualizace šablony Azure Resource Manager clusteru a nasazení

Aktualizace prostředků škálovací sady virtuálních počítačů

Aktualizace prostředku clusteru

Nasazení aktualizované šablony

Dosažení platného počátečního stavu pro převod deklarací certifikátů clusteru na certifikáty založené na CN

Další kroky

Další materiály