Reemplazando Certificados en Aria Suite (vRealize Suite)

Una de las operaciones de día 2 que mas terror nos daba hace unos años o posiblemente con la que mas sufríamos, fue el reemplazo de certificados para las soluciones VMware. Los que tuvimos que luchar esa batalla, recordaremos lo tedioso que era tener que reemplazar cada uno de los certificados de una solución de forma manual y encontrarse errores diferentes conforme avanzábamos.

Por suerte, esto ha cambiado y ahora Aria Suite Lifecycle (antes vRealize Suite Lifecycle Manager) nos ofrece una forma fácil, rápida y segura de reemplazar los certificados, por lo menos de los productos asociados a la Aria Suite (antes vRealize Suite) y por supuesto que sean gestionados desde Aria Suite Lifecycle.

En el procedimiento a continuación estaremos explicando cómo reemplazar los certificado autofirmados por certificados customizados, es decir certificados firmados por una entidad certificadora del cliente o CA Enterprise. El cambio de un certificado de un autofirmado por otro igualmente autofirmado, es similar al proceso explicado en este post y simplemente costa de los siguientes dos pasos por lo que no representa mayor tiene mayor dificultad.

Crear un certificado en el servicio de locker de vRealize Suite lifecycle Manager
Reemplazar el certificado viejo por el nuevo

Reemplazo de Certificado autofirmado por certificados customizados

Lo primero que debemos tener presente es que el reemplazo de certificados autofirmados por certificados customizados, incluye la participación del equipo de seguridad del cliente, quien será el encargado de proveernos los certificados validos para nuestros productos.

Una manera fácil de hacer esto es solicitar al cliente el/los certificados en extensión .pem y de esta manera evitamos tener que generar un Certificate Signing Request (CSR), que si bien podemos generarlos desde vRealize Suite Lifecycle Manager, pues lo único que haría es agregarnos un paso mas en el proceso. Por esta razón, recomiendo solicitar al cliente crear directamente los certificados en su herramienta y exportarlo en el formato indicado y con el Key sin cifrar.

Una vez nos han enviado el/los certificados podemos continuar con los siguientes pasos:

1. Verificar que los certificados los entreguen en .pem y que estén bien generados. Para esto podemos abrir el archivo .pem con un editor de texto y verificar que tenga la siguiente estructura.

2. Algunas veces nos envían el certificado con el key cifrado, entonces debemos pedir que nos envíen el Key sin clave. Y Rearmar el .pem en otro archivo pero esta vez utilizando el Key sin cifrar.

Recordemos que la sección asociada al Key debería contener los siguiente:

—–BEGIN RSA PRIVATE KEY—–

—–END RSA PRIVATE KEY—–

3. Una vez hemos verificado la estructura del certificado podemos ir al servicio de Locker de Aria Suite Lifecycle e importarlos en -> Certificates -> Import. En este paso solo debemos hacer click en BROWSER FILE y buscar el archivo .pem que construimos en el paso anterior. Automáticamente los campos Private Key y Certificate Chain serán poblados. Finalizamos el proceso haciedo click en el boton IMPORT

4. Una vez importados se mostraran los detalles del certificado de manera que podremos verificar que los Subject Alternative Name de cada certificado contenga los FQDN de todos los nodos de cada solución incluyendo el FQDN del VIP del balanceador que le corresponda, de ser necesario.

5. Si vamos a reemplazar el certificado de una solucion que se encuentra detrás de un balanceador como por ejemplos VMware Identity Manager (vIDM), ahora llamado Workspace One Access (WS1), debemos primero reemplazar el certificado en el balanceador siguiendo la guía de cada fabricante.

6. Una vez realizado el cambio de certificados en el balanceador, debemos realizar la action Re-trust Load Balancer en el servicio Lifecycle Operations -> Environments -> Para este ejemplo globalenvironment (ambiente asociado a vIDM o WS1).

