Nota: ¡Solo siga este artículo para entornos de federación de NSX-T administrados por VCF!
Antecedentes:
Existen diferentes tipos de certificados de NSX-T, como se describe a continuación:
Nombre del certificado |
Propósito: |
Reemplazable |
Validez predeterminada |
Gato |
Este es un certificado de API que se utiliza para la comunicación externa con nodos individuales de NSX Manager a través de la interfaz de usuario o la API. |
Sí |
825 días |
clúster de MP |
Este es un certificado de API que se utiliza para la comunicación externa con el clúster de NSX Manager mediante la VIP del clúster, a través de la interfaz de usuario o la API. |
Sí |
825 días |
Administrador local |
Este es un certificado de identidad principal de la plataforma para la federación. Si no utiliza la federación, este certificado no se utiliza. |
Sí |
825 días |
Para las soluciones VCF:
Tomcat y mp-cluster se reemplazan por certificados de CA firmados por VMCA desde vCenter. Es posible que los certificados mp-cluster y Tomcat aún estén allí, pero no se están utilizando.
NSX-T Manager con VCF:
- Tomcat: el nodo 1 > no se utiliza
- mp-cluster: la VIP > no se utiliza
Se reemplazó durante la instalación por lo siguiente:
Si desea comprobar si se está utilizando el certificado, ejecute la siguiente API en la plataforma Postman:
GET https://<nsx-mgr>/api/v1/trust-management/certificates/<certificate-id>
El certificado de administrador local es el certificado de identidad principal que se utiliza para comunicarse con otros sitios de la federación.
Un entorno
de federación de NSX-T contiene un clúster de administrador global activo y uno en espera, y uno o más clústeres de administrador local.
Figura 1: Muestra tres ubicaciones con clústeres de administrador global activos y en espera en las ubicaciones 1 y 2 con clústeres de administrador local en las tres ubicaciones.
Cómo determinar la cantidad de clústeres de administradores locales:
Para comprobar el entorno y averiguar cuántos clústeres de administrador local hay, siga los pasos y la
captura de pantalla que se indican a continuación:
En System >
Configuration>
Location Manager:
- En la parte superior del Local Manager, se muestra en qué clúster inició sesión. En este ejemplo, iniciamos sesión en un clúster de administrador local.
- En el centro de la página, se muestran los clústeres de administrador global, y cuál clúster está activo y cuál está en espera.
- Otros clústeres de administradores locales se ven en la parte inferior, en Sitios remotos.
Figura 2: Entorno de clúster de administrador local
Procedimiento para reemplazar certificados autofirmados de administrador local:
- Inicie sesión en NSX Manager en el clúster de Local Manager.
- Recolecte un respaldo de NSX-T antes de continuar. ¡Este paso es importante!
- Sistema>Administración del ciclo de> vida Respaldo y restauración>Iniciar respaldo
Figura 3: Recopile el respaldo de NSX-T.
- Compruebe los certificados y la fecha de vencimiento.
- Haga clic en System>Settings>Certificates
En el siguiente ejemplo, se muestra en rojo la fecha de vencimiento de los certificados de administrador local:
Figura 4: Fecha de vencimiento de los certificados de administrador local
Hay un certificado por clúster de Local Manager, independientemente de la cantidad de NSX Manager que haya dentro del clúster.
- Inicie sesión en cualquier instancia de NSX Manager del clúster 1 de Local Manager.
- Generar una nueva CSR.
- Haga clic en Configuración>del sistema>Certificados>CSR>Generar CSR
Figura 5: Genere una nueva CSR.
- Ingrese el nombre común como local-manager.
- Ingrese el nombre como LocalManager.
- El resto son detalles comerciales y de ubicación del usuario (esto se puede copiar de un certificado antiguo que vence).
- Haga clic en Guardar.
Figura 6: Ingrese los nombres de CSR y la información de localidad.
- Cree un certificado autofirmado mediante la CSR generada.
- Haga clic en la casilla >de verificación Nueva CSR Generar certificado de autofirma deCSR> para CSR.
Figura 7: Cree un certificado autofirmado.
- Asegúrese de que el Certificado de servicio esté establecido en No y haga clic en Guardar.
- Vuelva a la pestaña Certificados , busque el Nuevo certificado y copie el ID del certificado.
Figura 8: Copiar ID de certificado nuevo
- Reemplace el certificado de identidad de entidad de seguridad para el administrador local.
- Usuario para instalar la plataforma Postman.
- En la pestaña Autorización , seleccione Tipo>de autenticación básica.
- Ingrese los detalles de inicio de sesión de NSX-T Manager.
Figura 9: Ingrese los detalles de inicio de sesión de NSX-T Manager.
- En la pestaña Encabezados, cambie "application/xml" a "application/json".
Figura 10: En Postman, cambie "application/xml" a "application/json"
- En la pestaña Cuerpo , seleccione el
POST API
comando.
- Seleccione Raw y, a continuación, seleccione JSON.
- En el cuadro junto a POST, ingrese URL
https://<nsx-mgr-IP-local-manager-clusterX>/api/v1/trust-management/certificates?action=set_pi_certificate_for_federation
- En lo anterior, la URL es la IP utilizada para cualquier NSX Manager dentro de un clúster de Local Manager específico.
- En la sección del cuerpo , ingrese lo siguiente en dos líneas, como se muestra en la captura de pantalla:
{ "cert_id": "<certificate id, copied from step 3>",
"service_type": "LOCAL_MANAGER" }
Figura 11: Ingrese la URL de cualquier instancia de NSX Manager dentro de un clúster específico de Local Manager.
- Haga clic en Enviar y asegúrese de ver el resultado 200 OK.
- Repita los pasos del 1 al 4 en cada clúster de administradores locales 2 y 3.
Una vez que se completan estos pasos, crea un certificado nuevo en cada clúster de Local Manager y reemplaza el certificado de identidad principal en cada clúster de Local Manager.
Ahora es el momento de eliminar los certificados antiguos que vencen de cada uno de los tres clústeres de administradores locales.
- Compruebe que el certificado ya no esté en uso.
- Copiar ID de certificado
- Abrir cartero
- Seleccione GET API en lugar de POST.
-
Ingresar URL https://<nsx-mgr-IP-local-manager-clusterX>/api/v1/trust-management/certificates/<certificate-id>
- Busque "used_by" y confirme que tenga corchetes vacíos.
"used_by" : [ ],
"resource_type" : "certificate_self_signed",
"id" : "9cd133ca-32fc-48a2-898b-7acd928512a5",
"display_name" : "local-manager",
"description" : "",
"tags" : [ ],
"_create_user" : "admin",
"_create_time" : 1677468138846,
"_last_modified_user" : "admin",
"_last_modified_time" : 1677468138846,
"_system_owned" : false,
"_protection" : "NOT_PROTECTED",
"_revision" : 0
}
- Vaya a Configuración >del sistema >Certificados y seleccione el certificado requerido.
Figura 12: Seleccione el certificado necesario.
- Haga clic en Delete>Delete.
Figura 13: Elimine el certificado.
- Confirme que la identidad principal esté funcionando y utilizando los nuevos certificados:
- Abrir cartero
- Seleccione GET.
- URL de ejecución
https://<nsx-mgr-IP-local-manager-clusterX>/api/v1/trust-management/principal-identitie
.
- El resultado debe ser similar al siguiente, "certificate_id" debe mostrar el ID de certificado recién creado.
![ID de certificado muestra el ID del nuevo certificado](https://supportkb.dell.com/img/ka06P0000011FprQAE/ka06P0000011FprQAE_es_MX_6.jpeg)
Figura 14: ID de certificado muestra el ID de certificado nuevo.