Combinar archivos AVHDX en un único VHDX

Con equipos virtualizados mediante Hyper-V es posible realizar instántaneas / puntos de control / checkpoints de un estado completo de la máquina virtual. Esta posiblidad nos permite jugar en el tiempo con el estado de la máquina, realizar copias de seguridad, diferenciales... todas las ventajas de la virtualización.

En ocaciones es posible que el espacio ocupado por todos estos movimientos empieza a quedar pequeño, pese a eliminar puntos de control obsoletos no siempre se realiza la acción correspondiente en los ficheros de disco duro, creandose archivos diferenciales:

Lo primero que buscamos es el disco que queremos combinar, para ello desde la configuración de la máquina virtual tenemos que apunta a un fichero AVHDX en lugar de un VHDX pese a no tener puntos de control en activo:

 

Este es el último punto de control que utiliza, a partir de aquí debemos navegar pulsando en el botón "Inspeccionar" para conocer el siguiente fichero padre, de esta manera tendremos el árbol correcto de los discos. Es importante NO UTILIZAR la fecha de modificación de los ficheros AVHDX para establecer el orden de combinación, dependerá del uso que hayamos tenido del árbol de puntos de control que coincida o no con el real:

Una vez aclarado el orden, dependiendo de la versión de Hyper-V podremos hacerlos con la máquina encendida o apagada. Buscaremos la opción de "Editar disco...". Seleccionando desde el primer nodo (el que apunta directamente nuestra máquina virtual) y los siguientes EN ORDEN:

La opción de "Combinar" solo nos aparece al seleccionar un archivo diferencial AVHDX, a partir de entonces seguiremos la misma operación de manera secuencial sobre el resto de archivos.

 

Una vez finalizado el proceso, recuerda apuntar al nuevo último punto de combinación que hayas dejado.

Revisa la configuración de replicación si esta activada con otra máquina antes de proceder con la combinación de discos.


Creación de PFX a partir de clave pública y privada

En entornos Windows la encapsulación de certificado en ocasiones suele ser algo complicada en algunos contextos. En este en concreto, plantemos unir un certificado CER/CRT (es lo mismo) recibido con la clave pública con otro archivo con las claves privadas en un único archivo PFX

En ocasiones se utilizan diferentes extensiones para los certificados, lo primero es identificar cada fichero, podemos abrirlos con bloc de notas y reconocer las cabeceras:

Certificado público (micertificado.cer):

-----BEGIN CERTIFICATE-----
MIIFszCCBJugAwIBAgIQCn/RxfJgDNYmoD7jyCSfGjANBgkqhkiG9w0BAQsFADBe
...BLOQUE DE TEXTO...
KPYJupIYuFSDoL/C77KF9zntk1gft5o=
-----END CERTIFICATE-----

Clave privada asociada (clave.key):

-----BEGIN RSA PRIVATE KEY-----
MIIEpQIBAAKCAQEAzHvXgg7VbCHXDSihNDx3q5GrNhDhnw2IAU/z259t6wi+gTjv
..BLOQUE DE TEXTO...
PEMYrxRR46jUuQqNpqYqYk5Trg6dtjKf6/82caESpr1vYG0uErwXTow=
-----END RSA PRIVATE KEY-----

Necesitaremos varias herramientas:

  1. pvk2pfx en SDK Windows, en este caso de Windows 10 pero esta disponible para otras versiones
  2. Utilidad PVK de Stephen N Henson [mirror 1]

A partir de nuestro archivo de claves privadas (clave.key) generaremos un archivo PVK ejecutando (C:\Program Files (x86)\Windows Kits\10\bin\x64\):

PVK.exe -in clave.key -topvk -out misclaves.pvk -strong

Nos pedirá que introduzcamos una contraseña. Con los dos ficheros misclaves.pvk + micertificado.cer ejecturemos contra la herramienta del SDK asegurando las rutas de acceso:

pvk2pfx.exe /pvk misclaves.pvk /spc micertificado.cer /pfx MiCertificadoCompleto.pfx

 

Ya tendremos unificado en un fichero toda la información.

 

Manual Pvk2Pfx

Transferir funciones FSMO