7. Para efectuar el reemplazo de certificados lo único que debemos hacer es ir al servicio de Lifecycle Operations -> Environments -> click en VIEW DETAILS del ambiente en cuestión (para este caso globalenvironment) -> Click en los tres puntos (…) para listar mas opciones -> Replace Certificate

8. A continuación nos muestra un resumen del certificado actual

9. Hacemos click en NEXT para seleccionar el nuevo certificado (importado) desde la lista desplegable

10. Si el certificado es de una solución como vIDM del cual dependen otros productos, nos mostrará que durante el proceso de cambio de certificados hará un Re-Trust sobre los productos listados allí. Click en NEXT para continuar.

11. A continuación podremos seleccionar si queremos que Aria Suite Lifecycle cree por nosotros un snapshot en la VMs involucradas . Se recomienda esta acción a no ser que ya hayamos tomado un snapshot directamente desde el vCenter. Luego Click en NEXT

12. Para validar que el certificado que vamos a aplicar es correcto, debemos ejecutar un PRECHECK haciendo click en el botón RUN PRECHECK

13. Después de finalizar el PRECHECK podemos ver que nos solicita una acción de aceptar y nos indica que el remplazo de los certificados sobre los balanceadores debe hacerse manual como lo comentamos anteriormente. Procedemos entonces a hacer click en ACEPTAR y después en FINISH

Nota 1: Si por alguna razon, reemplaza el certificado de una solucion de Aria Suite (vRealize Suite) sin haber cambiado el certificado del balanceador recibirá una notificación en el Aria Suite Lifecycle (vRealize Suite Lifecycle Manager) indicándole que debe reemplazar el certificado en el balanceador (Importar el certificado nuevo en NSX-T, NSX-v, F5, o el balanceador que corresponda) siguiendo la guia del fabricante, como comentamos anteriormente.

Nota 2: De igual forma, si se cambia el certificado del balanceador despues de cambiar el certificado de vIDM entonces recibirá una unas notificaciones en Aria Suite Lifecycle indicándole que debe realizar una acción de re-trust en cada una de las soluciones que se encuentren detras de ese balanceador. Comenzando de nuevo por Workspace One Access (WS1A).

Nota 3: Sino hacemos esto vamos a recibir un Bad Gateway al intentar a hacer login en WS1A. Para evitar esto, recomendamos reemplazar el certificado del balanceador en primer lugar como lo hemos mencionado anteriormente

14. Si realizamos el reemplazo del certificado en el balanceador, en primera instancia como lo hemos recomendado, la URL de acceso al WS1 (VIP)después del reemplazo de los certificados del globalenvironment, debería mostrar el sitio como seguro y con los detalles del certificado que hemos importado.

15. Como hemos realizado un cambio que esta por fuera del control de Aria Suite Lifecycle (vRealize Suite Lifecycle Manager) debemos realizar la acción de Re-trust Load Balancer, desde la solucion de Workspace One Access / VMware Identity Manager (globalenvironment) y para esto vamos a Environment -> global environment -> click en los tres puntos (…) para mas opciones y luego click en Re-trust Load Balancer

16. (Opcional) Cuando termine vamos a cada unos de los productos que estaba integrados con vIDM o WS1A, como por ejemplo Aria Operations (antes vRealize Operations Manager), Aria Automation (antes vRealize Automation), Aria Operations for Logs (vRealize Log Insight), etc. En algunas ocasiones podríamos necesitar hacer click Re-Trust with Identity Manager en cada una de las soluciones de Aria Suite (vRealize Suite), aunque este proceso por lo general se hace automático durante el reemplazo de certificados de Workspace One Access (WS1A).

17. El reemplazo de certificados de todas las soluciones de la Aria Suite tienen el mismo procedimiento que hemos mencionado para el Workspace One Access (globalenvironement), razon por la cual no haremos este post mas largo.

Nota 4: Para las soluciones que no están detrás de un balanceador, es claro que podemos hacer directamente el reemplazo de certificados siguiendo los pasos 7-13.

Por ultimo, vamos a realizar el reemplazo de certificados de la solucion Aria Suite Lifecycle (vRealize Suite Lifecycle Manager). El reemplazo de esta solucion no tiene un orden especifico y se puede realizar en primero o ultimo lugar. Vemos entonces los siguientes pasos.

