Condividi tramite

Convertire i certificati del cluster da dichiarazioni basate sull'identificazione personale in nomi comuni

  • Articolo

La firma di un certificato (comunemente nota come identificazione personale) è univoca. Un certificato cluster dichiarato dall'identificazione personale fa riferimento a un'istanza specifica di un certificato. Questa specificità rende il rollover dei certificati e la gestione in generale, difficili ed espliciti. Ogni modifica richiede l'orchestrazione degli aggiornamenti del cluster e degli host di elaborazione sottostanti.

La conversione delle dichiarazioni di certificato di un cluster di Azure Service Fabric da identificazione personale a dichiarazioni basate sul nome comune del soggetto del certificato semplifica notevolmente la gestione. In particolare, il rollover di un certificato non richiede più un aggiornamento del cluster. Questo articolo descrive come convertire un cluster esistente in dichiarazioni basate su CN senza tempi di inattività.

Nota

È consigliabile usare il modulo Azure Az PowerShell per interagire con Azure. Per iniziare, vedere Installare Azure PowerShell. Per informazioni su come eseguire la migrazione al modulo AZ PowerShell, vedere Eseguire la migrazione di Azure PowerShell da AzureRM ad Az.

Passare ai certificati firmati dall'autorità di certificazione

La sicurezza di un cluster il cui certificato viene dichiarato dall'identificazione personale si basa sul fatto che non è possibile, o in modo computazionale, creare un certificato con la stessa firma di un'altra. In questo caso, la provenienza del certificato è meno importante, quindi i certificati autofirmati sono adeguati.

Al contrario, la sicurezza di un cluster i cui certificati vengono dichiarati da cn flussi dal trust implicito che il proprietario del cluster ha nel provider di certificati. Il provider è il servizio PKI (Public Key Infrastructure) che ha emesso il certificato. L'attendibilità si basa, tra gli altri fattori, sulle procedure di certificazione dell'infrastruttura a chiave pubblica, sul fatto che la sicurezza operativa venga controllato e approvato da altre parti attendibili e così via.

Il proprietario del cluster deve inoltre avere una conoscenza dettagliata delle autorità di certificazione che emettono i certificati, poiché si tratta di un aspetto fondamentale della convalida dei certificati in base all'oggetto. Ciò implica anche che i certificati autofirmati sono completamente inadatti a questo scopo. Letteralmente chiunque può generare un certificato con un determinato soggetto.

Un certificato dichiarato da CN viene in genere considerato valido se:

  • La catena può essere compilata correttamente.
  • L'oggetto ha l'elemento CN previsto.
  • L'autorità emittente (immediata o superiore nella catena) è considerata attendibile dall'agente che esegue la convalida.

Service Fabric supporta la dichiarazione di certificati da CN in due modi:

  • Con le autorità di certificazione implicite , il che significa che la catena deve terminare in un trust anchor.
  • Con le autorità emittenti dichiarate dall'identificazione personale, nota come aggiunta dell'autorità di certificazione.

Per altre informazioni, vedere Dichiarazioni di convalida dei certificati basate su nomi comuni.

Per convertire un cluster usando un certificato autofirmato dichiarato dall'identificazione personale in CN, il certificato firmato dalla CA di destinazione deve essere prima introdotto nel cluster tramite identificazione personale. Solo allora è possibile eseguire la conversione dall'identificazione personale a CN.

A scopo di test, un certificato autofirmato può essere dichiarato da CN, ma solo se l'autorità emittente viene aggiunta alla propria identificazione personale. Dal punto di vista della sicurezza, questa azione equivale quasi a dichiarare lo stesso certificato tramite identificazione personale. Una conversione corretta di questo tipo non garantisce una conversione corretta dall'identificazione personale a CN con un certificato firmato dalla CA. È consigliabile testare la conversione con un certificato appropriato firmato dalla CA. Esistono opzioni gratuite per questo test.

Caricare il certificato e installarlo nel set di scalabilità

In Azure, il meccanismo consigliato per ottenere e effettuare il provisioning dei certificati prevede Azure Key Vault e i relativi strumenti. È necessario effettuare il provisioning di un certificato corrispondente alla dichiarazione del certificato del cluster in ogni nodo dei set di scalabilità di macchine virtuali che costituiscono il cluster. Per altre informazioni, vedere Segreti nei set di scalabilità di macchine virtuali.

