Konvertera klustercertifikat från tumavtrycksbaserade deklarationer till vanliga namn

  • Artikel

Signaturen för ett certifikat (kallas vanligtvis tumavtryck) är unik. Ett klustercertifikat som deklareras med tumavtryck refererar till en specifik instans av ett certifikat. Den här specificiteten gör det svårt och explicit att distribuera certifikat och hantera dem i allmänhet. Varje ändring kräver orkestrering av uppgraderingar av klustret och de underliggande datorvärdarna.

Om du konverterar ett Azure Service Fabric-klusters certifikatdeklarationer från tumavtrycksbaserat till deklarationer baserat på certifikatets ämnesnamn (CN) förenklas hanteringen avsevärt. I synnerhet kräver rullning av ett certifikat inte längre en klusteruppgradering. Den här artikeln beskriver hur du konverterar ett befintligt kluster till CN-baserade deklarationer utan driftstopp.

Anteckning

Vi rekommenderar att du använder Azure Az PowerShell-modulen för att interagera med Azure. Se Installera Azure PowerShell för att komma igång. Information om hur du migrerar till Az PowerShell-modulen finns i artikeln om att migrera Azure PowerShell från AzureRM till Az.

Flytta till certifikatutfärdarsignerade certifikat

Säkerheten för ett kluster vars certifikat deklareras med tumavtryck vilar på det faktum att det är omöjligt, eller beräkningsmässigt omöjligt, att skapa ett certifikat med samma signatur som ett annat. I det här fallet är certifikatets ursprung mindre viktigt, så självsignerade certifikat är tillräckliga.

Däremot flödar säkerheten för ett kluster vars certifikat deklareras av CN från det implicita förtroende som klusterägaren har i certifikatprovidern. Providern är PKI-tjänsten (Public Key Infrastructure) som utfärdade certifikatet. Förtroendet baseras bland annat på PKI:s certifieringsmetoder, om deras driftsäkerhet granskas och godkänns av ännu andra betrodda parter och så vidare.

Klusterägaren måste också ha detaljerad kunskap om vilka certifikatutfärdare som utfärdar sina certifikat, eftersom detta är en grundläggande aspekt av validering av certifikat per ämne. Detta innebär också att självsignerade certifikat är helt olämpliga för detta ändamål. Bokstavligen kan vem som helst generera ett certifikat med ett visst ämne.

Ett certifikat som deklareras av CN anses vanligtvis vara giltigt om:

  • Dess kedja kan byggas korrekt.
  • Ämnet har det förväntade CN-elementet.
  • Utfärdaren (omedelbart eller högre i kedjan) är betrodd av agenten som utför verifieringen.

Service Fabric har stöd för att deklarera certifikat av CN på två sätt:

  • Med implicita utfärdare, vilket innebär att kedjan måste sluta i ett förtroendeankare.
  • Med utfärdare som deklarerats med tumavtryck, vilket kallas utfärdarens fästning.

Mer information finns i Common-name-based certificate validation declarations (Vanliga namnbaserade certifikatvalideringsdeklarationer).

Om du vill konvertera ett kluster med hjälp av ett självsignerat certifikat som deklarerats med tumavtryck till CN, måste målet, CA-signerat certifikat först introduceras i klustret med tumavtryck. Först då är konverteringen från tumavtryck till CN möjlig.

I testsyfte kan ett självsignerat certifikat deklareras av CN, men bara om utfärdaren fästs på sitt eget tumavtryck. Ur säkerhetssynpunkt är den här åtgärden nästan likvärdig med att deklarera samma certifikat med tumavtryck. En lyckad konvertering av den här typen garanterar inte en lyckad konvertering från tumavtryck till CN med ett CA-signerat certifikat. Vi rekommenderar att du testar konverteringen med ett korrekt CA-signerat certifikat. Det finns kostnadsfria alternativ för den här testningen.

Ladda upp certifikatet och installera det i skalningsuppsättningen

I Azure omfattar den rekommenderade mekanismen för att hämta och etablera certifikat Azure Key Vault och dess verktyg. Ett certifikat som matchar klustercertifikatdeklarationen måste etableras till varje nod i vm-skalningsuppsättningarna som utgör klustret. Mer information finns i Hemligheter på VM-skalningsuppsättningar.

