Migrar una Enterprise Root CA de SHA‑1 a SHA‑256 en Windows Server

La transición de SHA‑1 a SHA‑256 en una Enterprise Root CA es una medida crucial para mantener la confianza de la infraestructura de clave pública (PKI) corporativa y cumplir con los estándares de seguridad modernos. A continuación encontrarás una guía detallada, paso a paso, que cubre desde la fase de planificación hasta la supervisión posterior, con recomendaciones prácticas, comandos y consideraciones de negocio.

Índice

Requisitos previos y evaluación de compatibilidad

Antes de modificar cualquier parámetro de la autoridad certificadora (CA), realiza un inventario exhaustivo de todos los sistemas y dispositivos que confían en la raíz empresarial.

Inventario detallado —Enumera servidores, estaciones de trabajo, dispositivos móviles, aplicaciones internas, impresoras, controladores de dominio, sistemas de automatización industrial y elementos de red (firewalls, balanceadores).
Validación de compatibilidad —Verifica que cada elemento del inventario tolere certificados firmados con SHA‑256. La mayoría de los sistemas que corren versiones iguales o posteriores a Windows Vista/Server 2008 R2, Android 4.1, iOS 5 y macOS 10.6 ya lo soportan de forma nativa.
Identificación de excepciones —Registra dispositivos heredados (OT/IoT, impresoras de más de 10 años, sistemas embebidos) que solo aceptan SHA‑1. Establece un plan de sustitución o mantenimiento aislado para ellos.
Actualizaciones de software —Asegúrate de que todos los hosts Windows tengan instaladas las actualizaciones de seguridad críticas y KB revocatorias de SHA‑1.

Verificación de la salud de la PKI existente

Trabajar sobre una PKI inestable agrava los riesgos. Comprueba la integridad de la jerarquía:

Inicia pkiView.msc y confirma que todos los certificados (CA, CRL, AIA, OCSP) se muestren como OK.
Ejecuta certutil –verify –urlfetch <certificado> contra varios certificados emitidos para detectar rutas de confianza corruptas o CRL expiradas.
Revisa el Visor de eventos (Application & Services Logs → Microsoft → Windows → CAPI‑2) para encontrar errores de validación de cadena.

Realización de una copia de seguridad completa

Una migración de algoritmo es conceptualmente reversible, pero una falla puede dejar inoperable la emisión de certificados y provocar interrupciones de autenticación. Protege tu capacidad de recuperación:

Elemento	Método de respaldo	Descripción
Base de datos de la CA	`certutil –backupDB <ruta>`	Incluye certificados emitidos y estado de la CRL.
Claves privadas	`certutil –backupKey <ruta>`	Exporta la clave de la CA en formato PFX protegido.
Configuración	Asistente gráfico o `certutil –backup`	Captura plantillas, extensiones y parámetros del servicio.

Guarda la copia offline (encriptada y fuera del dominio), documenta el punto de restauración y comprueba que el procedimiento de restore funciona en un entorno aislado.

Configuración de la CA para usar SHA‑256

Este ajuste solo afectará a los certificados emitidos tras reiniciar el servicio CertSvc; los certificados vigentes con SHA‑1 permanecerán válidos hasta expirar.

certutil –setreg&nbsp;ca\csp\CNGHashAlgorithm&nbsp;SHA256
net stop certsvc
net start certsvc

Confirma la modificación con certutil –getreg ca\csp\CNGHashAlgorithm; debe devolver SHA256.

Renovación del certificado de la autoridad certificadora

Para emitir nuevos certificados con SHA‑256, la propia CA debe poseer un certificado raíz firmado con ese algoritmo.

Abre la consola Certification Authority.
Haz clic derecho sobre el nombre de la CA → All Tasks → Renew CA Certificate.
Elige Same key si deseas mantener el par de claves actual (el escenario recomendado para una CA de primer nivel interna). Si seleccionas New key, estarás creando realmente una nueva identidad de CA, con la consecuencia de redistribuir la raíz y revocar la antigua.
El asistente genera y habilita el certificado raíz SHA‑256 y emite una nueva CRL.

Tras la renovación, valida que la nueva CRL esté firmada con SHA‑256 mediante certutil –verifyCRL <crlfile>.

Distribución de la nueva raíz de confianza

Sin una distribución correcta, los equipos seguirán confiando en la raíz SHA‑1 antigua o no confiarán en ninguna, produciendo errores de TLS o de inicio de sesión.