È importante installare certificati cluster correnti e di destinazione nelle macchine virtuali di ogni tipo di nodo del cluster prima di apportare modifiche nelle dichiarazioni di certificato del cluster. Il percorso dal rilascio dei certificati al provisioning in un nodo di Service Fabric è descritto in dettaglio nel percorso di un certificato.

Portare il cluster a uno stato di avvio ottimale

Conversione di una dichiarazione di certificato dall'identificazione personale agli impatti basati su CN:

  • Modalità di individuazione e presentazione delle credenziali di ogni nodo nel cluster ad altri nodi.
  • Come ogni nodo convalida le credenziali della controparte al momento di stabilire una connessione sicura.

Esaminare le regole di presentazione e convalida per entrambe le configurazioni prima di procedere. La considerazione più importante quando si esegue una conversione da identificazione personale a CN è che i nodi aggiornati e non ancora aggiornati (ovvero nodi appartenenti a domini di aggiornamento diversi) devono essere in grado di eseguire correttamente l'autenticazione reciproca in qualsiasi momento durante l'aggiornamento. Il modo consigliato per ottenere questo comportamento consiste nel dichiarare il certificato di destinazione o obiettivo tramite identificazione personale in un aggiornamento iniziale. Completare quindi la transizione a CN in una successiva. Se il cluster è già in uno stato di avvio consigliato, è possibile ignorare questa sezione.

Esistono più stati di avvio validi per una conversione. L'invariante è che il cluster usa già il certificato di destinazione (dichiarato dall'identificazione personale) all'inizio dell'aggiornamento a CN. Si consideri GoalCert, OldCert1e OldCert2 in questo articolo.

Stati di avvio validi

  • Thumbprint: GoalCert, ThumbprintSecondary: None
  • Thumbprint: GoalCert, ThumbprintSecondary: OldCert1, dove GoalCert ha una data successiva NotBefore a quella di OldCert1
  • Thumbprint: OldCert1, ThumbprintSecondary: GoalCert, dove GoalCert ha una data successiva NotBefore a quella di OldCert1

Nota

Prima della versione 7.2.445 (7.2 CU4), Service Fabric ha selezionato il certificato di scadenza più lontano (il certificato con la proprietà 'NotAfter' più lontana), quindi gli stati iniziali precedenti alla versione 7.2 CU4 richiedono che GoalCert abbia una data successiva NotAfter rispetto a OldCert1

Se il cluster non si trova in uno degli stati validi descritti in precedenza, vedere le informazioni su come ottenere tale stato nella sezione alla fine di questo articolo.

Selezionare lo schema di convalida dei certificati basato su CN desiderato

Come descritto in precedenza, Service Fabric supporta la dichiarazione di certificati da CN con un trust anchor implicito o l'aggiunta esplicita delle identificazioni personali dell'autorità di certificazione. Per altre informazioni, vedere Dichiarazioni di convalida dei certificati basate su nomi comuni.

Assicurarsi di avere una buona comprensione delle differenze e delle implicazioni della scelta di uno dei due meccanismi. Sintatticamente, questa differenza o scelta è determinata dal valore del certificateIssuerThumbprintList parametro . Vuoto significa basarsi su una CA radice attendibile (trust anchor), mentre un set di identificazioni personali limita le autorità di certificazione dirette consentite dei certificati del cluster.

Nota

Il certificateIssuerThumbprint campo consente di specificare le autorità emittenti dirette previste di certificati dichiarati dal cn soggetto. I valori accettabili sono una o più identificazioni personali SHA1 separate da virgole. Questa azione rafforza la convalida del certificato.

Se non viene specificata alcuna autorità di certificazione o l'elenco è vuoto, il certificato verrà accettato per l'autenticazione se la catena può essere compilata. Il certificato termina quindi in una radice attendibile dal validator. Se si specificano una o più identificazioni personali dell'autorità di certificazione, il certificato verrà accettato se l'identificazione personale del relativo emittente diretto, come estratto dalla catena, corrisponde a uno dei valori specificati in questo campo. Il certificato verrà accettato se la radice è attendibile o meno.

Un'infrastruttura a chiave pubblica potrebbe usare autorità di certificazione diverse (note anche come autorità di certificazione) per firmare i certificati con un determinato soggetto. Per questo motivo, è importante specificare tutte le identificazioni personali dell'autorità di certificazione previste per tale oggetto. In altre parole, il rinnovo di un certificato non è garantito che venga firmato dallo stesso emittente del certificato da rinnovare.