Det är viktigt att installera både aktuella och målklustercertifikat på de virtuella datorerna för varje nodtyp i klustret innan du gör ändringar i klustrets certifikatdeklarationer. Resan från certifikatutfärdande till etablering till en Service Fabric-nod beskrivs ingående i Resan för ett certifikat.

Ge klustret ett optimalt starttillstånd

Konvertera en certifikatdeklaration från tumavtrycksbaserad till CN-baserad påverkan:

  • Hur varje nod i klustret hittar och visar sina autentiseringsuppgifter för andra noder.
  • Hur varje nod verifierar autentiseringsuppgifterna för sin motsvarighet när en säker anslutning upprättas.

Granska presentations- och valideringsreglerna för båda konfigurationerna innan du fortsätter. Det viktigaste när du utför en tumavtryck-till-CN-konvertering är att uppgraderade och ännu inte uppgraderade noder (dvs. noder som tillhör olika uppgraderingsdomäner) måste kunna utföra lyckad ömsesidig autentisering när som helst under uppgraderingen. Det rekommenderade sättet att uppnå det här beteendet är att deklarera mål- eller målcertifikatet med tumavtryck i en första uppgradering. Slutför sedan övergången till CN i en efterföljande. Om klustret redan är i ett rekommenderat starttillstånd kan du hoppa över det här avsnittet.

Det finns flera giltiga starttillstånd för en konvertering. Invarianten är att klustret redan använder målcertifikatet (deklarerat med tumavtryck) i början av uppgraderingen till CN. Vi överväger GoalCert, OldCert1och OldCert2 i den här artikeln.

Giltiga starttillstånd

  • Thumbprint: GoalCert, ThumbprintSecondary: None
  • Thumbprint: GoalCert, ThumbprintSecondary: OldCert1, om GoalCert har ett senare NotBefore datum än det för OldCert1
  • Thumbprint: OldCert1, ThumbprintSecondary: GoalCert, om GoalCert har ett senare NotBefore datum än det för OldCert1

Anteckning

Före version 7.2.445 (7.2 CU4) valde Service Fabric det längsta utgångna certifikatet (certifikatet med den längsta egenskapen NotAfter), så ovanstående starttillstånd före 7.2 CU4 kräver att GoalCert har ett senare NotAfter datum än OldCert1

Om klustret inte är i något av de giltiga tillstånd som beskrivits tidigare kan du läsa information om hur du uppnår det tillståndet i avsnittet i slutet av den här artikeln.

Välj önskat CN-baserat certifikatverifieringsschema

Som tidigare beskrivits har Service Fabric stöd för att deklarera certifikat av CN med ett implicit förtroendeankare eller genom att uttryckligen fästa utfärdarens tumavtryck. Mer information finns i Common-name-based certificate validation declarations (Vanliga namnbaserade certifikatvalideringsdeklarationer).

Se till att du har en god förståelse för skillnaderna och konsekvenserna av att välja någon av mekanismerna. Syntaktiskt bestäms den här skillnaden eller valet av parameterns certificateIssuerThumbprintList värde. Tom innebär att förlita sig på en betrodd rotcertifikatutfärdare (förtroendeankare), medan en uppsättning tumavtryck begränsar tillåtna direkta utfärdare av klustercertifikat.

Anteckning

Med certificateIssuerThumbprint fältet kan du ange förväntade direkta utfärdare av certifikat som deklarerats av ämnes-CN. Godtagbara värden är ett eller flera kommaavgränsade SHA1-tumavtryck. Den här åtgärden stärker certifikatverifieringen.

Om inga utfärdare har angetts eller om listan är tom godkänns certifikatet för autentisering om dess kedja kan skapas. Certifikatet hamnar sedan i en rot som är betrodd av validatorn. Om ett eller flera tumavtryck för utfärdare anges godkänns certifikatet om tumavtrycket för dess direktutfärdare, som extraherats från kedjan, matchar något av de värden som anges i det här fältet. Certifikatet godkänns oavsett om roten är betrodd eller inte.

En PKI kan använda olika certifikatutfärdare (även kallade utfärdare) för att signera certifikat med ett visst ämne. Därför är det viktigt att ange alla förväntade tumavtryck för utfärdaren för ämnet. Med andra ord är förnyelsen av ett certifikat inte garanterad att signeras av samma utfärdare som certifikatet som förnyas.