Remplazo de certificados de Aria Suite Lifecycle (vRealize Suite Lifecycle Manager)

1. En el servicio de Locker vamos a crear o importar un certificado para esta solucion. Como ya explicamos como importar un certificado, en este caso generaremos uno nuevo desde la opción -> Certificates -> Add Certificate. Recordar que si lo generamos desde el servicio de Locker, sera entonces un certificado autofirmado o Self-Signed.

2. En Lifecycle Operations click en –> Settings -> Change Certificate

3. Click en el boton REPLACE CERTIFICATE

4. Revisamos los detalles del certificado actual y hacemos click en NEXT

5. Seleccionamos el nuevo certificado, que importamos o generamos en el servicio de Locker y click en NEXT

6. Click en RUN PRECHECK para verificar que todo este bien con el certificado y si todo esta ok, click en FINISH

Nota: Después de un par de minutos, en el servicio de Lifecycle Operations deberíamos ver el Request asociado a este reemplazo de certificados como Completed.

Y podemos validar que el Subject del certificado ahora contienes los datos que configuramos en el nuevo certificado.

Nota 5: (Opcional) Si ha realizado reemplazo de certificados para WS1A antes de cambiar los de Aria Suite Lifecycle entonces realize una acción de RE-REGISTER dentro del servicio de Lifecycle Operations -> Settings -> Authentication Provider. Debería haberse realizado de manera automática, pero si tiene algún problema con la autenticación de usuarios de dominio en la solucion Aria Suite Lifecycle, este paso solucionara el inconveniente.

Referencias

ATENCIÓN!!!

TODOS LOS NOMBRES DE VMS USADOS EN ESTE BLOG SON INVENTADOS Y OBEDECEN A UN AMBIENTE DE LABORATORIO PROPIO, UTILIZADO PARA FINES DE ESTUDIO.

Reemplazo de certificados vCenter Server 6.5 U1 con PSC embebido

en 15 junio, 201820 septiembre, 2024 por Diego Felipe Tunubalá Medinaen vCenter Server, vSphereDeja un comentario

Existen varias opciones para reemplazar los certificados de la infraestructura vSphere y esta tarea puede contar con más o menos pasos de ejecución, sin ser necesariamente difícil, dependiendo del nivel de seguridad que espera la compañía.

Este artículo está orientado a aplicar el método de reemplazo Hibrido que es suficiente y recomendado para la mayoría de las compañías que buscan cumplir con un estándar de seguridad. Este método se centra en el reemplazado únicamente de los certificados Machine SSL de vCenter dejando la tarea de firmar los Solution User y los Certificados de los hosts a la CA (Certificate Authority) de VMware denominada VMCA (VMware Certificate Authority) alojada en el PSC, conociéndose este proceso como certificados auto firmados.

Para un vCenter Server con PSC (Platform Service Controller) embebido, VMCA estará alojada dentro del mismo Appliance, sin embargo; para un despliegue de vCenter Server Con PSC Externo, estará alojada dentro del appliance de PSC y no dentro del appliance del vCenter.

Para iniciar el proceso de reemplazo de certificados SSL en un vCenter Server 6.5 U1 con Platform Service Controller Embebido o Externo se deben tener en cuenta los siguiente KB oficiales de los cuales se ha extraído de manera simple y grafica los pasos para su correcta aplicación, de manera que no exista problema en la ejecución del mismo.

Nota: Si se cuenta con un despliegue de vCenter con PSC Externo basta con realizar el procedimiento descrito a continuación primero en el PSC y después en el vCenter, pero para mayor entendimiento crearemos un nuevo artículo para ese caso específico.

Referencias:

1. Replacing default certificates with CA signed SSL certificates in vSphere 6.x (2111219)

2. Creating a Microsoft Certificate Authority Template for SSL certificate creation in vSphere 6.x (2112009)

3. Obtaining vSphere certificates from a Microsoft Certificate Authority (2112014)