Dominio Active Directory —La replicación de Group Policy inserta automáticamente la raíz actualizada en «Trusted Root Certification Authorities». La propagación puede tardar hasta el siguiente reinicio de los controladores de dominio y la actualización de GPO en los clientes.
Dispositivos fuera del dominio —Exporta el certificado raíz en formato DER y distribúyelo por GPO a dominios de confianza, mediante MDM (Intune, Jamf, MobileIron), scripts de inicio (PowerShell), o mediante utilidades de despliegue de certificados en contenedores Docker/Kubernetes.
Infraestructura de red —Importa manualmente la raíz en firewalls, balanceadores, controladores WLAN o appliances de VPN que posean su propio almacén de confianza.
Ambientes OT/IoT —Si el firmware no permite SHA‑256, considera colocar dispositivos heredados detrás de una pasarela TLS que haga downgrade a SHA‑1 únicamente en el segmento aislado.

Pruebas piloto y validación

Implementa una zona de pruebas que refleje el mayor número posible de escenarios de producción:

Emite certificados de servidor, usuario y dispositivo y pruébalos con openssl s_client –connect y con certutil –pulse.
Evalúa cadenas de autenticación Kerberos, RDP, VPN y 802.1X.
Supervisa los registros del cliente (Event ID 36887, 36882) en el visor de eventos para detectar fallos de confianza.
Comprueba que los dispositivos obtengan la nueva CRL; un desfase en su publicación puede causar fallos intermitentes.

Supervisión continua y plan de reversión

Aunque la migración sea exitosa, sigue una estrategia de vigilancia activa hasta confirmar la estabilidad total.

Logs de la CA —Activa la auditoría de Certificate Services y revisa eventos de emisión (Event ID 4886 – 4888).
Monitoreo de red —Utiliza NetFlow o WireShark para buscar sesiones TLS que se caigan por alertas handshake_failure.
Métricas de endpoint —Los agentes EDR/AV modernos identifican discrepancias de confianza. Para Windows Defender for Endpoint, monitorea la alerta Deprecated hash algorithm.
Reversión planificada —Mantén el backup inicial hasta cumplir un periodo de gracia (por ejemplo, 30 días). El plan de rollback implica:
1. Detener CertSvc.
2. Restaurar la base de datos, claves y configuración.
3. Publicar CRL de emergencia revocando el certificado SHA‑256 si se emitió.
4. Forzar actualización de directivas de grupo (gpupdate /force).

Impacto en certificados existentes

Los certificados firmados con SHA‑1 siguen siendo válidos hasta su fecha de expiración. El algoritmo de firma se fija en el momento de emisión, y no se «re‑firma» retroactivamente. No obstante, conviene:

Planificar una renovación paulatina de certificados que expiran en menos de 12 meses; aprovecha para actualizar plantillas y aumentar el tamaño de clave a 3072‑bit o 4096‑bit si la política lo permite.
Monitorizar los clientes de navegador (Edge, Chrome, Firefox) que muestren advertencias «Certificate signed with deprecated algorithm» y avisar a los administradores de servicio.

Buenas prácticas adicionales

Longitud de clave —Aunque no es obligatorio cambiar la clave con el algoritmo, la recomendaciones NIST sugieren 3072 bits para RSA a partir de 2030. Si optas por New key, aprovecha para elevar la longitud.
CRL y OCSP —Asegura que ambas respuestas estén firmadas con SHA‑256. Ajusta la caducidad de la CRL para minimizar ventanas de exposición.
Documentación —Actualiza el CPS (Certification Practice Statement) incluyendo el racional de migrar a SHA‑256 y la fecha efectiva.
Hardening del servidor CA —Deshabilita algoritmos inseguros (MD5, DES, RC4) en HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Hashes y Ciphers.
Automatización —Integra Infrastructure as Code (Ansible, DSC, Chef) para mantener la configuración homogénea en ambientes DevOps.

Preguntas frecuentes

¿Hay que revocar el certificado raíz SHA‑1 antiguo?

No es estrictamente necesario si el entorno confía exclusivamente en SHA‑256 tras la migración, pero revocarlo reduce el riesgo de uso indebido. Si lo haces, distribuye una CRL extendida y verifica que ningún dispositivo dependa de esa raíz.

¿Se puede pasar directamente a SHA‑384 o SHA‑512?

Windows Server 2012 R2 y versiones posteriores soportan SHA‑384/512, pero algunos clientes (especialmente embedded) solo toleran SHA‑256. Evalúa la compatibilidad antes de elegir.

¿Qué ocurre con los certificados de firma de código?

La renovación de la CA no afecta a los binarios firmados previamente. Sin embargo, al firmar nuevas versiones, el timestamp también deberá usar SHA‑256 para evitar alertas de SmartScreen.

Conclusión

Cambiar de SHA‑1 a SHA‑256 en una Enterprise Root CA es una operación crítica pero alcanzable con una planificación meticulosa, buenas copias de seguridad y pruebas piloto exhaustivas. El resultado es una PKI más robusta, alineada con los estándares de la industria y libre de advertencias de seguridad.