El sistema crea los certificados necesarios para la comunicación entre los dispositivos de NSX y la comunicación externa, incluidos los dispositivos de Federación de NSX. Este tema incluye información de diversos certificados

A partir de la versión 4.1.0, se introdujeron varios tipos de certificados nuevos que no estaban en las versiones 3.2.x, como los certificados CCP, APH_TN, CBM_CLUSTER_MANAGER y CBM_CORFU. Estos eran parte del requisito de EAL4 para que los certificados se pudieran reemplazar. Los verá como parte del proceso de actualización.
Nota: En una implementación de NSX federada, los certificados procedentes de otras ubicaciones aparecerán en el panel Certificados. Esos certificados se muestran con nombres que comienzan con Site, como Site certificate L=PA,ST=CA,C=US, Site certificate UID=369cd66c-..., o solo con su UUID 637a2ebf-84d1-4548-a0ba-51d9420672ff. Si dichos certificados caducan, reemplácelos en el sitio de origen en el que se almacena la clave privada correspondiente. Puede encontrar esa información en el campo Utilizado por en la interfaz de usuario o en la API. Si reemplaza los certificados en cualquier Administrador global o Administrador local de origen, el sistema los sincronizará automáticamente en la implementación federada.

La tabla Certificados para NSX Manager indica los detalles del certificado, incluido el tiempo que los certificados son válidos solo para nuevas implementaciones. Los nuevos certificados no se generan durante las actualizaciones, por lo que las fechas de validez de los certificados reflejarán la fecha de caducidad predeterminada del certificado de una versión de NSX anterior. Para reemplazar los certificados autofirmados existentes por certificados firmados por una CA, consulte los detalles en Reemplazar certificados a través de API. Para obtener más información sobre los eventos de conformidad de seguridad, consulte el Catálogo de eventos de NSX.

Tabla 1. Certificados para instancias de NSX Manager
Convención de nomenclatura de certificados Propósito Reemplazable mediante service_type Validez predeterminada
APH (APH_AR) Clave pública de servidor APH (Appliance Proxy Hub) y replicador asincrónico para comunicación cruzada, para Federation Sí, usar service_type=APH. 825 días
APH_TN Certificado APH (hub de proxy de dispositivo) para la comunicación dentro del clúster y el nodo de transporte (TN) Sí, usar service_type=APH_TN. 825 días
API Certificado de servidor de API para el nodo de NSX Manager Sí, usar service_type=API. 825 días
CCP Certificado del plano de configuración de control para comunicación con los nodos de transporte Sí, usar service_type=CCP. 10 años
MGMT_CLUSTER (VIP) Certificado del servidor API utilizado por VIP Sí, usar service_type=MGMT_CLUSTER. 825 días
CBM_CLUSTER_MANAGER Certificado de cliente de Corfu Sí, usar service_type=CBM_CLUSTER_MANAGER. 100 años
CBM_CORFU Certificado de servidor de Corfu Sí, usar service_type=CBM_CORFU. En la versión 4.1.0, 825 días. A partir de la versión 4.1.1, 100 años.

Certificados para comunicación de Federación de NSX

De forma predeterminada, el Administrador global utiliza certificados autofirmados para comunicarse con componentes internos, Administrador locals registrados y para la autenticación de la interfaz de usuario o las API de NSX Manager.

Puede ver los certificados externos (interfaz de usuario/API) y entre sitios en NSX Manager. Los certificados internos no se pueden ver ni editar.

Nota: No habilite la VIP externa de Administrador local antes de registrar el Administrador local en el Administrador global. Cuando Federación de NSX y PKS deben usarse en el mismo Administrador local, complete las tareas de PKS para crear una VIP externa y cambiar el certificado de Administrador local antes de registrar el Administrador local en Administrador global.

Certificados para Administrador globals y Administrador locals

Después de agregar un Administrador local al Administrador global, se establece una relación de confianza mediante el intercambio de certificados entre Administrador local y Administrador global. Estos certificados también se copian en cada uno de los sitios registrados con Administrador global. En NSX 4.1.0, el certificado utilizado para establecer la confianza con el Administrador global solo se genera cuando el Administrador local se registra en el Administrador global. El mismo certificado se elimina si el Administrador local sale del entorno de Federación de NSX.

En la tabla Certificados para Global Managers y Local Managers puede consultar una lista de todos los certificados específicos de Federación de NSX creados para cada dispositivo y los certificados que estos dispositivos intercambian entre sí:

Tabla 2. Certificados para Administrador globals y Administrador locals
Convención de nomenclatura en el Administrador global o el Administrador local Propósito ¿Reemplazable? Validez predeterminada
Los siguientes son certificados específicos de cada dispositivo de Federación de NSX.
APH-AR certificate
  • Para el Administrador global y cada Administrador local.
  • Se utiliza para la comunicación entre sitios mediante el canal AR (canal Async-Replicator).
 Sí, usar service_type=APH. Consulte Reemplazar certificados a través de API. 10 años
GlobalManager
  • Para el Administrador global.
  • Certificado PI para el Administrador global.
 Sí, usar service_type=GLOBAL_MANAGER. Consulte Reemplazar certificados a través de API. 825 días
Cluster certificate
  • Para el Administrador global y cada Administrador local.
  • Se utiliza para la comunicación de la interfaz de usuario o la API con la VIP del Administrador global o del clúster de Administrador local.
Sí, usar service_type=MGMT_CLUSTER. Consulte Reemplazar certificados a través de API. 825 días
API certificate
  • Para el Administrador global y cada Administrador local.
  • Se utiliza para la comunicación de la interfaz de usuario/API con los nodos de Administrador global y Administrador local individuales para cada una de las ubicaciones que se agregan al Administrador global.
Sí, usar service_type=API. Consulte Reemplazar certificados a través de API. 825 días
LocalManager
  • A partir de NSX 4.1, se genera solo cuando los servidores de Administrador local se encuentran en el entorno de Federación de NSX. El certificado se elimina si el Administrador local sale del entorno de Federación de NSX.
  • Certificado PI para este Administrador local específico.
Sí, usar service_type=LOCAL_MANAGER. Consulte Reemplazar certificados a través de API. 825 días
El LM y el GM comparten sus certificados de clúster, API y APH-AR entre ellos. Si un certificado está firmado por una CA, la CA se sincronizará, pero ese certificado no.

Usuarios de identidad principal (PI) para Federación de NSX

Después de agregar un Administrador local al Administrador global, se crean los siguientes usuarios de PI con las funciones correspondientes.
Tabla 3. Usuarios de identidad principal (PI) creados para Federación de NSX
Dispositivo Federación de NSX Nombre de usuario de PI Función de usuario de PI
Global Manager LocalManagerIdentity

Uno para cada Administrador local registrado con este Administrador global.

 Auditor
Administrador local GlobalManagerIdentity Administrador empresarial
LocalManagerIdentity
Uno para cada Administrador local registrado con el mismo Administrador global. Para obtener una lista de todos los usuarios de PI del Administrador local (no están visibles en la interfaz de usuario), introduzca el siguiente comando de API: 
GET https://<local-mgr>/api/v1/trust-management/principal-identities
Auditor