4. Replacing a vSphere 6.x Machine SSL certificate with a Custom Certificate Authority Signed Certificate (2112277)

PASO 1: Creación de una plantilla Microsoft Certificate Authority para la creación de certificados SSL en vSphere 6.x.

Para realizar esta tarea nos podemos apoyar en el KB2112009 mencionado en las referencias, sin embargo, el procedimiento es detallado a continuación.

1. Al conectarse al servidor CA, generará los certificados a través de una sesión RDP.

2. Haga clic en Inicio> Ejecutar, escriba certtmpl.msc y haga clic en OK.

3. En la Consola de plantilla de certificado, en Nombre de visualización de la plantilla, haga clic con el botón derecho en Web Server y haga clic en Duplicar plantilla.

4. En la ventana Plantilla duplicada, seleccione Windows Server 2003 Enterprise para compatibilidad con versiones anteriores.

Nota: Si tiene un nivel de cifrado superior a SHA1, seleccione Windows Server 2008 Enterprise.

5. Haga clic en la pestaña General.

6. En el campo Nombre de visualización de la plantilla, ingrese vSphere 6.x como el nombre de la nueva plantilla.

7. Haga clic en la pestaña Extensiones.

8. Seleccione las políticas de la aplicación y haga clic en Editar.

9. Seleccione Server Authentication y haga clic en Remove, luego en OK.

Nota: Si existe Client Authentication, elimine esto de las Application Policies también.

10. Seleccione Key Usage y haga clic en Editar.

11. Seleccione la opción Signature is proof of origin (nonrepudiation). Deje todas las demás opciones como predeterminadas.

12. Haga clic en OK.

13. Haga clic en la pestaña Subject Name.

14. Asegúrese de que la opción Supply in the request esté seleccionada.

15. Haga clic en OK para guardar la plantilla.

16. Proceda a la sección Adding a new template to certificate templates para que la plantilla de certificado recién creada esté disponible.

PASO 2: Generar los Request Certificate para el vCenter Server

Debido a que vamos a necesitar un repositorio para alojar los archivos de Certificate Signing Request (.CSR) y el Private Key, necesitamos ingresar al appliance a través de la herramienta libre WINSCP con usuario root, para crear uno en la carpeta temporal. Este paso no es necesario y puede definirse directamente el destino como /tmp o cualquier otro directorio con permisos de escritura dentro del appliance. Sin embargo, para tener un mejor orden, lo vamos a crear.

Como configuración predeterminada vCenter o PSC Appliances, no permite la conexión remota de WinSCP, por lo que es necesario habilitarlo de la siguiente forma:

1. Inicie una conexión SSH al dispositivo vCenter Server.

2. Proporcione el nombre de usuario y la contraseña del usuario root cuando se le solicite.

3. Ejecute este comando para habilitar el shell Bash:

shell.set –enable True

4. Ejecute este comando para acceder al shell Bash:

Shell

5. En el shell Bash, ejecute este comando para cambiar el shell predeterminado a Bash:

Chsh -s /bin/bash root

Nota: Los pasos anteriormente mencionados corresponden al VMware KB Error when uploading files to vCenter Server Appliance using WinSCP (2107727).

Ahora ya podrá realizar una conexión remota con WinSCP. Una vez inicie sesión vaya al directorio raíz, después nos muévase hasta el directorio /tmp y haga click en el icono de nuevo directorio para crear la carpeta Cert, en la que posteriormente guardaremos y cargaremos nuestros archivos asociados a los certificados.

Nota: Si cuenta con un despliegue de vCenter Server con un PSC Embebido, habrá un certificado de Machine SSL. Sin embargo, Si tiene un vCenter Server con un PSC externo, cada máquina (PSC y vCenter) tendrá su propio certificado Machine SSL. Por lo tanto, debe realizar esta tarea en cada máquina.

6. Para reemplazar el certificado de Machine SSL con el certificado de CA personalizado:

Inicie el vSphere 6.x Certificate Manager:

