Certificaten beheren in Service Fabric-clusters

In dit artikel worden de beheeraspecten van certificaten behandeld die worden gebruikt voor het beveiligen van communicatie in Azure Service Fabric-clusters. Het vormt een aanvulling op de inleiding tot Service Fabric-clusterbeveiliging en de uitleg over verificatie op basis van X.509-certificaten in Service Fabric.

Vereisten

Voordat u begint, moet u bekend zijn met fundamentele beveiligingsconcepten en de besturingselementen die Service Fabric beschikbaar maakt om de beveiliging van een cluster te configureren.

Vrijwaring

Dit artikel paren theoretische aspecten van certificaatbeheer met praktijkvoorbeelden die betrekking hebben op de specifieke kenmerken van services, technologieën, enzovoort. Omdat een groot deel van de doelgroep hier intern is, verwijst het artikel naar services, technologieën en producten die specifiek zijn voor Azure. Als bepaalde Microsoft-specifieke gegevens niet van toepassing zijn op u, kunt u vragen om uitleg of richtlijnen in de sectie opmerkingen aan het einde.

Certificaatbeheer definiëren

Zoals u in het aanvullende artikel X.509-verificatie op basis van certificaten in Service Fabric-clusters leert, is een certificaat een cryptografisch object dat in feite een asymmetrisch sleutelpaar verbindt met kenmerken die de entiteit beschrijven die het vertegenwoordigt.

Een certificaat is echter ook een bederfelijk object, omdat de levensduur eindig is en gevoelig is voor inbreuk. Onbedoelde openbaarmaking of een geslaagde exploit kan een certificaat nutteloos maken vanuit het oogpunt van beveiliging. Dit kenmerk impliceert dat certificaten regelmatig of in reactie op een beveiligingsincident moeten worden gewijzigd.

Een ander aspect van certificaatbeheer, en een volledig afzonderlijk onderwerp, is het beveiligen van persoonlijke sleutels of geheimen van certificaten die de identiteiten van de entiteiten beschermen die betrokken zijn bij het aanschaffen en inrichten van certificaten.

We beschrijven certificaatbeheer als de processen en procedures die worden gebruikt om certificaten te verkrijgen en veilig en veilig te transporteren naar waar ze nodig zijn.

Sommige beheerbewerkingen, zoals inschrijving, beleidsinstelling en autorisatiebeheer, vallen buiten het bereik van dit artikel. Andere bewerkingen, zoals inrichten, vernieuwen, opnieuw versleutelen of intrekken, zijn alleen incidenteel gerelateerd aan Service Fabric. Het artikel behandelt ze echter enigszins, omdat u begrijpt dat deze bewerkingen u kunnen helpen uw cluster goed te beveiligen.

Uw onmiddellijke doel is waarschijnlijk om certificaatbeheer zoveel mogelijk te automatiseren om een ononderbroken beschikbaarheid van het cluster te garanderen. Omdat het proces gebruikersvrij is, wilt u ook beveiligingsgaranties bieden. Met Service Fabric-clusters is dit doel haalbaar.

In de rest van het artikel wordt eerst certificaatbeheer gedeconstrueerd en later wordt het inschakelen van automatisch inschrijven besproken.

In het bijzonder worden de volgende onderwerpen behandeld:

• Veronderstellingen over de scheiding van toeschrijvingen tussen eigenaar en platform
• De lange pijplijn van certificaatuitgifte naar verbruik
• Certificaatrotatie: Waarom, hoe en wanneer
• Wat kan er mis gaan?

In het artikel worden deze onderwerpen niet behandeld:

• Domeinnamen beveiligen en beheren
• Inschrijven bij certificaten
• Autorisatiebesturingselementen instellen om certificaatuitgifte af te dwingen.

Raadpleeg de registratie-instantie (RA) van uw favoriete PKI-service (Public Key Infrastructure) voor informatie over deze onderwerpen. Als u een interne lezer van Microsoft bent, kunt u contact opnemen met Azure Security.

Rollen en entiteiten die betrokken zijn bij certificaatbeheer

De beveiligingsbenadering in een Service Fabric-cluster is een geval van 'de eigenaar van het cluster declareert dit, Service Fabric-runtime dwingt het af.' Dit betekent dat bijna geen van de certificaten, sleutels of andere referenties van identiteiten die deelnemen aan het functioneren van een cluster, afkomstig zijn van de service zelf. Ze worden allemaal gedeclareerd door de eigenaar van het cluster. De eigenaar van het cluster is ook verantwoordelijk voor het inrichten van de certificaten in het cluster, het vernieuwen ervan indien nodig en het garanderen van hun beveiliging op elk gewenst moment.

Meer specifiek moet de eigenaar van het cluster ervoor zorgen dat:

• Certificaten die zijn gedeclareerd in de sectie NodeType van het clustermanifest, vindt u op elk knooppunt van dat type, volgens de presentatieregels.
• Certificaten die zijn gedeclareerd als in het voorgaande opsommingsteken, worden geïnstalleerd met de bijbehorende persoonlijke sleutels.
• Certificaten die zijn gedeclareerd in de presentatieregels, moeten de validatieregels doorgeven.

Service Fabric gaat uit van de volgende verantwoordelijkheden:

• Certificaten zoeken die overeenkomen met de declaraties in de clusterdefinitie
• Toegang verlenen tot de bijbehorende persoonlijke sleutels aan door Service Fabric beheerde entiteiten op basis van behoefte
• Certificaten in strikte overeenstemming met de vastgestelde aanbevolen beveiligingsprocedures en de clusterdefinitie valideren
• Waarschuwingen genereren voor het verlopen van certificaten of fouten bij het uitvoeren van de basisstappen van certificaatvalidatie
• Valideren (in zekere mate) dat aan de certificaatgerelateerde aspecten van de clusterdefinitie wordt voldaan door de onderliggende configuratie van de hosts

Hier volgt dat de werklast voor certificaatbeheer (als actieve bewerkingen) uitsluitend op de eigenaar van het cluster valt. De volgende secties bieden een beter overzicht van elk van de beheerbewerkingen, met inbegrip van beschikbare mechanismen en hun impact op het cluster.

Het traject van een certificaat

Laten we snel een overzicht geven van de voortgang van een certificaat van uitgifte naar verbruik in de context van een Service Fabric-cluster:

1. Een domeineigenaar registreert zich bij de RA van een PKI van een domein of onderwerp dat ze willen koppelen aan verlenende certificaten. De certificaten vormen op hun beurt bewijs van eigendom van het domein of onderwerp.