La specifica dell'autorità emittente è considerata una procedura consigliata. L'omissione dell'autorità emittente continuerà a funzionare per il concatenamento dei certificati fino a una radice attendibile, ma questo comportamento presenta limitazioni e potrebbe essere eliminato gradualmente nel prossimo futuro. I cluster distribuiti in Azure, protetti con certificati X509 rilasciati da un'infrastruttura a chiave pubblica privata e dichiarati da soggetto potrebbero non essere in grado di essere convalidati da Service Fabric (per la comunicazione da cluster a servizio). La convalida richiede che i criteri di certificato dell'infrastruttura a chiave pubblica siano individuabili, disponibili e accessibili.

Aggiornare il modello di Azure Resource Manager del cluster e distribuire

Gestire i cluster di Service Fabric con i modelli di Azure Resource Manager (ARM). Un'alternativa, che usa anche artefatti JSON, è Azure Resource Explorer. Un'esperienza equivalente non è attualmente disponibile nel portale di Azure.

Se il modello originale corrispondente a un cluster esistente non è disponibile, è possibile ottenere un modello equivalente nella portale di Azure. Passare al gruppo di risorse che contiene il cluster e selezionare Esporta modello dal menu Automazione a sinistra. Selezionare quindi le risorse desiderate. È necessario esportare almeno il set di scalabilità di macchine virtuali e le risorse del cluster. È anche possibile scaricare il modello generato. Questo modello potrebbe richiedere modifiche prima che sia completamente distribuibile. Il modello potrebbe anche non corrispondere esattamente a quello originale. Si tratta di una reflection dello stato corrente della risorsa cluster.

Le modifiche necessarie sono le seguenti:

  • Aggiornamento della definizione dell'estensione del nodo di Service Fabric (nella risorsa macchina virtuale). Se il cluster definisce più tipi di nodo, è necessario aggiornare la definizione di ogni set di scalabilità di macchine virtuali corrispondente.
  • Aggiornamento della definizione della risorsa cluster.

Qui sono inclusi esempi dettagliati.

Aggiornare le risorse del set di scalabilità di macchine virtuali

Da:

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

Con:

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

Aggiornare la risorsa cluster

Nella risorsa Microsoft.ServiceFabric/clusters aggiungere una proprietà certificateCommonNames con un'impostazione commonNames e rimuovere completamente la proprietà del certificato (tutte le relative impostazioni).

Da:

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

Con:

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

Per altre informazioni, vedere Distribuire un cluster di Service Fabric che usa il nome comune del certificato anziché l'identificazione personale.

Distribuire il modello aggiornato

Ridistribuire il modello aggiornato dopo aver apportato le modifiche.

$groupname = "sfclustertutorialgroup"

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

Ottenere uno stato di avvio valido per la conversione di un cluster in dichiarazioni di certificato basate su CN

Stato iniziale Aggiornamento 1 Aggiornamento 2
Thumbprint: OldCert1, ThumbprintSecondary: None e GoalCert ha una data successiva NotBefore rispetto a OldCert1 Thumbprint: OldCert1, ThumbprintSecondary: GoalCert -
Thumbprint: OldCert1, ThumbprintSecondary: None e OldCert1 ha una data successiva NotBefore rispetto a GoalCert Thumbprint: GoalCert, ThumbprintSecondary: OldCert1 Thumbprint: GoalCert, ThumbprintSecondary: None
Thumbprint: OldCert1, ThumbprintSecondary: GoalCert, dove OldCert1 ha una data successiva NotBefore rispetto a GoalCert Eseguire l'aggiornamento a Thumbprint: GoalCert, ThumbprintSecondary: None -
Thumbprint: GoalCert, ThumbprintSecondary: OldCert1, dove OldCert1 ha una data successiva NotBefore rispetto a GoalCert Eseguire l'aggiornamento a Thumbprint: GoalCert, ThumbprintSecondary: None -
Thumbprint: OldCert1, ThumbprintSecondary: OldCert2 Rimuovere uno di OldCert1 o OldCert2 per ottenere lo stato Thumbprint: OldCertx, ThumbprintSecondary: None Continuare dal nuovo stato di avvio

Nota

Per un cluster in una versione precedente alla versione 7.2.445 (7.2 CU4), sostituire NotBefore con negli NotAfter stati precedenti.

Per istruzioni su come eseguire uno di questi aggiornamenti, vedere Gestire i certificati in un cluster di Azure Service Fabric.

Passaggi successivi