Buenas chic@s! En el día de hoy vengo hablaros acerca de como reemplazar certificados en NSX-T. Si estas aquí es porque seguramente tienes un problema, o lo vas a tener. En este caso, este post esta orientado al problema relacionado con los certificados y su temprana caducidad, vamos al lio 🙂
Introducción al problema
Si estas leyendo esto, es que te has encontrado muchos de los certificados relacionados con los componentes de NSX a punto de caducar, o caducados. Esta bonita sorpresa es debido a que cuando se sube de la versión 3.2.x a la 4.1.x, esta contiene un BUG que hace que todos los certificados pasen de 100 años a 825 días. Si quieres leer algo mas, aquí tienes un KB relacionado con el tema.
Aquí te dejo un par de imágenes con los errores que te puedes encontrar.
Una vez visto esto, vamos a detallar los paso para solucionar esto.
Configuración
Para solucionar este problemas vamos a realizar los siguientes pasos:
- Identificar los certificados caducados
- Obtener los ID de los nodos de nuestro clúster de NSX-T
- Generar todos los CSR
- Generar los certificados contra la CA de NSX-T
- Chequear el estado de los nuevos certificados
- Aplicar los nuevos certificados
- Certificados del tipo CMB_*
- Resto de certificados
1.Identificar los certificados caducados
Lo primero que deberíamos hacer es sacar todos los certificados que están caducados y que estan en uso. Una vez lo tenemos, deberíamos rellenar una tabla como esta.
Si pulsamos en ella para ampliarla, veremos que en mi caso he añadido un campo que he llamado «Service_Type».Este campo es importante, ya que luego lo usaremos para las llamadas a la API. Para rellenar ese campo deberemos hacer uso del siguiente enlace.
https://docs.vmware.com/en/VMware-NSX/4.1/administration/GUID-3DD19193-770C-47F3-A0F3-7B7703F274C8.html
2.Obtener los ID de los nodos de nuestro clúster de NSX-T
Una vez tenemos identificados los certificados y los servicios asociados a ellos, debemos averiguar cuales son lo ID de los nodos que componen el clúster. Para ellos tenemos varios formas:
- CLI : Con el comando «get cluster status»
- UI: Desde la parte de System–> Appliances–> Seleccionado el nodo
En mi caso solo tengo un NSX Manager desplegado, en un entorno de producción deberíamos de tener un mínimo 3 nodos.
Si nos fijamos en el nombre del certificado caducado, el ID coincide con el que hemos obtenido previamente. En caso de quieras asegurarte, si pulsamos sobre el numero»1″, debajo del campo «Where Used», nos debería de salir el ID.
3.Generar todos los CSR
Una vez tenemos todos los certificados identificados, los nodos y lo servicios es hora de generar todos los CSR. En mi caso tenia caducados 12 certificados, por lo tanto deberé genera 12 CSR.
Tener cuidado con una cosa, os podrias encontrar con certificados que están caducados o a punto de caducar pero que no están en uso. Por ello, fijaros en el campos «Where Used», si esta en 0, es que no se esta usando.
Para generar los CSR, nos iremos a la parte de System–> Certificates–> Certificates y le daremos a «Generate CSR».
En mi caso para seguir un poco el orden, voy a poner el el mismo «Common Name» que tenia anteriormente. Debemos repetir esto para cada certificado que tenemos que renovar.
4.Generar los certificados contra la CA de NSX-T
Una vez creados todos los CSRs, ha tocado el momento de firmarlos con la CA interna, para ello nos desplazamos al menú de CSRs. Pulsamos sobre los 3 puntitos y clicamos en «Self Sign Certificate for CSR».
Deseleccionamos «Service Certificate» y pulsamos en «Save». Repetiremos el paso por cada uno de los certificados.
5.Chequear el estado de los nuevos certificados
Una vez tenemos lo certificados listos pasa usarse, vamos a comprobar que su estado es correcto. Para ello lanzaremos la siguiente llamada a la API.
GET https://<nsx-mgr>/api/v1/trust-management/certificates/<cert-id>?action=validateUna vez lanzado podemos comprobar que nos devuelve un código 200, además un «Status:OK». Por lo tanto chequeo realizado.
6.Aplicar los nuevos certificados
Para aplicar los certificados, los dividiremos en 2 tipos, empezaremos por:
Certificados del tipo CMB_*
Para cambiar todos los certificados cuyo servicio empiece por «CMB_*», usaremos la siguiente sintaxis:
POst https://NSXT-MANAGER_NAME_OR_IP/api/v1/trust-management/certificates/
CERTIFICATE_ID?action=apply_certificate&service_type=CBM_*=NODE_IDOs dejo una de la sintaxis que lance yo:
POST https://nsxt-manager.vmwarelab.local/api/v1/trust-management/certificates/
6acd1c99-dfd4-4f17-82db-a90968b662f8?action=apply_certificate&service_type=CBM_IDPS_REPORTING&node_id=7f772042-686d-8c55-5024-8d25cf4ec210
Una vez lanzado y devuelto el código 200, podemos observar que ya tenemos el certificados aplicado al servicio, fijaros en el «Where Used». Ahora ya podríamos borrar el que no nos vale.
Seguiremos aplicando el resto de certificados CBM_*, pero debemos tener un paso mas para 2 de ellos.
El primero de ellos seria el «Service_type=CBM_CLUSTER_MANAGER«, una vez aplicado debemos reiniciar su servicio, podemos hacerlo desde root, con el siguiente comando.
/etc/init.d/nsx-cluster-boot-manager restart
Una vez reiniciado, podremos seguir.
Otro que debemos tener en cuenta es es «Service_type=CBM_MP«, una vez aplicado se nos reiniciara el servicio de forma automática, así que, que no cunda el pánico.
Resto de certificados
En los casos del MGMT_CLUSTER,API y LOCAL_MANAGER, usaremos una sintaxis diferente.
MGMT_CLUSTER
POST https://NSXT-MANAGER_NAME_OR_IP/api/v1/trust-management/certificates/<cert-id>?action=apply_certificate&service_type=MGMT_CLUSTERAPI
POST https://NSXT-MANAGER_NAME_OR_IP/api/v1/trust-management/certificates/<cert-id>?action=apply_certificate&service_type=API&node_id=<node-id>LOCAL_MANAGER
POST https://NSXT-MANAGER_NAME_OR_IP/api/v1/trust-management/certificates/<cert-id>?=apply_certificate&service_type=LOCAL_MANAGER