Para vCenter Server 6.x Appliance:

/usr/lib/vmware-vmca/bin/certificate-manager

Para vCenter Server 6.x Windows:

C:\Archivos de programa\VMware\vCenter Server\vmcad\certificate-manager

7. Seleccione la opción 1 (Reemplazar certificado SSL de máquina con certificado personalizado)

8. Proporcione la contraseña de administrator@vsphere.local cuando se le solicite

9. Seleccione la Opción 1 (Generate Certificate Signing Request(s) and Key(s) for Machine SSL certificate)

10. Ingrese el directorio en el que desea guardar el Certificate Signing Request (solicitud de firma de certificado con extensión. CSR) y el Private Key (clave privada). Para este caso se utilizará el directorio creado anteriormente /tmp/Cert

A continuación, debe seguir un asistente que le preguntará los datos asociados a su compañía para poder crear certificados customizados.

Para este caso de laboratorio se utilizarán los siguientes datos como ejemplo:

Country: CO

Name: vcenter.lab.local

Organization: Lab

OrgUnit: Tecnologia

State: Cundinamarca

Locality: Bogota

IPAddress (optional):

Email: emailtest@lab.local

Hostname: vcenter.lab.local

VMCA Name: vcenter.lab.local

A diferencia de vSphere 6.0 Update 3, en vSphere 6.5 y versiones siguientes aparecerá el siguiente aviso:

Ingrese el valor correcto para VMCA ‘Nombre’:

Este valor es el FQDN de la máquina en la que se ejecuta la configuración del certificado, para este caso es el FQDN del vCenter Server Appliance.

Los archivos creados en el directorio /tmp/Cert tendrán los nombres vmca_issued_csr.csr y vmca_issued_key.key.

Descárguelos localmente con la Opción de Transferencia «Texto» para evitar que se agreguen caracteres al final del archivo.

PASO 3: Obtención de certificados de vSphere de una entidad emisora de certificados de Microsoft

1. Proporcione el vmca_issued_csr.csr a su autoridad de certificación para generar un certificado SSL de máquina, asígnele el nombre machine_name_ssl.cer. Para obtener más información, consulte Obtaining vSphere certificates from a Microsoft Certificate Authority (2112014).

2. Inicie sesión en la interfaz web de la autoridad certificadora de CA de Microsoft. Por defecto, es http: // servidor CA_FQDN / CertSrv /.

3. Haga clic en el enlace Request a certificate (.csr ).

4. Haga clic en advanced certificate request.

5. Haga clic en Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file, or submit a renewal request by using a base-64-encoded PKCS #7 file.

6. Abra la solicitud de certificado descargada anteriormente vmca_issued_csr.csr en un editor de texto sin formato y copie desde —–BEGIN CERTIFICATE REQUEST—– hasta —–END CERTIFICATE REQUEST—–, sin que queden espacios al final y péguelo en el cuadro Saved Request.

7. Seleccione la plantilla de certificado creada en pasos en el PASO 1, vSphere 6.5.

8. Haga clic en Submit para enviar la solicitud.

9. Haga clic en Base 64 encoded en la pantalla de Certificado emitido.

10. Haga clic en el enlace Descargar certificado.

Guarde el certificado como con el nombre que desee, para este caso será vspherelab.cer en un directorio de su equipo puede ser C:\Certs\

11. Vuelva a la página de inicio del servidor de certificados y haga clic en Descargar un certificado de CA, cadena de certificados o CRL.

12. Seleccione la opción Base 64.

13. Haga clic en el enlace de la cadena Descargar certificado de CA.

14. Guarde la cadena de certificados como cachainlab.p7b en la carpeta c:\Certs de su equipo.

15. Haga doble clic en el archivo cachainlab.p7b para abrirlo en el Administrador de certificados.

16. Navegue a C: \Certs\cachainlab.p7b> Certificados.

Por lo general las empresas que utilizan Entidades Certificadoras, tiene por lo menos una Enterprise Root CA Standalone y una o varias CA Subordinadas. En este caso se observan efectivamente dos.