Att ange utfärdaren anses vara bästa praxis. Om utfärdaren utelämnas fortsätter det att fungera för certifikat som kedjar ihop till en betrodd rot, men det här beteendet har begränsningar och kan fasas ut inom en snar framtid. Kluster som distribueras i Azure, skyddas med X509-certifikat som utfärdats av en privat PKI och deklarerats av ämne kanske inte kan verifieras av Service Fabric (för kommunikation mellan kluster och tjänster). Validering kräver att PKI:s certifikatprincip är identifierbar, tillgänglig och tillgänglig.

Uppdatera klustrets Azure Resource Manager-mall och distribuera

Hantera dina Service Fabric-kluster med Arm-mallar (Azure Resource Manager). Ett alternativ, som också använder JSON-artefakter, är Azure Resource Explorer (förhandsversion). En motsvarande upplevelse är inte tillgänglig i Azure Portal just nu.

Om den ursprungliga mallen som motsvarar ett befintligt kluster inte är tillgänglig kan en motsvarande mall hämtas i Azure Portal. Gå till den resursgrupp som innehåller klustret och välj Exportera mall på Automation-menyn till vänster. Välj sedan de resurser som du vill använda. Minst ska vm-skalningsuppsättningen och klusterresurserna exporteras. Den genererade mallen kan också laddas ned. Den här mallen kan kräva ändringar innan den kan distribueras helt. Mallen kanske inte heller matchar den ursprungliga exakt. Det är en återspegling av klusterresursens aktuella tillstånd.

De nödvändiga ändringarna är följande:

  • Uppdatera definitionen av Service Fabric-nodtillägget (under resursen för den virtuella datorn). Om klustret definierar flera nodtyper måste du uppdatera definitionen för varje motsvarande VM-skalningsuppsättning.
  • Uppdatera klusterresursdefinitionen.

Detaljerade exempel finns här.

Uppdatera vm-skalningsuppsättningsresurserna

Från:

"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')]"
                            }
                        },
                        ...
                    }
                },

Till:

"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')]"
                            }
                        },
                        ...
                    }
                },

Uppdatera klusterresursen

I resursen Microsoft.ServiceFabric/clusters lägger du till en certificateCommonNames-egenskap med en commonNames-inställning och tar bort certifikategenskapen helt och hållet (alla dess inställningar).

Från:

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

Till:

    {
        "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')]"
            },
        ...

Mer information finns i Distribuera ett Service Fabric-kluster som använder certifikatets eget namn i stället för tumavtrycket.

Distribuera den uppdaterade mallen

Distribuera om den uppdaterade mallen när du har genomfört ändringarna.

$groupname = "sfclustertutorialgroup"

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

Uppnå ett giltigt starttillstånd för konvertering av ett kluster till CN-baserade certifikatdeklarationer

Starttillstånd Uppgradera 1 Uppgradera 2
Thumbprint: OldCert1, ThumbprintSecondary: None och GoalCert har ett senare NotBefore datum än OldCert1 Thumbprint: OldCert1, ThumbprintSecondary: GoalCert -
Thumbprint: OldCert1, ThumbprintSecondary: None och OldCert1 har ett senare NotBefore datum än GoalCert Thumbprint: GoalCert, ThumbprintSecondary: OldCert1 Thumbprint: GoalCert, ThumbprintSecondary: None
Thumbprint: OldCert1, ThumbprintSecondary: GoalCert, där OldCert1 har ett senare NotBefore datum än GoalCert Uppgradera till Thumbprint: GoalCert, ThumbprintSecondary: None -
Thumbprint: GoalCert, ThumbprintSecondary: OldCert1, där OldCert1 har ett senare NotBefore datum än GoalCert Uppgradera till Thumbprint: GoalCert, ThumbprintSecondary: None -
Thumbprint: OldCert1, ThumbprintSecondary: OldCert2 Ta bort en av OldCert1 eller OldCert2 för att komma till tillstånd Thumbprint: OldCertx, ThumbprintSecondary: None Fortsätt från det nya starttillståndet

Anteckning

För ett kluster i en version före version 7.2.445 (7.2 CU4) ersätter NotBefore du med NotAfter i ovanstående tillstånd.

Anvisningar om hur du utför någon av dessa uppgraderingar finns i Hantera certifikat i ett Azure Service Fabric-kluster.

Nästa steg