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 e 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 nell'interfaccia utente in Dove utilizzato o nel campo Used By dell'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é i nuovi certificati non vengono generati durante gli aggiornamenti, le date di validità del certificato rifletteranno la data di scadenza predefinita di una versione di NSX precedente. Per sostituire i certificati autofirmati esistenti con certificati firmati dalla CA, fare riferimento ai dettagli in Sostituzione di certificati. 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-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 (ovvero tomcat) Certificato del server API per il nodo NSX Manager Sì, utilizzare service_type=API. 825 giorni
API - Client Corfu Certificato client Corfu Sì, utilizzare service_type=CBM_API. 100 anni
AR - Client Corfu Certificato client Corfu Sì, utilizzare service_type=CBM_AR. 100 anni
CCP - Client Corfu Certificato client Corfu del piano di configurazione di controllo Sì, utilizzare service_type=CBM_CCP. 100 anni
CSM-Client Corfu Certificato client Corfu Sì, utilizzare service_type=CBM_CSM. 100 anni
CCP Certificato Control Configuration Plane per comunicare con i nodi di trasporto Sì, utilizzare service_type=CCP. 10 anni
Cluster (ovvero mp-cluster) Certificato del server API utilizzato da VIP Sì, utilizzare service_type=MGMT_CLUSTER. 825 giorni
Gestore cluster - Corfu Certificato client Corfu Sì, utilizzare service_type=CBM_CLUSTER_MANAGER. 100 anni
Inventario CM - Client Corfu Certificato client Corfu

Sì, utilizzare service_type=CBM_CM_INVENTORY.

 100 anni
Server 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.
Client GM-Corfu Certificato client Corfu presente solo in Global Manager Sì, utilizzare service_type=CBM_GM. 100 anni
Report IDPS - Client Corfu Certificato client Corfu Sì, utilizzare service_type=CBM_IDPS_REPORTING. 100 anni
Gestore messaggistica - Client Corfu Certificato client Corfu Sì, utilizzare service_type=CBM_MESSAGING_MANAGER. 100 anni
Monitoraggio - Client Corfu Certificato client Corfu Sì, utilizzare service_type=CBM_MONITORING. 100 anni
MP - Client Corfu Certificato client Corfu Sì, utilizzare service_type=CBM_MP. 100 anni
Gestore sito - Client Corfu Certificato client Corfu Sì, utilizzare service_type=CBM_SITE_MANAGER 100 anni
Coordinatore aggiornamento - Client Corfu Certificato client Corfu Sì, utilizzare service_type=CBM_UPGRADE_COORDINATOR. 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 di certificati. 10 anni
GlobalManager
  • Per il Global Manager.
  • Certificato PI per Global Manager.
 Sì, utilizzare service_type=GLOBAL_MANAGER. Fare riferimento a Sostituzione di certificati. 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 di certificati. 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 di certificati. 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 di certificati. 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