2. De domeineigenaar wijst ook in de RA de identiteiten aan van geautoriseerde aanvragers, entiteiten die recht hebben op het aanvragen van de inschrijving van certificaten met het opgegeven domein of onderwerp.

3. Een geautoriseerde aanvrager registreert zich vervolgens bij een certificaat via een geheime beheerservice. In Azure is de service voor geheimbeheer van keuze Azure Key Vault, die veilig wordt opgeslagen en waarmee geheimen en certificaten kunnen worden opgehaald door geautoriseerde entiteiten. Key Vault vernieuwt en versleutelt het certificaat ook opnieuw zoals geconfigureerd in het bijbehorende certificaatbeleid. Key Vault gebruikt Microsoft Entra-id als id-provider.

4. Een geautoriseerde retriever of inrichtingsagent haalt het certificaat op uit de sleutelkluis, inclusief de persoonlijke sleutel, en installeert het op de computers waarop het cluster wordt gehost.

5. De Service Fabric-service (met verhoogde bevoegdheid op elk knooppunt) verleent toegang tot het certificaat aan de toegestane Service Fabric-entiteiten, die worden aangewezen door lokale groepen en worden gesplitst tussen ServiceFabric Beheer istrators en ServiceFabricAllowedUsers.

6. De Service Fabric-runtime opent en gebruikt het certificaat om federatie tot stand te brengen of om te verifiëren bij binnenkomende aanvragen van geautoriseerde clients.

7. De inrichtingsagent bewaakt het sleutelkluiscertificaat en activeert de inrichtingsstroom wanneer het verlenging detecteert. De eigenaar van het cluster werkt vervolgens de clusterdefinitie bij, indien nodig, om aan te geven dat er een intentie is om het certificaat over te rollen.

8. De inrichtingsagent of de clustereigenaar is ook verantwoordelijk voor het opschonen en verwijderen van ongebruikte certificaten.

Voor de doeleinden van dit artikel zijn de eerste twee stappen in de voorgaande reeks voornamelijk niet gerelateerd. De enige verbinding is dat de algemene naam van het onderwerp van het certificaat de DNS-naam is die in de clusterdefinitie wordt gedeclareerd.

Certificaatuitgifte en inrichtingsstroom worden geïllustreerd in de volgende diagrammen:

Voor certificaten die worden gedeclareerd met vingerafdruk

Voor certificaten die zijn gedeclareerd op basis van de algemene naam van het onderwerp

Certificaatinschrijving

Het onderwerp van certificaatinschrijving wordt uitgebreid besproken in de Key Vault-documentatie. Hier vindt u een overzicht voor continuïteit en eenvoudigere naslaginformatie.

Als u doorgaat met Azure als context en Key Vault als de geheime beheerservice gebruikt, moet een geautoriseerde certificaataangever ten minste machtigingen voor certificaatbeheer hebben voor de sleutelkluis, verleend door de eigenaar van de sleutelkluis. De aanvrager schrijft zich vervolgens als volgt in voor een certificaat:

• De aanvrager maakt een certificaatbeleid in Key Vault, waarmee het domein/onderwerp van het certificaat, de gewenste verlener, het sleuteltype en de lengte, het beoogde sleutelgebruik en meer worden opgegeven. Zie Certificaten in Azure Key Vault voor meer informatie.

• De aanvrager maakt een certificaat in dezelfde kluis met het beleid dat in de vorige stap is opgegeven. Hiermee wordt op zijn beurt een sleutelpaar gegenereerd als kluisobjecten en een certificaatondertekeningsaanvraag die is ondertekend met de persoonlijke sleutel, die vervolgens wordt doorgestuurd naar de aangewezen verlener voor ondertekening.

• Nadat de verlener of certificeringsinstantie (CA) antwoordt met het ondertekende certificaat, wordt het resultaat samengevoegd in de sleutelkluis en zijn de certificaatgegevens als volgt beschikbaar:

  • Onder {vaultUri}/certificates/{name}: Het certificaat, inclusief de openbare sleutel en metagegevens
  • Onder {vaultUri}/keys/{name}: De persoonlijke sleutel van het certificaat, beschikbaar voor cryptografische bewerkingen (verpakken/uitpakken, ondertekenen/verifiëren)
  • Onder {vaultUri}/secrets/{name}: Het certificaat, inclusief de persoonlijke sleutel, die kan worden gedownload als een niet-beveiligd PFX- of PEM-bestand.

Zoals u weet, bevat een certificaat in de sleutelkluis een chronologische lijst met certificaatexemplaren die een beleid delen. Certificaatversies worden gemaakt op basis van de levensduur en verlengingskenmerken van dit beleid. We raden u ten zeerste aan dat kluiscertificaten geen onderwerpen of domeinen of DNS-namen delen, omdat het in een cluster verstorend kan zijn om certificaatexemplaren van verschillende kluiscertificaten in te richten, met identieke onderwerpen, maar aanzienlijk andere kenmerken, zoals verlener, sleutelgebruik, enzovoort. Op dit moment bestaat er een certificaat in de sleutelkluis, klaar voor gebruik. Laten we nu de rest van het proces verkennen.

Certificaatinrichting

We hebben een inrichtingsagent genoemd, de entiteit die het certificaat ophaalt, inclusief de persoonlijke sleutel, uit de sleutelkluis en installeert deze op elk van de hosts van het cluster. (Vergeet niet dat Service Fabric geen certificaten inricht.)

