Dela via

Konvertera klustercertifikat från tumavtrycksbaserade deklarationer till vanliga namn

  • Artikel

Signaturen för ett certifikat (kallas ofta 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ävs inte längre en klusteruppgradering för att kunna rulla över ett certifikat. Den här artikeln beskriver hur du konverterar ett befintligt kluster till CN-baserade deklarationer utan driftstopp.

Kommentar

Vi rekommenderar att du använder Azure Az PowerShell-modulen för att interagera med Azure. Information om hur du kommer igång finns i Installera Azure PowerShell. 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 en annan. I det här fallet är certifikatets ursprung mindre viktigt, så självsignerade certifikat är tillräckliga.

Säkerheten för ett kluster vars certifikat deklareras av CN flödar däremot 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örtroende 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 information 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 deklarerats av CN anses vanligtvis vara giltigt om:

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

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 att utfärdaren fäster.

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

Om du vill konvertera ett kluster med hjälp av ett självsignerat certifikat som deklarerats med tumavtryck till CN, måste det ca-signerade certifikatet 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 endast 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 presenterar 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. Det invarianta ä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, där GoalCert har ett senare NotBefore datum än det för OldCert1
  • Thumbprint: OldCert1, ThumbprintSecondary: GoalCert, där GoalCert har ett senare NotBefore datum än det för OldCert1

Kommentar

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 finns i något av de giltiga tillstånd som beskrivits tidigare kan du läsa mer 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 med att uttryckligen fästa utfärdarens tumavtryck. Mer information finns i Common-name-based certificate validation declarations (Vanliga namnbaserade certifikatverifieringsdeklarationer).

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 de tillåtna direkta utfärdarna av klustercertifikat.

Kommentar

Med certificateIssuerThumbprint fältet kan du ange förväntade direkta utfärdare av certifikat som deklarerats av ämnes-CN. Acceptabla 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ärdaren anges godkänns certifikatet om tumavtrycket för dess direkta utfä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 du utelämnar utfärdaren 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, som 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änst). Validering kräver att PKI:s certifikatprincip kan identifieras, vara tillgänglig och tillgänglig.

Uppdatera klustrets Azure Resource Manager-mall och distribuera

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

Om den ursprungliga mallen som motsvarar ett befintligt kluster inte är tillgänglig kan du hämta en motsvarande mall i Azure-portalen. Gå till den resursgrupp som innehåller klustret och välj Exportera mall på Menyn Automation 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 fullt ut. Mallen kanske inte heller matchar den ursprungliga. 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 vanliga namn i stället för tumavtryck.

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 att konvertera 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åndet Thumbprint: OldCertx, ThumbprintSecondary: None Fortsätt från det nya starttillståndet

Kommentar

För ett kluster på en version före version 7.2.445 (7.2 CU4) ersätter du NotBefore 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