17. Haga clic con el botón derecho en cada uno de los certificados listados y haga clic en Todas las acciones> Exportar.

18. Haga clic en Siguiente.

19. Seleccione X.509 codificado Base-64 (.CER), y luego haga clic en Siguiente.

20. Si tiene más de una entidad certificadora Subordinada, realice los pasos para exportar, en cada uno de los certificados listados, expórtelos y guárdelos con un nombre que diferencie las subordinadas de la Root, como por ejemplo: C: \certs\interm64-1.cer, C:\certs\interm64-2.cer y C:\certs\Root64.cer.

Para este caso se han elegido los nombres SubCA.cer para la Entidad CA Subordinada y RootCA.cer para la principal.

PASO 4: Crear cadena de certificados

Una de los pasos que podría llegar a confundirnos es la creación de la cadena cuando en la compañía existen más de una CA, es decir una o varias subordinadas de la Root.

Para este caso se debe crear un nuevo certificado que denominaremos RootChain.cer y el cual contendrá la información tanto de la principal como de su subordinada(s) teniendo en cuenta el siguiente orden don de Intermediate son las CA Subordinadas y Root es la Principal:

1. Realice una copia del certificado exportado en el paso anterior para la CA Root y cámbiele el nombre a RootChain.cer

2. Abra el archivo creado RootChain.cer con un editor de texto sin formato

3. También abra el archivo exportado para SubCA.cer con un editor de texto sin formato y copie el contenido desde —–BEGIN CERTIFICATE REQUEST—– hasta —–END CERTIFICATE REQUEST—–, sin que queden espacios al final.

4. Vaya a la ventana del RootChain.cer abierto anteriormente en el editor de texto y pegue el contenido justo encima de —–BEGIN CERTIFICATE REQUEST—–

Recuerde que si tiene más de una CA Subordinada se debe copiar el contenido de cada una de ellas dentro del certificado RootChain.cer respetando el orden ya indicado.

5. Haga click en Archivo -> Guardar y déjelo abierto para posterior uso

6. Una vez creada la cadena RootChain.cer se debe adicionar el contenido de este archivo al certificado emitido por la CA para nuestro vCenter Server Appliance.

Para esto cree una copia del certificado de vCenter obtenido de la CA y cambie el nombre para identificarlo del original, por ejemplo vspherelabfull.cer

7. Vuelva a la ventana de RootChain.cer en el editor de texto y copie todo el contenido del archivo

8. Abra el archivo creado vspherelabfull.cer con un editor de texto sin formato y pegue el contenido del certificado RootChain.cer creado anteriormente, justo debajo de la línea —–END CERTIFICATE REQUEST—– del certificado customizado de vCenter Server.

9. Haga click en Archivo -> Guardar

PASO 5: Importar Certificados Customizados

Ya estamos listos para importar, los certificados al vCenter y ahora se deben cargar los archivos RootChain.cer y vspherelabfull.cer al directorio temporal /tmp/Cert del vCenter Server Appliance a través del WinSCP.

1. Vuelva a la sesión realizada hacia el vCenter Server con el WinSCP

2. Cargue los archivos RootChain.cer y vspherelabfull.cer al directorio temporal /tmp/Cert

Nota: Utilice la Opción de Transferencia «Texto» para evitar adicionar caracteres a los archivos

3. Regrese al vSphere 6.x Certificate Manager y seleccione la Opción 1 (Continue to importing Custom certificate(s) and key(s) for Machine SSL certificate).

4. Proporcione la ruta completa a vspherelabfull.cer y vmca_issued_key.key y del certificado RootChain.cer

5. Responda Yes (Y) para continuar la operación

6. Espere a que se realice el proceso. Esto puede tardar varios minutos, pero puede ver como se actualizan algunos servicios

7. Abra Internet Explorer o Google Chrome, si los tenía abiertos ciérrelos y vuélvalos a abrir. A continuación, digite el FQDN del vCenter y observará que ya no aparece el error de certificado y muestra el sitio como seguro.

Vista desde Internet Explorer