Resumen rápido: si necesitas llevar tu Autoridad de Certificación de Active Directory Certificate Services desde un servidor antiguo a uno moderno, la forma profesional y segura es una migración paralela “side‑by‑side”, reutilizando el mismo nombre de la CA y su clave privada. El nombre del servidor puede cambiar; el de la CA no.
Por qué evitar la actualización en el lugar
Una actualización “in‑place” prolonga el tiempo de indisponibilidad, complica el rollback y hereda arrastres de configuración y dependencias. La migración paralela te permite preparar un servidor nuevo, probar, revertir si es necesario y garantizar continuidad de emisión sin sorpresas. Además, separar el nombre del servidor del nombre de la CA elimina ataduras innecesarias: lo crítico es conservar la identidad de la CA (certificado y clave), no el hostname del equipo.
Estrategia recomendada de alto nivel
La estrategia óptima es montar un servidor nuevo con el rol de AD CS, instalar la CA con el certificado y la clave existentes, restaurar base de datos y CRLs, replicar extensiones CDP/AIA y validar. Cuando todo funcione, desinstalar el rol en el servidor anterior.
- Preparar y respaldar: certificado y clave de la CA en PFX, base de datos de certificados y CRLs, configuración del registro, inventario de CDP/AIA/OCSP.
- Provisionar servidor nuevo: unir al dominio e instalar AD CS y servicios asociados.
- Instalar la CA con identidad existente: seleccionar “usar certificado y clave privados existentes”.
- Restaurar datos: base de datos, CRLs y parámetros del registro.
- Garantizar rutas CDP/AIA antiguas: publicar en las ubicaciones históricas o redirigirlas vía alias.
- Puesta en marcha: publicar CRL, iniciar servicio y validar en clientes.
- Verificación: autoinscripción, renovación, OCSP y eventos de AD CS.
- Retiro del equipo anterior: planificado y sin prisa.
Decisiones previas y consideraciones
- Identidad inmutable de la CA: el nombre de la CA no debe cambiar. Cambiarlo equivale a una CA nueva y obligaría a reemitir certificados.
- Nombre del servidor: puede ser diferente. Lo importante es mantener accesibles las rutas CDP/AIA históricas (mediante publicación múltiple o alias DNS/HTTP).
- Tipo de CA: Enterprise o Standalone; subordinada u offline root. Ajusta los pasos de publicación en AD según corresponda.
- Proveedor criptográfico: valida si la clave de la CA está en CSP clásico o KSP moderno o en HSM; instala previamente los drivers/proveedores necesarios.
- Algoritmos y compatibilidad: la migración no cambia el algoritmo de firma de la CA. Si quieres modernizar (por ejemplo, a SHA‑256 y RSA más robusto) eso requiere una operación adicional planificada.
Inventario y respaldo mínimos
Antes de tocar nada, produce un inventario completo. Esta tabla resume lo imprescindible:
| Elemento | Qué respaldar | Herramienta o ruta | Notas |
|---|---|---|---|
| Certificado y clave de la CA | PFX con clave privada, protegido por contraseña | MMC o certutil -backupkey | La pieza más crítica. Verifica el PFX con importación de prueba. |
| Base de datos de la CA | EDB y logs | certutil -backupdb o copia del directorio de base de datos | Comprueba las rutas con certutil -getreg. |
| Listas de revocación | CRL y delta CRL recientes | Carpeta de publicación (FILE/HTTP) | Indispensable para validez de certificados en producción. |
| Configuración de la CA | Registro de AD CS (rama de la CA) | reg export | Incluye extensiones CDP/AIA y permisos. |
| Rutas CDP/AIA | Listado con URL de publicación efectivas | MMC de la CA y registro | Replícalas exactamente en el servidor nuevo. |
| OCSP | Configuración del Respondedor | Consola de OCSP | Actualiza el vínculo a la CA nueva tras la migración. |
| Plantillas y GPO | Documentación del uso actual | AD y directivas de grupo | Las plantillas residen en AD, no en el servidor de la CA. |
Comandos útiles para el respaldo
# Ejecutar en el servidor de la CA antigua con privilegios elevados
1) Confirmar rutas de base de datos y logs
certutil -getreg ca\DBDirectory
certutil -getreg ca\LogDirectory
2) Respaldar base de datos
mkdir C:\Backup\CA-db -Force
certutil -backupdb C:\Backup\CA-db
3) Respaldar clave/certificado de la CA a PFX (se solicitará contraseña)
mkdir C:\Backup\CA-key -Force
certutil -backupkey C:\Backup\CA-key
4) Respaldar configuración del registro
reg export "HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration" C:\Backup\CA-registry.reg /y
5) Copiar CRL y delta CRL
Ajusta la ruta a tu carpeta de publicación
robocopy "C:\Windows\System32\CertSrv\CertEnroll" "C:\Backup\CA-crl" .cr Provisionamiento del servidor destino
Prepara un servidor limpio unido al mismo dominio. Siempre que puedas, utiliza instalación mínima. Asegúrate de que las cuentas de servicio, puertos, agentes antivirus y exclusiones estén definidos y que el servidor tenga conectividad hacia las ubicaciones de publicación de CRLs y AIAs.
# Instalar el rol y las herramientas de administración
Install-WindowsFeature ADCS-Cert-Authority -IncludeManagementTools
Opcional: servicios web de inscripción si ya se usaban
Install-WindowsFeature ADCS-Enroll-Web-Pol, ADCS-Enroll-Web-Svc
Instalación de la CA reutilizando identidad
La clave del éxito es instalar la CA usando el certificado y la clave privada existentes y confirmando que el nombre de la CA coincide carácter por carácter con el anterior.
- Importa el PFX de la CA al almacén de equipo local (Personal) y marca la clave como exportable solo si así lo estaba antes.
- Inicia el asistente de AD CS y elige Usar un certificado y clave privada existentes.
- Selecciona el certificado de la CA y verifica que el Nombre de la CA coincide exactamente con el anterior.
- Completa la instalación, pero no inicies aún la emisión hasta restaurar la base de datos.
Si prefieres automatizar:
# Importar el PFX previamente respaldado
Se solicitará la contraseña
Import-PfxCertificate -FilePath C:\Backup\CA-key\CA_Backup.p12 `
-CertStoreLocation Cert:\LocalMachine\My
Instalar la CA usando claves existentes
Ajusta el tipo de CA según tu entorno (EnterpriseRootCA, EnterpriseSubordinateCA, StandaloneRootCA, StandaloneSubordinateCA)
Install-AdcsCertificationAuthority ` -UseExistingKeys`
-CAType EnterpriseSubordinateCA \`
-CACommonName "NOMBRE EXACTO DE LA CA" Restauración de base de datos y CRLs
- Detén el servicio de la CA en el servidor nuevo.
- Restaura la base de datos y los logs hacia las rutas configuradas.
- Copia las CRLs respaldadas a la carpeta de publicación.
# Detener servicio
net stop certsvc
Restaurar base de datos desde el backup
certutil -restoredb C:\Backup\CA-db
Copiar CRLs
robocopy C:\Backup\CA-crl "C:\Windows\System32\CertSrv\CertEnroll" .cr
(Opcional) Restaura parámetros de registro si necesitas reproducir extensiones exactas
reg import C:\Backup\CA-registry.reg
Arrancar servicio
net start certsvc
Publicar CRL y delta CRL
certutil -crl
Configuración de extensiones CDP y AIA
Las extensiones de puntos de distribución (CDP) y de acceso a información de la autoridad (AIA) deben quedar idénticas a las del servidor anterior para garantizar que los certificados emitidos en el pasado sigan validando. Lo más seguro es:
- Clonar la configuración anterior: compara la consola de la CA y la rama del registro exportada y reproduce exactamente las rutas, marcando las casillas equivalentes (publicar en AD, incluir en certificados emitidos, etc.).
- No cambies placeholders ni variables presentes en las rutas heredadas; limítate a replicarlas.
Buenas prácticas:
- Mantén al menos una ruta HTTP para CDP y otra para AIA; LDAP es valioso dentro del dominio.
- Publica la CRL en todas las rutas marcadas “Incluir en la CRL publicada” y “Incluir en la extensión CDP de los certificados emitidos” donde corresponda.
- Si existe Respondedor OCSP, valida que el acceso a la CA y al almacén de revocaciones esté operativo y que el firmante OCSP sea válido.
Compatibilidad con rutas históricas
Muchos certificados emitidos contienen URL que apuntan a nombres antiguos de host o rutas específicas. Tienes tres opciones para garantizar su validez tras la migración:
- Mantener el recurso de publicación anterior (share, sitio web, carpeta) y publicar desde el nuevo servidor hacia esa misma ubicación de red.
- Usar alias DNS/HTTP que resuelvan al nuevo servidor, preservando el FQDN histórico (por ejemplo, pki.empresa.local).
- Replicar con DFS o trabajos programados que copien automáticamente CRLs y certificados de la CA hacia los directorios “legados”.
# Ejemplo de publicación con copia a múltiples destinos
$origen = "C:\Windows\System32\CertSrv\CertEnroll"
$destinos = @(
"\\filesrv\pki\crl",
"D:\InetPub\wwwroot\pki\crl"
)
foreach ($d in $destinos) { robocopy $origen $d .cr /Z /R:2 /W:2 }
Publicación en directorio
En CA de empresa, conviene republicar certificados de la CA y CRLs en Active Directory para que los clientes los localicen vía LDAP:
# Publicar certificado de la CA en AD (AIA)
certutil -dspublish -f "C:\Windows\System32\CertSrv\CertEnroll\NombreCA.cer"
Publicar CRL en AD (CDP)
certutil -dspublish -f "C:\Windows\System32\CertSrv\CertEnroll\NombreCA.crl"
Asegurar presencia en el contenedor NTAuth para inscripción basada en certificados
certutil -dspublish -f "C:\Windows\System32\CertSrv\CertEnroll\NombreCA.cer" NTAuthCA Puesta en marcha y validaciones clave
Con el servicio activo y rutas de publicación confirmadas, realiza una ronda de pruebas exhaustiva:
- Publicación de CRL: fuerza publicación y comprueba fechas de siguiente actualización.
- Cadena de confianza: en un cliente estándar, valida la cadena de un certificado emitido recientemente y de uno antiguo.
- Revocación: revoca un certificado de prueba, publica CRL y verifica que la revocación se detecta con
certutil -url. - Autoinscripción: fuerza actualización de directivas y revisa logs de cliente.
- Respondedor OCSP: comprueba estado y firmante; reemite el certificado del respondedor si es necesario.
# En un cliente
gpupdate /force
certutil -pulse
Probar descarga de CRL y AIA
certutil -url <Rutaaun_certificado.cer>
Retiro seguro del servidor anterior
Una vez verificado todo por algunos días y sin eventos de error, procede a desinstalar el rol de AD CS en el equipo antiguo. Conserva un backup final y documenta el plan de rollback. Mantén el hostname antiguo reservado para evitar confusiones y, si usaste alias, deja el alias activo el tiempo que dure la vida de los certificados que lo referencian.
Escenarios especiales y consejos
- Uso de HSM: instala el software del fabricante, verifica acceso al contenedor de claves y prueba firma antes de instalar AD CS. Exporta una imagen de clave si tu política lo permite; si no, planifica una ventana ampliada para pruebas.
- Root offline: si tu raíz está fuera de línea, no se “migra” como tal con frecuencia. Asegúrate de que el nuevo emisores subordinados sigan apuntando a sus rutas y que la CRL de la raíz esté accesible y vigente. Publica nuevamente en AD/HTTP si se renovó.
- Modernización criptográfica: la migración no reemplaza el certificado de la CA. Si planeas rotarlo (nueva clave), prepara coexistencia de dos cadenas y rutas CDP con sufijos que eviten colisiones; comunica a los equipos de aplicaciones la nueva cadena con anticipación.
- Endurecimiento: aplica listas de control de acceso estrictas en la CA, deshabilita protocolos inseguros, configura auditoría de emisión/revocación, y excluye las rutas de base de datos/CRL del antivirus en tiempo real.
- Registro y monitoreo: centraliza eventos de la CA, alertas por próxima expiración de CRL y fallos de publicación.
Comparativa entre conservar y cambiar el nombre del servidor
| Opción | Ventajas | Riesgos o cuidados | Cuándo elegirla |
|---|---|---|---|
| Nuevo nombre | Permite coexistencia, rollback sencillo, pruebas sin presión | Debes mantener publicación en rutas antiguas o configurar alias | Casi siempre; favorece operaciones seguras |
| Mismo nombre | Puedes simplificar CDP/AIA si todo apunta al hostname | Requiere ventana de corte, riesgo si falla el renombrado, mayor presión | Solo si las rutas no admiten alias y el riesgo es aceptable |
Errores habituales y cómo evitarlos
- Reinstalar generando una clave nueva: rompes la identidad de la CA. Verifica siempre que instalas con el PFX correcto y el nombre idéntico.
- Olvidar las rutas heredadas: certificados antiguos no podrán descargar CRL/AIA. Mantén publicación en ambas rutas durante la transición.
- Publicar CRL con sello desfasado: sincroniza hora y revisa “Next Update”. Automatiza la publicación y copia.
- No republicar en directorio: los clientes del dominio dependerán de HTTP únicamente; republica en AD si la CA es de empresa.
- Permisos de seguridad incompletos: restaura la ACL de la CA desde el registro exportado o reconfigúrala con la consola asegurando operadores, supervisores y gestores de inscripción.
Guía detallada paso a paso
- Auditoría inicial
- Recopila nombre exacto de la CA desde la consola y anótalo literalmente.
- Enumera extensiones CDP/AIA y verifica casillas activas.
- Identifica servicios colaterales: OCSP, servicios web de inscripción, tareas de publicación.
- Respaldo
- Ejecuta los comandos de respaldo y valida el PFX importándolo en un host de laboratorio.
- Guarda copias en ubicación offline y protegida.
- Servidor nuevo listo
- Une al dominio, aplica parches, configura NTP y antivirus.
- Instala el rol y módulos de administración.
- Instalar la CA desde PFX
- Selecciona Usar certificado y clave privados existentes.
- Confirma el nombre de la CA; si no coincide, cancela y corrige.
- Restaurar base de datos
- Detén el servicio, restaura EDB/logs, importa CRLs y arranca.
- Extensiones y publicación
- Reproduce CDP/AIA y habilita publicación HTTP/LDAP/FILE como antes.
- Configura alias o copias hacia rutas heredadas.
- Validaciones
- Publica CRL, emite certificado de prueba, valida revocación, autoinscripción, OCSP.
- Revisa el visor de eventos por advertencias y errores.
- Transición de producción
- Coordina con equipos de aplicaciones críticas.
- Monitorea durante el primer ciclo de renovación relevante.
- Retiro del servidor antiguo
- Desinstala el rol una vez estable; conserva backup final.
Checklist de verificación
| Control | Estado | Evidencia |
|---|---|---|
| Nombre de la CA idéntico | Pendiente/OK | Consola de la CA |
| PFX restaurado | Pendiente/OK | Certificado en almacén LocalMachine\My |
| Base de datos restaurada | Pendiente/OK | certutil -restoredb sin errores |
| CRL publicada | Pendiente/OK | Archivos CRL en HTTP/LDAP/FILE |
| CDP/AIA replicados | Pendiente/OK | Extensiones en consola coinciden |
| Publicación en directorio | Pendiente/OK | certutil -dspublish completado |
| OCSP operativo | Pendiente/OK | Estado saludable y firma válida |
| Autoinscripción validada | Pendiente/OK | Certificados emitidos en clientes |
| Plan de rollback | Pendiente/OK | Procedimiento y backups documentados |
Preguntas frecuentes
¿Puedo cambiar el nombre de la CA durante la migración?
No. Cambiar el nombre de la CA crea una identidad diferente y obliga a reemitir certificados y recalcular confianzas.
¿Es obligatorio mantener el mismo nombre de servidor?
No. Puedes usar un hostname nuevo y es lo recomendable. Asegúrate de que las rutas CDP/AIA históricas sigan resolviendo hacia el nuevo servidor.
¿Se conservarán los números de serie y el contador?
Sí, al restaurar la base de datos de la CA se conserva la continuidad de emisión.
¿Qué pasa con las plantillas de certificados?
Residen en Active Directory; la migración del servidor de la CA no las altera. Aun así, valida permisos de inscripción en la nueva CA.
¿Debo volver a unir aplicaciones al almacén de confianza?
No, si la cadena de la CA no cambia. Revisa únicamente donde existan anclajes explícitos a rutas HTTP o a huellas digitales.
¿Puedo aprovechar para actualizar algoritmos?
No dentro de la misma migración. Planifica una rotación de clave de CA como proyecto aparte, con coexistencia temporal de cadenas y comunicación a interesados.
Plantilla de automatización
Ejemplo de script de orquestación para publicar CRLs automáticamente en múltiples destinos heredados tras cada emisión o ciclo programado:
# Ejecutar en el servidor de la CA nueva
$source = "C:\Windows\System32\CertSrv\CertEnroll"
$targets = @(
"\\fileserver\pki\crl",
"D:\Web\pki\crl",
"\\dfs\pki\crl"
)
Publicar CRL y delta
certutil -crl
Copiar a todos los destinos
foreach (\$t in \$targets) {
New-Item -ItemType Directory -Path \$t -Force | Out-Null
robocopy \$source \$t .cr /MIR /R:2 /W:2
}
Registrar evento sencillo de éxito
Write-EventLog -LogName Application -Source "CertSvc" -EntryType Information -EventId 10001 \`
-Message "CRLs publicadas en destinos heredados" Conclusiones prácticas
Para actualizar sin dolores, evita la actualización en el lugar y apuesta por una migración paralela que reutiliza la identidad de la CA. Mantén idéntico el nombre de la CA, garantiza que las rutas CDP/AIA de siempre siguen activas, restaura base de datos y CRLs, y valida de punta a punta: emisión, cadena y revocación. El nombre del servidor puede cambiar sin problema —y suele ser lo mejor— siempre que la publicación de CRL/AIA esté bien resuelta. Con un buen respaldo, una hoja de pruebas y publicación dual durante la transición, la migración se convierte en una operación controlada y reversible que no obliga a los clientes a cambiar nada.
Resumen de la pregunta
¿Cómo actualizar una CA de un equipo antiguo a uno moderno sin perder configuración ni tener que reconfigurar todo? ¿Conviene conservar el nombre del servidor o migrar a un host con nombre distinto?
Respuesta y solución
No realices una actualización en el lugar. Ejecuta una migración paralela hacia un servidor nuevo, conservando el mismo nombre de la CA. El nombre del servidor puede cambiar; cuida los puntos de distribución (CDP/AIA) y utiliza el certificado y la clave privados existentes de la CA durante la instalación.
Pasos recomendados
- Preparación y respaldo: PFX de la CA, base de datos, CRLs y configuración del registro. Inventario de CDP/AIA y OCSP. Verifica el nombre exacto de la CA.
- Servidor nuevo: Une al dominio e instala AD CS y servicios asociados.
- Instalación con identidad existente: Importa el PFX y confirma el nombre de la CA.
- Restauración: Detén la CA, restaura base de datos/CRLs y replica extensiones.
- Accesibilidad de CDP/AIA: Publica tanto en rutas antiguas como nuevas o usa alias DNS/HTTP.
- Puesta en marcha: Publica CRL y valida emisión, cadena y revocación.
- Verificación posterior: Autoinscripción, renovación y OCSP.
- Retiro: Desinstala el rol en el equipo antiguo cuando todo esté estable.
Decisión sobre el nombre del servidor
- Nuevo nombre de servidor: más seguro y reversible; requiere mantener publicación CDP/AIA heredada o alias.
- Mismo nombre de servidor: simplifica en algunos casos, pero añade complejidad operativa y riesgo en el corte.
Puntos críticos
- El nombre de la CA no cambia.
- Garantiza CDP/AIA heredados durante la transición.
- Instalación con clave/cert existente para evitar una identidad nueva.
- Pruebas previas y ventana de bajo impacto para ejecutar el cambio.