A la hora de incorporar nuevos servidores en un directorio activo, debemos revisar que funciones queremos transferir antes de dar de baja alguno. En entornos sencillos en los que un equipo es el único encargado de todos ellos debemos:

  1. Añadir el nuevo servidor al dominio existente
  2. Instalar y configurar los roles de Directorio Activo
  3. Migrar las funciones: RID, Controlador principal de dominio e infraestructura, de forma gráfica podemos hacerlo desde la gestión de "Usuarios y equipos de Active Directory". Pulsaremos sobre "Cambiar" en cada una de las tres pestañas, debemos hacerlo desde el sistema operativo más reciente:



  4. Consultamos las funciones FSMO con el comando: "netdom query fsmo" veremos que todavía queda por transferir "Maestro de esquema". Para realizado desde la interfaz gráfica ejecutamos desde la línea de comandos con permisos de administrador (dependerá de la versión de Windows):
    regsvr32 schmmgmt.dll
  5. Iniciamos "mmc" y añadimos el complemento "Esquema de Active Directory" pulsamos con el botón derecho sobre el nodo y seleccionamos la opción de "Cambiar el controlador de dominio de Active Directory…" y/o "Maestro de operaciones" seleccionado "Cambiar" como en pasos anteriores.

Plesk + Dotnetnuke + Let's Encrypt = CMS + SSL

Algunos gestores de contenidos, como en este caso Dotnetnuke, tienen reglas propias de redirección que pueden interferir a la hora de instalar certificados gratuitos de Let's Encrypt desde panel de control Plesk. Existen varias opciones, pero una de la más sencilla para este problema concreto es cambiar el tratamiento de las redirecciones del CMS:

    <friendlyUrl defaultProvider="DNNFriendlyUrl">
      <providers>
        <clear />
        <add name="DNNFriendlyUrl" type="DotNetNuke.Services.Url.FriendlyUrl.DNNFriendlyUrlProvider, DotNetNuke.HttpModules" includePageName="true" regexMatch="[^a-zA-Z0-9 _-]" urlFormat="humanfriendly" />
      </providers>
    </friendlyUrl>

Sustituyendo "advanced" por "humandfriendly", lo que dejará el sitio añadiendo la extensión .aspx de nuevo generando el directorio "\.well-known\acme-challenge\" que incluye la descarga del ficheros sin extensión como texto plano en su propio web.config

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <staticContent>
            <remove fileExtension="." />
            <mimeMap fileExtension="." mimeType="text/plain" />
        </staticContent>
    </system.webServer>
</configuration>

Ahora podemos volver a dejar la redirección como "advanced". Si, la otra opción es añadir el fichero anterior en el directorio indicado, Let's Encrypt creará una petición de comprobación del tipo:

http://midominio.es/.well-known/acme-challenge/8-TsVgjMp5v3BRkUVk4zwdiCVDlSkDaf...b

A partir de versiones más modernas, podemos añadir una configuración específica de URLs amigables desde la configuración Host en Sistemas > Configuración del sisstema > Configuración Avanzada > Configuración de URLs amigables

 

Si pese a ello sigue sin poder acceder a la ruta, puedes deshabilitar temporalmente desde Plesk, el soporte para .NET y renovar manualmente.

CRL: Lista de revocación de certificados publicada en servidor externo

Dependiendo de la complejidad de la infraestructura PKI de la organización, podemos desde la entidad de certificación publicar automáticamente en servidores externos, en este caso IIS, los datos.

Para ello compartimos una carpeta en el equipo con el servidor web asignando permisos de acceso y NTFS sobre el nombre de la máquina.

Añadimos en la publicación de la CA una nueva ruta hacia nuestro servidor local, el nombre del fichero y la ruta final debe ser el mismo que el expuesto externamente para el CRL:

file://\\servidorLocal\CA\<nombre de CA><sufijo de nombre de lista CRL><diferencias entre listas CRL permitidas>.crl

En nuestra entidad de certificación tendremos de la siguiente manera la publicación interna y el acceso de consulta externo, por ejemplo:

 

Para asegurarnos que el servidor es capaz de alcanzar las rutas de publicación, con el botón derecho sobre "Certificados revocados" pulsamos "Todas las tareas" -> "Publicar"

 

Comprobar las listas de revocación desde equipo externo

Existe la alternativa de utilizar OCSP para la comprobación de las listas, lo veremos en otro momento.