In de context van dit artikel wordt het cluster gehost op een verzameling virtuele Azure-machines (VM's) of virtuele-machineschaalsets. In Azure kunt u een certificaat van een kluis inrichten naar een VM/VMSS met behulp van de volgende mechanismen. Hierbij wordt ervan uitgegaan dat de inrichtingsagent eerder geheime machtigingen heeft gekregen voor de sleutelkluis door de eigenaar van de sleutelkluis.

• Ad-hoc: Een operator haalt het certificaat op uit de sleutelkluis (als PFX/PKCS #12 of PEM) en installeert het op elk knooppunt.

  Het ad-hocmechanisme wordt om meerdere redenen niet aanbevolen, variërend van beveiliging tot beschikbaarheid en wordt hier niet verder besproken. Zie veelgestelde vragen over virtuele-machineschaalsets van Azure voor meer informatie.

• Als een virtuele-machineschaalset geheim tijdens de implementatie: Door de eigen identiteit namens de operator te gebruiken, haalt de rekenservice het certificaat op uit een kluis met sjabloonimplementatie en installeert deze op elk knooppunt van de virtuele-machineschaalset, zoals wordt beschreven in veelgestelde vragen over virtuele-machineschaalsets van Azure.

  Notitie

  Met deze benadering kan alleen versiegeheimen worden ingericht.

• Met behulp van de Key Vault VM-extensie. Hiermee kunt u certificaten inrichten met versieloze declaraties, met periodieke vernieuwing van waargenomen certificaten. In dit geval heeft de VM/VMSS naar verwachting een beheerde identiteit, een identiteit die toegang heeft gekregen tot de sleutelkluizen die de waargenomen certificaten bevatten.

VMSS/compute-gebaseerde inrichting biedt beveiligings- en beschikbaarheidsvoordelen, maar biedt ook beperkingen. Het vereist standaard dat u certificaten declareert als versiebeheergeheimen. Deze vereiste maakt vmSS/compute-gebaseerde inrichting alleen geschikt voor clusters die zijn beveiligd met certificaten die zijn gedeclareerd met vingerafdruk.

Het inrichten op basis van extensies op basis van een Key Vault-VM installeert daarentegen altijd de nieuwste versie van elk waargenomen certificaat. waardoor het alleen geschikt is voor clusters die zijn beveiligd met certificaten die zijn gedeclareerd door de algemene naam van het onderwerp. Gebruik geen mechanisme voor automatischerefreshinrichting (zoals de Key Vault-VM-extensie) voor certificaten die worden gedeclareerd door instantie (dat wil gezegd door vingerafdruk). Het risico op verlies van beschikbaarheid is aanzienlijk.

Er bestaan andere inrichtingsmechanismen, maar de hier genoemde benaderingen zijn de momenteel geaccepteerde opties voor Azure Service Fabric-clusters.

Certificaatverbruik en -bewaking

Zoals eerder vermeld, is de Service Fabric-runtime verantwoordelijk voor het zoeken en gebruiken van de certificaten die zijn gedeclareerd in de clusterdefinitie. In het artikel X.509-verificatie op basis van certificaten in Service Fabric-clusters wordt in detail uitgelegd hoe Service Fabric de presentatie- en validatieregels implementeert en deze hier niet opnieuw wordt bekeken. In dit artikel wordt gekeken naar toegang en machtigingen verlenen, evenals bewaking.

Zoals u weet, worden certificaten in Service Fabric gebruikt voor een groot aantal doeleinden, van wederzijdse verificatie in de federatielaag tot TLS-verificatie (Transport Layer Security) voor de beheereindpunten. Hiervoor moeten verschillende onderdelen of systeemservices toegang hebben tot de persoonlijke sleutel van het certificaat. De Service Fabric-runtime scant regelmatig het certificaatarchief, op zoek naar overeenkomsten voor elk van de bekende presentatieregels.

Voor elk overeenkomend certificaat bevindt de bijbehorende persoonlijke sleutel zich en wordt de discretionaire toegangsbeheerlijst bijgewerkt met machtigingen (normaal gesproken lezen en uitvoeren) die worden verleend aan de identiteit waarvoor ze zijn vereist.

Dit proces wordt informeel aangeduid als ACLing. Het proces wordt uitgevoerd op een frequentie van één minuut en omvat ook toepassingscertificaten , zoals toepassingen die worden gebruikt voor het versleutelen van instellingen of als eindpuntcertificaten. ACLing volgt de presentatieregels, dus het is belangrijk om er rekening mee te houden dat certificaten die zijn gedeclareerd met vingerafdruk en die automatisch worden verwijderd zonder dat de volgende clusterconfiguratie-update niet toegankelijk is.

Certificaatrotatie

Notitie

De INTERNET Engineering Task Force (IETF) RFC 3647 definieert formeel verlenging als de uitgifte van een certificaat met dezelfde kenmerken als het certificaat dat wordt vervangen. De uitgever, de openbare sleutel van het onderwerp en de informatie blijven behouden. Opnieuw versleutelen is de uitgifte van een certificaat met een nieuw sleutelpaar, zonder beperkingen of de verlener kan wijzigen. Omdat het onderscheid belangrijk kan zijn (houd rekening met het geval van certificaten die worden gedeclareerd door algemene naam van het onderwerp bij het vastmaken van verleners), gebruikt dit artikel de neutrale termrotatie om beide scenario's te behandelen. Houd er rekening mee dat wanneer verlenging informeel wordt gebruikt, het verwijst naar opnieuw versleutelen.

Zoals eerder vermeld, ondersteunt Key Vault automatische certificaatrotatie. Dat wil gezegd, definieert het certificaatbeleid voor koppelen het tijdstip, ongeacht of het aantal dagen vóór de vervaldatum of het percentage van de totale levensduur, wordt bepaald wanneer het certificaat in de sleutelkluis wordt geroteerd. De inrichtingsagent moet na dit tijdstip worden aangeroepen en vóór de vervaldatum van het nu vorige certificaat, om dit nieuwe certificaat te distribueren naar alle knooppunten van het cluster.

Service Fabric helpt bij dit proces door statuswaarschuwingen te genereren wanneer de vervaldatum van een certificaat, dat momenteel in het cluster wordt gebruikt, sneller plaatsvindt dan een vooraf bepaald interval. Een automatische inrichtingsagent, de Key Vault VM-extensie, die is geconfigureerd om het sleutelkluiscertificaat te observeren, periodiek de sleutelkluis controleert, de rotatie detecteert en het nieuwe certificaat ophaalt en installeert. Voor het inrichten dat plaatsvindt via de functie VM/VMSS-geheimen, moet een geautoriseerde operator de VM/VMSS bijwerken met de URI van de key vault met versiebeheer die overeenkomt met het nieuwe certificaat.

Het gedraaide certificaat is nu ingericht voor alle knooppunten. Ervan uitgaande dat de rotatie die op het clustercertificaat is toegepast, is gedeclareerd met de algemene naam van het onderwerp, gaan we eens kijken wat er vervolgens gebeurt:

• Voor nieuwe verbindingen binnen en in het cluster zoekt en selecteert de Service Fabric-runtime het meest recent uitgegeven overeenkomende certificaat (de grootste waarde van de eigenschap NotBefore ). Dit is een wijziging ten laste van eerdere versies van de Service Fabric-runtime.

• Bestaande verbindingen blijven actief of mogen natuurlijk verlopen of anderszins worden beëindigd en er wordt een interne handler op de hoogte gesteld dat er een nieuwe overeenkomst bestaat.

Notitie

Momenteel selecteert Service Fabric vanaf versie 7.2 CU4+ het certificaat met de grootste (meest recent uitgegeven) NotBefore-eigenschapswaarde . Vóór 7.2 CU4 heeft Service Fabric het geldige certificaat gekozen met de grootste (meest recente verlopende) NotAfter-waarde .

Dit vertaalt zich in de volgende belangrijke waarnemingen:

• De beschikbaarheid van het cluster, of van de gehoste toepassingen, heeft voorrang op de instructie om het certificaat te roteren. Het cluster wordt uiteindelijk geconvergeerd op het nieuwe certificaat, maar zonder timinggaranties. Dit doet u als volgt:

  • Het is misschien niet direct duidelijk voor een waarnemer dat het gedraaide certificaat zijn voorganger volledig heeft vervangen. De enige manier om de onmiddellijke vervanging van het certificaat dat momenteel wordt gebruikt, af te dwingen, is door de hostmachines opnieuw op te starten. Het is niet voldoende om de Service Fabric-knooppunten opnieuw op te starten, omdat de onderdelen van de kernelmodus die leaseverbindingen vormen in een cluster, niet worden beïnvloed. Als u de VM/VMSS opnieuw opstart, kan dit ook leiden tot tijdelijk verlies van beschikbaarheid. Voor toepassingscertificaten is het voldoende om alleen de respectieve toepassingsexemplaren opnieuw op te starten.

  • Als u een opnieuw sleutelcertificaat introduceert dat niet voldoet aan de validatieregels, kan het cluster effectief worden verbroken. Het meest voorkomende voorbeeld hiervan is het geval van een onverwachte verlener, waarbij de clustercertificaten worden gedeclareerd volgens de algemene naam van het onderwerp met het vastmaken van verleners, maar het gedraaide certificaat is uitgegeven door een nieuwe of niet-declaratie van verleners.

Certificaat opschonen

Op dit moment zijn er geen bepalingen in Azure voor het expliciet verwijderen van certificaten. Het is vaak een niet-triviale taak om te bepalen of een specifiek certificaat op een bepaald moment wordt gebruikt. Dit is moeilijker voor toepassingscertificaten dan voor clustercertificaten. Service Fabric zelf, niet de inrichtingsagent, verwijdert in geen geval een certificaat dat door de gebruiker wordt gedeclareerd. Voor de standaardinrichtingsmechanismen:

• Certificaten die zijn gedeclareerd als VM/VMSS-geheimen, worden ingericht zolang er naar wordt verwezen in de VM/VMSS-definitie en kunnen ze worden opgehaald uit de sleutelkluis. Als u een sleutelkluisgeheim of -certificaat verwijdert, mislukken volgende VM-/VMSS-implementaties. Op dezelfde manier mislukt het uitschakelen van een geheime versie in de sleutelkluis ook vm-/VMSS-implementaties die verwijzen naar de geheime versie.

• Eerdere versies van certificaten die zijn ingericht via de Key Vault VM-extensie, zijn mogelijk of niet aanwezig op een VM/VMSS-knooppunt. De agent haalt alleen de huidige versie op en installeert deze en verwijdert geen certificaten. Het opnieuw maken van een knooppunt, dat gewoonlijk elke maand plaatsvindt, stelt het certificaatarchief opnieuw in op de inhoud van de installatiekopieën van het besturingssysteem, zodat eerdere versies impliciet worden verwijderd. Houd er echter rekening mee dat het omhoog schalen van een virtuele-machineschaalset leidt tot alleen de huidige versie van waargenomen certificaten die worden geïnstalleerd. Neem niet aan dat de homogeniteit van knooppunten met betrekking tot geïnstalleerde certificaten.

Beheer vereenvoudigen: een voorbeeld van automatisch inschrijven

Tot nu toe heeft dit artikel mechanismen en beperkingen beschreven, ingewikkelde regels en definities beschreven en dire voorspellingen gedaan van storingen. Nu is het tijd om automatisch certificaatbeheer in te stellen om al deze problemen te voorkomen. Laten we dit doen in de context van een Azure Service Fabric-cluster dat wordt uitgevoerd op een PaaS-vmschaalset (Platform as a Service) v2, met key Vault voor geheimenbeheer en het gebruik van beheerde identiteiten, als volgt:

• Validatie van certificaten wordt gewijzigd van vingerafdrukpinning naar subject + issuer-pinning. Elk certificaat met een specifiek onderwerp van een specifieke verlener wordt even vertrouwd.
• Certificaten worden ingeschreven bij en verkregen uit een vertrouwd archief (Key Vault) en vernieuwd door een agent (hier de Key Vault VM-extensie).
• Het inrichten van certificaten wordt gewijzigd van implementatietijd en versiegebaseerd (zoals gedaan door Azure Compute Resource Provider) naar post-implementatie met behulp van key Vault-URI's met versieloze versies.
• Toegang tot de sleutelkluis wordt verleend via door de gebruiker toegewezen beheerde identiteiten, die tijdens de implementatie worden gemaakt en toegewezen aan de virtuele-machineschaalset.
• Na de implementatie pollt en vernieuwt de agent (de Key Vault VM-extensie) waargenomen certificaten op elk knooppunt van de virtuele-machineschaalset. Certificaatrotatie is dus volledig geautomatiseerd, omdat Service Fabric automatisch het meest recente geldige certificaat ophaalt.

De reeks is volledig scriptbaar en geautomatiseerd en biedt een initiële implementatie van een cluster dat is geconfigureerd voor automatische inschrijving van certificaten met een gebruiker zonder aanraakscherm. De volgende secties bevatten gedetailleerde stappen, die een combinatie van PowerShell-cmdlets en fragmenten van JSON-sjablonen bevatten. Dezelfde functionaliteit is haalbaar met alle ondersteunde methoden voor interactie met Azure.

Notitie

In dit voorbeeld wordt ervan uitgegaan dat er al een certificaat bestaat in uw sleutelkluis. Voor het inschrijven en vernieuwen van een door Key Vault beheerd certificaat zijn handmatige stappen vereist, zoals eerder in dit artikel is beschreven. Voor productieomgevingen gebruikt u door Key Vault beheerde certificaten. We hebben een voorbeeldscript opgenomen dat specifiek is voor een interne PKI van Microsoft.

Notitie

Automatische inschrijving van certificaten is alleen zinvol voor door ca uitgegeven certificaten. Het gebruik van zelfondertekende certificaten, met inbegrip van certificaten die zijn gegenereerd tijdens de implementatie van een Service Fabric-cluster in Azure Portal, is niet logisch, maar is nog steeds mogelijk voor lokale of door ontwikkelaars gehoste implementaties als u de vingerafdruk van de uitgever declareert dat deze hetzelfde is als die van het leaf-certificaat.

Uitgangspunt

Laten we voor kortheid de volgende beginstatus aannemen:

• Het Service Fabric-cluster bestaat en wordt beveiligd met een door een CA uitgegeven certificaat dat is opgegeven met vingerafdruk.
• Het certificaat wordt opgeslagen in een sleutelkluis en ingericht als een geheim van een virtuele-machineschaalset.
• Hetzelfde certificaat wordt gebruikt om het cluster te converteren naar algemene certificaatdeclaraties op basis van een naam, zodat het kan worden gevalideerd door onderwerp en verlener. Als dit niet het geval is, haalt u het door de CA uitgegeven certificaat op dat voor dit doel is bedoeld en voegt u het toe aan de clusterdefinitie met vingerafdruk. Dit proces wordt uitgelegd in Certificaten toevoegen of verwijderen voor een Service Fabric-cluster in Azure.

Hier volgt een JSON-fragment van een sjabloon die overeenkomt met een dergelijke status. In het fragment worden veel vereiste instellingen weggelaten en worden alleen de certificaatgerelateerde aspecten geïllustreerd.

  "resources": [
    {   ## VMSS definition
      "apiVersion": "[variables('vmssApiVersion')]",
      "type": "Microsoft.Compute/virtualMachineScaleSets",
      "name": "[variables('vmNodeTypeName')]",
      "location": "[variables('computeLocation')]",
      "properties": {
        "virtualMachineProfile": {
          "extensionProfile": {
            "extensions": [
            {
                "name": "[concat('ServiceFabricNodeVmExt','_vmNodeTypeName')]",
                "properties": {
                  "type": "ServiceFabricNode",
                  "autoUpgradeMinorVersion": true,
                  "publisher": "Microsoft.Azure.ServiceFabric",
                  "settings": {
                    "clusterEndpoint": "[reference(parameters('clusterName')).clusterEndpoint]",
                    "nodeTypeRef": "[variables('vmNodeTypeName')]",
                    "dataPath": "D:\\SvcFab",
                    "durabilityLevel": "Bronze",
                    "certificate": {
                        "thumbprint": "[parameters('primaryClusterCertificateTP')]",
                        "x509StoreName": "[parameters('certificateStoreValue')]"
                    }
                  },
                  "typeHandlerVersion": "1.1"
                }
            },}},
          "osProfile": {
            "adminPassword": "[parameters('adminPassword')]",
            "adminUsername": "[parameters('adminUsername')]",
            "secrets": [
            {
                "sourceVault": {
                    "id": "[resourceId('Microsoft.KeyVault/vaults', parameters('keyVaultName'))]"
                },
                "vaultCertificates": [
                {
                    "certificateStore": "[parameters('certificateStoreValue')]",
                    "certificateUrl": "[parameters('clusterCertificateUrlValue')]"
                },
            ]}]
        },
    },
    {   ## cluster definition
        "apiVersion": "[variables('sfrpApiVersion')]",
        "type": "Microsoft.ServiceFabric/clusters",
        "name": "[parameters('clusterName')]",
        "location": "[parameters('clusterLocation')]",
        "certificate": {
            "thumbprint": "[parameters('primaryClusterCertificateTP')]",
            "x509StoreName": "[parameters('certificateStoreValue')]"
        },
    }
  ]

In de voorgaande code wordt in wezen aangegeven dat het certificaat met vingerafdruk json [parameters('primaryClusterCertificateTP')] en gevonden op de Key Vault-URI json [parameters('clusterCertificateUrlValue')] wordt gedeclareerd als het enige certificaat van het cluster, met vingerafdruk.

Vervolgens gaan we de aanvullende resources instellen die nodig zijn om ervoor te zorgen dat het certificaat automatisch wordt ingeschreven.

De vereiste resources instellen

Zoals eerder vermeld, wordt een certificaat dat is ingericht als een geheim voor een virtuele-machineschaalset, opgehaald uit de sleutelkluis door de Microsoft Compute Resource Provider-service. Dit doet u door de eigen identiteit namens de implementatieoperator te gebruiken. Dit proces wordt gewijzigd voor automatisch inschrijven. U schakelt over naar het gebruik van een beheerde identiteit die is toegewezen aan de virtuele-machineschaalset en die GET-machtigingen heeft gekregen voor de geheimen in die kluis.

U moet de volgende fragmenten tegelijkertijd implementeren. Ze worden alleen afzonderlijk vermeld voor play-by-play-analyse en uitleg.

Definieer eerst een door de gebruiker toegewezen identiteit (standaardwaarden worden als voorbeelden opgenomen). Zie de officiële documentatie voor meer informatie.

{
  "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "userAssignedIdentityName": {
      "type": "string",
      "defaultValue": "sftstuaicus",
      "metadata": {
        "description": "User-assigned managed identity name"
      }
    },
  },
  "variables": {
      "vmssApiVersion": "2018-06-01",
      "sfrpApiVersion": "2018-02-01",
      "miApiVersion": "2018-11-30",
      "kvApiVersion": "2018-02-14",
      "userAssignedIdentityResourceId": "[resourceId('Microsoft.ManagedIdentity/userAssignedIdentities', parameters('userAssignedIdentityName'))]"
  },    
  "resources": [
    {
      "type": "Microsoft.ManagedIdentity/userAssignedIdentities",
      "name": "[parameters('userAssignedIdentityName')]",
      "apiVersion": "[variables('miApiVersion')]",
      "location": "[resourceGroup().location]"
    },
  ]}

Verdeel vervolgens deze identiteit toegang tot de sleutelkluisgeheimen. Zie de officiële documentatie voor de meest recente informatie.

  "resources":
  [{
      "type": "Microsoft.KeyVault/vaults/accessPolicies",
      "name": "[concat(parameters('keyVaultName'), '/add')]",
      "apiVersion": "[variables('kvApiVersion')]",
      "properties": {
        "accessPolicies": [
          {
            "tenantId": "[reference(variables('userAssignedIdentityResourceId'), variables('miApiVersion')).tenantId]",
            "objectId": "[reference(variables('userAssignedIdentityResourceId'), variables('miApiVersion')).principalId]",
            "dependsOn": [
              "[variables('userAssignedIdentityResourceId')]"
            ],
            "permissions": {
              "secrets": [
                "get",
                "list"
              ]}}]}}]

In de volgende stap gaat u het volgende doen:

• Wijs de door de gebruiker toegewezen identiteit toe aan de virtuele-machineschaalset.
• Declareer de afhankelijkheid van de virtuele-machineschaalset voor het maken van de beheerde identiteit en het resultaat van het verlenen van toegang tot de sleutelkluis.
• Declareer de Key Vault-VM-extensie en vereist dat deze waargenomen certificaten ophaalt bij het opstarten. Zie de key vault-VM-extensie voor officiële Windows-documentatie voor meer informatie.
• Werk de definitie van de Service Fabric VM-extensie bij zodat deze afhankelijk is van de Key Vault-VM-extensie en om de declaratie van het clustercertificaat van vingerafdruk naar algemene naam te converteren.

Notitie

Deze wijzigingen worden als één stap aangebracht, omdat ze binnen het bereik van dezelfde resource vallen.

  "parameters": {
    "kvvmextPollingInterval": {
      "type": "string",
      "defaultValue": "3600",
      "metadata": {
        "description": "kv vm extension polling interval in seconds"
      }
    },
    "kvvmextLocalStoreName": {
      "type": "string",
      "defaultValue": "MY",
      "metadata": {
        "description": "kv vm extension local store name"
      }
    },
    "kvvmextLocalStoreLocation": {
      "type": "string",
      "defaultValue": "LocalMachine",
      "metadata": {
        "description": "kv vm extension local store location"
      }
    },
    "kvvmextObservedCertificates": {
      "type": "array",
      "defaultValue": [
                "https://sftestcus.vault.azure.net/secrets/sftstcncluster",
                "https://sftestcus.vault.azure.net/secrets/sftstcnserver"
            ],
      "metadata": {
        "description": "kv vm extension observed certificates versionless uri"
      }
    },
    "certificateCommonName": {
      "type": "string",
      "defaultValue": "cus.cluster.sftstcn.system.servicefabric.azure-int",
      "metadata": {
        "description": "Certificate Common name"
      }
    },
  },
  "resources": [
  {
    "apiVersion": "[variables('vmssApiVersion')]",
    "type": "Microsoft.Compute/virtualMachineScaleSets",
    "name": "[variables('vmNodeTypeName')]",
    "location": "[variables('computeLocation')]",
    "dependsOn": [
      "[variables('userAssignedIdentityResourceId')]",
      "[concat('Microsoft.KeyVault/vaults/', concat(parameters('keyVaultName'), '/accessPolicies/add'))]"
    ],
    "identity": {
      "type": "UserAssigned",
      "userAssignedIdentities": {
        "[variables('userAssignedIdentityResourceId')]": {}
      }
    },
    "virtualMachineProfile": {
      "extensionProfile": {
        "extensions": [
        {
          "name": "KVVMExtension",
          "properties": {
            "publisher": "Microsoft.Azure.KeyVault",
            "type": "KeyVaultForWindows",
            "typeHandlerVersion": "1.0",
            "autoUpgradeMinorVersion": true,
            "settings": {
                "secretsManagementSettings": {
                    "pollingIntervalInS": "[parameters('kvvmextPollingInterval')]",
                    "linkOnRenewal": false,
                    "observedCertificates": "[parameters('kvvmextObservedCertificates')]",
                    "requireInitialSync": true
                }
            }
          }
        },
        {
        "name": "[concat('ServiceFabricNodeVmExt','_vmNodeTypeName')]",
        "properties": {
          "type": "ServiceFabricNode",
          "provisionAfterExtensions" : [ "KVVMExtension" ],
          "publisher": "Microsoft.Azure.ServiceFabric",
          "settings": {
            "certificate": {
                "commonNames": [
                    "[parameters('certificateCommonName')]"
                ],
                "x509StoreName": "[parameters('certificateStoreValue')]"
            }
            },
            "typeHandlerVersion": "1.0"
          }
        },
  ] } ## extension profile
  },  ## VM profile
  "osProfile": {
    "adminPassword": "[parameters('adminPassword')]",
    "adminUsername": "[parameters('adminUsername')]",
  } 
  }
  ]

Hoewel deze niet expliciet wordt vermeld in de voorgaande code, moet u er rekening mee houden dat de URL van het sleutelkluiscertificaat is verwijderd uit de OsProfile sectie van de virtuele-machineschaalset.

De laatste stap is het bijwerken van de clusterdefinitie om de certificaatdeclaratie van vingerafdruk te wijzigen in algemene naam. De vingerafdruk van de uitgever wordt ook vastgemaakt:

  "parameters": {
    "certificateCommonName": {
      "type": "string",
      "defaultValue": "cus.cluster.sftstcn.system.servicefabric.azure-int",
      "metadata": {
        "description": "Certificate Common name"
      }
    },
    "certificateIssuerThumbprint": {
      "type": "string",
      "defaultValue": "1b45ec255e0668375043ed5fe78a09ff1655844d,d7fe717b5ff3593764f4d90654d86e8362ec26c8,3ac7c3cac8de0dd392c02789c8be97474f456960,96ea05926e2e42cc207e358668be2c316857fb5e",
      "metadata": {
        "description": "Certificate issuer thumbprints separated by comma"
      }
    },
  },
  "resources": [
    {
      "apiVersion": "[variables('sfrpApiVersion')]",
      "type": "Microsoft.ServiceFabric/clusters",
      "name": "[parameters('clusterName')]",
      "location": "[parameters('clusterLocation')]",
      "properties": {
        "certificateCommonNames": {
          "commonNames": [{
              "certificateCommonName": "[parameters('certificateCommonName')]",
              "certificateIssuerThumbprint": "[parameters('certificateIssuerThumbprint')]"
          }],
          "x509StoreName": "[parameters('certificateStoreValue')]"
        },
  ]

Op dit moment kunt u de eerder genoemde updates uitvoeren in één implementatie. De Service Fabric Resource Provider-service splitst de clusterupgrade in verschillende stappen, zoals beschreven in het segment over het converteren van clustercertificaten van vingerafdruk naar algemene naam.

Analyse en waarnemingen

Deze sectie is een catch-all voor het uitleggen van concepten en processen die in dit artikel zijn gepresenteerd, en om aandacht te vestigen op bepaalde andere belangrijke aspecten.

Over het inrichten van certificaten

De Key Vault VM-extensie, als inrichtingsagent, wordt continu uitgevoerd volgens een vooraf vastgestelde frequentie. Als het niet lukt om een waargenomen certificaat op te halen, gaat het verder met de volgende in de regel en wordt de sluimerstand uitgevoerd tot de volgende cyclus. De Service Fabric VM-extensie, als de opstartagent voor het cluster, vereist de gedeclareerde certificaten voordat het cluster kan worden formulier. Dit betekent op zijn beurt dat de Service Fabric VM-extensie alleen kan worden uitgevoerd na het ophalen van de clustercertificaten, hier aangegeven door de json "provisionAfterExtensions" : [ "KVVMExtension" ]" component en door de instelling van json "requireInitialSync": true de Key Vault-VM-extensie.

Dit geeft aan bij de Key Vault-VM-extensie dat tijdens de eerste uitvoering (na implementatie of opnieuw opstarten) de waargenomen certificaten moeten doorlopen totdat alle certificaten zijn gedownload. Als u deze parameter instelt op false, in combinatie met een fout bij het ophalen van de clustercertificaten, leidt dit tot een fout in de clusterimplementatie. Omgekeerd zou het vereisen van een initiële synchronisatie met een onjuiste of ongeldige lijst met waargenomen certificaten leiden tot een fout in de Key Vault-VM-extensie en opnieuw een fout bij het implementeren van het cluster.

Certificaatkoppeling, uitgelegd

Mogelijk hebt u de vlag voor de Key Vault-VM-extensie linkOnRenewal opgemerkt en is het feit dat deze is ingesteld op false. Deze instelling heeft betrekking op het gedrag dat wordt beheerd door deze vlag en de gevolgen ervan voor het functioneren van een cluster. Dit gedrag is specifiek voor Windows.

Volgens de definitie:

"linkOnRenewal": <Only Windows. This feature enables auto-rotation of SSL certificates, without necessitating a re-deployment or binding. e.g.: false>,

Certificaten die worden gebruikt om een TLS-verbinding tot stand te brengen, worden gewoonlijk verkregen als een ingang via de S-channel Security Support Provider. Dat wil gezegd, de client heeft niet rechtstreeks toegang tot de persoonlijke sleutel van het certificaat zelf. S-channel biedt ondersteuning voor omleiding of koppelen van referenties in de vorm van een certificaatextensie CERT_RENEWAL_PROP_ID.

Als deze eigenschap is ingesteld, geeft de waarde de vingerafdruk van het verlengingscertificaat aan en probeert het S-kanaal in plaats daarvan het gekoppelde certificaat te laden. In feite gaat het S-kanaal door deze gekoppelde en hopelijk acyclische lijst totdat het eindigt met het uiteindelijke certificaat, één zonder verlengingsmarkering. Deze functie, wanneer deze correct wordt gebruikt, is een uitstekende oplossing voor een verlies van beschikbaarheid die wordt veroorzaakt door bijvoorbeeld verlopen certificaten.

In andere gevallen kan dit de oorzaak zijn van storingen die moeilijk te diagnosticeren en te verhelpen zijn. S-channel voert het doorkruisen van certificaten op hun verlengingseigenschappen onvoorwaardelijke uit, ongeacht onderwerp, verleners of andere specifieke kenmerken die deelnemen aan de validatie van het resulterende certificaat door de client. Het is mogelijk dat het resulterende certificaat geen gekoppelde persoonlijke sleutel heeft of dat de sleutel niet aan de potentiële consument is gekoppeld.

Als koppelen is ingeschakeld, probeert de Key Vault-VM-extensie, wanneer er een waargenomen certificaat uit de sleutelkluis wordt opgehaald, te zoeken naar overeenkomende, bestaande certificaten om deze te koppelen via de extensie-eigenschap voor verlenging. De overeenkomst is uitsluitend gebaseerd op de alternatieve naam van het onderwerp (SAN) en werkt, als er twee bestaande certificaten zijn, zoals wordt weergegeven in de volgende voorbeelden: A: Certificaatnaam (CN) = "Alice's accessoires", SAN = {"alice.universalexports.com"}, verlenging = '' B: CN = "Bob's bits", SAN = {"bob.universalexports.com", "bob.universalexports.net"}, verlenging = ''

Stel dat een certificaat C wordt opgehaald door de Key Vault VM-extensie: CN = "Mallory's malware", SAN = {"alice.universalexports.com", "bob.universalexports.com", "mallory.universalexports.com"}

De SAN-lijst van certificaat A is volledig opgenomen in C's en dus A.renewal = C.thumbprint. De SAN-lijst van certificaat B heeft een gemeenschappelijk snijpunt met C's, maar is er niet volledig in opgenomen, dus B.renewal blijft leeg.

Elke poging om AcquireCredentialsHandle (S-channel) in deze status aan te roepen op certificaat A stuurt uiteindelijk C naar de externe partij. In het geval van Service Fabric gebruikt het transportsubsysteem van een cluster S-channel voor wederzijdse verificatie, waardoor het eerder beschreven gedrag de fundamentele communicatie van het cluster rechtstreeks beïnvloedt. Als u verdergaat met het voorgaande voorbeeld en ervan uitgaande dat A het clustercertificaat is, is de volgende stap afhankelijk van:

• Als de persoonlijke sleutel van C niet is gekoppeld aan het account waarop Service Fabric wordt uitgevoerd, ziet u fouten bij het verkrijgen van de persoonlijke sleutel (SEC_E_UNKNOWN_CREDENTIALS of vergelijkbaar).
• Als de persoonlijke sleutel van C toegankelijk is, ziet u autorisatiefouten die worden geretourneerd door de andere knooppunten (CertificateNotMatched, niet geautoriseerd, enzovoort).

In beide gevallen mislukt het transport en kan het cluster uitvallen. De symptomen variëren. Om het nog erger te maken, hangt de koppeling af van de volgorde van verlenging, die wordt bepaald door de volgorde van de lijst met waargenomen certificaten van de Key Vault VM-extensie, het vernieuwingsschema in de sleutelkluis of zelfs tijdelijke fouten die de volgorde van ophalen zouden wijzigen.

Als u dergelijke incidenten wilt beperken, raden we het volgende aan:

• Combineer niet de alternatieve namen van verschillende kluiscertificaten voor onderwerpen. Elk kluiscertificaat moet een afzonderlijk doel dienen en het onderwerp en san moeten dat met specificiteit weerspiegelen.

• Neem de algemene naam van het onderwerp op in de SAN-lijst (zoals letterlijk). CN=<subject common name>

• Als u niet zeker weet hoe u doorgaat, schakelt u het koppelen uit voor certificaten die zijn ingericht met de Key Vault VM-extensie.

  Notitie

  Het uitschakelen van koppelen is een eigenschap op het hoogste niveau van de Key Vault-VM-extensie en kan niet worden ingesteld voor afzonderlijke waargenomen certificaten.

Waarom moet ik een door de gebruiker toegewezen beheerde identiteit gebruiken? Wat zijn de gevolgen van het gebruik ervan?

Zoals blijkt uit de voorgaande JSON-fragmenten, is een specifieke volgorde van de bewerkingen en updates vereist om zowel het succes van de conversie te garanderen als de beschikbaarheid van het cluster te behouden. De virtuele-machineschaalsetresource declareert en gebruikt de identiteit ervan om geheimen op te halen in een (vanuit het perspectief van de gebruiker) enkele update.

De Service Fabric VM-extensie, die het cluster opstart, is afhankelijk van de voltooiing van de Key Vault-VM-extensie, die op zijn beurt afhankelijk is van het succesvol ophalen van waargenomen certificaten.

De Key Vault VM-extensie maakt gebruik van de identiteit van de virtuele-machineschaalset voor toegang tot de sleutelkluis. Dit betekent dat het toegangsbeleid voor de sleutelkluis al vóór de implementatie van de virtuele-machineschaalset moet zijn bijgewerkt.

Als u het maken van een beheerde identiteit wilt verwijderen of aan een andere resource wilt toewijzen, moet de implementatieoperator de vereiste rol (ManagedIdentityOperator) hebben in het abonnement of de resourcegroep, naast de rollen die nodig zijn voor het beheren van de andere resources waarnaar in de sjabloon wordt verwezen.

Onthoud dat de virtuele-machineschaalset vanuit het oogpunt van beveiliging wordt beschouwd als een beveiligingsgrens met betrekking tot de Azure-identiteit. Dat betekent dat elke toepassing die wordt gehost op de VIRTUELE machine, in principe een toegangstoken kan verkrijgen dat de VIRTUELE machine vertegenwoordigt. Toegangstokens voor beheerde identiteiten worden verkregen via het eindpunt van de niet-geverifieerde instantiemetagegevensservice. Als u denkt dat de virtuele machine een gedeelde of multitenant-omgeving is, wordt deze methode voor het ophalen van clustercertificaten mogelijk niet aangegeven. Het is echter het enige inrichtingsmechanisme dat geschikt is voor automatische inschrijving van certificaten.

Problemen oplossen en veelgestelde vragen

V: Hoe kan ik programmatisch inschrijven bij een door Key Vault beheerd certificaat?

Zoek de naam van de verlener uit de Key Vault-documentatie en vervang deze in het volgende script:

  $issuerName=<depends on your PKI of choice>
	$clusterVault="sftestcus"
	$clusterCertVaultName="sftstcncluster"
	$clusterCertCN="cus.cluster.sftstcn.system.servicefabric.azure-int"
	Set-AzKeyVaultCertificateIssuer -VaultName $clusterVault -Name $issuerName -IssuerProvider $issuerName
	$distinguishedName="CN=" + $clusterCertCN
	$policy = New-AzKeyVaultCertificatePolicy `
	    -IssuerName $issuerName `
	    -SubjectName $distinguishedName `
	    -SecretContentType 'application/x-pkcs12' `
	    -Ekus "1.3.6.1.5.5.7.3.1", "1.3.6.1.5.5.7.3.2" `
	    -ValidityInMonths 4 `
	    -KeyType 'RSA' `
	    -RenewAtPercentageLifetime 75        
	Add-AzKeyVaultCertificate -VaultName $clusterVault -Name $clusterCertVaultName -CertificatePolicy $policy
	
	# poll the result of the enrollment
	Get-AzKeyVaultCertificateOperation -VaultName $clusterVault -Name $clusterCertVaultName 

V: Wat gebeurt er wanneer een certificaat wordt uitgegeven door een niet-aangegeven of niet-opgegeven uitgever? Waar kan ik een volledige lijst met actieve verleners van een specifieke PKI verkrijgen?

Als de certificaatdeclaratie vingerafdruk van de uitgever opgeeft en de directe uitgever van het certificaat niet is opgenomen in de lijst met vastgemaakte verleners, wordt het certificaat beschouwd als ongeldig, ongeacht of de basis wordt vertrouwd door de client. Daarom is het essentieel om ervoor te zorgen dat de lijst met verleners actueel is. De introductie van een nieuwe verlener is een zeldzame gebeurtenis en moet algemeen worden openbaar gemaakt voordat certificaten worden uitgegeven.

Over het algemeen publiceert en onderhoudt een PKI een certificeringspraktijkverklaring, in overeenstemming met IETF RFC 7382. Naast andere informatie bevat de instructie alle actieve verleners. Het programmatisch ophalen van deze lijst kan afwijken van de ene PKI naar de andere.

Raadpleeg voor interne PKI's van Microsoft de interne documentatie over de eindpunten en SDK's die worden gebruikt om de geautoriseerde verleners op te halen. Het is de verantwoordelijkheid van de eigenaar van het cluster om deze lijst periodiek te controleren om ervoor te zorgen dat de clusterdefinitie alle verwachte verleners bevat.

V: Worden meerdere PKI's ondersteund?

Ja. U kunt niet meerdere CN-vermeldingen declareren in het clustermanifest met dezelfde waarde, maar u kunt verleners van meerdere PKI's weergeven die overeenkomen met dezelfde CN. Het is geen aanbevolen praktijk en procedures voor certificaattransparantie kunnen verhinderen dat dergelijke certificaten worden uitgegeven. Dit is echter een acceptabel mechanisme om van de ene PKI naar de andere te migreren.

V: Wat gebeurt er als het huidige clustercertificaat niet is uitgegeven door de CA of niet over het beoogde onderwerp beschikt?

Haal een certificaat op met het beoogde onderwerp en voeg het toe aan de definitie van het cluster als secundaire vingerafdruk. Nadat de upgrade is voltooid, start u een andere upgrade van de clusterconfiguratie om de certificaatdeclaratie te converteren naar een algemene naam.