Il sistema crea i certificati necessari per la comunicazione tra le appliance di NSX e le comunicazioni esterne, incluse le appliance federazione di NSX. Questo argomento illustra le varie informazioni sui certificati

A partire dalla versione 4.1.0, sono stati introdotti diversi nuovi tipi di certificati che non erano presenti nella versione 3.2.x. Ad esempio, i certificati CCP, APH_TN, CBM_CLUSTER_MANAGER e CBM_CORFU. Questi tipi facevano parte del requisito EAL4 per rendere sostituibili i certificati. Verranno visualizzati durante il processo di aggiornamento.
Nota: In una distribuzione di NSX federata, i certificati provenienti da altre posizioni vengono visualizzati nel riquadro Certificati. Tali certificati vengono visualizzati con nomi che iniziano con Site, ad esempio Site certificate L=PA,ST=CA,C=US, Site certificate UID=369cd66c-... o solo con il loro UUID 637a2ebf-84d1-4548-a0ba-51d9420672ff. Se tali certificati stanno per scadere, sostituirli nel sito di origine in cui è memorizzata la chiave privata corrispondente. Tali informazioni sono disponibili nel campo Utilizzato da nell'interfaccia utente o nell'API. Se si sostituiscono i certificati in un Global Manager o Local Manager di origine qualsiasi, il sistema li sincronizza automaticamente nella distribuzione federata.

La tabella Certificati per NSX Manager contiene i dettagli dei certificati, incluso l'intervallo di tempo in cui i certificati sono validi solo per le nuove distribuzioni. Poiché durante gli aggiornamenti non vengono generati nuovi certificati, le date di validità dei certificati rifletteranno la data di scadenza del certificato predefinito di una versione di precedente di NSX. Per sostituire i certificati autofirmati esistenti con certificati firmati dalla CA, fare riferimento ai dettagli in Sostituzione dei certificati tramite API. Per ulteriori informazioni sugli eventi di conformità della sicurezza, fare riferimento a Catalogo eventi NSX.

Tabella 1. Certificati per NSX Manager
Convenzione di denominazione dei certificati Scopo Sostituibile utilizzando service_type Validità predefinita
APH (denominato anche APH_AR) Chiave pubblica del server APH (Appliance Proxy Hub) e replicatore asincrono per le comunicazioni incrociate, per la federazione Sì, utilizzare service_type=APH. 825 giorni
APH_TN Certificato APH (Appliance Proxy Hub) per la comunicazione all'interno del cluster e del nodo di trasporto (TN) Sì, utilizzare service_type=APH_TN. 825 giorni
API Certificato del server API per il nodo NSX Manager Sì, utilizzare service_type=API. 825 giorni
CCP Certificato Control Configuration Plane per comunicare con i nodi di trasporto Sì, utilizzare service_type=CCP. 10 anni
MGMT_CLUSTER (denominato anche VIP) Certificato del server API utilizzato da VIP Sì, utilizzare service_type=MGMT_CLUSTER. 825 giorni
CBM_CLUSTER_MANAGER Certificato client Corfu Sì, utilizzare service_type=CBM_CLUSTER_MANAGER. 100 anni
CBM_CORFU Certificato del server Corfu Sì, utilizzare service_type=CBM_CORFU. In 4.1.0, 825 giorni. A partire dalla versione 4.1.1, 100 anni.

Certificati per la comunicazione federazione di NSX

Per impostazione predefinita, Global Manager utilizza certificati autofirmati per la comunicazione con componenti interni, Local Manager registrati e per l'autenticazione per l'interfaccia utente o le API di NSX Manager.

È possibile visualizzare i certificati esterni (interfaccia utente/API) e tra siti in NSX Manager. I certificati interni non possono essere visualizzati o modificati.

Nota: Non abilitare il VIP esterno di Local Manager prima di registrare Local Manager in Global Manager. Quando è necessario utilizzare federazione di NSX e PKS nello stesso Local Manager, completare le attività di PKS per creare un VIP esterno e modificare il certificato di Local Manager prima di registrare Local Manager in Global Manager.

Certificati per Global Manager e Local Manager

Dopo aver aggiunto un Local Manager nel Global Manager, viene stabilita una relazione di attendibilità scambiando certificati tra Local Manager e Global Manager. Questi certificati vengono copiati anche in ciascuno dei siti registrati in Global Manager. A partire da NSX 4.1.0, il certificato utilizzato per stabilire l'attendibilità con il Global Manager viene generato solo quando il Local Manager viene registrato con il Global Manager. Lo stesso certificato viene eliminato se Local Manager esce dall'ambiente federazione di NSX.

Vedere la tabella Certificati per Global Manager e Local Manager per un elenco di tutti i certificati specifici di federazione di NSX creati per ogni appliance e dei certificati che queste appliance si scambiano tra loro:

Tabella 2. Certificati per Global Manager e Local Manager
Convenzione di denominazione nel Global Manager o Local Manager Scopo Sostituibile? Validità predefinita
I certificati seguenti sono specifici di ogni appliance di federazione di NSX.
APH-AR certificate
  • Per il Global Manager e ogni Local Manager.
  • Utilizzato per la comunicazione tra siti tramite il canale AR (canale Async-Replicator).
 Sì, utilizzare service_type=APH. Vedere Sostituzione dei certificati tramite API. 10 anni
GlobalManager
  • Per il Global Manager.
  • Certificato PI per Global Manager.
 Sì, utilizzare service_type=GLOBAL_MANAGER. Fare riferimento a Sostituzione dei certificati tramite API. 825 giorni
Cluster certificate
  • Per il Global Manager e ogni Local Manager.
  • Utilizzato per la comunicazione dell'interfaccia utente/API con il VIP del cluster del Global Manager o Local Manager.
Sì, utilizzare service_type=MGMT_CLUSTER. Fare riferimento a Sostituzione dei certificati tramite API. 825 giorni
API certificate
  • Per il Global Manager e ogni Local Manager.
  • Utilizzato per la comunicazione dell'interfaccia utente/API con i singoli nodi Global Manager e Local Manager e per ciascuna posizione aggiunta al Global Manager.
Sì, utilizzare service_type=API. Vedere Sostituzione dei certificati tramite API. 825 giorni
LocalManager
  • A partire da NSX 4.1, viene generato solo quando i server Local Manager si trovano nell'ambiente federazione di NSX. Il certificato viene eliminato se Local Manager esce dall'ambiente federazione di NSX.
  • Certificato PI per questo Local Manager specifico.
Sì, utilizzare service_type=LOCAL_MANAGER. Vedere Sostituzione dei certificati tramite API. 825 giorni
LM e GM condividono i propri certificati Cluster, API e APH-AR. Se un certificato è firmato dalla CA, viene sincronizzata la CA ma non il certificato.

Utenti PI (Principal Identity) per federazione di NSX

Dopo aver aggiunto un Local Manager al Global Manager, vengono creati i seguenti utenti PI con i ruoli corrispondenti.
Tabella 3. Utenti PI (Principal Identity) creati per federazione di NSX
Appliance di federazione di NSX Nome utente PI Ruolo utente PI
Global Manager LocalManagerIdentity

Uno per ogni Local Manager registrato in questo Global Manager.

 Revisore
Local Manager GlobalManagerIdentity Amministratore aziendale
LocalManagerIdentity
Uno per ogni Local Manager registrato nello stesso Global Manager. Per ottenere l'elenco di tutti gli utenti PI Local Manager perché non sono visibili nell'interfaccia utente, immettere il seguente comando API: 
GET https://<local-mgr>/api/v1/trust-management/principal-identities
Revisore