Sdílet prostřednictvím

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

  • Článek

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. Tato specifika činí převod certifikátů a správu obecně, obtížné a explicitní. Každá změna vyžaduje orchestraci upgradů clusteru a podkladových hostitelů výpočetních prostředků.

Převod deklarací certifikátů clusteru Azure Service Fabric z kryptografického otisku na deklarace založené na běžných názvech subjektu certifikátu (CN) výrazně zjednodušuje správu. Převzetí certifikátu už navíc 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:

Při práci s Azure doporučujeme používat modul Azure Az PowerShellu. Pokud chcete začít, přečtěte si 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á ve skutečnosti, že není možné nebo výpočetně nepůjde vytvořit certifikát se stejným podpisem jako jiný. V tomto případě je provenience 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 toky CN 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. Vztah důvěryhodnosti je mimo jiné založen na postupech certifikace infrastruktury veřejných klíčů, zda je jejich provozní zabezpečení auditováno a schváleno dalšími důvěryhodnými stranami atd.

Vlastník clusteru musí mít také podrobné znalosti o tom, které certifikační autority vydávají své certifikáty, 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é. Doslova každý může vygenerovat certifikát s daným předmětem.

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

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

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

  • U implicitních vystavitelů to znamená, že řetězec musí končit ukotveným vztahem důvěryhodnosti.
  • U vystavitelů deklarovaných 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é na běžných názvech.

Pokud chcete cluster převést 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. Pouze pak je možný převod z kryptografického otisku na CN.

Pro účely testování může být certifikát podepsaný svým držitelem deklarován cn, ale pouze v případě, že je vystavitel připnutý k vlastnímu kryptografickému otisku. Z hlediska zabezpečení je tato akce téměř ekvivalentní k 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 testovat převod se správným certifikátem podepsaným 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 jeho 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 aktuální i cílové certifikáty clusteru na virtuální počítače každého typu uzlu clusteru. Cesta od vystavení certifikátu ke zřízení na uzlu Service Fabric je podrobně popsána v cestě certifikátu.

Zajištění optimálního stavu spuštění clusteru

Převod deklarace certifikátu z kryptografického otisku na dopady založené na CN:

  • Jak každý uzel v clusteru najde a zobrazí jeho přihlašovací údaje jiným uzlům.
  • Jak každý uzel ověří přihlašovací údaje svého protějšku při navazování zabezpečeného připojení.

Než budete pokračovat, projděte si pravidla prezentace a ověření obou konfigurací. Nejdůležitějším aspektem při provádění převodu kryptografického otisku na CN je, že upgradované a neupgradované uzly (tj. uzly patřící do různých upgradovaných domén) musí být během upgradu schopny kdykoli 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 v 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 stavu spuštění, můžete tuto část přeskočit.

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

Platné počáteční stavy

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

Poznámka:

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

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

Výběr požadovaného schématu ověřování certifikátů založených na CN

Jak jsme popsali dříve, Service Fabric podporuje deklarování certifikátů podle CN s implicitním ukotvením 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é na běžných názvech.

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

Poznámka:

Toto certificateIssuerThumbprint pole umožňuje určit 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 posiluje ověření certifikátu.

Pokud nejsou zadáni žádní vystavitelé nebo je seznam prázdný, certifikát se přijme pro ověření, pokud je možné sestavit jeho řetěz. Certifikát pak skončí v kořenovém adresáři důvěryhodném validátorem. Pokud je zadaný 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 ho podepíše stejný vystavitel jako obnovovací certifikát.

Určení vystavitele se považuje za osvědčený postup. Vynechání vystavitele bude nadále fungovat pro řetězení certifikátů až do důvěryhodného kořenového adresáře, ale toto chování má omezení a může být v blízké budoucnosti ukončeno. Clustery nasazené v Azure zabezpečené pomocí certifikátů X509 vydaných privátní pkI a deklarované subjektem nemusí být možné ověřit službou Service Fabric (pro komunikaci mezi clustery). Ověření vyžaduje, aby zásady certifikátu PKI byly zjistitelné, dostupné a přístupné.

Aktualizace šablony Azure Resource Manageru a nasazení clusteru

Spravujte clustery Service Fabric pomocí šablon Azure Resource Manageru (ARM). Alternativou, která také používá artefakty JSON, je Azure Resource Explorer. V tuto chvíli není na webu Azure Portal k dispozici ekvivalentní prostředí.

Pokud původní šablona odpovídající existujícímu clusteru není dostupná, můžete na webu Azure Portal získat ekvivalentní šablonu. Přejděte do skupiny prostředků, která obsahuje cluster, a v nabídce Automation vlevo 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 si také můžete stáhnout. Tato šablona může vyžadovat změny, než bude plně nasaditelná. Šablona také nemusí přesně odpovídat původnímu. Je to odraz aktuálního stavu prostředku clusteru.

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

  • Aktualizace 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čů.
  • Aktualizace definice prostředku clusteru

Tady jsou uvedeny podrobné příklady.

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

Od:

"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 úplně odeberte vlastnost certifikátu (všechna její nastavení).

Od:

    {
        "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 clusteru na deklarace certifikátů 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 Upgrade na Thumbprint: GoalCert, ThumbprintSecondary: None -
Thumbprint: GoalCert, ThumbprintSecondary: OldCert1, kde OldCert1 má pozdější NotBefore datum než GoalCert Upgrade na Thumbprint: GoalCert, ThumbprintSecondary: None -
Thumbprint: OldCert1, ThumbprintSecondary: OldCert2 Odebrání nebo OldCert1 OldCert2 získání stavu Thumbprint: OldCertx, ThumbprintSecondary: None Pokračovat z nového počátečního stavu

Poznámka:

Pro cluster ve verzi starší než 7.2.445 (7.2 CU4) nahraďte NotBefore 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